Gentoo Forums :: View topic - Gentoo seems to be chasing nu Linux design (/usr merge)

Gentoo seems to be chasing nu Linux design (/usr merge)

View unanswered posts
View posts from last 24 hours

Goto page Previous 1, 2, 3, 4, 5, 6 Next

Gentoo Forums Forum Index

Gentoo Chat

View previous topic :: View next topic

Author

Message

pjp
Administrator

Joined: 16 Apr 2002
Posts: 20552

Posted: Mon Jul 22, 2019 8:52 pm Post subject:

Naib wrote:

since udev is one of hte trouble poackages (from their perspective), why not bolster eudev with a more sane rules management. Define what is critical to boot (is alsa? no so get it the fk out of the critical path) and move on

In the bigger picture, "why not" is because the people doing the coding aren't interested in doing those things. As for eudev, maybe those involved will (at some point)?
_________________
Quis separabit? Quo animo?

saellaven
l33t
l33t

Joined: 23 Jul 2006
Posts: 655

Posted: Mon Jul 22, 2019 10:55 pm Post subject:

Naib wrote:

This should be a non-issue yet somehow it is. What EXACTLY needs to be started soo early it has to come before network and nfs? What about these applications cannot be postponed OR even better split launched (a stub to get going and then a reload post nfs)

I really am struggling to see how this became an issue OR how this cannot easily be fixed. The Freedesktop/Redhat/Systemd/Pottering excuse of "oh other packages" when one of them is part of systemd source tree is a poor excuse. More to the point why is the FOSS community just accepting this?

From the oft-cited-site-of-irrational-reasoning:

Quote:

Here's a short, very in-comprehensive list of software we are aware of that currently are not able to provide the full set of functionality when /usr is split off and not pre-mounted at boot: udev-pci-db/udev-usb-db and all rules depending on this (using the PCI/USB database in /usr/share), PulseAudio, NetworkManager, ModemManager, udisks, libatasmart, usb_modeswitch, gnome-color-manager, usbmuxd, ALSA, D-Bus, CUPS, Plymouth, LVM, hplip, multipath, Argyll, VMWare, the locale logic of most programs and a lot of other stuff.

udev = systemd
PulseAudio = systemd (or at least Poettering since he's the one that gifted us both)
NetworkManager = FreeDesktopOrg
ModemManager = FDO
udisks = FDO
libatasmart = Poettering
usb_modeswitch - never heard of it, but it is niche software mostly used for ZTE equipment over usb, not exactly an earth shattering need there
gnome-color-manager = FDO
usbmuxd = again, never heard of it... niche software to play with iphones over usb
ALSA = independent, but I can boot without sound, thanks
DBus = FDO
CUPS = independent, but I don't need printing at boot
Plymouth = FDO and FFS, it's a splash screen at boot
LVM = um, I have no isssues with LVM booting and it's properly installed in /sbin thanks
hplip = see CUPS
multipath = some kind of device manager I've never heard of, contact info has a @redhat.com address
Argyll = some kind of color correction program... again, we're really reaching for straws if color correction is boot time critical
VMWare = independent, but if you're installing vmware, you should know what you're doing already

FDO, Poettering and systemd all heavily rely on RedHat for funding...

So, um, nearly all of the problems are caused by RedHat... and, just like systemd, all of the solutions literally amount to RedHat throwing their weight around and manipulating key developers in other distributions to essentially make those distributions broken clones of RedHat, then RedHat proclaiming that their terrible solutions are the answer to the problems that they caused and that everyone else has cut themselves off at the knees too.

saellaven
l33t
l33t

Joined: 23 Jul 2006
Posts: 655

Posted: Mon Jul 22, 2019 10:59 pm Post subject:

Naib wrote:

Personally I think the packages that provide an init/unit file but also depend on files in /usr (ie the problem child packages w.r.t. split usr) should be identified...

WilliamH already manipulated the Gentoo Council years ago to declare that a separate /usr without an initramfs is unsupported, specifically because he wanted us to follow the RedHat model. The Council simply went along with it rather than researching the situation themselves, since, as the sole owner of all of the boot packages and a fellow Council member, he had to know what he was talking about.

The entire Council abdicated their responsibilities at his request... let that sink in.

There's an entire group of RedHat sycophants in the Gentoo dev community that have gotten themselves into positions of power and then abused that power to corrupt Gentoo and to run off devs and users that wouldn't go along with them.

spork_kitty
Tux's lil' helper

Joined: 05 Jul 2019
Posts: 124

Posted: Mon Jul 22, 2019 11:00 pm Post subject:

NeddySeagoon wrote:

spork_kitty,

spork_kitty wrote:

... typically requires an initramfs (adding more steps to kernel upgrades,)

Why?
My initrd is kernel agnostic. Its the user space tools I need to support root in LVM on top of raid5.
There are no kernel modules in there. Its just over 10 years old and it still works unchanged.

steveL provided a set of patches so that separate /usr continued to work.

They will not fix the /bin <-> /usr/bin merge. That's just Windowsesque

I had read that it's possible to bork your system if you upgrade something important like a filesystem or LUKS/LVM, but then try to access it from the (old) initrd. It was suggested to rebuild the initrd after every major upgrade (which I typically do alongside a kernel upgrade) Was that misinformation?

Also thanks for the link to the patch! Bookmarked.

Elleni
Veteran
Veteran

Joined: 23 May 2006
Posts: 1291

Posted: Tue Jul 23, 2019 6:47 am Post subject:

saellaven wrote:

Naib wrote:

Personally I think the packages that provide an init/unit file but also depend on files in /usr (ie the problem child packages w.r.t. split usr) should be identified...

That reading is very sad and frustrating from an enthusiastic gentoo user point of view. Lacking knowledge to keep that redhat shit out of my gentoo, I am completely dependent on others and I hope there will be some anti-red-head-anti-poettering-anti-williamh kind of wiki, which will describe how I can get rid of that shit maybe even an no-evil-readhat-overlay/profile that keeps that unwanted stuff out. :cry:

And I am willing to support every activity that could prevent those evil individuals who compromise my beloved gentoo.

Gatsby
Tux's lil' helper

Joined: 18 Jan 2010
Posts: 121
Location: 127.0.0.1

Posted: Tue Jul 23, 2019 12:44 pm Post subject:

saellaven wrote:

Full ACK. ++

Regards, Gatsby
_________________
"Its your Gentoo, your way. When it breaks, you can keep all the pieces."
-- NeddySeagoon@forums.gentoo.org

NeddySeagoon
Administrator

Joined: 05 Jul 2003
Posts: 54665
Location: 56N 3W

Posted: Tue Jul 23, 2019 12:52 pm Post subject:

Elleni, There is Olde Fashioned Gentoo I need to publish an overlay that goes with that. How far do you want to go and determined are you? Gatsby, That quote in not true. More and more $UPTREAMS expect /usr to be available before localmount runs. The council ruling was to not force Gentoo devs to do extra work to support a separate /usr where it was not supported $UPTREAM. Anything else would lead to an ever growing patch set that would not be accepted $UPTREAM. It was in fact, recognising the inevitable. I tend to agree that not supporting separate /usr is broken by design but the ever growing patch set to maintain it in Gentoo would become untenable too. _________________ Regards, NeddySeagoon Computer users fall into two groups:- those that do backups those that have never had a hard drive fail.

Gatsby
Tux's lil' helper

Joined: 18 Jan 2010
Posts: 121
Location: 127.0.0.1

Posted: Tue Jul 23, 2019 1:26 pm Post subject:

NeddySeagoon,

it is not only the separate /usr thing.

There is -as saellaven pointed out-

Quote:

an entire group of RedHat sycophants in the Gentoo dev community that have gotten themselves into positions of power
and then abused that power to corrupt Gentoo and to run off devs and users that wouldn't go along with them.

It takes more and more effort and time to work around the daily increasing number of "Hubbs"isms in Gentoo and keep the devilish RedHat at bay.

Regards, Gatsby
_________________
"Its your Gentoo, your way. When it breaks, you can keep all the pieces."
-- NeddySeagoon@forums.gentoo.org

Naib
Watchman

Joined: 21 May 2004
Posts: 6069
Location: Removed by Neddy

Posted: Tue Jul 23, 2019 2:38 pm Post subject:

NeddySeagoon wrote:

Elleni,

There is Olde Fashioned Gentoo
I need to publish an overlay that goes with that. How far do you want to go and determined are you?

Gatsby,

That quote in not true.
More and more $UPTREAMS expect /usr to be available before localmount runs.
The council ruling was to not force Gentoo devs to do extra work to support a separate /usr where it was not supported $UPTREAM.

Anything else would lead to an ever growing patch set that would not be accepted $UPTREAM. It was in fact, recognising the inevitable.

I tend to agree that not supporting separate /usr is broken by design but the ever growing patch set to maintain it in Gentoo would become untenable too.

And this is why I am going to merge /usr. I did have a reply written along these lines but well

powercut.
Basically upstream is making this decision for us as more and more applications assume a flat /usr. If gentoo stuck to its guns of supporting split usr the overhead would be huge AND also goes against one of the things I like about gentoo... minimal modifications to upstream.

This is why I made the statement about what are the troublesome applications because a better course of action is to address those. What is REALLY needed to boot and what just needs starting during boot

saellaven wrote:

Naib wrote:

From the oft-cited-site-of-irrational-reasoning:
...

udev = systemd Needs to be fixed. it needs the concept of early boot and later boot.
PulseAudio = systemd (or at least Poettering since he's the one that gifted us both) Why do I need PA starting early on? this can wait till after network mount or started as a user process at login (as it should be.. PA isn't a system service, it is a user service)
NetworkManager = FreeDesktopOrg DIAF.. A networkmanager != network negotiator. This can be after a slim start which does dhcpcd etc (which systemd does)
ModemManager = FDO as above... this needs slimming down. Have a slim client to deal with initial connectivitiy (facilitate nfs) and then a manager for rich user experience
udisks = FDO wtf does this do?
a daemon, udisksd, that implements well-defined D-Bus interfaces that can be used to query and manipulate storage devices This can be delayed as this required /root mounted anyway which fstab has todo before udisk could be used. udisk doesn't care about network drives so this can be delayed.
libatasmart = Poettering again this isn't needed to mount disk to start Systemd so why does this need to be used before network mounts
usb_modeswitch - never heard of it, but it is niche software mostly used for ZTE equipment over usb, not exactly an earth shattering need there - if it is needed, slim it down
gnome-color-manager = FDO hahaha not needed to start the system
usbmuxd = again, never heard of it... niche software to play with iphones over usb not needed to start the system
ALSA = independent, but I can boot without sound, thanks not needed to start the system
DBus = FDO MAJOR problem for systemd as they went all in with dbus ...
CUPS = independent, but I don't need printing at boot not needed to boot the system
Plymouth = FDO and FFS, it's a splash screen at boot well... ins't the recommendation to use initramfs with this as this is early bootsplash anyway BEFORE even root is mounted.
LVM = um, I have no isssues with LVM booting and it's properly installed in /sbin thanks Well aspects must work to mount root... so why is this an issue whether usr is a partition or not?
hplip = see CUPS not needed to boot
multipath = some kind of device manager I've never heard of, contact info has a @redhat.com address ???
Argyll = some kind of color correction program... again, we're really reaching for straws if color correction is boot time critical not needed to boot
VMWare = independent, but if you're installing vmware, you should know what you're doing already not needed to boot

The VAST majority are not needed to boot and thus can be delayed. dbus and udev are an issue *IF* aspects have gone all-in with these concepts. This should be fixable
_________________
#define HelloWorld int
#define Int main()
#define Return printf
#define Print return
#include <stdio>
HelloWorld Int {
Return("Hello, world!\n");
Print 0;

pjp
Administrator

Joined: 16 Apr 2002
Posts: 20552

Posted: Tue Jul 23, 2019 3:26 pm Post subject:

NeddySeagoon wrote:

More and more $UPTREAMS expect /usr to be available before localmount runs.
The council ruling was to not force Gentoo devs to do extra work to support a separate /usr where it was not supported $UPTREAM.

Anything else would lead to an ever growing patch set that would not be accepted $UPTREAM. It was in fact, recognising the inevitable.

I tend to agree that not supporting separate /usr is broken by design but the ever growing patch set to maintain it in Gentoo would become untenable too.

Then it is a general problem within the Linux ecosystem. Which would appear to be an effort to achieve monoculture, with the vulnerabilities and risks of catastrophic failure associated with it. I'm not a marketer, so I'm sure they'd use different messaging.

Gatsby wrote:

It takes more and more effort and time to work around [...] and keep the devilish RedHat at bay.

++
_________________
Quis separabit? Quo animo?

saellaven
l33t
l33t

Joined: 23 Jul 2006
Posts: 655

Posted: Tue Jul 23, 2019 3:53 pm Post subject:

NeddySeagoon wrote:

Gatsby,

That quote in not true.
More and more $UPTREAMS expect /usr to be available before localmount runs.
The council ruling was to not force Gentoo devs to do extra work to support a separate /usr where it was not supported $UPTREAM.

Anything else would lead to an ever growing patch set that would not be accepted $UPTREAM. It was in fact, recognising the inevitable.

I tend to agree that not supporting separate /usr is broken by design but the ever growing patch set to maintain it in Gentoo would become untenable too.

As I pointed out, the upsteam that is the issue, is RedHat... Virtually every package that is a problem is developed on their dime.

The patches aren't unwieldy and if we're all just going to run RedHat, why bother with a Gentoo at all? THAT was RedHat's agenda all along.

In terms of avoiding RedHat stupidity, my local overlay consists of:
lm_sensors (because they block on <=openrc-0.38 even though 0.17 is working fine)
openrc (because I don't like where williamh took it)
virtual/tmpfiles (see openrc)

None of which would be necessary had williamh had never joined gentoo and decided to throw his weight around on behalf of systemd/RedHat.

Anon-E-moose
Watchman

Joined: 23 May 2008
Posts: 6186
Location: Dallas area

Posted: Tue Jul 23, 2019 4:16 pm Post subject:

saellaven wrote:

NeddySeagoon wrote:

As I pointed out, the upsteam that is the issue, is RedHat... Virtually every package that is a problem is developed on their dime.

Yep

Quote:

The patches aren't unwieldy and if we're all just going to run RedHat, why bother with a Gentoo at all? THAT was RedHat's agenda all along.

*emphasis added by me*

Quote:

In terms of avoiding RedHat stupidity, my local overlay consists of:
lm_sensors (because they block on <=openrc-0.38 even though 0.17 is working fine)
openrc (because I don't like where williamh took it)
virtual/tmpfiles (see openrc)

I have a few more in local but they include yours,
eudev 1.10 w/patches for missing include files (still works fine)
samba 3.6.25 w/associated programs (because it still works well on my internal network)
lots of odds and ends stuff that's been removed from main gentoo, that I wanted available, just in case.
though in looking at it, I need to just tar it up and do a major cleanup to just those I'm using. :lol:

_________________
UM780, 6.12 zen kernel, gcc 13, openrc, wayland

Gatsby
Tux's lil' helper

Joined: 18 Jan 2010
Posts: 121
Location: 127.0.0.1

Posted: Tue Jul 23, 2019 6:03 pm Post subject:

Hi saellaven,

saellaven wrote:

NeddySeagoon wrote:

Indeed.

Btw. thanx for the hint with virtual/tmpfiles.
A modified ebuild in one's local overlay, and some packages, recently depending on the contaminated sys-apps/opentmpfiles, don't need it any longer.

Regards, Gatsby
_________________
"Its your Gentoo, your way. When it breaks, you can keep all the pieces."
-- NeddySeagoon@forums.gentoo.org

pjp
Administrator

Joined: 16 Apr 2002
Posts: 20552

Posted: Tue Jul 23, 2019 7:12 pm Post subject:

Split off Is Profile 17.1 a move toward a Linux monoculture? as both this thread and it warrant seprate discussions. _________________ Quis separabit? Quo animo?

Anon-E-moose
Watchman

Joined: 23 May 2008
Posts: 6186
Location: Dallas area

Posted: Tue Jul 23, 2019 8:16 pm Post subject:

Naib wrote:

udev = systemd Needs to be fixed. it needs the concept of early boot and later boot.

It worked that way once upon a time, well, until sys-d took it over and threw that part away. udev-postmount
edit to add: it's also part of the reason that I still run an old eudev.

All the rest of the packages are of no consequence, they aren't needed at boot and shouldn't even be being considered as they're really only useful once you've achieved the default run level (3-5)
If sys-d needs those packages for it to run properly at boot, then sys-d needs a major rewrite, as it's doing it all wrong.
And the rest of us shouldn't have to suffer for their piss-poor programming.
_________________
UM780, 6.12 zen kernel, gcc 13, openrc, wayland

NeddySeagoon
Administrator

Joined: 05 Jul 2003
Posts: 54665
Location: 56N 3W

Posted: Tue Jul 23, 2019 9:58 pm Post subject:

Maybe systemd will follow HAL into oblivion. They have some similarities. _________________ Regards, NeddySeagoon Computer users fall into two groups:- those that do backups those that have never had a hard drive fail.

Anon-E-moose
Watchman

Joined: 23 May 2008
Posts: 6186
Location: Dallas area

Posted: Tue Jul 23, 2019 10:22 pm Post subject:

NeddySeagoon wrote:

Maybe systemd will follow HAL into oblivion.
They have some similarities.

Possibly.
My original thought was no, it won't go there because RH is behind it, but then when I thought about it, I think they were behind HAL too.

I'm still waiting for the major hackers to target sys-d based linux systems and the fit to hit the shan :wink:

_________________
UM780, 6.12 zen kernel, gcc 13, openrc, wayland

tld
Veteran
Veteran

Joined: 09 Dec 2003
Posts: 1848

Posted: Tue Jul 23, 2019 11:34 pm Post subject:

Anon-E-moose wrote:

Things are going to get really interesting when RHEL 6 and CentOS 6 are EOLed at the end of 11/2020. I think there are likely a lot of admins holding onto their RHEL 6 servers for dear life trying to decide what to do. As to security, I wouldn't be the least bit surprised if the black hats out there have tons of systemd ammo that they've been holding on to until version 7 becomes more common.

In terms of the future of systemd, maybe I'm just thinking wishfully but I've wondered as to the effect of IBM buying RH. IBM bought RH almost entirely because of "the cloud" and related stuff. Just maybe they'll decide that having an "enterprise" Linux "server" that's actually suited to be a server (which face it, systemd with all it's desktop related baggage is NOT) trumps the RH motivation to make Linux their Windows. Again...rather wishful.

Tom

GDH-gentoo
Veteran
Veteran

Joined: 20 Jul 2019
Posts: 1778
Location: South America

Posted: Wed Jul 24, 2019 2:06 am Post subject:

Naib wrote:

saellaven wrote:

Naib wrote:

From the oft-cited-site-of-irrational-reasoning:
...

udev = systemd Needs to be fixed. it needs the concept of early boot and later boot.

As far as I can tell, udev itself is not a problem, at least on Gentoo. Eudev certainly isn't, and although I'm not going to check by installing it, I would even dare to say systemd's udev isn't either. I might have to add "for now", or "as long as split-usr is set", given what we are discussing here. If the right options were passed to meson, systemd-udevd will be in /lib/systemd, libudev will be in /lib (/lib64 for multilib profiles), internal udev executables like scsi_id will be in /lib/udev, and the rules files will be expected to be in /lib/udev/rules.d. All that is in the rootfs, so not a problem if /usr isn't present. Udev rules are a different story. systemd-udevd will just do what they tell it to do, and it is true that rules can invoke arbitrary programs, so it is an issue when exactly a rule's action is going to be carried out. But blaming udev for that is like feeding GCC a poorly written program, and blaming GCC when the resulting executable misbehaves at runtime.

So maybe it's time to dissect part of the "booting without /usr is broken" page

Booting without /usr is broken wrote:

One thing in advance: systemd itself is actually mostly fine with /usr on a separate file system that is not pre-mounted at boot time.

OK, likely true. For now.

Booting without /usr is broken wrote:

Quite a number of programs these days hook themselves into the early boot process at various stages. A popular way to do this is for example via udev rules.

Now the quoted question becomes relevant. How many of these programs are there, and why would they want to "hook themselves into the early boot process"? But a more immediate question would be: how often does this happen on Gentoo? It certainly doesn't happen on my Gentoo, which is admittedly rather minimal. But but let's say this is true.

Booting without /usr is broken wrote:

The binaries called from these rules are sometimes located on /usr/bin, or link against libraries in /usr/lib, or use data files from /usr/share. If these rules fail udev will proceed with the next one, however later on applications will then not properly detect these udev devices or features of these devices.

Then, generally speaking, this is a packaging error, isn't it? If these binaries come from a package that has a GNU-style build system, it looks like whoever built it passed the wrong --prefix, --bindir, --libdir, --datadir, etc. options to the configure script

However, up to this point all this is still a vague reference to "some programs".

Booting without /usr is broken wrote:

OK, I'm not sure what this is about, but see later.

Booting without /usr is broken wrote:

D-Bus

Not on Gentoo, or at least not with OpenRC. "D-Bus" isn't very specific either, I suppose it means "the dbus-daemon process for the system-wide message bus". And well: it is not needed at early boot. Its OpenRC service script contains a 'need localmount' in its depend() function, so it is guaranteed to run after all filesystems are mounted. Including /usr. So it doesn't matter how D-Bus is packaged. Unless, maybe, there is a certain PID 1 program that wants to communicate with the bus daemon early :wink:

? (unchecked, actually)

Booting without /usr is broken wrote:

LVM

Not on Gentoo. Like has been said, executables are in /sbin. Libraries are in /lib. Dynamic modules (if that's what they are) are in /lib/device-mapper. All that is in the rootfs, so not a problem if /usr isn't present. In fact, like I said, I take advantage of this. I have /usr in a LV, no initramfs, recent stable, unmodified OpenRC, and it all seems to work fine.

Booting without /usr is broken wrote:

...

I don't use those, so I can't comment.

Booting without /usr is broken wrote:

You don't believe us? Well, here's a command line that reveals a few obvious cases of udev rules that will silently fail to work if /usr is split off and not pre-mounted: egrep 'usb-db|pci-db|FROM_DATABASE|/usr' /*/udev/rules.d/*

OK, I tried this. And what came up? As far as I can tell, false positives. I have matches in a single udev rules file, /lib/udev/rules.d/78-sound-card.rules. It contains rules of this style:

Code:

ENV{ID_MODEL_FROM_DATABASE}=="<something>", do something

So they seem do something (set another property, actually) based on the value of device property ID_MODEL_FROM_DATABASE. Where does that come from? Earlier in the file there is this:

Code:

IMPORT{builtin}="hwdb"

OK, so running hwdb sets the property. This is not a real program, it is an udev builtin: its code is contained in the systemd-udev binary, which is in /lib/systemd. And what does this builtin do? Apparently, it reads device properties from a database, hwdb.bin. Where is this database? If the right options were passed to meson, either in /etc/udev, or in /lib/udev. All that is in the rootfs, so not a problem if /usr isn't present.

Booting without /usr is broken wrote:

-- and you find a lot more if you actually look for it. On my fresh Fedora 15 install that's 23 obvious cases.

Oooh, Fedora. Maybe that little detail has a lot to do with all of this?

So I guess the bottom line for me is "everything has been OK so far, just don't screw up now".

Last edited by GDH-gentoo on Wed Jul 24, 2019 11:40 am; edited 1 time in total

Naib
Watchman

Joined: 21 May 2004
Posts: 6069
Location: Removed by Neddy

Posted: Wed Jul 24, 2019 6:37 am Post subject:

I would appreciate if you correctly quoted... Only the 1st part is from me. All the rest of your quotes are from free desktop propoganda BUT you have not cited that so people do not know that. EVEN worse it reads as it if is mine.. _________________ #define HelloWorld int #define Int main() #define Return printf #define Print return #include <stdio> HelloWorld Int { Return("Hello, world!\n"); Print 0;

Fitzcarraldo
Advocate

Joined: 30 Aug 2008
Posts: 2056
Location: United Kingdom

Posted: Wed Jul 24, 2019 11:30 am Post subject:

NeddySeagoon wrote:

Maybe systemd will follow HAL into oblivion.
They have some similarities.

I have my doubts. systemd covers a lot more than HAL did; if systemd were to be kiboshed, many (most) Linux distributions would be up the creek without a paddle. I don't see that happening.
_________________
Clevo W230SS: amd64, VIDEO_CARDS="intel modesetting nvidia".
Compal NBLB2: ~amd64, xf86-video-ati. Dual boot Win 7 Pro 64-bit.
OpenRC systemd-utils[udev] elogind KDE on both.
My blog

GDH-gentoo
Veteran
Veteran

Joined: 20 Jul 2019
Posts: 1778
Location: South America

Posted: Wed Jul 24, 2019 11:41 am Post subject:

Naib wrote:

I would appreciate if you correctly quoted...

Sorry, I fixed the quotes.

Tony0945
Watchman

Joined: 25 Jul 2006
Posts: 5127
Location: Illinois, USA

Posted: Wed Jul 24, 2019 1:53 pm Post subject:

Fitzcarraldo wrote:

I have my doubts. systemd covers a lot more than HAL did; if systemd were to be kiboshed, many (most) Linux distributions would be up the creek without a paddle. I don't see that happening.

Even if they did, they would replace it with something even uglier, denser, more integrated. They plan to be Windows II not an improved Unix.
The goals are polar opposites. Monolithic vs modular. I HATE it! Sure, I could use it. I use XP every day., but preferably isolated in a VM.

Elleni
Veteran
Veteran

Joined: 23 May 2006
Posts: 1291

Posted: Wed Jul 24, 2019 7:25 pm Post subject:

NeddySeagoon wrote:

Elleni,

There is Olde Fashioned Gentoo
I need to publish an overlay that goes with that. How far do you want to go and determined are you?

Hey NeddySeagoon, thanks for your link. I'll do some reading and find out how determined I am, I'll come back to you when ready :wink:

NeddySeagoon
Administrator

Joined: 05 Jul 2003
Posts: 54665
Location: 56N 3W

Posted: Wed Jul 24, 2019 9:38 pm Post subject:

Tony0945,

Tony0945 wrote:

Fitzcarraldo wrote:

I have my doubts. systemd covers a lot more than HAL did; if systemd were to be kiboshed, many (most) Linux distributions would be up the creek without a paddle. I don't see that happening.

There is no plan and no systems design. Look how systemd just grew.

Given proper planning, design and testing, its possible that systemd could have fixed all the problems it was supposed to address without introducing lots of news ones.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.

Display posts from previous:

	Gentoo Forums Forum Index Gentoo Chat	All times are GMT Goto page Previous 1, 2, 3, 4, 5, 6 Next
Page 2 of 6

Jump to:

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

Copyright 2001-2025 Gentoo Foundation, Inc. Designed by Kyle Manna © 2003; Style derived from original subSilver theme. | Hosting by Gossamer Threads Inc. © | Powered by phpBB 2.0.23-gentoo-p11 © 2001, 2002 phpBB Group
Privacy Policy