It is also a ton of coding for a very small team of devs.
2 Likes
This would be great - one of the reasons I spent so long on OpenSUSE was the way the installer set up all the subvolumes and snapper for you. It can be done on Arch/EndeavourOS but it is a bit fiddly and very annoying when you forget to do something simple (like add a pacman-cache subvolume).
1 Like
Im just hesitant on BTRFS for the average user still, I use it because if something happens i can deal with it but Im just not 100% on if someone not comfortable setting it up through terminal can deal with issues if they arise.
Id love for it to eventually be the default but I just dont know yet personally.
1 Like
I personally think it’s better left in the EndeavourOS wiki and if someone wants Btrfs they can install it very easily this way. I know very little about the setup. Sure i know Btrfs is a file system and you can install it with luks encryption or not and timeshift with snapshots. I have done it numerous times following the wiki. I would struggle to do it easily trying to follow the Arch wiki because of the way the Arch wiki is written. I find it too convoluted for my liking. My opinion only for me and maybe that’s not the right word? Sure it has lots of information but it’s not very user friendly for those lacking more knowledge. I get by but sometimes it’s not easy. I know that this setup works and i’m using it on one of my systems. But, I don’t think it’s for everyone and i don’t think it should be the default on the install. At least that’s how i feel about it right now. Someday i may change my thoughts on it. 
The other issue is keeping the ISO small enough and the least amount of work for the devs.
4 Likes
On the other hand, the “average user” is probably SOL no matter what file system is used if it craps out on them, and the point I am making is that Btrfs doesn’t have a higher fail rate than any other Linux file system these days.
2 Likes
Most users may also benefit from setup tweaks like switching off quotas (don’t really see a need for them with the current EnOS BTRFS installation guide) & enabling scrubbing.
something like the garuda setup as an option would be nice.
This request is with us since our first release.
At this moment we are facing another issue that is kind of related to this request and that is the size of the ISO.
Both Arch and Calamares have grown in size. Our upcoming release is almost reaching that magic mark of 2 GB and this is without any significant changes shipping on the ISO.
2 GB is the maximum we are allowed on Github and we can tackle this issue very easily by moving the ISOs to Fosshost. However, and this will be our question to you in the near future, do you think it is acceptable if we’re going to release bigger sized ISOs or should we look for other solutions to decrease the size of it?
We already are looking into different scenarios to decrease the size of the ISO, from cutting up the install process to looking into another installer.
There still is some space before we arrive at that point but the way the ISO currently is built doesn’t allow us any more flexibility in adding features, without increasing the size of the ISO.
We are brainstorming behind the scenes to offer you the best solution for the future.
7 Likes
Could you xz-compress the ISOs or is that more of an img thing?
100% agree! said well 
1 Like
We already use compressing techniques, other Arch-based devs are complaining about the same thing.
As I said, we are looking into several solutions but one thing is certain, both Arch and Calamares will grow over time.
As a comparison, our very first release was 1.29 GB and our recent one is around 1.86 GB.
1 Like
I think it would be wise to get away from MS-Github and use a more free alternative, like GitLab. Also, look into making it possible for the ISO image torrent to be seeded automatically. I am more than happy to seed it whenever any of my computers is on and connected to my home network.
6 Likes
This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.