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).

near ChatGPT4 performance locally, on an iPhone

Last I checked, iPhones don’t have terabytes of RAM. Nothing that runs on a small battery powered device is ever going to be in the ballpark of ChatGPT. At least not in the foreseeable future.

First of all, you’re implying it runs latest Windows - but Windows 11 shipped a few years ago.

Second - not really a fair comparison. 18 years ago the iPhone didn’t even exist. And the oldest model (17 years old) had really weak hardware. 4GB of storage, 128MB of RAM, and the CPU was an order of magnitude slower than current spec CPUs (it was also 32 bit - and 64 bit ARM is a completely new architecture - similar to the failed Itanium).

Even if it was supported, it would be a horrible experience.

Apple was advertising that these devices would be refurbished when they were sending them out to be destroyed

When did Apple claim that? Sure if you send them a one year old phone, they will refurbish it (they will also pay you several hundred dollars to take the device off your hands). But they’ve never refurbished several year old models. Those have always been recycled (destroyed) regardless of what condition they are in.

Sure we can make a different ticket for that to move this along, but we’re getting product to agree first.

Ooof, I’m glad I never worked there.

QA’s job should be to make sure the bugs are known/documented/prioritised. It should never be a roadblock that interrupts work while several departments argue over what to do with a ticket.

Seriously who cares if the current ticket is left open with a “still need to do XYZ” or it gets closed and a new one is open “need to do XYZ”. Both are perfectly valid, do whichever one you think is appropriate and don’t waste anyone’s time discussing it.

does anyone know if there’s any actual data that shows personal disability information being recorded/collected?

That’s basically the crux of the case right? The law is pretty clear, Google can’t collect that data (or at least, if they do, then they’d have to comply with a long list of privacy regulations that I’m pretty sure they don’t comply with).

Um, did they actually do something impressive or is it just a really big gas tank?

I’m struggling to imagine why anyone would even want 1,300 miles of range in a PHEV. Surely it’d be better to have a smaller tank and more space inside the vehicle.

Apple has the target disk mode, but doesn’t the laptop need to be shut down for it to work?

Modern Macs can’t do Target Disk Mode. If you had the right cables (thunderbolt or firewire) it was really fast, just as quick as a high end internal PCIe SSD.

And yes, you did need to reboot - because the other computer had full arbitrary read/write access to the raw sectors on the drive with no safety checks or security. If you did that while the computer was running normally, you’d corrupt the data on the disk as soon as they both tried to do a write operation at the same time — and also TDM needed to be used with caution - the other computer could easily install a rootkit or steal all your saved passwords.

It’s been replaced with “Mac Sharing Mode” which operates while the Mac is running normally, does have all the necessary algorithms in place to avoid corrupting the disk, full security to authenticate each read/write operation and block attempts to mess with system files, and therefore is orders of magnitude slower than TDM.

If any of that is part of the hiring process - I don’t want the job.

If HR is incompetent enough to consider things like relationship status or political opinions then what other bullshit policies does the company have? It’s probably the tip of the iceberg.

By far most important thing is to have good colleagues, because without good colleagues your job will be miserable or the company will not last (or both). Made the mistake of working for a shitty job at high pay once and it was one of the worst decisions of my life.

Don’t waste your life working for incompetent companies.

Also, as someone who has hired devs… if you have a public profile, and it doesn’t make you look hopelessly incompetent, then your application is going onto my shortlist. Too many applications cross my desk to look at all of them properly, so a lot of good candidates won’t even get considered. But if there’s a GitHub or similar profile, I’m going to open it, and if I see green squares… you’ve got my attention.

You’ll get my attention wether the username matches your real name or not, but bonus points if it’s your real name. Openness leads to trust. And trust is criitcal.

The big difference is exclusive content. Music has a few exceptions but in general sign up for one service and you can listen to anything.

That forces music services to compete on the overall experience (and price), while video services pretty much exclusively compete based on what content is available and literally none of them offer all of the things a person wants to watch. So nobody will ever be happy with any streaming service.

Yeah I’ve given up on integration tests.

We have a just do “smoke testing” — essentially a documented list of steps that a human follows after every major deployment. And we have various monitoring tools that do a reasonably good job detecting and reporting problems (for example, calculating how much money to charge a customer is calculated twice by separate systems, and if they disagree… an alert is triggered and a human will investigate. And if sales are lower than expected, that will be investigated too).

Having said that, you can drastically reduce the bug surface area and reduce how often you need to do smoke tests by moving as much as possible out of the user interface layer into a functional layer that closely matches the user interface. For example if a credit card is going to be charged, the user interface is just “invoice number, amount, card detail fields, submit, cancel”. And all the submit button does is read every field (including invoice number/amount) and send it to an API endpoint.

From there all of the possible code paths are covered by unit tests. And unit tests work really well if your code follows industry best practices (avoid side effects, have a good dependency injection system, etc).

I generally don’t bother with smoke testing if nothing that remotely affects the UX has changed… and I keep the UX as a separate project so I can be confident the UX hasn’t changed. That code might go a year without a single code commit even on a project with a full time team of developers. Users also appreciate it when you don’t force them to learn how their app works every few months.

It was great, in 2017

It hasn’t stopped being great. In fact it’s better than it ever was.

We need better safe guards and checks so that some person can’t just delete France.

The map is updated millions of times per day. There are checks in place, but minor edits don’t get much review especially if it’s something simple like “this street has a bus stop”. Deleting France, yeah someone would notice that change and block it. Most software doesn’t use the realtime map state - they use a slightly older version of the map in part to avoid using a version of the map that has been compromised.

You really only see the current map state if you are editing the map.

Everything-but-Windows?

No. Any device that implements a certain DHCP feature is vulnerable. Linux doesn’t support it, because most Linux systems don’t even use DHCP at all let alone this edge case feature. And Android doesn’t support it because it inherited the Linux network stack.

I would bet some Linux systems are vulnerable, just not with the standard network packages installed. If you’re issued a Linux laptop for work, wouldn’t be surprised if it has a package that enables this feature. It essentially gives sysadmins more control over how packets are routed for every computer on the LAN.

The long-term popularity of any given tool for software development is proportional to how much labour arbitrage it enables.

Right. Because if you quote $700,000 to do a job in C/C++, and someone else quotes $70,000 to do the same job in JavaScript… no prizes for correctly guessing who wins the contract.

But that’s not the whole story. Where C really falls to shit is if you compare it to giving the JavaScript project $500,000. At that point, it’s still far cheaper than C, but you can hire a 7x larger team. Hire twice as many coders and also give them a whole bunch of support staff (planning, quality assurance, user experience design, a healthy marketing budget…)

JavaScript is absolutely a worse language than C/C++. But if you compare Visual Studio to Visual Studio Code (with a bunch of good plugins)… then there’s no comparison VSCode is a far better IDE. And Visual Studio has been under active development since the mid 90’s. VSCode has existed less than half that long and it has already eclipsed it, despite being backed by the same company, and despite that company being pretty heavily incentivised to prioritised the older product (which they sell for a handsome profit margin, while the upstart is given away for free).

I learned C 23 years ago and learned JavaScript 18 years ago. In my entire life, I’ve written maybe 20,000 lines of C code where I was actually paid to write that code and I couldn’t possibly estimate the number of lines of JavaScript. It’d be millions.

I hate JavaScript. But it puts food on the table, so turn to it regularly.

Large Language Models are a remarkable discovery that should, in the long term, tell us something interesting about the nature of text. They have some potentially productive uses. It’s destructive uses and the harm it represents, however, outweigh that usefulness by such a margin that, yes, I absolutely do think less of you for using them. (You can argue about productivity and “progress” all you like, but none of that will raise you back into my good opinion.)

Yeah you’re way off the mark. Earlier today I added this comment to my code:

// remove categories that have no sales

For context… above that comment was a fifty lines of relatively complex code to extract a month of sales data from several database tables, and summarise it down to a simple set of figures which can be used to generate a PDF report for archival/potential future auditing purposes. Boring business stuff that I’d rather not work on, but it has to be done.

The database has a bunch of categories which aren’t in use currently (e.g. seasonal products) and I’d been asked to remove them. I copy/pasted that comment from my issue tracker into the relevant function, hit enter, and got six lines of code. A simple map reduce function that I could’ve easily written in two minutes. The AI wrote it in a quarter of a second, and I spent one minute checking if it worked properly.

That’s not a “potential” productivity boost, it’s a big one. Does that make me worse at my job? No - the opposite. I’m able to focus all of my attention on the advanced features of my project that separate it from the competition, without getting distracted much by all the boring shit that also has to be done.

I’ve seen zero evidence of LLM authored code being destructive. Sure, it writes buggy code sometimes… but humans do that too. And anyone with experience in the industry knows it’s easier to test code you didn’t write… well guess what, these days I don’t write a lot of my code. So I’m better equiped to catch the bugs in it.

PowerShell is heads and shoulders over bash

Sure… but that’s a low bar. Bash is basically the worst shell of them all (if you exclude the ones that are so bad nobody uses them).

I’m a fan of fish personally. It’s both concise and feature rich. The fish language isn’t something I’d want to write a complex shell script in, but it’s a thousand times better than bash and if you’re writing something complex then I’d argue any scripting language is the wrong tool for the job. Including Power Shell. You should be using a proper programming language (such as C#).

PowerShell is innovative, for sure. But string output/input shells scripting wasn’t broken (unless you use bash) and I’m convinced trying to fix it by replacing simple string input/output with objects was a mistake.

I love OOP. However I also love using existing tools that work well, and none of those tools are designed to be OOP.

Swift is a relatively young language (ten years) and ~3 years ago a lot of things were brand new or had relatively recently been refactored. Also Apple released it to the public before it was really finished - and did the final work finishing off the language out in the open with collaboration as any well run open source project should be developed.

For the first five years or so it was barely ready for production use in my opinion, and it sounds like tried to use it when it was ready but still had a bit of rough edges such as docuemntation.

For example async/await was added around when you looked into it and that obviously made a lot of documentation relating to threads out of date (from memory they pretty much deleted all of it and started the long process of rewriting it, beginning with very basic docs to get broad coverage before having detailed coverage).

And before that the unicode integration wasn’t quite right yet — they did the tough work to make this work (most of these characters are multiple bytes long):

let greeting = "Hello, 🌍! こんにちは! 🇮🇳"

for character in greeting {
    print(character)
}

And this evaluates to true even though the raw data of the two strings are totally different:

let eAcute: Character = "\u{E9}" // é
let combinedEAcute: Character = "\u{65}\u{301}" // e followed by  ́

if eAcute == combinedEAcute {
    print("Both characters are considered equal.")
}

I hated how strings were handled in the original Swift, but it’s great now. Really hard to write documentation when fundamentals like that are changing. These days though, swift is very stable and all the recent changes have been new features that don’t affect existing code (or already written documentation). For example in 2023 they added Macros - essentially an inline function (your function won’t be compiled as an actual function - the macro code will be embedded in place where it’s “called”).

You define a Macro like this:

macro func assertNotNil(_ value: Any?, message: String) {
    if value == nil {
        print("Assertion failed: \(message)")
    }
}

And then if you write this code:

assertNotNil(optionalValue, message: "optionalValue should not be nil")

… it will compile as this:

if optionalValue == nil {
    print("Assertion failed: optionalValue should not be nil")
}

Notice it doesn’t even do any string interpolation at runtime. All of that happens at compile time! Cool stuff although it’s definitely a tool you can shoot yourself in the foot with.