warpspin

My wife used to fall for every Firefly season 2 hoax on social media in the past because she wished it to be true. It was very funny when I could come to her to announce there will be a season 2.

Mixed feelings about it being animated. The older I become, the more I have trouble relating to painted characters, no real clue why, so I couldn't even enjoy things I should have enjoyed like Arcane.

Also, of course, no Shepherd Book :-(

Anyway, I hope I'll like it. Really loved season 1.

Just talked with a colleague and we used this as example where vibe coding is already brain draining people.

Exactly. Guess what: I've been on Apple for 26 years. iOS 26 is already a shit show, the new Watch OS even more so, and never ever will I allow it to update my main work platform, my Macbook Pro, to something which promises to be even worse.

Hmm, I second this. Haven't compared Qwen3.5 122B yet, but played around with OpenCode + Qwen3-Coder-Next yesterday and did manual comparisons with Claude Code and Claude Code is still far ahead in general felt "intelligence quality".

There were times when we couldn't await to upgrade to the next Mac OS version. Tahoe is not one of those versions.

Already iOS 26 made me consider switching to Android, and now I've pondered returning to Linux after 26 years on Mac OS. Bizarrely, right now it's the quality of the hardware alone holding me at Mac OS. Wouldn't have expected that 6 or 7 years ago.

Sick of the forced UI refreshes and "modern" designs. Will Apple understand again this is where I work and basically live in and not some kind of entertainment system where I need design refreshes so it feels all shiny and new?

Some things sound very clever in your head until you say them aloud.

Next step: Start Chrome in emulated X86CSS and start X86CSS in emulated Chrome.

One of the major problems of MySQL and its many derivatives is the splintering of the ecosystem.

Would rather prefer people would cooperate on ONE fork, e.g. get your extension framework integrated into MariaDB or something.

Hmm, yes, I know that one and one of the reasons why I considered the naming weird. Original Tcl expect is rather automation than testing in the slot in my mind it occupies, even if it maybe could be (badly) used as a testing tool.

> This assumes the code you wrote is already correct and giving the correct answer, so why bother writing tests?

It catches regressions. Which is the one thing where such semi-automated testing is most useful in my eyes.

No clue though why they gave it that weird "expect" name. Basically, it's semi-automated regression testing.

Android's not better, unfortunately. We also tried them for the kids, and most protection software back then simply could be killed by rebooting the phone and overloading the phone a bit immediately after reboot.

MariaDB has system-versioned tables, too, albeit a bit worse than MS SQL as you cannot configure how to store the history, so they're basically hidden away in the same table or some partition: https://mariadb.com/docs/server/reference/sql-structure/temp...

This has, at least with current MariaDB versions, the annoying property that you really cannot ever again modify the history without rewriting the whole table, which becomes a major pain in the ass if you ever need schema changes and history items block those.

Maria still has to find some proper balance here between change safety and developer experience.

It's totally buggy unfortunately, and has been for years. Also, all time limit features are circumventable by switching time zones for example.

Sometimes apps will randomly appear to have time limits which the parent has never set also.

It's really a bugfest through and through.

Wished he'd spend as much as effort on writing endings for his books as on that blog post.

Sorry. Just grumpy, cause I always love the first 80% of his books and then they somehow... just disintegrate.

While I support protecting insects and I literally see how their amounts decreased since I've been a child, I wished people would stop the alarmist "food supply in danger" headline. It's not, at least not because of the insects. Most of our food supply is not dependent on wild insects, instead people usually pay for cultivated bees to pollinate their plants. Business is too serious to rely on circumstance.

The real problem is that loads of the wild plant life depends on wild insects, and we do not want to lose that.

Don't get me wrong. Neither I deny climate change, nor do I say we should destroy nature as much as we do.

But we need to start talking the truth instead of invented talking points, or people won't take science serious anymore... even more than they already ignore it.

I loved Red Alert 2 so much at release. Always was the pinnacle of (single player) RTS for me. The over-the-top characters, the cheesy story, the terrain interactions...

Everything afterwards felt lame and was geared too much towards multiplayer balance, which does not interest me the least.

> I feel that my clients and I never had significant difficulty in finding providers

Yes, for professional uses. But we lost the next generation of devs. You could put PHP on any shared webspace and people started messing with it and from that messing, the next generation of open source PHP programmers came.

I have been using Perl for almost 30 years now, privately and professionally. People here tend to say, Perl 6 or Python killed it, but that's not what I experienced in those 30 years. Not that simple.

It was a combination of things, the Perl 6 announcement was one of the smaller parts actually.

- TIMTOWDI lost against "batteries included", and it lost big: It's not so much that the simpleness of the Python language won over Perl, the real and absolutely major problem at that time was the success of CPAN, which "killed" Perl 5. Perl 5 would have needed ONE object system, ONE base exception class, ONE way to do function signatures. Instead at the time, it came bundled with a bunch of Perl 4 utilities which nobody dared unbundling, CGI and a handful math functions. Being able to pick is nice, but everybody else did pick, too, and so if you used any CPAN dependencies, you soon had 3 incompatible object systems, 4 type systems, 5 exception systems co-existing within your project. A problem Perl has to this day and the reason why my team tends to re-implement stuff instead of pulling in dependencies. Python's "batteries included" approach easily won out, because stuff worked with each other and you didn't burn then scarce RAM on having different implementations of the same thing.

- Perl started to lose at the low-cost hosters against PHP already pretty early. It was easier during a certain time period to have a halfway performant PHP installation than a performant Perl installation. Hosters usually only offered CGI for Perl, not mod_perl, while PHP usually was offered as FastCGI module or mod_php which supposedly was easier to install. No low cost hoster wanted to mess with mod_perl, because it always was a hassle to setup.

- Speaking of mod_perl, things in the web dev sector still stayed pretty stable as long as Apache 1 ruled. People had to use mod_perl, but then you had a pretty performant solution. Then Apache 2 came around but mod_perl 2 wasn't ready for a long time (honestly I don't know whether it ever became ready). The Perl community at that time appeared entirely unprepared for that. While Python users were accustomed to run standalone Python servers behind proxies, Perl always was relying mostly on mod_perl. But threading in Perl stagnated and ran against a wall, and Apache 2 preferred multi process multi threading modes versus the simpler prefork multiprocess model that Apache 1 and mod_perl 1 ran on. This was the time were you could basically feel the creaking and everything breaking apart: suddenly there was no clear path forward, with mod_perl2's stability issues and the general threading stability issues of Perl 5.

It took years for the community to recover from that and focus on things like the Python-inspired PSGI/Plack as a way forward.

So, how does Perl 6 fit into this? Yes, in the early 2000s we did think, it would be just around the corner and be a clear upgrade path and solve everything wrong with Perl 5. Nice fantasy at the time. But at the same time, people were busy with far more pressing immediate problems, like how to migrate away from mod_perl1. When Python's WSGI and soon after that, Ruby on Rails came, they pressed directly into the vacuum left open by the mod_perl 2/Apache 2 disaster and this is actually what sealed the deal, IMHO.

I'm not even sure you can generalize to "in the EU" here. A lot of contract law might be different between countries.

So for example, in Germany, an EULA would be considered an AGB, and subject to §303 BGB and following paragraphs, which e.g. means, "surprising" clauses which you cannot reasonably expect beforehand being part of the EULA would be unenforcable or §307 BGB would make certain kinds of one-sided/lop-sided clauses unenforcable.

Other EU countries might have other laws. I'm not really sure this is an area of unification, and a lot of the commonalities there is might be more due to the common heritage of Napoleon's Code Civil which underlies contract law in many european countries, instead of EU unification efforts.

Have to insert my regular rant that while I wholeheartedly support compensating font creators, pay-per-view licensing for fonts is ridiculous and must end. Offer manageable flat fees, more people will license. Continue this license policy and stuff like in this article, even more people will run to open fonts.

Lol. This is supposed to replace me at my job already?

Great experiment!

It's pretty obvious that instead https://darkkhaki.bikeshed.com/ is the correct URL. Everyone knows.

SCNR

Seems somebody volunteered for the AI's torment nexus!

> Lots of tools support it: [...| Windows Explorer (Map Network Drive, Connect to a Web site...)

Not sure he ever tried supporting that. We once did and it was a nightmare. People couldn't handle it at all even with screenshotted manuals.

My personal experience says that even the dumbest user is able to use FileZilla successfully, and therefore SFTP, while people just don't get the built-in WebDAV support of the OSes.

I also vaguely recall that WebDAV in Windows had quite a bit of randomly appearing problems and performance issues. But this was all a while ago, might have improved since then.

Well played. Have been using Mac OS for 20 years and I did not expect this result, if asked.

This is why you should always be wary about re-implementing OS behaviour yourself in your widgets, you will always miss at least one detail, but more probably dozens of them.

Seems to redirect back to HN now when you visit it from HN? Still glad it was mentioned here. Have been pondering buying a vacuum robot for a while and the missing privacy was off putting, so I haven't bought one yet, and I only today learnt of the project.

Can somebody who runs this on one of the recommended Dreame mopping robots say from experience whether you actually lose some kind of essential features the built-in firmwares have? The "why not" page says feature parity is a non-goal but only specifically mentions multifloor where I can understand the reasoning.

While some of the professional development probably was on host systems, not all of it was.

Especially since the release of Turbo Assembler in 1985, serious development on the C64 was quite comfortable.

Years later in the 90ies, Fairlight enhanced Turbo Assembler with REU support, which made development on the machine itself ridiculously comfortable. Basically the only thing missing I can recall was there was no concept of version management back then.

Of course, this came too late for professional development but it's basically what the demo scene ran on till cross assembling from PCs came in vogue.

In theory, yes, you could compare it. In practice, the build would need to be reproducible which is non-trivial depending on the size the of the project and the external dependencies the project itself has.

Plus, in theory you'd also need reproducible builds for everything because who knows what your compiler did to the source ;-)

Reality is, as you already implied: in practice you cannot "be careful" except avoiding obvious malware.

At SOME point you have to trust SOMEONE, unless you use TempleOS in which case you can trust whatever god you have.

That sentence is such an epic roundhouse kick.