| View previous topic :: View next topic |
| Author |
Message |
CasperVector
Apprentice
Joined: 03 Apr 2012
Posts: 156
|
 Posted: Thu Jan 11, 2018 3:46 pm Post subject: |
 |
|
| jd2066 wrote: | So far in my system administration of a Gentoo Linux system with openrc, the lack of automatic tmpfiles management hasn't really seemed to be an much of an issue.
There maybe some tmpfiles that got left in /tmp but it doesn't seem to really cause any issues to just ignore it (unless the tmp files are really big for some reason) so I'm not sure of the necessity of the systemd-tmpfiles daemon. |
This seems to be mainly about systemd-tmpfilesd, but I think my stance on opentmpfiles might be a useful reference; of course, you can also find other people's opinions on tmpfiles in these links.
_________________
My current OpenPGP key:
RSA4096/0x227E8CAAB7AA186C (expires: 2020.10.19)
7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C |
|
| Back to top |
|
 |
khayyam
Watchman
Joined: 07 Jun 2012
Posts: 6227
Location: Room 101
|
| Posted: Thu Jan 11, 2018 10:01 pm Post subject: |
|
|
| khayyam wrote: | | My argument has been fairly clear from the outset, firstly, what are the standards involved (why are system binaries in /lib ... or config files in /usr/lib) and who is setting them, and for what reason. Secondly, does the introduction of said standards, and/or mechanisms (specifically tmpfiles.d), solve an actual problem, and does the solution make the system more robust. So, if you can answer to those particular arguments, then we are having a discussion, otherwise, if you pick around the edges, then it is, as you say, "fruitless". |
| jd2066 wrote: | | Oh, I get it now. Your argument wasn't specifically about systemd or it's components but rather any developers of a piece of software that uses their own ideas for how something should work because they think it's best even when the idea is not better then the current standard or is better but not enough to make it worth bothering with. Thus the point was more about mentioning systemd and it's components as an example of this happening instead of being the argument being restricted to why certain things were done and if there was a good idea behind them. |
Yes, and no, there is a relation between the two, systemd seems to be the "example" par excellence of such behaviour.
| jd2066 wrote: | | One simple example of that being the move from /sbin/runscript to /sbin/openrc-run for openrc init scripts. Having a better name that is less generic is a good idea but the effort required to update every init script to use it likely was not worth it. |
I've argued against this disproportionate pain/gain, and yes, that is a perfect example of what can happen.
| jd2066 wrote: | | Checking on my system, it appears all my init scripts do use the new path but likely for compatibility my system still a /sbin/runscript file (That diff -s reports is identical to the binary file as /sbin/openrc-run). |
Hehe, "for compatibility", eventually the marginal issue with net-dialup/minicom will be completely solved :)
| jd2066 wrote: | | As for the systemd file system layout idea, I don't know what to say because I'm not sure it makes since. |
I doesn't need to "make sense", that is why I said initially that "hubris [and] brute force" is involved (along with various arguments about this or that being "legacy", "broken", etc).
| jd2066 wrote: | | On the usefulness of systemd-tmpfiles (The daemon that carries out the actions specified in tmpfiles.d), it does seem to have a purpose. Most programs that use temporary files, end up creating and removing the files themselves unless the files needs to be pre-created with specific permissions then the init script or package manager takes care of that. This works ok though if a program doesn't remove the tmp file due to a crash for instance then you can have unused tmp files hanging around doing nothing. |
OK, let me turn that argument around on you: care to provide a real world example? I've setup various high-availability clusters, and servers, and have never had an issue with such files, I have however had issues with the same hosts not booting because udev was updated. That is why I don't trust anything these people do, they have no idea about how to engineer robust systems.
| jd2066 wrote: | | The idea of systemd-tmpfiles is that instead of having programs handle the creation/deletion of their tmpfiles or having the package manager/init scripts handle the creation/deletion of the tmpfiles, just have a daemon that handles those things for you so tmpfiles creation and deletion is all done by a centralized system that in theory results in better management and cleaning of tmpfiles that will be beneficial to the system administrator who doesn't need to clean up old tmp files as that is handled automatically. |
Implicit in this is the idea that there is a huge amount of 'tmpfile' creation/deletion, when that isn't the case, its essentially a non-problem ... if your init is doing basic sanity checks for services, etc.
| jd2066 wrote: | | I'm not sure if opentmpfiles works the same way though as it doesn't appear to be a deamon that stays running in the background so I'm not sure if it can function in the same way or not. |
Its a oneshot ...
| jd2066 wrote: | | So far in my system administration of a Gentoo Linux system with openrc, the lack of automatic tmpfiles management hasn't really seemed to be an much of an issue. There maybe some tmpfiles that got left in /tmp but it doesn't seem to really cause any issues to just ignore it (unless the tmp files are really big for some reason) so I'm not sure of the necessity of the systemd-tmpfiles daemon. |
Which should tell you something. In my case I don't run opentmpfiles at all, but I'm watchful that something may break in future because of that fact.
best ... khay |
|
| Back to top |
|
|
szatox
Advocate
Joined: 27 Aug 2013
Posts: 3131
|
| Posted: Thu Jan 11, 2018 10:16 pm Post subject: |
|
|
| Quote: | | This works ok though if a program doesn't remove the tmp file due to a crash for instance then you can have unused tmp files hanging around doing nothing. |
and those files are typically located in /tmp, so they will be removed during reboot and then they would no longer be hanging around.
Some distributions wipe /tmp every now and then even without reboot. Obviously, if such a file remains open when it's being deleted, it's kept on the filesystem until is finally closed for any reason.
Sure, it's not the cleanest solution for long-running servers, but I'm not a big fan of the idea that init script should create any files for a service. One reason is because I think of tmp in similar way I think about application's memory (E.g. you're not supposed to be interested in _my_ memory, even if happens to be swapped out to a disk, and I should not bother you with it, so get out of my way and let me do my job) |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Sun Jan 14, 2018 4:44 pm Post subject: Re: Effects of blocking systemd via INSTALL_MASK |
|
|
| jd2066 wrote: | | Other binaries go in /usr/bin which has compatibility symlinks at /bin, /sbin, /usr/sbin to point to that directory. |
| krinn wrote: | You miss a point there, because it is not obvious as you may not notice the hole hide behind that.
LFSH define /sbin as "tools for admin that are needed to boot", /usr/sbin for tools that are not critical too boot, while still use by admin.
But if you remove /sbin and symlink it to /usr/sbin, it mean "critical to boot" are now in /usr/sbin, which in turn mean: you cannot boot if /usr is not mount.
So by removing /sbin and symlink it to /usr/sbin you void anyone that will use /usr in a separate partition ; which is not a big deal as systemd doesn't like that.
But the funny part, is that you are hinting everyone: if you have something critical to boot, it should goes in /usr/sbin because we may remove /sbin one day ; and the proper way is to use /usr/sbin and not /sbin
And if dhcpcd start to agree the "systemd" way, it will not put its binary in /sbin, but in /usr/sbin ; and all users using systemd that cannot use a separate /usr won't see any change: /usr must be present at boot, or the system will fail to use dhcpcd.
But for non systemd users, that do use separate /usr, it mean: oh nice, now dhcpcd install itself in /usr/sbin and i couldn't use dhcpcd in recovery mode, because i couldn't boot if my /usr is not mount, which i mount normally later. |
Damn, yeah, you're absolutely right.
Great analysis. | jd2066 wrote: | | I don't know why those behind systemd thought they needed to change the file system layout like that. |
| krinn wrote: | | So for me, best answer to this is: "to fuck all other init that could boot with a separate /usr while trying to making sure they couldn't do that anymore" |
It's amazing how much mental effort these guys will expend on dreaming up new ways to fuck over the rest of us, just for not wanting to use their crapfest.
If only they spent a tenth of that headspace on self-reflection, they might start to see what the rest of us have been banging on about.
As my boss likes to say: "Task separation is also conceptually useful." |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Sun Jan 14, 2018 5:11 pm Post subject: Re: Effects of blocking systemd via INSTALL_MASK |
|
|
| khayyam wrote: | If you follow the trajectory of some of these changes, then you'll find at the root of it its one change following on as a consequence of some prior action (so, the opposite of design), ie:
| Wikipedia: Filesystem_Hierarchy_Standard wrote: | | Modern Linux distributions include a /run directory as a temporary filesystem (tmpfs) which stores volatile runtime data, following the FHS version 3.0. According to the FHS version 2.3, such data were stored in /var/run but this was a problem in some cases because this directory is not always available at early boot. As a result, these programs have had to resort to trickery, such as using /dev/.udev, /dev/.mdadm, /dev/.systemd or /dev/.mount directories, even though the device directory isn't intended for such data. |
So, the problem of having a location for "volatile runtime data" for "early boot" is "solved" ... and now we move /var/run to /run, because ... ummm its "volatile" ... so now we need tmpfiles.d, because the contents of /var/run doesn't survive reboot ... and along comes the next great issue, and solution. |
Indeed; another great post.
"Change following on as a consequence of some prior action" is the norm, rather than the exception IME; all of which illustrates Djikstra's point:
"The computer scientist's greatest challenge is not to get caught up in complexity of one's own making."
First you have to go through the "epiphany", the insight moment that in fact all your work is making the situation worse, because you're trying to fix problems you made for yourself, that wouldn't exist if you hadn't done X back then.
Being able to step back, and throw away the design^W prototype and start from scratch, using the knowledge you gained while exploring the domain, is essential.
To the specific, the elision of "early boot" with "non-persistent" is a howler.
As a shell-scripter, I find it extraordinary that programs can't simply try to make a required directory, if they find a path doesn't work, and simply bail with an error message if that fails.
It's the first thing I learnt to do for update, nearly a decade ago, in #bash (or ##bash, as it was back then.)
IF the admin also wants to run a tmpfiles.d, that's fine too, but it's a totally separate issue (and hardly rocket-science to implement: I knocked one up in sh a few years ago to illustrate a point about sh as a language to another coder.) |
|
| Back to top |
|
|
NeddySeagoon
Administrator
Joined: 05 Jul 2003
Posts: 54216
Location: 56N 3W
|
| Posted: Sun Jan 14, 2018 5:30 pm Post subject: |
|
|
| Fred Brooks wrote: | | plan to throw one away; you will, anyhow. |
If you haven't heard of Fred Brooks or read The Mythical Man-Month you will be failing no learn from history.
_________________
Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Sun Jan 14, 2018 7:46 pm Post subject: |
|
|
| NeddySeagoon wrote: | | Fred Brooks wrote: | | plan to throw one away; you will, anyhow. |
If you haven't heard of Fred Brooks or read The Mythical Man-Month you will be failing to learn from history. |
Indeed. Nice to see that quote from someone who's actually lived the book ;-)
In truth, it's the "second-system" you end up throwing away; usually you do a first draft that is not ambitious, but does something simply and well. And crucially, it relies on libc, or other libraries, to do all the work.
Then you think you understand the domain ;-), "throw one away" because it's embarrassingly simple, and get ambitious on your second attempt.
That's the one you need to bin, and go back to your first implementation; but it's hard, because you've put so much time into it, and it's got all those lovely extra ideas you dreamt up, to which you are now quite ego-attached.
That's okay: do them in version 2, from a solid simple base. Kernighan tell us repeatedly:
Work incrementally, always with a running program, however simple, instead of on a grand design that takes ages to get to a working state (which often means: never.)
As Knuth said (AoCP 1.4.1 Subroutines): to start, work top down, delegating all work to lower functions, as if they exist and do exactly what you want.
Work out the API, as you'll have different calls to the same basic idea; some calls may show the same sequence, needing to be moved into the function (factor it out, and call it on entry) and so on.
Then come back up the other way, implementing the lowest level first, unit-testing as you come up the tree.
Then throw it away, and start again :-) |
|
| Back to top |
|
|
Tony0945
Watchman
Joined: 25 Jul 2006
Posts: 5127
Location: Illinois, USA
|
| Posted: Mon Jan 15, 2018 7:25 pm Post subject: |
|
|
I found the directory /usr/lib64/tmpfiles.d containing .conf files that aren't. https://www.freedesktop.org/software/systemd/man/tmpfiles.d.html indicates that these are for use by systemd.
So I moved the directory to /usr/lib64/tmp/tmpfiles.d and rebooted. Normal boot with no error messages. Then I did | Code: | rc-update del tmpfiles.setup boot
rc-update del tmpfiles.dev sysinit |
and with my sysrescuecd usb stick handy, rebooted. Again normal boot with no problems.
Can I conclude that I can add /usr/lib/tmpfiles.d to INSTALL_MASK to keep systemd crap off my openrc system? |
|
| Back to top |
|
|
khayyam
Watchman
Joined: 07 Jun 2012
Posts: 6227
Location: Room 101
|
| Posted: Mon Jan 15, 2018 7:52 pm Post subject: |
|
|
| Tony0945 wrote: | | Can I conclude that I can add /usr/lib/tmpfiles.d to INSTALL_MASK to keep systemd crap off my openrc system? |
Tony0945 ... those files are installed because there is the expectation that either systemd-tmpfiles, or opentmpfiles, will be run, and the "tmpfiles" created. Sure you can remove tmpfiles.* from the runlevel, purge those files from your filesystem, and INSTALL_MASK the location, but don't think that this is the end of it. You simply don't know what might start expecting something provided by tmpfiles.d ... and what the result will be should they not be there.
I have not INSTALL_MASKED this because I figure without my knowing what gets installed there I may run afoul of some change. However, I'm not runing opentmpfiles, and don't plan to any time soon.
best ... khay |
|
| Back to top |
|
|
rich0
Developer
Joined: 15 Sep 2002
Posts: 161
|
| Posted: Sat Jan 20, 2018 8:42 pm Post subject: Re: Effects of blocking systemd via INSTALL_MASK |
|
|
| steveL wrote: | Years of work from users, and ofc all that groundwork from Bob Burtle, got it to the point where it was reliable, and then it was subsumed by systemd, as if only the systemd team were capable of providing dynamic device "discovery".
This may be non-technical in terms of how the attack is carried out, but it is an attack on the spirit of FLOSS, with wide-reaching technical implications. |
TIL - using FLOSS source code in your FLOSS project is an attack on the spirit of FLOSS. |
|
| Back to top |
|
|
rich0
Developer
Joined: 15 Sep 2002
Posts: 161
|
| Posted: Sat Jan 20, 2018 8:48 pm Post subject: |
|
|
They're not only used by systemd.
Sure, a systemd manpage is going to talk about how systemd uses something. That doesn't mean that other programs can't operate in a compatible way.
You might or might not be able to get away with removing those files. Also, if you do remove them your system may or may not break without warning in the future. It may be that some programs are falling back to manual directory creation now, but may remove this in the future in the expectation that tmpfiles.d is taking care of it. |
|
| Back to top |
|
|
Mr. T.
Guru
Joined: 26 Dec 2016
Posts: 477
|
| Posted: Sun Jan 21, 2018 10:45 am Post subject: Re: Effects of blocking systemd via INSTALL_MASK |
|
|
| rich0 wrote: | | steveL wrote: | Years of work from users, and ofc all that groundwork from Bob Burtle, got it to the point where it was reliable, and then it was subsumed by systemd, as if only the systemd team were capable of providing dynamic device "discovery".
This may be non-technical in terms of how the attack is carried out, but it is an attack on the spirit of FLOSS, with wide-reaching technical implications. |
TIL - using FLOSS source code in your FLOSS project is an attack on the spirit of FLOSS. |
You are talking about the differences between free and open development philosophies. |
|
| Back to top |
|
|
rich0
Developer
Joined: 15 Sep 2002
Posts: 161
|
| Posted: Sun Jan 21, 2018 2:17 pm Post subject: Re: Effects of blocking systemd via INSTALL_MASK |
|
|
| helecho wrote: | | rich0 wrote: | | steveL wrote: | Years of work from users, and ofc all that groundwork from Bob Burtle, got it to the point where it was reliable, and then it was subsumed by systemd, as if only the systemd team were capable of providing dynamic device "discovery".
This may be non-technical in terms of how the attack is carried out, but it is an attack on the spirit of FLOSS, with wide-reaching technical implications. |
TIL - using FLOSS source code in your FLOSS project is an attack on the spirit of FLOSS. |
You are talking about the differences between free and open development philosophies. |
Not sure how this comes into play. Systemd is licensed under the GPL and as such guarantees the four essential freedoms. It is FLOSS. Anybody can modify it, or fork it, and so on. Heck, our eudev fork stands as a prime example of this.
The four essential freedoms do not require an upstream project to do things the way a user wants them to, or to accept a particular contribution. They govern what you can do with the software you receive, not what the authors of that software do with it (other than preserving your own rights to the four freedoms if the authors incorporated other free software into it).
Systemd adopting code into udev is no more an attack on the spirt of FLOSS than a bunch of Gentoo devs forking eudev out of udev and doing their own thing with it. That IS the spirit of FLOSS. If you don't want other people using your FLOSS code in a way you don't approve of, why did you make it FLOSS in the first place? |
|
| Back to top |
|
|
krinn
Watchman
Joined: 02 May 2003
Posts: 7470
|
| Posted: Sun Jan 21, 2018 2:55 pm Post subject: |
|
|
| rich0 wrote: | | You might or might not be able to get away with removing those files. Also, if you do remove them your system may or may not break without warning in the future. It may be that some programs are falling back to manual directory creation now, but may remove this in the future in the expectation that tmpfiles.d is taking care of it. |
tmpfiles.d is a service not provide by openrc, it's a service provide by tmpfiles.d with openrc.
It's not because you have that default dependency set in gentoo that your program should start assume openrc provide it ; it is not.
So if your program start depends on tmpfiles.d, your program make it wrong everywhere:
- your program assume systemd is there, because tmpfiles.d is provide with it
- your program assume openrc is use, it assume openrc do have that dependency AND user system is running the service.
This is only true in gentoo that openrc is default, but false because not all gentoo run openrc.
This is false that all openrc even ones able to use tmpfiles.d are using tmpfiles.d, many other distros use openrc.
This is false also in gentoo that the tmpfiles.d service is running, it depends if the user has allow this or not.
- your program assume tmpfiles.d is there, when it's a functionality only provide by gentoo and systemd.
So to end up your program is now depending on : any systemd distro or gentoo WITH openrc AND tmpfiles.d AND tmpfiles.d running
While you may have legit or safe reasons to make such program with such conditions to exists to just run it (if you program already depends on some systemd lib/functionality, you don't really care if systemd is not there), if your program is gentoo specific and openrc specific and tmpfiles.d specific you don't care because without them it cannot work.
But your program usage is restrict a lot.
If we take dhcpcd, it mean dhcpcd couldn't work with tmpfiles.d, so without systemd or without a gentoo with opernc and tmpfiles.d running.
I really, really, but really doubt Roy Marples would do such stupid mistake: because it would mean dhcpcd list of user is now a bunch of users.
So your scary but may remove this in the future in the expectation that tmpfiles.d is taking care of it. is false.
For ANY programs that is not systemd specific and not gentoo specific, it will never happen until all distros mandate tmpfiles.d, because it would sign their death.
All you could say is that gentoo devs may mandate tmpfiles.d in gentoo specific programs, but even this is total crap and should be report and removed :
* portage is our default package manager, still, portage is clearly aim to not be gentoo only, this is show by portage prefix.
* openrc is our default rc, but openrc is not only made for gentoo, it was first goal of Roy Marples that openrc would stay open and distro agnostic, and it has work, openrc is use in many distros, you cannot change openrc to be gentoo specific.
Because of this, anyone starting to make any assumption over openrc or portage that they will mandate usage of tmpfiles.d is making an error, and that error should be report and fix.
So, anyone using tmpfiles.d can only mandate it if systemd is use, and if not, it then could be only optionally use. |
|
| Back to top |
|
|
rich0
Developer
Joined: 15 Sep 2002
Posts: 161
|
| Posted: Sun Jan 21, 2018 3:11 pm Post subject: |
|
|
| krinn wrote: | | rich0 wrote: | | You might or might not be able to get away with removing those files. Also, if you do remove them your system may or may not break without warning in the future. It may be that some programs are falling back to manual directory creation now, but may remove this in the future in the expectation that tmpfiles.d is taking care of it. |
So if your program start depends on tmpfiles.d, your program make it wrong everywhere:
- your program assume systemd is there, because tmpfiles.d is provide with it
- your program assume openrc is use, it assume openrc do have that dependency AND user system is running the service. |
Programs that require tmpfiles.d can just depend on virtual/tmpfiles.
Whether provided by systemd or opentmpfiles+openrc, the service runs by default once the package is installed. I'm not sure about opentmpfiles in conjunction with other service managers - it is added to the openrc sysinit+boot runlevels if the service manager looks at them.
| krinn wrote: | While you may have legit or safe reasons to make such program with such conditions to exists to just run it (if you program already depends on some systemd lib/functionality, you don't really care if systemd is not there), if your program is gentoo specific and openrc specific and tmpfiles.d specific you don't care because without them it cannot work.
But your program usage is restrict a lot. |
Ok, for the 10 installations left on the planet that don't run either systemd or openrc it won't work. I imagine most upstreams aren't going to lose a lot of sleep over this. Somebody packaging for a distro that doesn't use systemd or openrc would just need to note the issue and correct it for their install. |
|
| Back to top |
|
|
berferd
Tux's lil' helper
Joined: 13 May 2004
Posts: 117
|
| Posted: Sun Jan 21, 2018 4:56 pm Post subject: |
|
|
There are only 10 Android devices in the world? This is amazing! I can't believe 30% of all the Android devices in the world are in my house!
Only 10 chrome books? 10 installs of DD-WRT? If we count the OpenWRT installs in the world, then 40% of all non-openrc, non-systemd installs in the world are in my house!
This new learning amazes me! |
|
| Back to top |
|
|
rich0
Developer
Joined: 15 Sep 2002
Posts: 161
|
| Posted: Sun Jan 21, 2018 5:16 pm Post subject: |
|
|
| berferd wrote: | There are only 10 Android devices in the world? This is amazing! I can't believe 30% of all the Android devices in the world are in my house!
Only 10 chrome books? 10 installs of DD-WRT? If we count the OpenWRT installs in the world, then 40% of all non-openrc, non-systemd installs in the world are in my house!
This new learning amazes me! |
You left out all the computers running Windows, OSX, and all the other non-Linux kernels as well.
I did not specify what kinds of installations I was talking about.
In any case, the maintainers of daemons that might rely on tmpfiles.d probably aren't terribly concerned with Android and OpenWRT. And if the maintainers of Android or OpenWRT wanted to use those daemons processing the tmpfiles.d files would be fairly trivial, as would be just writing a script to create the needed directories in some other way. Though, I imagine they'd just embrace the tmpfiles.d approach since it is pretty simple and useful. |
|
| Back to top |
|
|
berferd
Tux's lil' helper
Joined: 13 May 2004
Posts: 117
|
| Posted: Sun Jan 21, 2018 5:48 pm Post subject: |
|
|
| rich0 wrote: |
You left out all the computers running Windows, OSX, and all the other non-Linux kernels as well.
|
I assumed we were talking about Linux. My bad. I also have one machine running FreeBSD and one running OpenBSD too. That plus my FreeBSD virtual server makes me responsible for 60% of all the non-systemd, non-openrc installs on in the planet!
Wait I forgot about the three FreeBSD machines we run at work. And the several dozen Ubuntu Trusty machines there too. I think there's a problem with your numbers. |
|
| Back to top |
|
|
CasperVector
Apprentice
Joined: 03 Apr 2012
Posts: 156
|
| Posted: Sun Jan 21, 2018 6:20 pm Post subject: |
|
|
| berferd wrote: | | I think there's a problem with your numbers. |
Considering all those Alpine Linux containers which use OpenRC without tmpfiles (whether builtin or standalone), this problem seems slightly larger than you thought 
_________________
My current OpenPGP key:
RSA4096/0x227E8CAAB7AA186C (expires: 2020.10.19)
7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C
Last edited by CasperVector on Mon Jan 22, 2018 1:32 am; edited 1 time in total |
|
| Back to top |
|
|
rich0
Developer
Joined: 15 Sep 2002
Posts: 161
|
| Posted: Sun Jan 21, 2018 6:44 pm Post subject: |
|
|
| berferd wrote: | | rich0 wrote: |
You left out all the computers running Windows, OSX, and all the other non-Linux kernels as well.
|
I assumed we were talking about Linux. My bad. I also have one machine running FreeBSD and one running OpenBSD too. That plus my FreeBSD virtual server makes me responsible for 60% of all the non-systemd, non-openrc installs on in the planet!
Wait I forgot about the three FreeBSD machines we run at work. And the several dozen Ubuntu Trusty machines there too. I think there's a problem with your numbers. |
Indeed, and all of them can process files in tmpfiles.d, or work around these, if upstream decides to use them.
Things change. If you want to stick with Ubuntu Trusty, then just stick with software in the Ubuntu Trusty repository and people who can handle change will take care of all those pesky details for you. |
|
| Back to top |
|
|
berferd
Tux's lil' helper
Joined: 13 May 2004
Posts: 117
|
| Posted: Sun Jan 21, 2018 7:45 pm Post subject: |
|
|
But that's exactly what I don't want. I don't want "experts" deciding how to handle details for me. They suck at it and I wish they would stop.
Change for the sake of change is not progress. |
|
| Back to top |
|
|
rich0
Developer
Joined: 15 Sep 2002
Posts: 161
|
| Posted: Sun Jan 21, 2018 8:36 pm Post subject: |
|
|
| berferd wrote: | | But that's exactly what I don't want. I don't want "experts" deciding how to handle details for me. They suck at it and I wish they would stop. |
Well, it isn't like there has been a mad rush to make programs crash if tmpfiles.d isn't in use. Plus a lot of that is distro-level. The software just expects /var/my/config to exist and have the right owner, and how it gets that way is up to the distro. Files like PID files are often passed to software as a parameter (or maintained by the service manager), and the program simply expects to be able to have permissions to create it wherever it is told to do so when it is run.
Much of the strength of tmpfiles.d is that it makes it easy to create these kinds of files/directories/etc in a standardized way, especially when it is done on ephemeral storage. With the increasing popularity of stateless containers and other less-traditional installations this can be useful. When the root filesystem is a tmpfs with a couple of things bind-mounted on top it is helpful to be able to have a lot of directories/permissions quickly set up on demand at runtime. |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Mon Jan 22, 2018 12:35 am Post subject: Re: Effects of blocking systemd via INSTALL_MASK |
|
|
| steveL wrote: | Years of work from users, and ofc all that groundwork from Bob Burtle, got it to the point where it was reliable, and then it was subsumed by systemd, as if only the systemd team were capable of providing dynamic device "discovery".
This may be non-technical in terms of how the attack is carried out, but it is an attack on the spirit of FLOSS, with wide-reaching technical implications. |
| rich0 wrote: | | TIL - using FLOSS source code in your FLOSS project is an attack on the spirit of FLOSS. |
Eh, what?
Not sure what to say to someone who clearly does not understand the point they are failing to counter. | rich0 wrote: | | Ok, for the 10 installations left on the planet that don't run either systemd or openrc it won't work. I imagine most upstreams aren't going to lose a lot of sleep over this. Somebody packaging for a distro that doesn't use systemd or openrc would just need to note the issue and correct it for their install. |
And this luser attitude simply sucks.
I can't quite believe you're a Gentoo developer, tbh: you have such a lame approach, and a clear lack of understanding.
My advice would be to research the background (it's called UNIX.) |
|
| Back to top |
|
|
rich0
Developer
Joined: 15 Sep 2002
Posts: 161
|
| Posted: Mon Jan 22, 2018 1:02 am Post subject: Re: Effects of blocking systemd via INSTALL_MASK |
|
|
| steveL wrote: | | My advice would be to research the background (it's called UNIX.) |
Funny, back when I was using SunOS 4 I don't recall it having support for stateless containers. You'll have to remind me what the POSIX standard specifies for how to instruct a service manager to create a directory in a stateless container.
If you want to run 1990s-style Unix then just use the software that was around in the 90s, or write software that behaves the way you want it to. Nobody is installing anything on your system against your wishes. You're the one in control of whether you tell the package manager to install something... |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Tue Mar 06, 2018 12:14 am Post subject: Re: Effects of blocking systemd via INSTALL_MASK |
|
|
| rich0 wrote: | Funny, back when I was using SunOS 4 I don't recall it having support for stateless containers. You'll have to remind me what the POSIX standard specifies for how to instruct a service manager to create a directory in a stateless container.
If you want to run 1990s-style Unix then just use the software that was around in the 90s, or write software that behaves the way you want it to. Nobody is installing anything on your system against your wishes. You're the one in control of whether you tell the package manager to install something... |
The sad part is you still don't get it (after all this time..)
Hang out in #bash for 6-12 months and learn from the people who really understand the UNIX userland: the sysadmins who live it everyday, and are liable for the end-results.
Not the academics and the "developers" who barely understand it in theory and at a remove.
And spend the same amount of time learning at least two assembly languages, if you haven't already.
Then come back and re-read your previous posts, and see what you think of yourself. |
|
| 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
