this post was submitted on 26 Mar 2024
878 points (95.9% liked)
linuxmemes
21272 readers
627 users here now
Hint: :q!
Sister communities:
- LemmyMemes: Memes
- LemmyShitpost: Anything and everything goes.
- RISA: Star Trek memes and shitposts
Community rules (click to expand)
1. Follow the site-wide rules
- Instance-wide TOS: https://legal.lemmy.world/tos/
- Lemmy code of conduct: https://join-lemmy.org/docs/code_of_conduct.html
2. Be civil
- Understand the difference between a joke and an insult.
- Do not harrass or attack members of the community for any reason.
- Leave remarks of "peasantry" to the PCMR community. If you dislike an OS/service/application, attack the thing you dislike, not the individuals who use it. Some people may not have a choice.
- Bigotry will not be tolerated.
- These rules are somewhat loosened when the subject is a public figure. Still, do not attack their person or incite harrassment.
3. Post Linux-related content
- Including Unix and BSD.
- Non-Linux content is acceptable as long as it makes a reference to Linux. For example, the poorly made mockery of
sudoin Windows. - No porn. Even if you watch it on a Linux machine.
4. No recent reposts
- Everybody uses Arch btw, can't quit Vim, and wants to interject for a moment. You can stop now.
Please report posts and comments that break these rules!
founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
Faster, more stable, no systemd, supports musl and architectures not usually supported by most distros. It's probably the most stable rolling release distro out there.
What is the benefit of no systemd?
It's too popular and it works too well.
The main benefit is that when people get tired of distro flame wars, they can move on to init system flame wars.
With the price of energy being what it is, people need the systemd flame wars to keep them warm!
No, I just don't like systemd. It's bloated and full of bugs. Just because almost every distro out there uses it, doesn't mean it's good.
I'm feeling warmer already, thanks!
OK, I have to admit, i kinda fell for it 😂.
It made me chuckle, so thanks for that!
Boasting, mainly.
I have no horse in this race, I don't have strong feelings about it either way as long as it works. But I can't help but notice that OP skipped replying to me.
OP said “bloated and full of bugs”.
I've been using Arch since shortly before they started using systemd and literally never ran into a systemd bug.
I have no clue at this point what “bloated” means. Maybe if everything works and you don't have to hack up your own solution all the time, that's “bloat”?
Oh great so now i have to unlearn systemd again?
Runit is even easier than doing things in systemd.
https://youtu.be/PRpcqj9QR68
It really is that easy. Runit is probably the simplest init/service manager there is out there.
Here is an alternative Piped link(s):
https://piped.video/PRpcqj9QR68
Piped is a privacy-respecting open-source alternative frontend to YouTube.
I'm open-source; check me out at GitHub.
Does it support glibc while it supports musl?
Yes. From their website:
"Patching incompatible software"
What does that mean? If glibc is supported why there is a portability issueand requirement of patches?
Presumably so it can work with either libc implementation.
I have checked the void website and it does NOT support glibc. Here is it:
Wait edit: there is musl variant and glibc variant..
musl practices very strict and minimal standard compliance. Many commonly used platform-specific extensions are not present. Because of this, it is common for software to need modification to compile and/or function properly. Void developers work to patch such software and hopefully get portability/correctness changes accepted into the upstream projects.
Proprietary software usually supports only glibc systems, though sometimes such applications are available as flatpaks and can be run on a musl system. In particular, the proprietary NVIDIA drivers do not support musl, which should be taken into account when evaluating hardware compatibility.
glibc chroot
Software requiring glibc can be run in a glibc chroot.
Well if glibc is supported all glibc softwares must work right?? Patching the software to support musl would not be needed if it does support glibc
Even if it's supported, it doesn't mean it needs to be installed in every system. If the user wants to use a Musl-based system, the software working only on glibc needs to be patched. At least that's how I understood these statements.
But the Void Linux team specifically wants to support both glibc and musl
Some patches are there for software that reauires systemd or parts of it.
They are likely referring to musl. Patches might be needed for some programs to work with musl.
Not just musl, software that depends on systemd (or parts of it) as well.
We also need to patch binaries as well sometimes 😁. It is fun though, cutter and/or iaito are great tools.
Yes, there are basically 2 builds for every architecture. One is glibc, the other is musl. I haven't used the musl builds that much, just toyed with them a few times (mainly because of lack of software), but if you only use open source software that doesn't specifically depend on the GNU toolchain, yes, you can daily drive it, no doubt there. And yes, it is faster than the glibc builds.
Yeah different builds. Not what i expected
Many programs aren't packaged for Void though
Repackaging is easy though with xbps-src.
Tell me more about it. Let's say I have an Arch (AUR) package that I want to repackage for Void, how do I do it?
The syntax is a bit different, but everything else, more or less the same. In fact, if you just wanna repackage a deb or an rpm, it's even easier than in Arch, xbps-src can handle deb and rpm automatically, it detects dependencies and does repackaging on it's own. You basically just have to feed it the deb/rpm file in a one liner, that's it.
I should probably give an example. Here is the template file (they're called templates in Void) for Viber. You basically just feed it the deb, do a
vcopy(copy operation specific to xbps-src) and that's it, everything else regarding the repackaging is done automatically by xbps-src.Thanks for the explanation. How does xbps-src handle dependencies? I.e. does it somehow detect the dependencies in the original package and find corresponding Void Linux packages? What about dependency versions? What happens if a dependency is not available in the Void repos?
Regarding feeding it rpm/deb packages, it reads the dependencies from the deb/rpm package and uses the equvalent names in shlibs (shared libraries). That's basically a list of libs that some applications expect to find, so xbps-src just makes a symbolic link to the equvalent lib with the name that the app expects to find. Look at the example I gave above with libtiff.
Regarding everything else built from source, there are 3 types of dependencies, since the packages are built in a chroot: hostdepends - dependcies that are requires by the chroot system, makedepends - dependencies that are required to build the package, depends - dependencies that are required to run the package. The ones that are required just to run the thing are the just depends, the other 2 are required for building only.
You find the equivalent lib in Void (the xtools package is a great help for a lot of things, including repackaging), add it to shlibs and that's it. If it's proprietery or Void doesn't have it (higly unlikely if it's open source... I have yest to run in a case like that), you have to put in the template as a distfile (if proprietery and only binary versions are available), or you have to compile from source (also done automatically by xbps-src once it detect there are distfiles for the lib and is not present in the repos).
Building from source is also easy in most cases (when no patches need to be applied). xbps-src has build styles (gnu-make, meson, etc.), so you just define that in the buildstyle parameter and it does everything automatically, including adding missing build dependencies.
xbps-src goes through a lot of trouble to make packaging and building as automatic as possible.
Thank you very much for this in-depth explanation. I will definitely consider Void as my next distro of choice.
I think you'll like it 😊.
I'll put it on a spare SSD on my PC tomorrow. By any chance, is it possible to install Void on an Apple Silicon MacBook? I'm really annoyed by Fedora Asahi and I'm looking for a better distro to put on it.
IDK, depends on the CPU architecture... I'm not that famlilar with Macs, but if it's x64 capable, yeah, no problem.
I think there was a list of supported architectures on the website 🤔...
Can't find it now. Anyway, x86, x86_64, ARMv6/v7/v8 are all supported out of the box. PPC is also supported, but you have to build everything yourself from scratch (there was one maintainer that maintained a PPC build, but he gave up on it a year or so ago, he went on to form Chimera Linux), which can be done by crossbuilding on any of the supported architectures using xbps-src... but that's a lot of work to be honest, if it's a PPC architecture, you're better off using Chimera Linux.
I do recommend trying the glibc version first, since you'd have to run everything that depends on glibc in a chroot, on a musl install. Yeah, it is doable, but if you're not really experienced with this, just use the glibc version.
Apple Silicon is ARMv8. It needs a custom kernel with custom drivers though. Would it be possible to repackage the Asahi kernel and other packages from their Fedora COPR repo using xbps-src? I'll definitely try this out at some point because it looks interesting. For now I'll try Void on my x86 machine though.
Yes, that should be possible.
But, I would first try the naked Void install with additional firmware. lspci and lsusb should point you to which manufaturer you're missing drivers for and you can install the additional firmware from the non-free Void repo, (you can add that manually to the repos, it doesn't come bundled with it). If that deosn't work, hey, you can always try repackaging 🤷. Just remember to remove the non-free firmware first, so it doesn't conict with the repackaged stuff from RH (yes, things like firmware packages or drivers can conflict with each other, especially since you're taking them from a repo xbps knows nothing about).
Yeah, just test it out on old x86 hardware, that's what I did at first as well.
Gonna give it a try one day
Interesting. I will have to try it some time. I just know on my raspberry pi 5, out of the few OSes I could get to run on it, Arch was the fastest and smoothest running, and gets updates all the time. All this, even though rpi5 is not even officially supported yet!
How is it faster? You mean every program runs faster or what?
No, just bootup and general responsivness of the system. Software is still compiled by the ssme compilers used in other distros. Everything is not magically faster.
Though on the musl build, yeah, it is faster. Trouble is, you can't run glibc software on it. Through chroot, yeah, but natively, no.