Thanks for sharing. I was rambling a bit. I talked about how I came to contribute to ARM, what was the motivation to change the install process to calamares and how our ARM edition is unique compared to other ARM distros.
Thanks to @admins and especially @Pudge for making me part of the team and motivating and helping me contribute to .
Much love to the community in general for being an invaluable source of knowledge for me and making my linux journey fun.
leepspvideo on Youtube does a review of Artemis on the Raspberry Pi 4 4GB. He only has two gripes, Firefox being slow and having a two step process. I plan to leave a comment as to why that is.
I understand the image part, because these guys are used to using the RPi imager to burn on their SD cards., but as I’ve described in a previous post, I feel that it’s slow and restrictive.
If people want to use the script based install process to burn the image, it can be done only on a Arch based system because if the packages/functions we use inside the script.
So we thought that having the script in the iso which already has the needed packages so it would the easiest for most users
But power uses might feel different and they must be wondering they they have to get the x64 iso to install arm.
I don’t use the x86_64 image as it does not work on my laptop. I use the exper_images installer and it works great for me. The only thing I would like to see it have is the ability to feed in a pkglist.txt file so I can have the standard packages I have on my systems. Also to have zram/zswap setup by default and maybe the log program that keeps logs in memory to lengthen the life of the sdcard.
Sounds like a tempest in a teapot to me.
The larger the capacity of the uSD, the less effect this would have on a uSD card.
If you have a 8GB uSD and the OS takes 4GB, then trim (or something like it) only has 4GB to spread the cell writes across. So in this case that 4GB would get a workout.
If you have a 64GB uSD and the OS takes the same 4GB, then trim would have 60GB to spread the cell writes across. That’s 15 times more memory to spread cell writes across. I think it would take a long time to wear out a uSD in that scenario.
Plus, It may or may not be a pain in the long run. I can easily see if systemd gets messed up and doesn’t rsync the log then the forums will be busy.
Just think about how many Topics and how many posts in those Topics are about BTRFS problems and questions. Now how many Topics and how many posts have you seen about ext4.
I can easily see this situation for uSD logs versus RAM logs. Looks like a lot of work for little in return.
No, it is not. I was talking about x86_64 also, not just ARM.
Here is a discussion I found about wear leveling.
I think there are some misconceptions about uSD cards wearing out.
I believe that the main factor in uSD life is the manufacturer. If one has a good brand like SanDisk Ultra, it would be hard to wear it out in normal usage. Even with all the testing I have done in two years, where I was constantly formatting and re-formatting the whole uSD, I have only had one uSD that I thought might be bad.
Pudge
EDIT:
Since this is a public forum, I decided that instead of quoting the discussion, it would be better to link to it. I don’t want to get anyone’s knickers in a bind.