Just like the recent Bazzite post, this page is full of buzzwords, but fails to explain what it actually is. It’s an image-based Linux distro. Which is nothing groundbreaking, and a solution looking for a problem, because classic Linux distros just work.
> Aurora is nothing more than a collection of bash scripts, containerfiles and custom programs stitched together.
That sentence appearing on the same page as "rock-solid" is not very convincing either and does not instil confidence.
Don’t worry. These immutable distros break in completely new and unexpected ways, especially since a lot of programs don’t quite gel with it or with the flatpak stuff (e.g. mdns still not really supported)
I want to offer a counter perspective. While the idea is simple and technically not new, it is implemented in a way that allows a huge swath of people to migrate from windows relatively painlessly. It is something. Dismissing it as 'not groundbreaking' is missing the forest for the trees.
What is the magic solution that will make people migrate? Non-image-based mainstream Linux distros, like Ubuntu, tend to be stable and don’t randomly break. Random breakage happens in Ubuntu, but it also happens in Windows, and probably in those image-based distros as well.
Ubuntu is basically windows. I can give you that it is stable, but if you are actually arguing that there is not difference between those ( no 'magic solution' ) edit: , then I don't buy the argument. I think you may be missing the point I was making.
edit: I re-read my previous post. It is possible it is not clear, there is a level of ease and stability that comes 'image based' distros. I am putting quotation marks, because I am almost wondering if this is the equivalent of leather warm seats in the car. You don't think you need it or want it, because car warms up just fine so its not needed. And yet.. when you try use it once, you are hooked.
Do you have any solid sources for the "huge swath" of people being enabled by this to migrate from Windows to Linux?
The only thing that will enable people to migrate is third-party app support; no matter how good Linux distros get it's all moot if the software users use every day doesn't support it.
No. Source is me. I am the anecdata. shrug It absolutely can be wrong, but to me the pattern is relatively clean. Most of the converts I have seen thus far were Windows holdouts.
It’s saying something that your post lists all the negative aspects of movie theaters and positive aspects of watching at home without actually specifying why “Movie theaters still win on a couple fronts”.
I went to see Avatar on a Imax screen. It was already about a month after the release so it was pretty quiet.
But those kinds of movies are rare- and it is expensive. You have to drive and park for half an hour, pay 30 euro for two tickets and ofcourse the drinks. Not something I want to do every week.
One way theaters win is that you can meet your friends / S.O. there without bringing them home; some people don't have living accommodations that are suited to hosting guests.
They will own it, and then what? Will Claude Code end every response with "by the way, did you know that you can switch to bun for 21.37x faster builds?"
If you go with the defaults, they might be. But if you manually define the letter for your external drive, it will keep it forever. (I have my external drive set to X. I’m not sure if Windows would respect that assignment if I had plugged in 19 other drives, but that is never going to happen.)
Depends on your setup. These days, I have a D drive for sharing data with the Linux install I never use. I used to have a D drive for user data (to keep them safe when reinstalling Windows) back in the 9x/XP days (and my CD drive was E).
I also use the drive letter assignment feature, so my external USB drive is always drive X.
> GitHub has been useful to store all repositories of the Dillo project, as well as to run the CI workflows for platforms in which I don't have a machine available (like Windows, Mac OS or some BSDs).
The post does not mention CI anywhere else, are they doing anything with it, keeping it on GitHub, or getting rid of it?
> Furthermore, the web frontend doesn't require JS, so I can use it from Dillo (I modified cgit CSS slightly to work well on Dillo).
That sounds like a bad approach to developing a Web browser, surely it would be better to make Dillo correctly work with the default cgit CSS (which is used by countless projects)?
No doubt this is desirable. However, adding all the CSS features required to support cgit may have been a lot more work than editing cgit's CSS. It's an attempt at avoiding yak shaving; adding recursive sub-projects that balloon a project's scope of work far beyond the original plan.
Dillo is actively developed, and the project of "migrate away from github" is complete, so now other work can be started and completed (like adding the CSS features required to support mainline cgit).
This was the part that mystified me. Love it or hate it, GitHub Actions is free. Alternative providers like Codeberg have much tighter limits on it, and it sounds unlikely the author's solution includes CI at all.
Coming from Github myself, I cannot imagine going back to it after using Gerrit for even just a few days.
The workflow in Gerrit really makes a lot of sense, unfortunately its the workflow in GitHub that has screwed up everyone's idea of what code review should look like[1], even by one of GitHub's co-founder own's admission.
I personally find the rebase and stacking commit focused method of integration that Gerrit uses to be easier and cleaner than PR's in GitHub.
Having done CI integrations with both, Gerrit's APIs send pre- and post-merge events through the same channel, instead of needing multiple separate listeners like GitHub.
> In my case, first I tried using the latest Python 3.13.9 both from Windows 7 (bad idea due to resource fork loss) and macOS 10.14.6 Mojave, but neither worked: it seems like that version of Python was just too new. I then retried with Python 3.8.10 instead (which I chose thinking it might be more period-appropriate for the script's age) on Mojave, which worked flawlessly.
Ah, classic Python. Removing features [0] and breaking perfectly working software just because the feature is old, ugly, and not widely used.
Why not C89? Try to make it as portable as possible. The software is intended for preservation of old computers and their software. Would make sense for the software to be as portable as possible.
Who knows, maybe someone would want to run it on vintage Mac hardware?
This is a good point. For a while, I was writing vintage Mac hacking tools in ANSI C [1].
The answer is that it's too hard. I want to see the Happy Mac on as much exotic hardware as possible, but my day job keeps me very busy, and I want to enjoy my hobby without tedium and toil. I prefer to use a language that is "easier to write, easier to read, easier to understand, easier to maintain" [2].
It already exists. But, if any, Free Pascal with Lazarus for classic Mac ppc would be ideal.
Put that MacSSL port available under fpc and now you can compete with the rest.
That's a bit reductive. We're talking about something only relevant to retrocomputing (MacOS 9 is unsupported as of early 2002 per Wikipedia) where they could scarcely find evidence of anyone using it at all. And taking these things out of the standard library means that core devs can wash their hands of it. (It also means that a large majority of users can avoid downloading and storing things that will always be useless to them; but nobody seems to care about that sort of thing any more, much to my chagrin.)
The "Clean Code" book is famous for making bad suggestions and producing unreadable code with too many functions just for the sake of following its rules.
It's worth noting that the author of "Clean Code" does not appear to have written any software of significance. He's nothing more than a preaching salesman.
There are far more real developers to learn good practices from. Brian Kernighan, Dennis Ritchie, Linus Torvalds, etc.
> Aurora is nothing more than a collection of bash scripts, containerfiles and custom programs stitched together.
That sentence appearing on the same page as "rock-solid" is not very convincing either and does not instil confidence.
reply