FirstRib Void Linux choice

[wiak]

So in early 2019, 'FirstRib' said: we should be using Void Linux repos and package manager for projects on this forum!!!... and thus it began.
But was it a good idea????!

DistroWatch page click rankings don't really tell us much about anything, but out of those distros that have been individually ranked by over one hundred individuals, that would I believe bring some statistical significance to the result:

https://distrowatch.com/dwres.php?resou ... istro=void

Distro table result: https://distrowatch.com/dwres.php?resource=ranking

By the way, Void Linux can also run on Raspberry Pi. Unfortunately I don't have one or I'd modify build_firstrib_rootfs build script to build for that platform too (with similarly modified FR initrd if possible).

[Grey]

DistroWatch page click rankings don't really tell us much about anything,

Wow, Mint has already overtaken Endeavour there (on the main page) I didn't expect it. Now in the top five "leaders" only two representatives from Arch. Debian and Ubuntu take "revanche".

[Grey]

Wow, Mint has already overtaken

Yeah, that's the thing. Mint continues to prepare for the "fall" of Ubuntu and just recently released a "spare" variation based on Debian. The people cheered up, everyone started throwing hats in the air, shouting approving slogans... and raised the rating

[tosim]

FYI-Mint has had a Debian v for several years now. In fact Mint • 6-beta "LMDE" just released.

[Grey]

FYI-Mint has had a Debian v for several years now.

Well yes. That's why I said "continues" Such releases are much rarer than the main ones, so they create a "stir" among fans.

[williwaw]

But was it a good idea????!

I have been wondering the same lately. Not because of anything wrong with Void, I think they have earned their marks, but ............

Is a rolling release distro used for a base more compatible with saves and sfs than a fixed release base?

[geo_c]

But was it a good idea????!

I have been wondering the same lately. Not because of anything wrong with Void, I think they have earned their marks, but ............

Is a rolling release distro used for a base more compatible with saves and sfs than a fixed release base?

I'll give my two cents, I'm a fan of the rolling release when it comes to Void, but it is a bit more complicated in terms of "saves', which are not so cut and dry. It requires one to manage saves of upper_changes much more thoughtfully. Sequencing and timing of the updates (or choosing to update system-wide at all) has to be balanced and managed against personal use-case needs. As long as the underlying rootfs remains unchanged, upper_changes can be treated as "full install" if one wishes. It only gets complex when playing with layers and backups of the upper_changes.

But I don't think it's complicated at all when it comes to updating to newer versions of applications and frameworks. On something like a static pup or older Debian/Ubuntu that kind of updating can get extremely complicated.

[wiak]

But was it a good idea????!

I have been wondering the same lately. Not because of anything wrong with Void, I think they have earned their marks, but ............

Is a rolling release distro used for a base more compatible with saves and sfs than a fixed release base?

I'll give my two cents, I'm a fan of the rolling release when it comes to Void, but it is a bit more complicated in terms of "saves', which are not so cut and dry.

I haven't put any effort into this. FR provides underlying mechanism for roll-backs, but begs the creation of a system mechanism for making that user-friendly/useful transparent, consistent, and unbreakable (which concerns the package manager database) when that mechanism is stuck to. Another useful possible related but different development revolves around automating kernel upgrades; rolling these into the underlying system (often existing in sfs form). We know you can't break the 'sequence' of the rollbacks, which have to be used on a LIFO basis, so that is the first utility/mechanism that would be worth a lot of effort in development along with merging together parts of that sequence (Last In part) when wanting to do so. I'd like to see that as an argument/parameter-passed command-based mechanism since that approach also lends itself to alternative GUI frontends rather than mixing in the likes of yad or gtkdialog or whatever graphics approach found convenient. A well-designed trustable rollback-control system like that would indeed be really useful when using the underneath constructed rolling-release distro like Void Linux provides; actually I really prefer rolling-releases such as Void provides, and moreso since Void team do a really good job of keeping everything working reliably despite using close to leading edge software updates.

Like all distros, KL/FR needs more developers, though not Void Linux specific (upstream Void takes care of most of that). A lot of development work can be shared across different distro designs, but core parts relating to the particular facilities provides by any distro initrd tend to be specific to that distro-type; of course any such development will apply across the widening KL range of distro varieties.