Gentoo, Slackware and more

bimon · 2020-05-10 10:28:13

Head_on_a_Stick wrote:

Gentoo are responsible for eudev: https://wiki.gentoo.org/wiki/Project:Eudev

Thanks for notice, are there any other alive active binary distributions based on Gentoo except Calculate?

Do binary Gentoo derivatives always inherit portage system as their package management?

Why there is no a distribution with a package manager like apt but with sources taken from Gentoo?
Would not it be easier to cook Slackware with some automation from Gentoo if keeping own snapshots of Gentoo sources and also package it in debs?

Is there anything comparable to Arch Package Archive in Gentoo?

Would not it be cool to have some scripts which would be able with a minimal manual interaction to build a Slackware or Devuan like distro (at least the same or nearest versions of software, lets not spreading over sub-packages like doc, lib, dev, etc.) from what we have in Gentoo if making its own snapshots?

Last edited by bimon (2020-05-10 10:37:45)

steve_v · 2020-05-11 06:35:19

*Gentooer since 2002*

bimon wrote:

are there any other alive active binary distributions based on Gentoo except Calculate?

Sabayon & Redcore spring to mind. Both are Gentoo derivs with optional binary repos.

bimon wrote:

Do binary Gentoo derivatives always inherit portage system as their package management?

Sabayon uses it's own package manager (entropy) for binary packages, alongside portage for source installs.

bimon wrote:

Why there is no a distribution with a package manager like apt but with sources taken from Gentoo?

Because why would you? Building packages from source is the entire point of Gentoo, and all the magic happens in portage.
Gentoo source repos are generally just clones of upstream, it's portage that does the patching required to make them "gentoo sources" at build/install-time. The only real exceptions are where gentoo _is_ upstream, e.g. eudev. How/why would you use apt instead?

bimon wrote:

Would not it be easier to cook Slackware with some automation from Gentoo if keeping own snapshots of Gentoo sources and also package it in debs?

Again, why?
Portage is gentoo, gentoo is portage. Slackware is stoatally different.
If you want slackware with apt-like package management, slapt-get is a thing. I don't see how throwing portage and/or gentoo patches into the pot as well would make anything easier... More likely it'd make it quite the opposite.

bimon wrote:

Is there anything comparable to Arch Package Archive in Gentoo?

Not as far as I am aware, and if you're talking binary packages it'd be effectively impossible due to every user setting their own USE flags and compiler options - everyone's binaries therefore being incompatible.
Not using your own USE flags / compile-time options defeats the point of Gentoo.

It's not particularly difficult to implement this yourself locally, but a centralised setup really only works for a binary-only distro.

bimon wrote:

Would not it be cool to have some scripts which would be able with a minimal manual interaction to build a Slackware or Devuan like distro (at least the same or nearest versions of software, lets not spreading over sub-packages like doc, lib, dev, etc.) from what we have in Gentoo if making its own snapshots?

sed 's/cool/non-trivial/g'
The things that make all those distros unique are also things that make mixing them pretty impractical IMO.

I've used Gentoo, Slackware, Debian and Arch extensively (Gentoo & Devuan right now, Slackware was my first GNU/Linux but package management is still a PITA), and they're completely different animals. I don't see anything to be gained from trying to mix them except a bunch of wheel-reinventing.

Last edited by steve_v (2020-05-11 06:41:31)

bimon · 2020-05-11 11:13:47

steve_v wrote:

bimon wrote:
are there any other alive active binary distributions based on Gentoo except Calculate?
Sabayon & Redcore spring to mind. Both are Gentoo derivs with optional binary repos.

Is not Sabayon dead (not being updated)? Though their google group indicates some activity.

Redcore looks interesting:
https://redcorelinux.org/news/redcore-l … ira-stable

What does it mean:

linux kernel 5.1.20 fully hardened, as default

what type of hardening they do without grsec?

Btw, a nice review of systemD free distros, Devuan is there too:

https://web.archive.org/web/20200511110 … t-systemd/

Last edited by bimon (2020-05-11 11:19:28)

bimon · 2020-05-11 11:21:10

steve_v wrote:

