| View previous topic :: View next topic |
| Author |
Message |
khayyam
Watchman
Joined: 07 Jun 2012
Posts: 6227
Location: Room 101
|
 Posted: Thu Jan 04, 2018 4:20 pm Post subject: |
 |
|
| depontius wrote: | | I would really feel better if someone would fork OpenRC. |
depontius ... as I argued some time back this isn't as straightforward as it might seem, you would be forced to take one or other of the following approaches: 1). follow openrc changes (so as to be a drop in replacement) or 2). maintain all available rcscripts separately from the main tree. The former essentially reduces the 'fork' to nothing but a re-branding, the later is both impractical (because those initscripts are installed from ::gentoo ... and would require the user adopt a separately maintained tree/fork) and is unlikely to gain any support or traction (for the same reason). Similarly with opentmpfiles, this could be dropped, but there will be cases in which files/directories are no longer created/installed via ::gentoo and some of these you simply can't 'fix' without first having forked the packages involved (or you leave it to users to figure out such things).
As I've said time and time again, without there having been strong opposition at the time gentoo adopted systemd into the tree anything subsequent is too little, too late.
best ... khay |
|
| Back to top |
|
 |
tld
Veteran
Joined: 09 Dec 2003
Posts: 1816
|
| Posted: Thu Jan 04, 2018 4:43 pm Post subject: |
|
|
| khayyam wrote: | | depontius ... as I argued some time back this isn't as straightforward as it might seem, you would be forced to take one or other of the following approaches: 1). follow openrc changes (so as to be a drop in replacement) or 2). maintain all available rcscripts separately from the main tree. |
Are you referring primarily to the change from /sbin/runscript to /sbin/openrc-run? I wasn't aware of other changes specifically required in the scripts themselves, and that change predates even the 0.17 that I'm running. | khayyam wrote: | | dThe former essentially reduces the 'fork' to nothing but a re-branding, the later is both impractical (because those initscripts are installed from ::gentoo ... and would require the user adopt a separately maintained tree/fork) and is unlikely to gain any support or traction (for the same reason). |
As far as getting traction, there appears to be quite an interest in OpenRC on the part of Devuan(?).
I tend to agree though...while I've always been in the "Gentoo is about choice" camp, the bottom line appears to be that systemd can't be a choice without pissing all over the other choices, and it's getting very old.
Tom |
|
| Back to top |
|
|
Naib
Watchman
Joined: 21 May 2004
Posts: 6051
Location: Removed by Neddy
|
| Posted: Thu Jan 04, 2018 5:00 pm Post subject: |
|
|
A better option would be to provide "unitfile" support to openRC
ZOMG HERESY!!! BURN THE HEATHEN
hear me out (and I have said this before  )
The downside of initrd was "dirty shell scripts" which actually boils downto distro's being piss-poor at shell scripting. Systemd actually removed this via their unitfiles & now what you see is upstream produce and maintain unitfiles because... they can be really simple
| Code: | [Unit]
Description=Setup foo
#After=network.target
[Service]
Type=oneshot
ExecStart=/opt/foo/setup-foo.sh
RemainAfterExit=true
ExecStop=/opt/foo/teardown-foo.sh
StandardOutput=journal
[Install]
WantedBy=multi-user.target |
"butbutbut openRC init scripts are simple as well!!!!11one!!" we too fscking bad! Gentoo/OpenRC missed the boat. However simple they are, they are still SHELL SCRIPT's, that concept that scares the crud out of the general linux community. It is gentoo that maintains OpenRC scripts NOT upstream.
Distro's don't want the hassle of maintaining init scripts so that already puts OpenRC at a disadvantage (even spinning the init scripts off as a separate package is a weak solution). OpenRC should have come up with their own ini file concept such that 99% of all services could be started with a simple file. Now that has gone SystemD unitfiles are the defacto standard
_________________
| Quote: | | Removed by Chiitoo |
|
|
| Back to top |
|
|
khayyam
Watchman
Joined: 07 Jun 2012
Posts: 6227
Location: Room 101
|
| Posted: Thu Jan 04, 2018 5:18 pm Post subject: |
|
|
| khayyam wrote: | | depontius ... as I argued some time back this isn't as straightforward as it might seem, you would be forced to take one or other of the following approaches: 1). follow openrc changes (so as to be a drop in replacement) or 2). maintain all available rcscripts separately from the main tree. |
| tld wrote: | | Are you referring primarily to the change from /sbin/runscript to /sbin/openrc-run? I wasn't aware of other changes specifically required in the scripts themselves, and that change predates even the 0.17 that I'm running. |
tom ... that would be one change that a fork would have to decide to follow or not, but there are others, such as the addition of the 'want' target. Still, I was thinking more along the lines of, now that opentmpfiles is the 'standard' go to mechanism for creating volatile files/directories there's really no need for rcscripts to do the following:
| Code: | | checkpath -d -m 0755 -o foo:foo /var/run/foo |
... as many do:
| Code: | # grep -l checkpath /etc/init.d/*
/etc/init.d/alsasound
/etc/init.d/bootmisc
/etc/init.d/consolefont
/etc/init.d/device-mapper
/etc/init.d/fcron
/etc/init.d/ip6tables
/etc/init.d/iptables
/etc/init.d/keymaps
/etc/init.d/kmod-static-nodes
/etc/init.d/root
/etc/init.d/savecache
/etc/init.d/syslog-ng
/etc/init.d/termencoding
/etc/init.d/tor |
| khayyam wrote: | | The former essentially reduces the 'fork' to nothing but a re-branding, the later is both impractical (because those initscripts are installed from ::gentoo ... and would require the user adopt a separately maintained tree/fork) and is unlikely to gain any support or traction (for the same reason). |
| tld wrote: | | As far as getting traction, there appears to be quite an interest in OpenRC on the part of Devuan(?). |
Yes, and it was adopted by TrueOS (BSD), but you are unlikely to see either adopt a fork if the rcscripts from ::gentoo didn't work as is (so, point 1 above), or if the entire available rcscripts were not maintained, and supported, seperately (point 2 above).
| tld wrote: | | I tend to agree though...while I've always been in the "Gentoo is about choice" camp, the bottom line appears to be that systemd can't be a choice without pissing all over the other choices, and it's getting very old. |
Yes, and at the time there was an almost complete disregard for what adoption would mean ("standardisation of the base system") ... even while systemd developers were stating it as "policy".
best ... khay |
|
| Back to top |
|
|
krinn
Watchman
Joined: 02 May 2003
Posts: 7470
|
| Posted: Fri Jan 05, 2018 8:30 am Post subject: |
|
|
sync your tree guys, zmedico have a sane brain 
yeah: and look at the bug, you'll see systemd lover tagging the changes as "simply wrong". |
|
| Back to top |
|
|
khayyam
Watchman
Joined: 07 Jun 2012
Posts: 6227
Location: Room 101
|
| Posted: Fri Jan 05, 2018 10:27 am Post subject: |
|
|
| Naib wrote: | | Code: | ExecStart=/opt/foo/setup-foo.sh
[...]
ExecStop=/opt/foo/teardown-foo.sh |
|
Naib ... "dirty shell scripts" ... and that somewhat undermines your argument, hiding complexity elsewhere doesn't make a unitfile "simple".
best ... khay |
|
| Back to top |
|
|
krinn
Watchman
Joined: 02 May 2003
Posts: 7470
|
| Posted: Fri Jan 05, 2018 10:50 am Post subject: |
|
|
| khayyam wrote: | | Naib wrote: | | Code: | ExecStart=/opt/foo/setup-foo.sh
[...]
ExecStop=/opt/foo/teardown-foo.sh |
|
Naib ... "dirty shell scripts" ... and that somewhat undermines your argument, hiding complexity elsewhere doesn't make a unitfile "simple".
best ... khay |
the unit there is running another script, but worst, from another location, and it's best path to error (you had to watch now /opt/foo rights), if you forget/mistake... it would mean anyone able to alter /opt/foo/foo-setup-foo.sh can let systemd do what user want with systemd rights. |
|
| Back to top |
|
|
Naib
Watchman
Joined: 21 May 2004
Posts: 6051
Location: Removed by Neddy
|
| Posted: Fri Jan 05, 2018 10:53 am Post subject: |
|
|
| khayyam wrote: | | Naib wrote: | | Code: | ExecStart=/opt/foo/setup-foo.sh
[...]
ExecStop=/opt/foo/teardown-foo.sh |
|
Naib ... "dirty shell scripts" ... and that somewhat undermines your argument, hiding complexity elsewhere doesn't make a unitfile "simple".
best ... khay |
thats just the example i pulled of a unit file, doesn't have to be that.
My point is distro's don't want to manage init scripts. An ini file to launch a program (be it an elf, script etc...) makes things simpler and for a lot of the cases thats all that is needed.
_________________
| Quote: | | Removed by Chiitoo |
|
|
| Back to top |
|
|
khayyam
Watchman
Joined: 07 Jun 2012
Posts: 6227
Location: Room 101
|
| Posted: Fri Jan 05, 2018 11:49 am Post subject: |
|
|
| Naib wrote: | | khayyam wrote: | | [...] "dirty shell scripts" ... and that somewhat undermines your argument, hiding complexity elsewhere doesn't make a unitfile "simple". |
thats just the example i pulled of a unit file, doesn't have to be that. |
Naib ... ok, but it serves as a good example, because it shows that some mechanism is involved in the "setup" or "teardown" of the service, be that "dirty shell scripts", or some hidden function of the init system. So while you can argue that a unitfile is simple, what happens (or what needs to happen for every individual instance) is not, and so it really comes down to what is exposed of those functions (and so what use they can be put to, and the level of skill required to leverage that use).
| Naib wrote: | | My point is distro's don't want to manage init scripts. An ini file to launch a program (be it an elf, script etc...) makes things simpler and for a lot of the cases thats all that is needed. |
Its not just "don't", having seen sysvrc from redhat, debian, etc, it's more a question of compitance. Anyhow, you mean like this? ...
| /etc/init.d/ntpd: | name="OpenNTPD"
command="/usr/sbin/ntpd"
pidfile="/run/ntpd.pid"
command_args="-p ${pidfile} ${NTPD_OPTS}"
depend() {
need net
after ntp-client
use dns logger
} |
best ... khay |
|
| Back to top |
|
|
Ant P.
Watchman
Joined: 18 Apr 2009
Posts: 6920
|
| Posted: Fri Jan 05, 2018 12:22 pm Post subject: |
|
|
| I'd go a step further and say any daemon that requires "need net" is defective. They should be able to handle interfaces and addresses coming and going at runtime. Most actually do, but there's some notably crufty software that doesn't, including ISC stuff (bind, dhcpd). |
|
| Back to top |
|
|
Tony0945
Watchman
Joined: 25 Jul 2006
Posts: 5127
Location: Illinois, USA
|
| Posted: Fri Jan 05, 2018 2:49 pm Post subject: |
|
|
| Ant P. wrote: | | I'd go a step further and say any daemon that requires "need net" is defective. They should be able to handle interfaces and addresses coming and going at runtime. Most actually do, but there's some notably crufty software that doesn't, including ISC stuff (bind, dhcpd). |
I definitely concur.
Also: "ini" files? Shades of Windows 95. What's next? the registry? As Linux devolves into Windows because RedHat wants to become Micro$oft. |
|
| Back to top |
|
|
Naib
Watchman
Joined: 21 May 2004
Posts: 6051
Location: Removed by Neddy
|
| Posted: Fri Jan 05, 2018 2:55 pm Post subject: |
|
|
| Tony0945 wrote: | | Ant P. wrote: | | I'd go a step further and say any daemon that requires "need net" is defective. They should be able to handle interfaces and addresses coming and going at runtime. Most actually do, but there's some notably crufty software that doesn't, including ISC stuff (bind, dhcpd). |
I definitely concur.
Also: "ini" files? Shades of Windows 95. What's next? the registry? As Linux devolves into Windows because RedHat wants to become Micro$oft. |
Thats essencially what a unit file is.. call it what you want but it is just a config file
_________________
| Quote: | | Removed by Chiitoo |
|
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6747
|
| Posted: Fri Jan 05, 2018 2:59 pm Post subject: |
|
|
| Tony0945 wrote: | | What's next? the registry? |
This is implemented in gnome since ages. |
|
| Back to top |
|
|
Tony0945
Watchman
Joined: 25 Jul 2006
Posts: 5127
Location: Illinois, USA
|
| Posted: Fri Jan 05, 2018 3:23 pm Post subject: |
|
|
| mv wrote: | | Tony0945 wrote: | | What's next? the registry? |
This is implemented in gnome since ages. |
You are right! |
|
| Back to top |
|
|
Naib
Watchman
Joined: 21 May 2004
Posts: 6051
Location: Removed by Neddy
|
| Posted: Fri Jan 05, 2018 3:33 pm Post subject: |
|
|
The concept of a registry is quite sound the problem is windows ballsed it up and GNOME went batshit insane (at least it wasn't binary)
_________________
| Quote: | | Removed by Chiitoo |
|
|
| Back to top |
|
|
saellaven
l33t
Joined: 23 Jul 2006
Posts: 646
|
| Posted: Fri Jan 05, 2018 5:05 pm Post subject: |
|
|
| Naib wrote: | | Tony0945 wrote: | | Ant P. wrote: | | I'd go a step further and say any daemon that requires "need net" is defective. They should be able to handle interfaces and addresses coming and going at runtime. Most actually do, but there's some notably crufty software that doesn't, including ISC stuff (bind, dhcpd). |
I definitely concur.
Also: "ini" files? Shades of Windows 95. What's next? the registry? As Linux devolves into Windows because RedHat wants to become Micro$oft. |
Thats essencially what a unit file is.. call it what you want but it is just a config file |
That doesn't mean the complexity of init scripts has gone away, it's simply obfuscated and harder for sysadmins to find and deal with. It's not enough to simply know shell anymore, you need to know C. Worse, systemd is constantly having massive sections added or rewritten because it was never designed to begin with, it just kept absorbing more functionality.
At the end of the day, what systemd creates, is a monoculture centered around RH, whom everyone has to pay for support (which is why RH loves it). And that monoculture is going to be prone to all kinds of vulnerabilities, particularly because there is no design and certainly no planning for security. If you or Debian of whomever want to hitch your wagon to that, that's fine, just don't be surprised when it blows up in your face and don't force those of us that don't want anything to do with systemd to adopt it (or parts of it). And for as much as is wrong with systemd, that's the worst part, the ideology that all must adopt it's braindead ideas. |
|
| Back to top |
|
|
krinn
Watchman
Joined: 02 May 2003
Posts: 7470
|
| Posted: Fri Jan 05, 2018 6:34 pm Post subject: |
|
|
Because they do not use a versioning system, it mean "new keyword" and "new value of keyword" have to be dealt by systemd old version
With the problematic then ; when you see something unknown to your systemd version, how should systemd react to that?
a) you stop and claim the unit files is not for your systemd version
b) you ignore the unknown keyword or value and continue (with or without a warning)
- a) is the safest way to deal with that ; but it would mean any unit files made for latest systemd using a new keyword couldn't be use with older systemd.
It's something easy dealt with versioning (like portage do with EAPI) but systemd don't use version in unit.
- b) "may" appears safe for keyword but not always!!!
if you use b) on keyword, it mean your old system that doesn't know the new keyword <no_run_if=""> will ignore it, and will just then run the unit even if the condition to not run it is present
And the new "hypothetical" useful keyword <no_run_if="uid>0"> mean the unit will be run even if uid is not 0, because while systemd doesn't know what no_run_if is made for (normal), it accept to just ignore it and continue executing the unit, searching for known keywords and actions to do.
So it's only safe if you know the new keyword may get ignore, and it create no issue ignoring it (but it's a paradox, because if you can safely ignore it, it would mean that keyword is not useful at all, and have no reason to just exist).
- b) on value and use a default value is also not safe, and it has hit systemd once, it was if i remember well, systemd unable to match a user name 0something with his uid and it was using uid=0 (!)
while it's generally easy to deal with value content, it could still be a problem (it's easy to see if the value is of the expect type: char, number...) but it's less easy if you want check a range (if you accept only 0-9, a new unit that would allow range to be 10 will not work). And you goes again into the problematic: if i see 10, should i accept 10, reject 10 or use 0 (my default setting for that value).
And this is a huge issue, each time systemd want to add another keyword or value to an existing keyword, they are limited by how an old systemd (and old just mean previous version) will handle this, and need to think about it.
It mean this is a blocker to create new keywords freely, and so, limit how you could expand the API of unit files in systemd. Which mean: a limited set and a dead end.
The only safe way to dealt with that is versioning.
* Stop on anything unknown ; which is impossible as it would mean each time someone download an unit file, he must look at all keywords and see if his systemd could handle them. It's doable if you use a trick, like adding version in unit name: instead of offering nfs.unit you offer nfs-systemd-version-X.unit + nfs-systemd-version-Z.unit... but this is against the "all standard" mentality of one nfs.unit for all systemd versions...
* The last possibility to deal with that is: no versioning, stop on unknown keywords, and if anyone complain nfs.unit doesn't work with systemd version X, you kick his balls with a "upgrade to latest systemd douche" (i'll put this last possibility, because it's something they indeed could do, and knowing them, it's not really fictional). |
|
| Back to top |
|
|
CasperVector
Apprentice
Joined: 03 Apr 2012
Posts: 156
|
| Posted: Sat Jan 06, 2018 5:39 am Post subject: |
|
|
| krinn wrote: | | With the problematic then ; when you see something unknown to your systemd version, how should systemd react to that? |
Or ditch systemd and use daemontools-like init/rc systems
By using chainloading, you get almost everything "unit files" support, without all the crap that comes with systemd.
And by using a little shell scritping and a rc system (eg. s6-rc or anopa) that supports dependency and oneshots, the "almost" in the preceding sentence can be left out.
_________________
My current OpenPGP key:
RSA4096/0x227E8CAAB7AA186C (expires: 2020.10.19)
7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C |
|
| Back to top |
|
|
dmpogo
Advocate
Joined: 02 Sep 2004
Posts: 3267
Location: Canada
|
| Posted: Sat Jan 06, 2018 8:52 am Post subject: |
|
|
| Naib wrote: | | The concept of a registry is quite sound the problem is windows ballsed it up and GNOME went batshit insane (at least it wasn't binary) |
So do you have an example of sound implementation ? Or maybe it is concept, after all ? |
|
| Back to top |
|
|
Naib
Watchman
Joined: 21 May 2004
Posts: 6051
Location: Removed by Neddy
|
| Posted: Sat Jan 06, 2018 9:40 am Post subject: |
|
|
| dmpogo wrote: | | Naib wrote: | | The concept of a registry is quite sound the problem is windows ballsed it up and GNOME went batshit insane (at least it wasn't binary) |
So do you have an example of sound implementation ? Or maybe it is concept, after all ? |
sound implementation would be in win3.1 before they went batshit insane with it for win95
The idea of a central place for lookup make sense. This isn't soo much of an issue for linux due to /etc but for window (3.1 era) it did because applications where everywhere and their ini files where everywhere... no easy way for one application to discover the other (without some massive daemon running...). This was why MS added registry in windows 3.1 as a means to centralise the info with a common structure rather then app-x having a different ini style to app-y
thing is MS pulled the sys conf into the registry, poor backend db handling, binary blob, no way to bootstrap in the event of a failure
_________________
| Quote: | | Removed by Chiitoo |
|
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Sat Jan 06, 2018 11:22 am Post subject: |
|
|
| Naib wrote: | | The downside of initrd was "dirty shell scripts" which actually boils downto distro's being piss-poor at shell scripting. |
Indeed.
Your answer to "the supposed experts are not", is weird though.
In any other field, including hardware design, you simply flip the idiot-bit on those "experts" and find another supplier, with people who know their craft. | Quote: | | "butbutbut openRC init scripts are simple as well!!!!11one!!" we too fscking bad! Gentoo/OpenRC missed the boat. |
Which is a marketing issue, not a technical one.
Your argument has no technical grounds, IOW.
As we all know, we can write much simpler init scripts in openrc; and we can also get complex, when we need to.
At no point do we surrender efficiency. | Quote: | | However simple they are, they are still SHELL SCRIPT's, that concept that scares the crud out of the general linux community. |
So what? C scares the crud out of people who don't know it; or at least, it should.
Should we then stop using C, even though it is the best fit for the job?
And your argument falls completely on its face, when one considers that the initramfs mandated by systemdbust (so now everyone has to have one, even when we don't need nor want it; yay for choice, and downright broken thinking), which always ends up being tailored for the environment (here's a nifty script to do it for you..) RELIES on SHELL.
So does an awful lot else.
UNIX is designed around the concept of the shell, with argv and main as the interface to processes (standardised in C.)
Nubs who don't get that, don't get UNIX yet; (not to put too fine a point on it.)
This is why shell (written properly) is incredibly efficient; it's been running every UNIX system since the 70s, when 64K of RAM was a pipe-dream. | Quote: | | It is gentoo that maintains OpenRC scripts NOT upstream. |
This is another point (not technical) worth addressing. It's the age-old chicken-and-egg problem of how do you get enough users for upstreams to work towards your base as a target. | Quote: | | Distro's don't want the hassle of maintaining init scripts so that already puts OpenRC at a disadvantage (even spinning the init scripts off as a separate package is a weak solution). OpenRC should have come up with their own ini file concept such that 99% of all services could be started with a simple file. |
FFS we did already, at least a decade ago.
Gentooistas simply didn't care that other distros were full of fail; why should we?
It's the same reason we never bothered about RedHat being unable to provide an etc-update tool, even though Debian had one for so long that we could simply import it.
No-one has the time to sort out someone else's messes as well as our own. | Quote: | | Now that has gone SystemD unitfiles are the defacto standard |
They're dooomed to fail in the longer-term, IMO.
cf: Beizer "Software Testing Techniques" (1983 or 1990, either edition will do) for a discussion of why. Ch 7 in the first ed, ch 9 in the second.
In a nutshell, every system ends up having a language, though you might have to dig to find it. (This is also discussed in "The Practice of Programming", by Kernighan and Pike, though the testing and verification implications are not addressed; it's just assumed you'll use the right tool for the job.)
As such, it's better to be upfront, and work with a proper syntax from the beginning.
If you don't, you end up reinventing it via an ad-hoc language, with accretions and baggage that has never been properly designed, and problems arising from conflicting metaphors that have never even been considered as such. (Sound familiar? ;)
You see the same effect with "GOTO" in udev config files, the usecases with people like mv asking for "evaluated config files," and again the same effect with "ExecPre" etc in systemdbust.
Or to put it another way: "Those who don't understand UNIX, end up reinventing it: badly."
WRT collaboration on initscripts, devuan and all the others who prefer "classic" UNIX to whatever the hell GnomeOS^W Lennix is supposed to be, provide a healthy basis.
So, if anything, the situation has only improved for the prospects of more eyeballs and help with openrc initscripts, giving the lie to the notion that a standard has been set across computing by systemdbust (already preposterous, prima facie, and simply untenable when one considers the lack of design, perspective and craft.)
--
I still find your answer to "the experts are not" to be completely at odds with your position on "software engineers can't be trusted", although it must be said that you are not actually discussing software engineers but software "developers", and here as elsewhere, terminology (or nomenclature) matters.
The elision allows all kinds of people who've never paid their dues, to pass themselves off as self-proclaimed "kernel experts", "userspace experts" and so on (as evinced in the crap about the wise "architects" all reaching some kind of magnanimous consensus that we should all bow down before Poeterring. No doubt after they'd finished their latest javascript project.)
If "software engineers can't be trusted", and need all kinds of harsh process (that doesn't in fact work for this field), how on earth you then get to "distros who can't even write shell, should be protected from themselves" (rather than fall by the wayside as clearly incompetent), is beyond me.
Hopefully you can see the disparity in the positions, without my belabouring it further.
And no, we don't need .ini files; we just need to stop listening to nubs who can't even write sh, whinging about how crap it is (so "use this turd instead. See how polished it is? Shiny..")
Redirect them to #bash instead, so they can learn from real UNIX userland experts, instead of mess everything up for the rest of us. |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6747
|
| Posted: Sat Jan 06, 2018 11:42 am Post subject: |
|
|
| steveL wrote: | | initramfs mandated by systemdbust |
It is not a problem to use systemd without initramfs. |
|
| Back to top |
|
|
roki942
Apprentice
Joined: 18 Apr 2005
Posts: 285
Location: Seattle
|
|
| Back to top |
|
|
khayyam
Watchman
Joined: 07 Jun 2012
Posts: 6227
Location: Room 101
|
| Posted: Mon Jan 08, 2018 10:26 pm Post subject: |
|
|
roki942 ... that would be "hope I die before I get old" on the left channel, and "meet the new boss", on the right channel :) Personally, I'd suggest one or other of Sun Ra, Hanatarash, or Captain Beefheart ... BECAUSE you'll need it!!!
best ... khay |
|
| Back to top |
|
|
jd2066
Apprentice
Joined: 04 Jun 2006
Posts: 155
|
| Posted: Tue Jan 09, 2018 1:29 pm Post subject: |
|
|
| Naib wrote: | | upstream produce and maintain unitfiles because... they can be really simple |
When I first read about systemd, the idea of unit files did seem nice and simple.
Sadly, from what I've read over the last few years, unit files are not as simple as they seem at first.
It's can be hard to determine what a unit file does without having a good understanding of what the various options available for unit files are and what they do.
Even a simple unit file will rely on default behavior can be an issue if the default behavior is not obvious or easy to understand.
| Tony0945 wrote: | | Also: "ini" files? Shades of Windows 95. What's next? the registry? As Linux devolves into Windows because RedHat wants to become Micro$oft. |
Unit files use a format similar to an ini file which is basically just key value pairs divided into sections.
There isn't anything really wrong with the format and other *nix software uses it.
The format of values in a unit file doesn't matter as much though, it could be in JSON or XML but the end result would be a text configuration file verse a text shell script file.
Though I suppose if unit files used a configuration format that was a bit more flexible and descriptive then INI style, it might be easier to understand what the unit is doing.
| Naib wrote: | | The concept of a registry is quite sound the problem is windows ballsed it up and GNOME went batshit insane (at least it wasn't binary) |
| Naib wrote: | sound implementation would be in win3.1 before they went batshit insane with it for win95
The idea of a central place for lookup make sense. This isn't soo much of an issue for linux due to /etc but for window (3.1 era) it did because applications where everywhere and their ini files where everywhere... no easy way for one application to discover the other (without some massive daemon running...). This was why MS added registry in windows 3.1 as a means to centralise the info with a common structure rather then app-x having a different ini style to app-y |
Yeah, that was a problem.
Just adding /etc and /home/user/.program style configuration directories to Windows at that point instead of adding the registry may have worked better to solve the INI files stored everywhere issue.
| Naib wrote: | | thing is MS pulled the sys conf into the registry, poor backend db handling, binary blob, no way to bootstrap in the event of a failure |
Yeah the registry had a lot of issues, many of the issues relating to reliability and performance were addressed in Vista but there are still enough down sides that make it pain to deal with in Windows that wouldn't be much better if done on *nix systems.
Using binary databases for configuration just seems like more trouble than it's worth.
| saellaven wrote: | | That doesn't mean the complexity of init scripts has gone away, it's simply obfuscated and harder for sysadmins to find and deal with. It's not enough to simply know shell anymore, you need to know C. Worse, systemd is constantly having massive sections added or rewritten because it was never designed to begin with, it just kept absorbing more functionality. |
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. |
|
| 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
