Sure - but in the real world that mostly only happens when the documentation is an afterthought.

Not sure about jellyfin, but I assume it uses ffmpeg? The M1 is fast enough that ffmpeg can re-encode raw video footage from a high end camera (talking file sizes in the 10s of gigabyte range) an order of magnitude faster than realtime.

That would be about 20W. Apparently it uses 5W while idle — which is low compared to an Intel CPU but actually surprisingly high.

Power consumption on my M1 laptop averages at about 2.5 watts with active use based on the battery size and how long it lasts on a charge and that includes the screen. Apple hasn't optimised the Mac Mini for energy efficiency (though it is naturally pretty efficient).

TLDR if you really want the most energy efficient Mac, get a secondhand M1 MacBook Air. Or even better, consider an iPhone with Linux in a virtual machine - https://getutm.app/ - though I'm not sure how optimsied ffmpeg will be in that environment... the processor is certainly capable of encoding video quickly, it's a camera so it has to be able to encode video well.

This. My Mac has 16GB but I use half of it with a Linux virtual machine, since I use my Mac to write Linux (server) software.

I don't need to do that - I could totally run that software directly on my Mac, but I like having a dev environment where I can just delete it all and start over without affecting my main OS. I could totally work effectively with 8GB. Also I don't need to give the Linux VM less memory, all my production servers have way less than that. But I don't need to - because 8GB for the host is more than enough.

Obviously it depends what software you're running, but editing text, compiling code, and browsing the web... it doesn't use that much. And the AI code completion system I use needs terabytes of RAM. Hard to believe Apple's one that runs locally will be anywhere near as good.

Here's a tip on good documentation: try to write the documentation first. Use it as your planning process, to spec out exactly what you're going to build. Show the code to people (on GitHub or on a mailing list or on lemmy or whatever), get feedback, change the documentation to clarify any misunderstandings and/or add any good ideas people suggest.

Only after the docs are in a good state, then start writing the code.

And any time you (or someone else) finds the documentation doesn't match the code you wrote... that should usually be treated as a bug in the code. Don't change the documentation, change the code to make them line up.

You don't need metaphors. It's pretty simple.

The Spotify app should have a button that takes you to their website, where you can sign up for a premium subscription.

It doesn't have one because Apple would kick Spotify out of the App Store.

Also - all other links to the Spotify website (support, terms of service, privacy policy, etc) take you to pages where the main navigation of the website has been removed so that you can't find the signup page. Because again, Apple bans that. For the longest time apps have not allowed to have any way for users to find a signup form on a website.

That policy is now illegal in the EU (and a growing list of other countries) and Apple's attempt at compliance is a new API - only available in Europe - that informs the user that they might be a victim of theft, fraud, etc before they get taken to a website that is deliberately sandboxed... supposedly to prevent theft/fraud/etc but more likely because it makes it really difficult for Spotify to link that signup with an existing free account.

Oh and if Spotify opts to expose users to see that horror show... they'd have to pay tens of millions of dollars per year to Apple. They have so far refused to do so, meaning the new regulations have failed (well, they were failing, until the EU declared Apple's compliance efforts insufficient).

Once again this is not a Rust vulnerability.

This is a Windows vulnerability and Rust is simply the first set of tools to implement a workaround - since Microsoft can't do it without breaking backwards compatibility.

Somehow the narrative has turned into negative PR for Rust when in fact they are handling this vulnerability better than anyone else in the industry.

To be fair, it’s the most interesting story the verge has covered in about, well, as long as the verge has existed.

This is a big deal - it’s going to shape the entire tech industry for the foreseeable future. And it’s going to drag on in court and probably also congress for years and years.

Apple is the target of the lawsuit but the DoJ is also telling every other tech company what rules they need to operate under. The last decade of “just do whatever you want” is over.

Reddit was open source until relatively recently. According to the source code, editing comments does overwrite your data. Or at least it used to.

Keeping old data is expensive, and usually a waste of money.

That's because Europe has actual experience with having their privacy invaded and it wasn't just to show you relevant ads. During the war my grandparents burned letters and books after reading them. And they had nothing to hide either - and all of the ones they burned were perfectly innocent and legal... but even those can be taken out of context and used against you during a police investigation.

The UN formally declared privacy as a human right a few years after the war ended. Specifically in response to what happened during the war.

A lot of the data used by police to commit horrific crimes was collected before the war, for example they'd go into a cemetery home and find a list of people who attended a funeral six years ago, then arrest everyone who was there. You can't wait for a government to start doing things like that - you have to stop the data from being collected in the first place.

Imagine how much worse it could be today, with so much more data collected and automated tools to analyse the data. Imagine if you lived in Russian occupied Ukraine right now - what data can Russia find about you? Do you have a brother serving in Ukraine's army? Maybe your brother would defect if you were taken hostage...

The web was already flooded with human generated spam, adding AI spam to the mix hasn't really changed anything meaningful - you still can't find useful content on the vast majority of webpages.

What we really need is a better search engine, one that doesn't include low quality content... that might be something AI can help with.

There have been credible leaks that this was a management level problem.

They specifically didn't want the aircraft to be inspected - as it had already been inspected and doing it again would have delayed delivery... so they had a policy in place where the door was worked on "off the books" so to speak, and therefore almost nobody even knew that the work was being done. Including the people who were responsible for checking if it had been done properly.

Boeing management originally blamed Spirit for the mistake because at first glance of the work log Spirit were the only engineers who worked on the door. It was only when they checked a second backchannel work log that they discovered maintenance had been done which required removing the door even though according to the log the door was never removed (the leak is someone at Boeing replaced the rubber seal that sits in between the door and the cabin...).

Yes, someone forgot to insert the bolts however the reality is mistakes happen and telling people not to make mistakes doesn't work. You need to create an environment where mistakes don't get anyone killed and management has failed to do that.

An engineer should not do any work at all unless they have been instructed, in writing, on a well defined schedule, to do that work. And that task should be left open until it has been fully checked to verify it was done properly. That didn't happen here, and apparently it's a regular thing.

Sure, 99.999% of the time those checks are a waste of time. But when you're doing thousands of jobs a day those checks will find problems regularly and that should be all the motivation management needs to make sure the inspections are never skipped.

Meh - I'm pretty sure Torvalds is just saying in public what thousands of other people were thinking quietly.

It sure is unpleasant to have your mistakes pointed out in public... but it's a hell of a lot better than not even knowing you made a mistake at all which is usually what happens.

It would be better if Torvalds told the guy he's an idiot in a private email but I'm not going to get worked up over that. Honestly I have a bigger problem with The Register making a headline out of it. The kernel mailing list is relatively private... this article is going to be attached to this poor engineer for the rest of his career. They should have omitted his name at least.