I think of it more as a “continuous integration”
having just done a test install on a spare drive, mostly to check out the systemd-boot thing id like to say that the new default pasma theme/colours look great!
but in the installer, the page where you select bootloader could be a bit confusing for inexperienced users i think, it looks like there are 3 different things that need configuring instead of just one with 3 options. maybe a simple drop-down menu with systemd-boot as default would be better.
just my view, everything worked perfectly
1 Like
Is there any info on what Cassini is and how is it different with EOS?
Cassini is just the name of the latest EOS’ ISO release.
You can read in the OP about the new features implemented in this ISO.
2 Likes
Cassini is the name of EndeavourOS’s latest ISO. It’s not a different version of EndeavourOS, mind you. Because EndeavourOS is a rolling release distro, every user who keeps their system up to date will essentially be running the same “version.”
You can read all about Cassini here:
https://endeavouros.com/news/cassini-packed-with-new-features-is-here/
3 Likes
OK got it, It is little counter-intuitive for rolling release distros as you said because it is the same thing after the first update. The question now is: should I re download my iso installer tho? It is going to download the new version of packages anyway. So is it any better, lets say in reducing the download size after install.
Yes. The installer has quite a lot of changes. Also, we don’t maintain old ISOs so the online installer can break as packages change.
4 Likes
Does installer has all CPU architectures in one file?
There is only one ISO.
1 Like
For mainstream consumer computers (Desktops and Laptops), there are mainly two CPU architectures offered, Intel and AMD. Both these CPU architectures are manufactured utilizing the CISC instruction set referred to as x86_64. x86_64 is a 64 bit architecture. The exceptions are older Apple products, and cell phones but we won’t get into that.
The EndeavourOS liveISO will install EnOS on computers based on the x86_64 architecture.
On the Linux side lines, are the ARM devices, which utilize the RISC instruction set. Mostly aarch64 which is 64 bit. There is an option in the liveISO that will launch a script that will copy an aarch64 bit RISC image for a Raspberry Pi 4b, an Odroid N2, or a PineBook Pro to a storage device.
That is all that the EnOS ISO offers, which will cover 95% of the consumer computers out there.
Pudge
3 Likes
Yeah, The reason I asked that because I saw the section about ARM in the announcement so I wanted to make sure I am not downloading the correct one. There is also x86_32 systems to consider which I guess they should have included in the iso. It is so cool that all of that is less than 2GB in size.
There is no such thing. You probably mean IA-32 architecture. This is not supported, as far as I’m aware.
2 Likes
Because Arch Linux dropped support for 32-bit some years back, whatever is based on it (including EndeavourOS) is 64-bit only at the moment.
1 Like
Hello,
A bit late, but Romanian translation is on.
https://forum.endeavouros.com/t/cassini-plin-de-noi-caracteristici-este-aici/35263
1 Like
Not an expert but, dracut being the default on Fedora gives me reason to think it’s not too unwieldy and, from what documentation I’ve found, it’s been around since 2009. I just went ahead and swapped over. Reboot was successful if nothing else.
2 Likes
If you have been keeping your system (as in your previous installation) up-to-date, there’s really no reason for you to re-install via the newly released iso. Unless you have a very good reason to re-install, it would likely result in wasted effort. Case in point: you might have to reconfigure some things and re-install the packages you use, etc.
If by “redownload” you mean keeping a copy of a latest ISO just in case you need to reinstall, then yeah, I’d say it’s a good idea to keep a copy of the new iso around.
I wouldn’t say it’s counter-intuitive. If anything, it actually makes perfect logical sense. One of the main reasons people use Arch is so that they can have access to bleeding-edge software. If you think about it, for us to use bleeding-edge software, the rolling release model is pretty much the only sensible way to go. To understand this, let’s consider a simple scenario with a package called foobar.
Let’s say you are running foobar 1.2.3 today. And then a week later, another version of foobar (let’s call it foobar 1.2.4) gets pushed into the repository. Further suppose that at least one of foobar’s dependencies have changed in foobar 1.2.4 (maybe foobar 1.2.4 uses a newer version of some .so file, who knows). If we want to use foobar 1.2.4, we have to ensure that all dependencies are installed (the newer .so file, in this case). For rolling release distros, this is possible because as soon as a new version of a library gets pushed into the repository, the developers will rebuild every single package (in the repo) depending on that library against the new library. And the moment we run sudo pacman -Syu foobar, pacman will: a) install foobar 1.2.4 and its dependencies; b) upgrade all the local packages to match their newer versions in the repo courtesy of them having been rebuilt against the new version of the library. That is why, thanks to the brilliant creators of pacman, you can safely use foobar 1.2.4 without breaking your system.
You simply cannot do this on a point release distro. The idea behind point release distros is infrequent updates. But if updates are infrequent, how are we supposed to use bleeding edge software? foobar 1.2.4 requires foolib.2.3.so to work. But the current release of my distro only ships with foolib.2.1.so and the next system update for my distro won’t be available for another 6 months! That means I’ll be stuck with foobar 1.2.3 until my next system update, which hopefully ships with foolib.2.3.so.
Same here. I’ve encountered no issues whatsoever after switching to dracut. The entire process (installing dracut + setting up dracut + uninstalling mkinitcpio) took just under three minutes.
Go into the Systemd-boot tutorial in these forums and there’s a description of a tool that pretty-much automates it for you. (kernel-install-for-dracut …but read the instructions in the systemd-boot tutorial).
I know. I made the switch to systemd-boot days ago. I was only agreeing with you that dracut works fine.
1 Like
WOW!!!
I can say nothing but WOW!!!. It summarises all that can be said.
Just dreaming if there is a way for systemd-boot to support booting snapshots!