"it came to me as a microsleep misinterpretation of a radio news broadcast" feels like the most tech thing, to me. this is always where the best ideas seem to come from, a misinterpretation that gets fixed up into an enhancement.

As a musician, this happens to me as well. If I hear a piece of music in a noisy environment my brain will fill in the gaps. I’ll think, “Wow, this music is really interesting.”

Then I’ll hear it in a quiet environment and realize that I preferred the version where my brain adding things to make up for what I couldn’t hear before.

I guess it’s a little like diffusion. The brain has natural denoising processes which, in an unconscious way, taps into our tastes.

Also works with visual noise & beholding.

It's funny to me that the patch threads attempting to fix a concern with the CPU from the OS both immediately derail into "oh no, you broke something!!1"

the CPU is assumed to work, despite Linux being designed with portability, theres not really a programming interface to cleanly disable arbitrary features, I guess we just screw with it until it seems to work OK and no one is yelling.

Granted, Linux isnt a product, and a patch in a thread is unlikely to impact anyone

Proof by counterexample, just find the inevitable security flaw.

Optimistically because the component was considered self-contained, and done?

If you build things with wires, diodes, multiplexers, breakers, fuses and keyed connectors there's less maintenance needed than if you try and build a system entirely out of transistors and manually applied insulators.

I haven't looked at the package itself, but was it built on top of the C libraries with like, bindgen?

e: a glance suggests thats not the case, but perhaps they were ported naively by simply cloning the structure without looking at what it was implementing? that's definitely the path of least resistance for this type of thing. On top of that the spec itself is apparently in POSIX, some parts of which are, well, spotty; compared to RFCs

Well, it probably depends on which software's concern will be implementing a policy to prevent users from having permission to fill critical directories and prevent the system from operating normally, which is discussed in the article. Which is also a coordination problem because the most common user of disk is software itself, I think.

FHS seems to specifically imbue the user with the responsibility and consequences of filling up the disk.

Linux for me is all about customization and control, particularly of hardware, which you'd usually do for optimization (performance, workflow, latency, stability), which is fun if you care about optimization and efficiency, but for "good enough/I'm used to it/I'm a satisfied paying customer" I suppose there's no reason to investigate or risk. The market has poured loads of capital into satisfying PC multimedia use-case.

I'd suspect there's probably versions of all those that have been made to function basically through WINE.

If your curious, it's very easy to use it as a hypervisor, and pull out what you can, though IOMMU/SR-IOV might be tricky.

Alternatively, checking if Blender/GIMP service your use cases wouldn't even require switching...

AutoHotKey has been solved a lot of different ways, for sure.

But yeah, granular detailed control over your hardware is still the primary use-case for Linux, so if you view bad defaults, annoying install procedures, occasional show stopping bugs a hindrance rather than an opportunity, maybe it's not a strong candidate.

I hear that. I enjoy that kind of tinkering; I just have too much on my plate with my business to go as deep into it as I used to. But I'm still interested in Linux, if only because it's a much-needed third option. I've been on and off it as a daily driver over the years.

I'm guessing others here who are primarily on Windows can relate to this. We've been disappointed with what Apple and Microsoft are doing, and we want, not necessarily more customization of our OS, just less interference.

I adore this machinery, there's a lot of money riding on the idea that interest in AI/ML will result in the value being in owning bunch of big central metal like cloud era has produced, but I'm not so sure.

I'm sure the people placing multibillion dollar bets have done their research, but the trends I see are AI getting more efficient and hardware getting more powerful, so as time goes on, it'll be more and more viable to run AI locally.

Even with token consumption increasing as AI abilities increase, there will be a point where AI output is good enough for most people.

Granted, people are very willing to hand over their data and often money to rent a software licence from the big players, but if they're all charging subscription fees where a local LLM costs nothing, that might cause a few sleepless nights for a few execs.

We could potentially see one-time-purchase model checkpoints, where users pay to get a particular version for offline use, and future development is gated behind paying again- but certainly the issue of “some level of AI is good enough for most users” might hurt the infinite growth dreams of VCs

tts would be an interesting case-study. it hasn't really been in the lime-light, so could serve as a leading indicator for what will happen when attention to text generation inevitably wanes

I use Read Aloud across a few browser platforms cause sometimes I don't care to read an article I have some passing interest in.

The landscape is a mess:

it's not really bandwidth efficient to transmit on one count, local frameworks like Piper perform well in alot of cases, there's paid APIs from the big players, at least one player has incorporated api-powered neural tts and packaged it into their browser presumably ad-supported or something, yet another has incorporated into their OS, already (though it defaults to speak and spell for god knows why). I'm not willing to pay $0.20 per page though, after experimenting, especially when the free/private solution is good enough.

Yeah, a fuse or a breaker is a pretty common thing.

Probably a more apt analogy would be a keyed adapter.

This is uncanny and worryingly specific, and I'm not a lawyer, but if you're not already under suspicion of being a criminal, then installing graphene doesn't match this definition I think

"This regulation will only apply to people who are already criminals" is a line that has never held

Suspect, they wrote, and that happens all the time. If you go into a store on the way home from work, and 99 days this works fine but the 100th day they want to look in your bag, but you can't show them confidential drawings of the Google Pixel 14 Max that you carry as part of your work, now they'll think you really did steal something and you went from no suspicion (spot check) to definitely a suspect and new things start to apply to you, e.g. if you leave without resolving the suspicion the police might have grounds to enter your house or search you when you walk out next time. The suspicion is based on being a suspect, not on any actual evidence (nobody saw you put anything in your bag)

I mean, you don't really have to speculate about what this is for, it's for an authority providing for lawful search, it seems pretty well-scoped, and similar to any old search warrant, which is not a new thing, really https://classic.austlii.edu.au/au/legis/nsw/consol_act/deccd...

Basically, they're not really setting up for a blanket ban on personal security features, that interpretation is obviously catastrophizing. Not that there aren't hamfisted laws somewhere like this, but NSWs implementation seems OK I guess

We have mass surveillance already in all 5 eyes countries that assumes that anyone can be a criminal at all times.

I find Rust pretty cohesive and consistent in its semantics. Accomplishing different tasks involves less sugar than other languages like this article seems to focus on.

Generally all of the interfaces conform to the patterns in the mem module. If you want to understand the structure of everything else unambiguously it would be best to start there: https://doc.rust-lang.org/std/mem/