bimon wrote:
Why there is no a distribution with a package manager like apt but with sources taken from Gentoo?
Because why would you? Building packages from source is the entire point of Gentoo, and all the magic happens in portage.
Gentoo source repos are generally just clones of upstream, it's portage that does the patching required to make them "gentoo sources" at build/install-time. The only real exceptions are where gentoo _is_ upstream, e.g. eudev. How/why would you use apt instead?

My idea was to use portage for building and then apt for repackaging, I just like apt

bimon · 2020-05-11 11:26:21

steve_v wrote:

bimon wrote:
Would not it be easier to cook Slackware with some automation from Gentoo if keeping own snapshots of Gentoo sources and also package it in debs?
Again, why?
Portage is gentoo, gentoo is portage. Slackware is stoatally different.
If you want slackware with apt-like package management, slapt-get is a thing. I don't see how throwing portage and/or gentoo patches into the pot as well would make anything easier... More likely it'd make it quite the opposite.

The only nice thing for me in Slackware is its list of software and exact versions which bring its famous stability.
In other words it is just a one single text file with enumeration of all software and versions in a Slackware release.
If we could take the same versions from Gentoo and build them using portage would we get in result something the same stable as Slackware?
I do not need slackbuilds, its slack building tools, etc. just a base, Patrick could concentrate on choosing right versions of different software (where his skills are outstanding) instead of the whole Slackware packaging thing.

Last edited by bimon (2020-05-11 11:32:39)

bimon · 2020-05-11 11:31:55

steve_v wrote:

bimon wrote:
Is there anything comparable to Arch Package Archive in Gentoo?
Not as far as I am aware, and if you're talking binary packages it'd be effectively impossible due to every user setting their own USE flags and compiler options - everyone's binaries therefore being incompatible.
Not using your own USE flags / compile-time options defeats the point of Gentoo.
It's not particularly difficult to implement this yourself locally, but a centralised setup really only works for a binary-only distro.

Flags could be set on user's side as it is done now, why not keeping regular public snapshots of Gentoo sources and ebuilds to reuse them more later, several years after snapshots done, ZFS would greatly save on disk space.

steve_v · 2020-05-11 21:22:16

bimon wrote:

Is not Sabayon dead (not being updated)? Though their google group indicates some activity.

The github repos look active to me, last commit 3 days ago.

bimon wrote:

Redcore looks interesting:
https://redcorelinux.org/news/redcore-l … ira-stable
What does it mean:
linux kernel 5.1.20 fully hardened, as default
what type of hardening they do without grsec?

Uhh, this apparently, on top of using Gentoo's hardened profile.

bimon wrote:

My idea was to use portage for building and then apt for repackaging, I just like apt

Well I guess you could do that... You'd be throwing out the best part of the Debian buildsystem though, and you'd have to get all the dependency info etc. out of portage and into the debs... And apt's dependency resolver isn't aware of USE flags, profiles and such, so you'd have to fix that too... Sounds like work to me.

bimon wrote:

The only nice thing for me in Slackware is its list of software and exact versions which bring its famous stability.
In other words it is just a one single text file with enumeration of all software and versions in a Slackware release.
If we could take the same versions from Gentoo and build them using portage would we get in result something the same stable as Slackware?

So basically just a gentoo (non-rolling) snapshot release with well-tested versions? Sure. Just gotta find someone to test and maintain everything. Bags not.

bimon wrote:

Flags could be set on user's side as it is done now, why not keeping regular public snapshots of Gentoo sources and ebuilds

I guess you could. I don't see any demand for it though, and using such a snapshot would entail forfeiting all later security patches and whatnot as like all rolling distros Gentoo doesn't maintain old software versions.
The only reason Debian stable is viable in production is that debian-security backports patches. Gentoo doesn't, because everything is designed around the rolling release model.
IMO snapshots are best done on the local machine anyway. Don't like an update? Just 'zfs restore $snapshot'. Much better than waiting to rebuild everything from an old portage tree.

bimon · 2020-05-12 01:32:19

steve_v wrote:

IMO snapshots are best done on the local machine anyway. Don't like an update? Just 'zfs restore $snapshot'. Much better than waiting to rebuild everything from an old portage tree.

Good point, I did it too for Gentoo and GUIX in a chroot and VM guest's zvol.

I am not sure for what rolling distributions like Gentoo and Arch are good? GUIX seems to be something like rolling too?

And Arch somehow makes security patches, most likely many packages are rebuilt and updated often.

If I do not like Slackware then I do not have anything convenient except Devuan and Alpine for stable releases?

Not sure about antiX, is it stable enough for production? How much people maintaining it? Google even does not show their page with a list of packages and search of packages?

steve_v · 2020-05-12 02:39:23

bimon wrote:

I am not sure for what rolling distributions like Gentoo and Arch are good? GUIX seems to be something like rolling too?

Gentoo is a fantastic desktop / workstation / dev box, and it's probably the most flexible GNU/Linux distro ever devised. I wouldn't run it on a server or muggle-kiosk though, it's too needy WRT frequent updates and user-intervention.

Arch is a lot like gentoo in those regards, but without all the customisation that makes Gentoo Gentoo. Unstable, a PITA to update if you don't do it often enough, and additionally I found that it sometimes suffers from binary linking issues if your update server goes out of sync... But it does have much Shiny New Shit and the AUR user-provided packages if that's what you're into.

As far as I can see: The point of Archlinux is bleeding-edge software. The point of Gentoo is customisation.

bimon wrote:

If I do not like Slackware then I do not have anything convenient except Devuan and Alpine for stable releases?

That was the conclusion I came to when looking for a systemd-free server OS. My standards for such are quite exacting, and revolve around it being well-supported, low-maintenance and receiving regular security patches.
There were very few distros that fit the bill before the systemd invasion (i.e. pretty much Debian or RedHat), and there are fewer still now.

bimon wrote:

Not sure about antiX, is it stable enough for production? How much people maintaining it? Google even does not show their page with a list of packages and search of packages?

I always thought of Antix as a livecd distro, so I've not considered it.

Last edited by steve_v (2020-05-12 02:59:50)

bimon · 2020-05-12 07:16:15

steve_v wrote:

As far as I can see: The point of Archlinux is bleeding-edge software. The point of Gentoo is customisation.

Then they are both good for me only to play with them in VM/chroot.

In Arch I can find something new to try, test, check how it works, and then try to build on Devuan or wait when it is done by someone else.

Gentoo seems good for me to build something small and rare like hardened kernel by @anthrax for currently relatively rare architecture like i586. Such kernel + a few of software like a few base packages and AppArmor could be used on ancient hardware for a text only router or console which from some point of view (say absence of modern backdoors) may be more secure than modern and shiny distros on modern hardware.

Then I can try to build binary packages in Gentoo chroot and install them to physical old hardware?

Last edited by bimon (2020-05-12 07:22:15)

steve_v · 2020-05-12 13:09:18

bimon wrote:

Then they are both good for me only to play with them in VM/chroot.

Personally I don't mind a rolling release as the primary (and only) OS on my desktop, and Gentoo has served me well in that capacity.
The customisation potential isn't just for special-purpose deployments or ricing either, it's being able to have the features you want, rather than what the distro maintainers thought would suit everyone. It's like having your own personal distro, and IMO that's a grand thing on a personal desktop.
FWIW there are two Gentoo branches, and the "stable" one sees very little breakage... Well, less than I remember from Arch anyway.

Each to their own though, I certainly understand the desire for a stable release and I sure wouldn't give a Gentoo box to my gran or deploy it in an office.
I would use Devuan for those, but frankly being a year behind Debian is too stable for me. It just makes too many compatibility problems.

bimon wrote:

In Arch I can find something new to try, test, check how it works, and then try to build on Devuan or wait when it is done by someone else.

In Gentoo I see some github repo I like the look of, whip up an ebuild in a few minutes, and add it to my local portage tree.
Or just add someone else's overlay.

bimon wrote:

Gentoo seems good for me to build something small and rare like hardened kernel by @anthrax for currently relatively rare architecture like i586.

Indeed it is. I actually installed current (as of a couple years ago) Gentoo on a 486 DX4-100 not so long ago. It's one of the very few distros that can easily be built with i486 (or i586 for that matter) specific optimisations, LFS + custom scripts being the other common choice. Architecture-specific optimisations make more difference than one might expect on old hardware.

bimon wrote:

Then I can try to build binary packages in Gentoo chroot and install them to physical old hardware?

Or set up the build box as a network binhost, or use distcc. I used to use distcc way back when my main desktop was a 486, with a mighty Pentium 2 downstairs pitching in for compiles.

bimon · 2020-05-12 14:07:30

steve_v wrote:

bimon wrote:
Then I can try to build binary packages in Gentoo chroot and install them to physical old hardware?
Or set up the build box as a network binhost, or use distcc. I used to use distcc way back when my main desktop was a 486, with a mighty Pentium 2 downstairs pitching in for compiles.

May I know, why did you try to use that old hardware? Is there any difference between i486 vs i586 in terms of the purpose why you tried this except Pentium having much more RAM available?

i486 is something about 16-64 Mb of RAM and on some boards a few MBs more?

Last edited by bimon (2020-05-12 16:07:06)

steve_v · 2020-05-13 07:08:25

bimon wrote:

May I know, why did you try to use that old hardware?

Because at the time (~2000 - 2003), a hopped-up 486 (120Mhz CPU, unofficial 40MHz bus, 2(!) VLB cards, 32MB RAM) junk-bin special was all I had.

The more recent install was simply a case of finding I still had enough old parts to assemble a retro box, and doing so for the hell of it.
IBM branded SFF 486 desktop, circa 1994. All the right bits, and worth a surprising amount nowadays as they're starting to become "vintage". Runs a stripped-down Gentoo, dual booting PC-DOS for DooM and Duke Nukem.
Ed. One of these. Top spec 100MHz model.

bimon wrote:

Is there any difference between i486 vs i586 in terms of the purpose why you tried this except Pentium having much more RAM available?

Plenty. The pentium brought many new instructions, as well as widespread PCI bus support.
Multimedia was especially painful on 486-class boxes, if you wanted to play MP3s at realtime you pretty much had to compile mpg123 with special optimisations. MMX changed all that.

Unless you're talking about really specialised embedded boards, there's no reason to use a 486 for anything but a nostalgia trip. i586 is better in every way... Well, except for that embarrasing FPU bug in the early pentium chips of course.

bimon wrote:

i486 is something about 16-64 Mb of RAM and on some boards a few MBs more?

Most late-model 486 boards supported 64MB, but finding compatible SIMMs wasn't particularly easy. 32MB was a lot more common.
I believe there were some server boards that supported 128MB, but I've never actually seen one.

16MB was considered a standard desktop for most of the era, and if you had more than that you usually had to map an address-space hole for the video memory... So although mine had 32MB installed, I could only use 30MB due to my 2MB graphics card. Had to bugger about with kernel patches to get that working too IIRC.

Last edited by steve_v (2020-05-13 07:45:23)

bimon · 2020-05-13 09:28:34

steve_v wrote:

The more recent install was simply a case of finding I still had enough old parts to assemble a retro box, and doing so for the hell of it.
IBM branded SFF 486 desktop, circa 1994. All the right bits, and worth a surprising amount nowadays as they're starting to become "vintage". Runs a stripped-down Gentoo, dual booting PC-DOS for DooM and Duke Nukem.

I played DOOM first time in about 1994 too on a i386 with 8GB of RAM. I have brought a copy of DOOM game from Novosibirsk summer mathematical school.

Last edited by bimon (2020-05-13 09:29:33)

steve_v · 2020-05-13 10:18:01

bimon wrote:

I played DOOM first time in about 1994 too on a i386 with 8GB of RAM.

I think you mean 8MB, LOL. My 386 had 4, and it sure couldn't run Doom. 16MHz CPU, hercules monochrome graphics, and a spacious 80MB HDD.
Another dumpster special, and the first PC I could call "mine".

I still play (GZ)Doom from time to time, and it's still awesome. Fairly sure I have enough WADs to last me until the heat death of the universe too:

~ $ du -ch `find Games/Doom/Mods -iname '*.wad'` | tail -1
3.4G    total

Aside, I highly recommend timidity++ & the soundfonts from arachnosoft for full appreciation of Dooms epic soundtrack.

Last edited by steve_v (2020-05-13 10:28:58)

bimon · 2020-05-13 12:26:43

steve_v wrote:

bimon wrote:
I played DOOM first time in about 1994 too on a i386 with 8GB of RAM.
I think you mean 8MB, LOL.

Of course, yes
Wonderful how much memory size on modern computers raised since those times.

steve_v wrote:

I still play (GZ)Doom from time to time, and it's still awesome. Fairly sure I have enough WADs to last me until the heat death of the universe too:
~ $ du -ch `find Games/Doom/Mods -iname '*.wad'` | tail -1
3.4G    total
Aside, I highly recommend timidity++ & the soundfonts from arachnosoft for full appreciation of Dooms epic soundtrack.

Cool, thanks

PedroReina · 2020-05-13 16:02:29

steve_v wrote:

I think you mean 8MB, LOL.

My first Linux kernel compilation was on a 486 with 4 MB of RAM. But it succeded and I was amazed.

steve_v · 2020-05-22 11:58:03

PedroReina wrote:

My first Linux kernel compilation was on a 486 with 4 MB of RAM.

Yeah, that'll take a while.
Dunno if a modern kernel would build on that, it has grown some. Guess I try it next time I have a free week to watch paint dry...

MLEvD · 2021-04-19 09:03:21

4 MB! Luxury, My dad wrote a home accounting program in 1K on the ZX81.

Two years later, he bought a 16K rampack, Because tax rules changed, not because kids were showing promise on thru the wall.

PedroReina · 2021-04-19 11:57:37

steve_v wrote:

Yeah, that'll take a while.

Sure, one night; but I was sleeping.

MLEvD wrote:

My dad wrote a home accounting program in 1K on the ZX81.

I wrote software for ZX81, but never could run it because I had no money then to buy one computer, not even that humble ZX81.

dice · 2021-04-19 12:43:47

PedroReina wrote:

steve_v wrote:
Yeah, that'll take a while.
Sure, one night; but I was sleeping.
MLEvD wrote:
My dad wrote a home accounting program in 1K on the ZX81.
I wrote software for ZX81, but never could run it because I had no money then to buy one computer, not even that humble ZX81.

What was the ZX81 worth back then where you come from?

I read in wikipedia they were around $100 in 1981 in the US. Goes to show how much a dollar was worth back then.

PedroReina · 2021-04-20 16:46:44

dice wrote:

What was the ZX81 worth back then where you come from?

I'm sorry, but I don't remember the price; I just remember that it was far out of my budget. Years later I could buy a Sinclair QL, my first computer.

Dutch_Master · 2021-04-20 17:26:52

bimon wrote:

Is not Sabayon dead (not being updated)? Though their google group indicates some activity.

Not anymore, if ever:
https://forums.funtoo.org/topic/4882-fu … ng-forces/

Daniel Robbins is/was the main architect of Gentoo, so expect some improvements to Sabayon when it comes to init systems.

The officially official Devuan Forum!

#1 2020-05-10 10:28:13

Gentoo, Slackware and more

#2 2020-05-11 06:35:19

Re: Gentoo, Slackware and more

#3 2020-05-11 11:13:47

Re: Gentoo, Slackware and more

#4 2020-05-11 11:21:10

Re: Gentoo, Slackware and more

#5 2020-05-11 11:26:21

Re: Gentoo, Slackware and more

#6 2020-05-11 11:31:55

Re: Gentoo, Slackware and more

#7 2020-05-11 21:22:16

Re: Gentoo, Slackware and more

#8 2020-05-12 01:32:19

Re: Gentoo, Slackware and more

#9 2020-05-12 02:39:23

Re: Gentoo, Slackware and more

#10 2020-05-12 07:16:15

Re: Gentoo, Slackware and more

#11 2020-05-12 13:09:18

Re: Gentoo, Slackware and more

#12 2020-05-12 14:07:30

Re: Gentoo, Slackware and more

#13 2020-05-13 07:08:25

Re: Gentoo, Slackware and more

#14 2020-05-13 09:28:34

Re: Gentoo, Slackware and more

#15 2020-05-13 10:18:01

Re: Gentoo, Slackware and more

#16 2020-05-13 12:26:43

Re: Gentoo, Slackware and more

#17 2020-05-13 16:02:29

Re: Gentoo, Slackware and more

#18 2020-05-22 11:58:03

Re: Gentoo, Slackware and more

#19 2021-04-19 09:03:21

Re: Gentoo, Slackware and more

#20 2021-04-19 11:57:37

Re: Gentoo, Slackware and more

#21 2021-04-19 12:43:47

Re: Gentoo, Slackware and more

#22 2021-04-20 16:46:44

Re: Gentoo, Slackware and more

#23 2021-04-20 17:26:52

Re: Gentoo, Slackware and more

Board footer