

Another fun fact: official German spelling later changed “thal” to “tal” (both pronounced as a hard “t”), so now the valley is Neandertal, not “Neanderthal”


Another fun fact: official German spelling later changed “thal” to “tal” (both pronounced as a hard “t”), so now the valley is Neandertal, not “Neanderthal”


The slowness was not a tax on the real work; the slowness was the real work. It was how the work got good, and how the people producing the work got good
This line reminded me of a couple of articles, linked below, that I read on AI use in astrophysics. Developing junior researchers is a big part of the point of their work, so they really are going to have to limit their AI use to make sure development happens. But worry that industry won’t care; they’ve been hollowing out junior positions for years, because there’s no value in training a senior who is just going to jump ship to a company that doesn’t train juniors. That’s an existing problem, but AI seems likely to make it worse.


And that’s only, like, the most basic part of an industrial e-stop. On top of directly disconnecting the energy source, it also has to include redundant circuits (since it’s possible for a contactor to break and fail open, or weld and fail closed), and some even need to have signal pulses constantly going through them to actively confirm they haven’t been pressed. They absolutely should not just send a signal to a Linux computer, because general-purpose operating systems are too complex to be rated for safety.
This isn’t even my area of expertise yet I know this stuff. The fact that they failed at the very first requirement is really messed up.


Even if you press that big red emergency stop button on the mower itself, a hacker can send another command to unlock it, Makris says.
Holy cow. I work in factories, and I know enough about industrial safety to know that would not fly.
I’ve heard it said that the horse is man’s best slave.


I host a CalDAV server (specifically Nextcloud’s Calendar app, though plenty of others exist, like Radicale) and all my devices sync with it.
There is way too much sensationalism around this law. All this law calls for is an OS-level “Are you over 18?” button, the kind that’s been all over the internet for decades. See the Ubuntu mailing list discussion for a possible technical approach. There does not appear to be any requirement for age verification beyond that of the system administrator, and reporting is by a total of four age brackets, so even the privacy impact is limited.
The benefit of something like this is that age can be enforced by the system administrator rather than the user, so parents can set their kids’ computers with an accurate age bracket. Meanwhile, all of us with just a single user can set the highest age brackets and move on with our lives. Now, as the CEO of System76 says, kids will find ways around it, and we shouldn’t discourage kids from controlling their own computers, but he says “If there is any solace in these two laws, it’s that they don’t have any real restrictions”.
But that same article notes that New York has a proposed bill S8102A that is much more draconian. California’s law is a minor nuisance, while New York’s bill sounds like an outright danger. Please focus on a real threat, especially considering it’s much easier to change laws while they’re still only bills.
AsteroidOS mostly supports watches that come stock with Wear OS, which is a modified version of Android, which, guess what, runs a Linux kernel. These watches are on the more powerful end of the computing spectrum. As you say, there are a lot of smart watches that use pretty lean MCUs, but those aren’t running AsteroidOS or Wear OS, as noted in this FAQ entry.
Downvotes are to show that the content does not contribute to discussion. This comment is not related to the top-level post, and looks to be low-effort trolling, so it is not contributing to discussion, and deserves downvotes.
Distrobox might be the easiest way. If you use a custom HOME directory you can even keep the build artefacts isolated.
Follow the link and go down to the third point:
Isn’t this just ReactOS?
ReactOS tries to reimplement the Windows NT kernel, and that has always been its Achilles heel, holding it back from a hardware compatibility and stability standpoint. The loss32 concept is to achieve a similar-feeling end result to ReactOS, but built on a more usable foundation, using components known to work well (the Linux kernel, WINE, everything that glues those together, and a sprinkling of ReactOS userland niceties). As a bonus, the OS would still technically be a Linux distro, so it would be possible to run Linux software when necessary, something ReactOS can’t do.
Follow the link and go down to the third point:
Isn’t this just ReactOS?
ReactOS tries to reimplement the Windows NT kernel, and that has always been its Achilles heel, holding it back from a hardware compatibility and stability standpoint. The loss32 concept is to achieve a similar-feeling end result to ReactOS, but built on a more usable foundation, using components known to work well (the Linux kernel, WINE, everything that glues those together, and a sprinkling of ReactOS userland niceties). As a bonus, the OS would still technically be a Linux distro, so it would be possible to run Linux software when necessary, something ReactOS can’t do.
Nice review of the historical trajectory of desktop Linux. I was surprised that the article mentioned Homebrew rather than Distrobox. This is the first time I’ve seen Homebrew given as a solution for command-line tools on an image-based desktop.


I believe that’s pretty much what happened after the dot-com crash. A lot of fiber was laid during the bubble, it went dormant after the crash, but it was useful afterward as the internet continued growing.


That sounds like an issue with the underlying OpenStreetMap data that is used by Organic Maps (and CoMaps, and OsmAnd, and others). Map quality depends on where you are in the world and who is contributing to the maps there. If data is incomplete around you, you could contribute to it (but easier said than done, I know).
I can’t say why the route would be hours longer than Google maps, but I’ve noticed OsmAnd~ tends to overestimate drive time for me (I think it overestimates delay from traffic lights). Or it could just be that calculating routes on your phone doesn’t always give results as good as calculating routes on Google’s servers.
I used to have scripts like that, but eventually switched to ssh aliases. You can set up an alias for each machine in ~/.ssh/config with lines like this:
Host p1
HostName 192.168.1.123
Port 22
User pi
Then access with ssh p1. Slightly more typing, but avoids adding more commands to your $PATH. Also has the benefit of letting you use the same alias with other ssh-related commands like sftp.


Automatics also allow for engine braking. From a quick search, it sounds like a toss-up as to whether that triggers brake lights. Regardless, the article mentions the benefit is not only from cars slowing down, but also from indicating that a car is preparing to stop or “that a stationary vehicle might initiate movement”. Neither of those can be done by an engine brake, so front brake lights would still have a benefit even with a driver that likes engine braking.
I feel like you may have misunderstood the article. It’s talking about how support is increasing for dedicated Copy keys, and that programmable keyboards make it easy to use dedicated Copy keys. The article does not mention changing the behaviour of Ctrl-C.
The comic was released the day after the election, by an author who lives in the United States. I suspect the comic is explicitly about American politics.
Sounds like it has similar goals to bcache (not bcachefs) and LVM caching, except that it operates in userspace instead of at the kernel level. Can you explain what the benefits are of keeping this out of the kernel?