Your FTWs (for the wins) and delights in void


#47

After using Void for a number of years and loving its stability and bang up to date nature, runit and speed and robustness of xbps, I felt comfortable and didn’t expect much in the way of surprises …

then wow, set up a server, for a specific set of functions and you get a sleek lean fast mean machine… previously before Debian morphed into a systemdOS variant I’d have sworn by it for a VPS or bare metal machine serving web related services, but Void Linux just blows it out of the water, just wow

a truly delightful distro Void FTW !


(figosdev) #48

sp far, im working with void because:

no systemd, blob-free kernel, bsd-like, 32-bit support (very rare thing now) and its not in the debian family.

ive worked with the debian family of distros for 10 years, im ready to put that behind. the other reason void is a priority (other than the kernel) is that i want people to know void is still here, it will fork/rename (if necessary) just fine-- and if it doesnt need to, even better. yes, void is still here, im creating a derivative of it right now.


(Xander Hoogendoorn) #49

I’ve tried lots of distributions. None of them worked for me. I always managed to find some flaw with it.

Void, Im happy with.

Runit is really simple and I quite like that.
Xbps is nice to work with.
System is up and running quite quickly, without any problems.

No systemd crap. YAY!


(Reza Maulana) #50

AFAIK, in the past xtraeme himself really disliked when conversation about forking void being brought up. Like it or not, Void is pretty small distro for now, forking it wouldn’t do any good to the distro and its community.

Rather than forking Void, I think you should just improve specific features that you need.


(figosdev) #51

philosophical differences, which i counted on (my efforts are too amateur to really threaten, rival or compete with anything going on here) though my impressions are:

xtraeme? where? you know i went looking for him, i even found a guy with the same handle (same spelling) on imgur. not sure its your guy. id really like you to find him, it seems clear this will go on without him. i get it if youre saying everyone else agrees philosophically.

i believe small distros are what we need most right now. void is small, but robust. i cant imagine what i would improve, the changes i make to it will most likely be for people that never loved arch. you really dont want that in void proper!

i dont consider it a fork. i automate the remixing of distros, to create things that serve different purposes/audiences. like if i open up a small vegetarian place next to a small place that serves mostly chicken, the net result will probably be the chicken place increasing in business/traffic, rather than losing it.

im finally modifying the ext3 without corrupting it, so the next version of mkfigos (2.9) is likely to be available soon. its so modest you should be laughing at it, not lamenting a thing. picture someone drawing a nice picture of your distro in crayon, before you think of it as a “fork.”

“specific features that you need.”

i chose void as a very solid base for a derivative. 32-bit support and your kernel are main attractions, or i might have very well chosen obarun instead. but it does me zero good to harm your distro. if i do that, it may not suit my purposes. i benefit more from your success.


(oliver) #52

I’m not sure he was opposed to forking, I got the impression he didn’t really see the point when Void already had plain/XFCE/Mate and other versions already out there.


(Jeffrey) #53

I removed coreutils, nvi, dash, findutils, grep, diffutils, gzip, sed, which and tar and added links to busybox. So far everything seems to be working without issue (as though by magic!).

It would be nice if xbps-alternatives had all these as alternative groups, but I’m still happy with how painless it was. (the only thing that seemed to be an issue is that man doesn’t work with busybox less, and runit has a dependency on gawk, so gawk can’t be removed).

edit: if you want to try at home, xbps-remove coreutils in a chroot, then exit the chroot to link coreutils to busybox. I used xbps-query -f coreutils to get a list of all the binaries coreutils provides. The rest can be done on a live system, but removing coreutils also requires removing dracut and your kernel, so no more kernel updates. Going to spend some more time with this and see if I can make fake packages to meet these dependencies.


#54

Such a package would be nice. Please keep us up to date with your progress on it.


(Erin) #55

Dracat is removed due to a dependency? Can you force install it and see if busybox overcomes the dependency issue?


(Edmond Dantes ) #56

dracut xbps package depends on coreutils, but I don’t think coreutils are strictly required to build the inistramfs; on the other hand dracut uses bash to create the initial ram disk, so this seems kinda the obliged dependency. Therefore a custom template including bash but not coreutils is probably what’s needed.

IIRC busybox is included in default dracut modules, so if a busybox binary were to be detected, I think dracut would grep and include it. At this point would be wise to omit coreutils module


(maxice8 alter) #57

there used to be a base-system-busybox pkg

$ git log -- srcpkgs/base-system-busybox

(Jeffrey) #58

That’s interesting, the last message in the log says it’s been superseded by the busybox package. But the busybox package is missing the alternatives groups to replace coreutils.

I’m overhauling the alternatives groups for busybox so that you can install a base system with xbps-install busybox ; xbps-alternatives -s busybox, but this will ultimately require a lot of other packages to be modified (to have correct alternatives groups, so for example if you make busybox the alternative to sed, it won’t overwrite the gnu-sed binary that’s installed). Once I have something that can be installed similar to xbps-install base-voidstrap I’ll make a new topic and get some feedback on how to best handle all those alternatives groups.

I don’t expect dracut will be a real issue, it looks like I can mark the busybox package as providing coreutils to circumvent the dependency issue, but I haven’t tested if it works yet.


(maxice8 alter) #59

Nobody wants to maintain that, well you might want and i can only offer you good luck.

please don’t add coreutils to provides when busybox doesn’t actually provide what is expected from coreutils.


(Jeffrey) #60

You know I’m not a package maintainer right? It’s not going to hurt you if I build a broken system. Ultimately it would be nice if I could do this in a way that could get merged back into void-packages, but that’s a long way off anyway and right now I’m more interested in seeing how well this would actually run.


(maxice8 alter) #61

No i don’t, i assume not since the ratio of users to contributors is very wide. But if one modifies the packages i always assume the wish to contribute back.

Would be nice indeed


#62

Interesting. Firefox using apulse for sound, instead of pulseaudio? :thinking: (a popular topic these days…)


(Samdeep) #63

The community, especially on this forum.


#64

It caters to all my needs as a control freak… :smiley: But in all seriousness Void has good taste in software and leaves it practically upstream.


(Jordan) #65

Mimicry is the best weapon :wink:

Anyways, I’ve just come back to Void after spending 8+ hours trying to stop virt-manager segfaulting on Gentoo (musl).

Lots of recompiling @world, debugging with strace and gdb, wondering what the hell was going on until I find out that it’s built on python2.7 (my laptop was just running 3+ and afterwards having it complain about missing configParser (module). Installed it and it still didn’t work. Void on the other hand, installed and running in 20 mins!

Oh well, idiocy comes from the simplest ignorance… :smiley: