Hacker Newsnew | past | comments | ask | show | jobs | submit | Onavo's commentslogin

They are hardly an exception in that region, it's always been that way.

There were no good options previously. It was either C or C++. Most of the other languages were either fringe or had a GC, or had a pseudo runtime GC (Swift). The culture of Java and C# and Go didn't really support the type of low level optimizations needed, even though you could technically do system programming if you restrict yourself to a specific subset of language and cut yourself off from most of the standard library and ecosystem. Nim was unstable. OCaml had the same issues as Go and Java and C#. You simply did not have any options until Rust came along. Oberon was an academic trinket. The less said about the various lisps and forths the better.

OS and embedded programming require bare metal support and data structures that can run standalone in the absence of an OS and standard library, and the ecosystem must exist to support such a style of programming.

Currently Rust has over 10000 crates that would theoretically work just fine in an kernel environment.

https://crates.io/categories/no-std


Well the newer WiFi standards on 6Ghz support a lot more channels. Not a perfect work around by any means but it does significantly reduce congestion.

Yes, that helps quiet a lot in practice because in most places there's limited "frequency-domain" capacity (i.e. free channels) but plenty of "time-domain" capacity, (i.e. free air-time). So even if you are sharing a channel with 4 other APs and their users, everybody may subjectively feel the network is fast. When chopping up the time domain into nanoseconds there's just a lot of idle time available, even if clients are pulling down files at 600Mbps.

But at a fundamental level, the channel space (~60 across all bands best case) is extremely limited but the potential growth in transmitters is unbounded. It's like a linear hack to an exponential problem. It seems to work at first, but under very high load conditions performance still degrades ever faster until it falls off a cliff. Then there's all sorts of complex dynamic behaviour like the hidden node problem to add to this, but it all boils down to needing air-time and SNR.


> But at a fundamental level, the channel space (~60 across all bands best case) is extremely limited but the potential growth in transmitters is unbounded.

You’re overlooking the spatial dimension: https://en.wikipedia.org/wiki/Spatial_multiplexing


Yeah 6Ghz freq doesn't have DFS channels which remove a lot of usable channels for 5Ghz. Unfortunately it'll be a while until most devices support 6Ghz.

> Unfortunately it'll be a while until most devices support 6Ghz.

Per this May 2025 Juniper presentation, half of their deployed APs have 6 GHZ enabled, and at least 20%—but as much as 50% depending on the environment—of clients have 6 GHz:

* https://www.youtube.com/watch?v=sV-3gA0OP9s

Corporate environments (where client hardware is more standardize) has higher 6 GHz adoption, BYOD (universities) environments have lower adoption.

So I'm not sure how you define "a while" as, but it's probably already the majority at most workplaces, and will be for personal stuff with-in a year or so.


But defaults should be sane and safe. RNG isn't the sort of thing you want to be messing up. Every JS dev was taught that Math.random is not safe by default, but the crypto package is.

There's a bunch of companies doing garage GPU datacenters now. Probably can act as a heat source during winter too if you have a heat pump.

That's an interesting idea [1], the value being that its easier to build servers into a bunch of homes that are being built than building a datacenter. Every now and then something reminds me of "Dad's Nuke", a novel by Marc Laidlaw, about a family that has a nuclear reactor in their basement. A really bizarre, memorable satire [2].

[1] https://finance.yahoo.com/sectors/technology/articles/nvidia...

[2] https://en.wikipedia.org/wiki/Dad%27s_Nuke


I think at this point Steam might as well just release the hounds and let third parties build and sell steam compatible hardware (the Android play). Their own attempts have been, well, not great. Dealing with hardware supply chains is a very different game than software. They already have a platform, the hardware is purely for distribution. Whether they make a profit on hardware or not doesn't really matter. They are basically the opposite of Apple.

Steam already supports 3rd-party controllers and VR headsets. SteamOS is available on several 3rd-party handhelds. What more do you need for "steam compatible hardware"?

Do they support any third-party controllers that are anything like the Steam controller(s)? To my knowledge, third party support is only for traditional game-console-like controllers.

According to Wikipedia, they already officially support the Lenovo Legion Go S.

Not sure what you mean by "not great," the Steam Deck is awesome. The one in our household is like 3 years old and still sees daily use. They have been very well received by the PC gaming community.

SteamOS is mostly just the regular Steam client on top of Linux. You will get more or less the same overall experience by starting with a reasonably capable GPU, then installing any mainstream Linux distro, then installing the Steam client, and making a few tweaks. Valve has been very active in upstreaming fixes and features to upstream projects like the Linux kernel and Wine, so the Steam Deck (and soon Steam Machine) doesn't actually have any special sauce, it's just a nice self-contained unit for those who just want to play games and not be bothered by the OS under the hood.


As far as I know there's nothing preventing third parties from building and selling hardware with SteamOS or a similar software stack.

https://en.wikipedia.org/wiki/SteamOS

They aren't going to let you advertise them as Steam-branded hardware without an agreement, but there are multiple handhelds that have done so to be branded officially Steam Compatible.


They tried this many years ago with the original steam machines, it went horribly. Also, you can install SteamOS or Bazite on most machines. Not sure what the issue is here.

SteamOS does not currently really work on modern desktops/laptops. You can force it but it’s really not made for it. They’re pretty clear about that, I think they even pulled down the OS download page from their site and now clearly mark it as for restoring old machines.

Likely to change soon though with the steam machine release


Bazzite is great, though. And doesn't lock you in to Steam or DRM if you don't use them.

Yeah I’ve been using it as a daily driver, no windows partition or anything, for over a year. It’s been great. Having an AMD CPU/GPU combination definitely helps though

What is "Steam compatible hardware"? Isn't that like saying "App Store compatible hardware"?

You can say the same about swipe to unlock and that had been litigated to death.

I did say the same about swipe-to-unlock:

>> Something that's bothered me about user-facing patents


If we are gonna go down that rabbit hole, then the natural conclusion is Haskell.

How good are LLMs at understanding Haskell errors and then dealing with them?

The last time I had a go with Haskell, the errors reminded me so much of hellish terminal compilers from the 80s and 90s that I quickly gave up. Been there, not doing that again.


Which seems pretty reasonable tbh. Claude Code is amazing with Elm in my experience.

I like your username.

I don't think OP's upset with the actual delivery trucks (though NYC banned them from city center for very good reasons). It's those F150 and Cybertruck pavement princesses and massive SUVs that are problematic.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: