| View previous topic :: View next topic |
| Author |
Message |
depontius
Advocate
Joined: 05 May 2004
Posts: 3509
|
 Posted: Tue Jan 09, 2018 1:55 pm Post subject: |
 |
|
| jd2066 wrote: | Yeah and some of that complexity can be seen in the systemd.exec man page that lists all the various things you can put in a unit file.
I guess sense unit files can't just have code added like init scripts can, they needed to add an option for many of the known things that init scripts did. |
I have a pet saying, "Every specialty / configuration language aspires to be Turing-complete, and keeps getting enhanced until it gets there." At least init scripts were up-front about it. I've seen (and done, once or twice) way too many examples that weren't, and their means of achieving Turing-completeness can be incredibly awkward.
_________________
.sigs waste space and bandwidth |
|
| Back to top |
|
 |
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Sun Jan 14, 2018 7:02 pm Post subject: |
|
|
| steveL wrote: | | initramfs mandated by systemdbust |
| mv wrote: | | It is not a problem to use systemd without initramfs. |
I meant the udev fiasco, when "separate /usr is broken" became "separate /usr is broken without an initramfs" (because we've learnt we can't just magically remove separate /usr partitions.. serious users won't let us.)
systemdbust were definitely the team who brought us that bit of bulshytt.
My apologies for the confusion in terms. |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Sun Jan 14, 2018 7:11 pm Post subject: |
|
|
| jd2066 wrote: | Yeah and some of that complexity can be seen in the systemd.exec man page that lists all the various things you can put in a unit file.
I guess sense unit files can't just have code added like init scripts can, they needed to add an option for many of the known things that init scripts did. |
| depontius wrote: | | I have a pet saying, "Every specialty / configuration language aspires to be Turing-complete, and keeps getting enhanced until it gets there." At least init scripts were up-front about it. |
Bingo. And still are :-)
That's why it's much simpler just to start with an actual syntax: you can keep it as simple as you like, but you can also extend it, years down the road when it's needed.
All useful programs read input, and that input always implies a (usually very simple, at first) format. It's the internal languages that the professional tester needs to find (assuming the programmers know the basics.) cf: Beizer (ibid.) | Quote: | | I've seen (and done, once or twice) way too many examples that weren't, and their means of achieving Turing-completeness can be incredibly awkward. |
Indeed, and all we're seeing here, is YAF another example learning the hard way (instead of doing the basic research, or y'know, just listening to the people already working in the space.) |
|
| Back to top |
|
|
berferd
Tux's lil' helper
Joined: 13 May 2004
Posts: 117
|
| Posted: Sun Jan 14, 2018 8:42 pm Post subject: |
|
|
| jd2066 wrote: |
Yeah and some of that complexity can be seen in the systemd.exec man page that lists all the various things you can put in a unit file.
I guess sense unit files can't just have code added like init scripts can, they needed to add an option for many of the known things that init scripts did. |
But there's more than one man page that lists the various things that can go into a unit file:
https://www.freedesktop.org/software/systemd/man/systemd.service.html
I had to write a unit file for work, unfortunately. I spent an afternoon reading the docs to make sure I understood what I was writing. It was not a pleasant experience. It feels like layer after layer of hacks to emulate a scripting language badly, precisely like you say.
Check out their "Network targets":
https://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/
"network.target has very little meaning during start-up."
And also, we've been dealing with this in our prod systems:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=864341
No, moving to a systemd distro was not my idea. |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6747
|
| Posted: Mon Jan 15, 2018 5:33 am Post subject: |
|
|
| steveL wrote: | I meant the udev fiasco, when "separate /usr is broken" became "separate /usr is broken without an initramfs" (because we've learnt we can't just magically remove separate /usr partitions.. serious users won't let us.)
systemdbust were definitely the team who brought us that bit of bulshytt. |
I had understood that you had meant that, but AFAIK neither systemd nor udev have explicit dependencies for a non-separate /usr on boot: It is non-sane applications like polkit or bluetooth drivers which have that crazy dependencies, and you have the same problems with these applications, no matter whether you use systemd+udev or any other boot system like openrc+eudev. It is correct 'though that the recommendation in the systemd docs is to have an initramfs in case of a separate /usr due to these problem. |
|
| Back to top |
|
|
jd2066
Apprentice
Joined: 04 Jun 2006
Posts: 155
|
| Posted: Mon Jan 15, 2018 1:18 pm Post subject: |
|
|
| steveL wrote: | | I meant the udev fiasco, when "separate /usr is broken" became "separate /usr is broken without an initramfs" (because we've learnt we can't just magically remove separate /usr partitions.. serious users won't let us.) |
According to the Booting Without /usr is Broken page, booting without /usr being available (i.e. Not part of the root file system or mounted via initrd) was something the didn't work correctly even before systemd came into the picture because "programs these days hook themselves into the early boot process at various stages" and because many of those programs can be "located on /usr/bin, or link against libraries in /usr/lib, or use data files from /usr/share", if /usr is not available for those programs during boot then you can experience silent failures from those programs and some things will not work.
If /usr is part of the root file system or mounted in an initrd then this isn't a problem and those program will run just fine.
I'm not expert on the subject though so I cannot really say if that is correct about that but the explanation seems to make sense and using an initrd is fairly simple due the programs available to generate them like gen-kernel so it doesn't seem like a big deal anyway.
| berferd wrote: | | But there's more than one man page that lists the various things that can go into a unit file: |
Yep, you are correct, I just looked at the systemd man pages and this is what I found:
General / basic definition of unit files:
* systemd.unit - Lists what unit files are, some general options and links to configuration for each unit type.
Configuration for each unit type:
* systemd.service
Replaces init scripts, service monitors like monit, and possibly other things.
* systemd.socket
Used for socket-based activation (Not really sure what that is).
* systemd.path
Used for path-based activation (Not really sure what that is).
* systemd.timer
Used for timer-based activation like to start a program based on what time it is.
It can be used instead of cron in some cases (maybe all, I'm not sure).
* systemd.device
This unit type "encodes information about a device unit". (Not sure what this means)
* systemd.mount
From the page "Mount units may either be configured via unit files, or via /etc/fstab" and "In general, configuring mount points through /etc/fstab is the preferred approach"
It seems the reason for this type is internal use by systemd as fstab is preferred and the entries in fstab are made into dynamic mount units by [url=systemd-fstab-generator]systemd-fstab-generator[/url] for systemd to use.
* systemd.automount
I'm not sure what the difference between this and the systemd.mount type is.
* systemd.swap
This unit type can mount swap devices or swap files.
For swap devices, configuration can be done via fstab and [url=systemd-fstab-generator]systemd-fstab-generator[/url] will parse it to turn it into a dynamic swap unit.
* systemd.target
From man page "Target units [...] exist merely to group units via dependencies (useful as boot targets), and to establish standardized names for synchronization points used in dependencies between units. Among other things, target units are a more flexible replacement for SysV runlevels in the classic SysV init system."
I guess this replaces the need to manage run levels as the systemd target functions handle this kind of functionality automatically.
* systemd.slice
From man page "A slice unit is a concept for hierarchically managing resources of a group of processes. This management is performed by creating a node in the Linux Control Group (cgroup) tree. Units that manage processes (primarily scope and service units) may be assigned to a specific slice."
I'm not sure what this means.
* systemd.scope
From the man page "Scope units are not configured via unit configuration files, but are only created programmatically using the bus interfaces of systemd. [...] Unlike service units, scope units manage externally created processes, and do not fork off processes on its own. The main purpose of scope units is grouping worker processes of a system service for organization and for managing resources."
I'm not sure what this means.
Shared options available for different service types:
* systemd.exec - Options for the execution environment used
* systemd.kill - Options for how systemd should kill a process
* systemd.resourcecontrol - Options for "resource control of spawned processes"
Reading the page, the reasoning is that "Modern networking tends to be highly dynamic" so all software using network functions should just watch for network status changes instead of using the network targets.
According to the page "software that assumes continuous network is available" is "of the simple non-well-written kind".
The pages lists 3 approaches for software to do this: Monitor rtnlink, use pseudo-addresses that "are unconditionally available" and using IP_FREEBIND sockopt.
You can use the network-online.target unit file for software that need to wait for a "routable IP address" to be setup.
Any remote mounts in fstab will use this target automatically.
If no services use this target and no remote mounts exist then the "target is not pulled into the boot, thus avoiding any delays during boot should the network not be available".
In general, it appears the main thing systemd does that init systems like openrc don't do is dependency management beyond just services.
So services can depend on the existence of sockets, file paths, mount points, devices, etc.
For services that don't specify those but still have a dependency then systemd will do it's best to figure out what the dependency is and create dynamic unit files for them so that systemd can create the best order of starting services that will ensure that started service has all the things it requires to run and do so as fast as possible.
Also after booting, systemd can manage all those things if something needs to be done as it knows all of that information.
This is likely why systemd needs to have control of many things that other init systems don't like managing the mounting of file systems, setting up swap files/partitions, syncing time via a built-in service so anything that needs correct time will have it, etc.
This of course leads to the inevitable questions of as systemd grows, how much functionality that was provided via independent software packages will be replaced with systemd functionality and where did does it end.
In theory, this should have an end point where systemd is declared to have core functionally in a complete state with a stable API / ABI for other programs to use that programs can trust will not just suddenly change.
At least that is how it appears software development is normally done.
With systemd being in development for at least 8 years now and that not being the case, it appears the systemd developers have a different idea of how to do software development. |
|
| Back to top |
|
|
Tony0945
Watchman
Joined: 25 Jul 2006
Posts: 5127
Location: Illinois, USA
|
| Posted: Mon Jan 15, 2018 1:41 pm Post subject: |
|
|
| jd2066 wrote: | According to the Booting Without /usr is Broken page, booting without /usr being available (i.e. Not part of the root file system or mounted via initrd) was something the didn't work correctly even before systemd came into the picture because "programs these days hook themselves into the early boot process at various stages" and because many of those programs can be "located on /usr/bin, or link against libraries in /usr/lib, or use data files from /usr/share", if /usr is not available for those programs during boot then you can experience silent failures from those programs and some things will not work.
If /usr is part of the root file system or mounted in an initrd then this isn't a problem and those program will run just fine. |
THAT is the heart of the problem: fixing the wrong thing. It was those errant programs that had the bug i,e. they were built in the false assumption that /usr was always available during the boot process. So to accommodate those buggy programs, the init system was hamstrung instead of fixing/patching the programs; which is what several posters are complaining about. Instead of building on what exists and works, today's developers (in general, not just Gentoo developers) want to reinvent the wheel. I might add that desiring to create elaborate integrated packages directly contravening the unix philosophy is a separate but equal mistake.
Note, I have never used a separate /usr and don't expect every too, but it is a legitimate use case and used to work, then was deliverately broken because of buggy application programs. |
|
| Back to top |
|
|
Tony0945
Watchman
Joined: 25 Jul 2006
Posts: 5127
Location: Illinois, USA
|
| Posted: Mon Jan 15, 2018 1:48 pm Post subject: |
|
|
| jd2066 wrote: | | In theory, this should have an end point where systemd is declared to have core functionally in a complete state with a stable API / ABI for other programs to use that programs can trust will not just suddenly change.[ |
That endpoint is when all user functionality is brought into the operating system ala Windows(TM). cf The lawsuit regarding integrating IE into the OS and Microsoft's court filing alleging that an operating system by definition included a web browser.
As to when, it is when they stop backward tinkering, which is never. |
|
| Back to top |
|
|
jd2066
Apprentice
Joined: 04 Jun 2006
Posts: 155
|
| Posted: Mon Jan 15, 2018 2:58 pm Post subject: |
|
|
| Tony0945 wrote: | | THAT is the heart of the problem: fixing the wrong thing. It was those errant programs that had the bug i,e. they were built in the false assumption that /usr was always available during the boot process. |
From what I read on that page, it wasn't that simple as according to the FHS the top level directories are for binaries and libraries required for the system to boot up and the /usr directories are for binaries and libraries as for the things used after booting up.
If an application is primarily used after booting but runs some commends during boot via something like a udev rule then it's not quite clear where the program and it's libraries should go.
In the end, it seems it was decided the separation was pointless so for Fedora and other distros that did the UsrMerge, only /usr is used for storing binaries and shared libraries which does then force initrd to be used if /usr is on another partition because there is no top-level directories (only symlinks to /usr) with just essential boot binaries and libraries.
I guess weather that was the right call or if more effect should have been done to allow things to work as before is a matter of debate and I'm not sure what the right answer on that is.
I'm not sure of the point of storing /usr on a separate partition anyway but I guess some users think it's a good idea. |
|
| Back to top |
|
|
NeddySeagoon
Administrator
Joined: 05 Jul 2003
Posts: 54232
Location: 56N 3W
|
| Posted: Mon Jan 15, 2018 3:11 pm Post subject: |
|
|
jd2066,
/usr can be shared via NFS to as many systems as you need.
It can also be be mounted read only if you are really paranoid.
What was the root filesystem has moved into the initrd and the old root has became user.
plus ça change, plus c'est la même chose
All that's added is the complexity of the initrd.
A system should be able to boot and give an admin a root shell with /usr empty and without an initrd.
That's how you determine what goes what goes where.
udev is broken by by design and has been for many years.
_________________
Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
| Back to top |
|
|
jd2066
Apprentice
Joined: 04 Jun 2006
Posts: 155
|
| Posted: Mon Jan 15, 2018 3:50 pm Post subject: |
|
|
| NeddySeagoon wrote: | /usr can be shared via NFS to as many systems as you need.
It can also be be mounted read only if you are really paranoid. |
What is the reason for NFS mounting /usr?
Is it so all the system have up to date packages that install in /usr?
If so, I'm not sure if that would work with a package manager.
Is it to save space on individual systems?
Doesn't seem like you would save enough space for it to be worth it unless the systems had really small hard drives.
| NeddySeagoon wrote: | A system should be able to boot and give an admin a root shell with /usr empty and without an initrd.
That's how you determine what goes what goes where. |
That makes sense though not possible in some cases such as the root file system on an LVM volume (it requires an initrd to mount the LVM volume).
| NeddySeagoon wrote: | | udev is broken by by design and has been for many years. |
Are you saying udev has been broken since the first version or some time after that?
If it's the former then how did systems manage /dev without udev?
Last edited by jd2066 on Mon Jan 15, 2018 3:51 pm; edited 1 time in total |
|
| Back to top |
|
|
krinn
Watchman
Joined: 02 May 2003
Posts: 7470
|
| Posted: Mon Jan 15, 2018 3:51 pm Post subject: |
|
|
| jd2066 wrote: | | I'm not sure of the point of storing /usr on a separate partition anyway but I guess some users think it's a good idea. |
For (even more) two primary reasons:
* remove files from / and store them in /usr that is on another (not really partition) but disk: your / is lacking space and /usr provide that extra space ; which of today makes a little "less" sense, because hdd are cheap and big. But for early days, you couldn't really afford to discard the disk use by / that wasn't cheap at all ; so it was doable to store something on floppy, or another disk, and reclaims space from / by migrating what is not necessary to boot in /usr (you care about man pages?)
* use of a read-only /usr or nfs /usr ; because you may export /usr to all your systems and all will have access to /usr content, but this content is not duplicate on all systems (you loose space for man pages, but all systems could use man page as your server is exporting them ready to use), again space and money saver. But also ease handling of everything: if a user specially ask "hey dude, i need man page of gcc!", providing gcc man pages on your server allow all systems to have access to gcc man pages without having to update all systems.
There's a lot of reasons, but these two ones are the ones early system: hdd weren't cheap at all, and small (remember because they weren't big, / space could become a problem fast).
Today even /usr on separate partition is worth, if you crypt it, your system should work fine, and when you mount it, you uncrypt its content to use it, but until it is mount, its content is crypt.
So you may argue, that most of these reasons were valid for "early system", as of today, they maybe not. Maybe, but it's not because it's an old practice that it doesn't work, it was working fine, and even if you don't yourself have any reasons to use it, it doesn't remove the fact is was working fine.
It's when you start thinking: ok i don't gives a fuck about /usr on separate partition that you start breaking it : you start installing cirtical to boot programs in /usr and this will break it.
And after you have create some more programs doing that: you can create a program that proudly claim: "my program is working fine with /usr on separate partition, because it doesn't use itself anything in /usr for writing, and doesn't need to read in early boot something that is in /usr : i'm only the messenger there".
Seriously, only the messenger? Who has done the shit of using /usr/sbin first when LFHS told you not to do so, who made most of those buggy programs that use /usr to write something in it or read something on early boot?
Who is the fuckhead that create exception rule that break /usr ????Look at that:
| https://www.freedesktop.org/software/systemd/man/hwdb.html wrote: | | The content of all hwdb files is read by systemd-hwdb and compiled to a binary database located at /etc/udev/hwdb.bin, or alternatively /usr/lib/udev/hwdb.bin |
It mean: if you use /etc/udev/hwdb.bin than you are doing it good!
But if you start using /usr/lib/udev/hwdb.bin you are doing it all wrong:
1/ You don't know the problems because you are a shithead packager without knowledge from unix
2/ Worst, you are using that because "someone" has allow you to do so, and if that someone knows nobody should do that ; then why he has create it???
So systemd can claim all it wish "i'm just the messenger" ; this show systemd authors knows the problem, and indeed use /etc/udev/hwdb.bin, but they gently allow everyone not knowing a shit about it, to create problems by using /usr/lib/udev/hwdb.bin.
And it's the same for the symlink case with /sbin /usr/sbin: if you want stay safe yourself, keep installing in /sbin critical to boot programs, but if you start thinking "oh well, what's the diff anyway? Oh and maybe one time they will remove /sbin, so the logical safe choice is to install my critical to boot program in /usr/sbin, hooray i'm so smart!!!"
So no, you aren't smart, just a douche that fall in the trap put by people who knows, and once you were trapped, they will use YOUR program bad behaviour to claim THEIR program is only the messenger.
Just the messenger??? Or more "Messenger of hell in disguise"? |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Mon Jan 15, 2018 4:10 pm Post subject: |
|
|
| steveL wrote: | | I meant the udev fiasco, when "separate /usr is broken" became "separate /usr is broken without an initramfs" (because we've learnt we can't just magically remove separate /usr partitions.. serious users won't let us.) |
| jd2066 wrote: | According to the Booting Without /usr is Broken page
..
I'm not expert on the subject though so I cannot really say if that is correct about that but the explanation seems to make sense and using an initrd is fairly simple due the programs available to generate them like gen-kernel so it doesn't seem like a big deal anyway. |
So "everything's all right, then, we can keep trusting these people?" No.
This is what keeps happening: someone well-meaning reads the upstream propaganda, which like any good sales-pitch, "seems to make sense", and then we have to keep correcting the mistaken perceptions engendered by that propaganda.
None of this is very interesting to a programmer.
So I'll let the sysadmins in the crew do their end-user hand-holding thing instead. ;-)
They're much better at the explanation thing, than I am; I learnt that lesson well from ##bash.
--
You don't need to know the reasons why an admin wants to use something: that's a rabbit-hole that leads to frustration and irritation on both sides.
That they do, is enough (or should be.)
IOW: stop questioning the basis, and deal with the actuality: separate /usr is used for all sorts of reasons, none of which excuse breaking a simple use-case that has worked for over 40 years. |
|
| Back to top |
|
|
jd2066
Apprentice
Joined: 04 Jun 2006
Posts: 155
|
| Posted: Mon Jan 15, 2018 4:14 pm Post subject: |
|
|
| krinn wrote: | For (even more) two primary reasons:
* remove files from / and store them in /usr that is on another (not really partition) but disk: your / is lacking space and /usr provide that extra space ; which of today makes a little "less" sense, because hdd are cheap and big. But for early days, you couldn't really afford to discard the disk use by / that wasn't cheap at all ; so it was doable to store something on floppy, or another disk, and reclaims space from / by migrating what is not necessary to boot in /usr (you care about man pages?)
* use of a read-only /usr or nfs /usr ; because you may export /usr to all your systems and all will have access to /usr content, but this content is not duplicate on all systems (you loose space for man pages, but all systems could use man page as your server is exporting them ready to use), again space and money saver. But also ease handling of everything: if a user specially ask "hey dude, i need man page of gcc!", providing gcc man pages on your server allow all systems to have access to gcc man pages without having to update all systems.
There's a lot of reasons, but these two ones are the ones early system: hdd weren't cheap at all, and small (remember because they weren't big, / space could become a problem fast). |
Right that makes since.
| krinn wrote: | | Today even /usr on separate partition is worth, if you crypt it, your system should work fine, and when you mount it, you uncrypt its content to use it, but until it is mount, its content is crypt. |
I don't understand what the point of this would be.
If you are crypting things wouldn't you just crypt the whole root file system?
| krinn wrote: | | So you may argue, that most of these reasons were valid for "early system", as of today, they maybe not. Maybe, but it's not because it's an old practice that it doesn't work, it was working fine, and even if you don't yourself have any reasons to use it, it doesn't remove the fact is was working fine. |
Yeah, I suppose that is true.
| krinn wrote: | | [a lot of text] |
This part was kind of rant like and I didn't quite understand it all.
I would have to look into the "I'm just messenger" thing as the files going into /usr were from things like udev, NetworkManager, PulseAudio, LVM, etc. so not systemd but as all those things seem to have been developed by RedHat and and systemd is developed by RedHat too then it's possible that it's the same developers who did those changes and later claimed to just be a messenger.
I don't fully understand hwdb.bin so I'm not sure what you are referring to.
On the merging of bin and sbin, that is listed in the systemd man pages but I'm not sure if any distros have actually done that. |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Mon Jan 15, 2018 4:18 pm Post subject: |
|
|
| steveL wrote: | I meant the udev fiasco, when "separate /usr is broken" became "separate /usr is broken without an initramfs" (because we've learnt we can't just magically remove separate /usr partitions.. serious users won't let us.)
systemdbust were definitely the team who brought us that bit of bulshytt. |
| mv wrote: | | I had understood that you had meant that, but AFAIK neither systemd nor udev have explicit dependencies for a non-separate /usr on boot: It is non-sane applications like polkit or bluetooth drivers which have that crazy dependencies, and you have the same problems with these applications, no matter whether you use systemd+udev or any other boot system like openrc+eudev. It is correct 'though that the recommendation in the systemd docs is to have an initramfs in case of a separate /usr due to these problem. |
You mean, polkit as brought to us by the same systemdbust crowd?
So in a nutshell:
"We wrote some shitty programs, that break early startup, because we force them on everyone and we don't know what we're doing. So now everyone, separate usr is broken."
"OK, OK, separate usr without initramfs is broken; don't blame us, we're just the messenger."
Yeah, right. |
|
| Back to top |
|
|
NeddySeagoon
Administrator
Joined: 05 Jul 2003
Posts: 54232
Location: 56N 3W
|
| Posted: Mon Jan 15, 2018 4:23 pm Post subject: |
|
|
jd2066,
A long time ago, there was a completely static /dev. Its still there is the stage3 tarball but the kernel mounts tmpfs /dev over the top, so you don't see it.
A static /dev still works too but it needs some additions to the /dev in the stage3.
The first replacement for the static /dev was devfs. udev competed with devfs for a while, then the devfs kernel maintainer vanished, leaving udev.
At this time all these different ways af managing /dev were compatible with a separate /usr and being able to boot with /usr missing.
It was some time later that that udev came to depend on /usr. It went through a phase of depending on /var too.
_________________
Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
| Back to top |
|
|
Tony0945
Watchman
Joined: 25 Jul 2006
Posts: 5127
Location: Illinois, USA
|
| Posted: Mon Jan 15, 2018 4:38 pm Post subject: |
|
|
@krinn:
Very good explanation. I have another use case. When I worked as a consultant at various Motorola divisions the C compiler and tools were mounted on a network dtive. This was probably an NFS drive. Why? So that all developers were using the exact same revision of tools and libraries. Why not duplicate them all on local PC's? They were dozens of developers. It's simpler to administer at one location. Update that one location (a mainframe) and don't worry about rolling out the changes and whether code is going back into the repository that only builds with old tools. The alternative is a Gestapo gong around examining all the cubicles. |
|
| Back to top |
|
|
krinn
Watchman
Joined: 02 May 2003
Posts: 7470
|
| Posted: Mon Jan 15, 2018 4:52 pm Post subject: |
|
|
| jd2066 wrote: | | If you are crypting things wouldn't you just crypt the whole root file system? |
you may at will: use non crypt /, use a different encryption for / and /usr... That's linux, you do what you wish.
| jd2066 wrote: | This part was kind of rant like and I didn't quite understand it all.
I would have to look into the "I'm just messenger" thing as the files going into /usr were from things like udev, NetworkManager, PulseAudio, LVM, etc. so not systemd but as all those things seem to have been developed by RedHat and and systemd is developed by RedHat too then it's possible that it's the same developers who did those changes and later claimed to just be a messenger. |
Yeah that. But also trapping other devs, then cite their programs as proof, because out of the list, 99% were made by you, still having a 1% not made by you may prove you weren't alone doing shit.
| jd2066 wrote: | | I don't fully understand hwdb.bin so I'm not sure what you are referring to. |
udev/systemd use hwdb to match pci/usb devices vendor:product_id number with a driver, so the magic of udev/systemd loading the right driver for your device comes from just a lookup table, if you have it in /etc, this mean udev/systemd are able to boot and still able to match device and driver, so still able to autoload modules need for your devices.
And if someone package it in /usr, then when you boot, and /usr is not there, udev/systemd cannot read it, so no more autoload of modules
| jd2066 wrote: | | On the merging of bin and sbin, that is listed in the systemd man pages but I'm not sure if any distros have actually done that. |
Well, i think all systemd distro will.
And gentoo doesn't not, but it doesn't mean systemd zealots didn't try this
They have attack gentoo for the sole purpose of pushing systemd: there's no benefits from asking such changes for gentoo, only to push gentoo more into systemd hands.
They have succeed here
So this prove the cancer systemd is, not the program itself, but the politics behind it, this kind of one ring to rules them all.
That's why everyone keep claiming we're systemd haters or whatever, when we (at least me) don't gives a fuck at systemd the program, but do care about the systemd politics, and this thread name is perfectly set, it's not about systemd, but the systemd politics.
And i don't care if /usr is working or not for systemd users, but it's different if you do that on all users, even the ones not using systemd. |
|
| Back to top |
|
|
Tony0945
Watchman
Joined: 25 Jul 2006
Posts: 5127
Location: Illinois, USA
|
| Posted: Mon Jan 15, 2018 4:54 pm Post subject: |
|
|
| NeddySeagoon wrote: | A long time ago, there was a completely static /dev. Its still there is the stage3 tarball but the kernel mounts tmpfs /dev over the top, so you don't see it.
A static /dev still works too but it needs some additions to the /dev in the stage3. |
Back in thdays of RedHat 5.x and maybe thru 7.x, they used a static dev in which every conceivable driver was built into the kernel and their were static block and characters devices in /dev that pointed to those tables regardless of whether the corresponding hardware existed or not!
One problem with that was "how many hard drives do you build in?" A boot-time discoverable /dev made sense on a mass binary distribution as a static /dev (augmented by hot plugging) makes sense on your individual system. The sin was putting udev in /usr/lib/udev instead of /lib/udev as code required at boot should be.
Look at this mishmash: | Code: | tony@X3 ~ $ equery f eudev |grep -v /usr/share|grep -v include
/bin
/bin/udevadm
/etc
/etc/init.d
/etc/init.d/udev-postmount
/etc/udev
/etc/udev/hwdb.d
/etc/udev/rules.d
/etc/udev/udev.conf
/lib
/lib/udev
/lib/udev/accelerometer
/lib/udev/ata_id
/lib/udev/cdrom_id
/lib/udev/collect
/lib/udev/mtd_probe
/lib/udev/rule_generator.functions
/lib/udev/rules.d
/lib/udev/rules.d/40-gentoo.rules
/lib/udev/rules.d/42-usb-hid-pm.rules
/lib/udev/rules.d/50-firmware.rules
/lib/udev/rules.d/50-udev-default.rules
/lib/udev/rules.d/60-cdrom_id.rules
/lib/udev/rules.d/60-drm.rules
/lib/udev/rules.d/60-keyboard.rules
/lib/udev/rules.d/60-persistent-alsa.rules
/lib/udev/rules.d/60-persistent-input.rules
/lib/udev/rules.d/60-persistent-serial.rules
/lib/udev/rules.d/60-persistent-storage-tape.rules
/lib/udev/rules.d/60-persistent-storage.rules
/lib/udev/rules.d/60-persistent-v4l.rules
/lib/udev/rules.d/61-accelerometer.rules
/lib/udev/rules.d/64-btrfs.rules
/lib/udev/rules.d/75-cd-aliases-generator.rules
/lib/udev/rules.d/75-net-description.rules
/lib/udev/rules.d/75-persistent-net-generator.rules
/lib/udev/rules.d/75-probe_mtd.rules
/lib/udev/rules.d/75-tty-description.rules
/lib/udev/rules.d/78-sound-card.rules
/lib/udev/rules.d/80-drivers.rules
/lib/udev/rules.d/95-udev-late.rules
/lib/udev/scsi_id
/lib/udev/v4l_id
/lib/udev/write_cd_rules
/lib/udev/write_net_rules
/lib64
/lib64/libudev.so.1
/lib64/libudev.so.1.6.0
/sbin
/sbin/udevadm
/sbin/udevd
/usr
/usr/lib32
/usr/lib32/libgudev-1.0.so
/usr/lib32/libgudev-1.0.so.0
/usr/lib32/libgudev-1.0.so.0.2.0
/usr/lib32/libudev.so
/usr/lib32/libudev.so.1
/usr/lib32/libudev.so.1.6.0
/usr/lib32/pkgconfig
/usr/lib32/pkgconfig/gudev-1.0.pc
/usr/lib32/pkgconfig/libudev.pc
/usr/lib64
/usr/lib64/girepository-1.0
/usr/lib64/girepository-1.0/GUdev-1.0.typelib
/usr/lib64/libgudev-1.0.so
/usr/lib64/libgudev-1.0.so.0
/usr/lib64/libgudev-1.0.so.0.2.0
/usr/lib64/libudev.so
/usr/lib64/pkgconfig
/usr/lib64/pkgconfig/gudev-1.0.pc
/usr/lib64/pkgconfig/libudev.pc
|
|
|
| Back to top |
|
|
NeddySeagoon
Administrator
Joined: 05 Jul 2003
Posts: 54232
Location: 56N 3W
|
| Posted: Mon Jan 15, 2018 4:57 pm Post subject: |
|
|
Tony0945,
I get | Code: | $ equery f eudev |grep -v /usr/share|grep -v include
!!! No installed packages matching 'eudev' |
:)
_________________
Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
| Back to top |
|
|
dmpogo
Advocate
Joined: 02 Sep 2004
Posts: 3267
Location: Canada
|
| Posted: Mon Jan 15, 2018 8:21 pm Post subject: |
|
|
| jd2066 wrote: | | NeddySeagoon wrote: | /usr can be shared via NFS to as many systems as you need.
It can also be be mounted read only if you are really paranoid. |
What is the reason for NFS mounting /usr?
Is it so all the system have up to date packages that install in /usr?
If so, I'm not sure if that would work with a package manager.
|
For many of us, me including, Unix is primarily distributed, largely network transparent OS. I spent my young years (circa 1992) having 10 telnet windows + couple of graphics windows
opened on 4 different servers on 3 continents at the same time. I never bother to check where the disks which hosts the software are, certainly they were not attached to my workstation.
In this model booting a local station and running software are completely unrelated things, and make boot process dependent on storage that mostly hosts userland soft is a design madness.
It is a model completely opposite to a single user laptop/phone, which seemed now had grabbed most attention. |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6747
|
| Posted: Mon Jan 15, 2018 8:47 pm Post subject: |
|
|
| steveL wrote: | | You mean, polkit as brought to us by the same systemdbust crowd? |
I was told that polkit development was mainly driven by ubuntu. Is this information wrong? |
|
| Back to top |
|
|
Naib
Watchman
Joined: 21 May 2004
Posts: 6051
Location: Removed by Neddy
|
| Posted: Mon Jan 15, 2018 8:58 pm Post subject: |
|
|
| mv wrote: | | steveL wrote: | | You mean, polkit as brought to us by the same systemdbust crowd? |
I was told that polkit development was mainly driven by ubuntu. Is this information wrong? |
It is developed and maintained by David Zeuthen from Red Hat and hosted by the freedesktop.org project.
| Code: |
git clone git://anongit.freedesktop.org/polkit
...
cd polkit
...
git log --format='%aN' | sort -u
707 David Zeuthen
64 Miloslav Trmač
32 Colin Walters
11 Michael Biebl
7 Matthias Clasen
6 Danny Kukawka
6 Richard Hughes
5 Jim Meyering
4 Carlos Corbacho
4 Jeremy Linton
3 Doug Goldstein
3 Joe Marcus Clarke
3 Kay Sievers
3 Martin Pitt
3 Philip Withnall
2 Anders Jonsson
2 Dariusz Gadomski
2 Nikki VonHollen
2 Rui Matos
2 Ryan Lortie
2 Tomas Chvatal
2 Vincent Untz
2 Yanko Kaneti
1 Adam Jackson
1 Adrian Bunk
1 Alan Near
1 Alexander Sack |
_________________
| Quote: | | Removed by Chiitoo |
|
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Tue Jan 16, 2018 2:01 pm Post subject: |
|
|
I'm not getting into a rehash of history; polkit has always been part of the "gentle Putsch", along with consolekit, logind etc.
At the time, many of us said "why not just use PAM?" which was widely rubbished by the systemdbust crowd.
Wind forward a few years later, and polkit pretty much wraps PAM.
And no, just because PAM was originally developed back in the days when RedHat was still a collaborative player (ie the 1990s) does not mean the RedHatMegaPlex division of a huge multinational conglomeration, is our friend. |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6747
|
| Posted: Tue Jan 16, 2018 5:27 pm Post subject: |
|
|
| steveL wrote: | | I'm not getting into a rehash of history; polkit has always been part of the "gentle Putsch", along with consolekit, logind etc. |
All the *kit rubbish was originally developed by canonical according to arguments I heard several times in discussions. AFAIK, the only relation to systemd to it was that at some point a consolekit clone had been implemented by systemd under the name "logind" in the usual NIH manner. I had never checked these informations, but I have heard them so often in discussions that I had no doubts about them. |
|
| Back to top |
|
|
|
|
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
|
|
Gentoo Chat
