Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
The Politics of systemd Part 3
View unanswered posts
View posts from last 24 hours

Goto page Previous  1, 2, 3, 4 ... 10, 11, 12  Next  
Reply to topic    Gentoo Forums Forum Index Gentoo Chat
View previous topic :: View next topic  
Author Message
luiztux
n00b
n00b


Joined: 31 Aug 2015
Posts: 19
Location: /usr/portage/distfiles

PostPosted: Tue Jul 04, 2017 7:38 pm    Post subject: Reply with quote

krinn wrote:
You know what is really good with sh scripts?

You don't depends on Pottering to fix any and do it yourself, and it's like raising your stupid badly broken sh script security by like 200%


Indeed...

Hey guys, what about this?

Gnome devs with inflamed egos too.
Back to top
View user's profile Send private message
tld
Veteran
Veteran


Joined: 09 Dec 2003
Posts: 1222

PostPosted: Tue Jul 04, 2017 11:32 pm    Post subject: Reply with quote

luiztux wrote:
Gnome devs with inflamed egos too.
I cringe whenever I read anything that mentions "libsystemd". I always think of a quote from one of the BSD devs (in a really great youtube interview linked somewhere in one part of this thread), where he says "If the name of your library is lib<my-daemon-name> you're doing it wrong". Hahah...Amen to that.

Tom
Back to top
View user's profile Send private message
helecho
Apprentice
Apprentice


Joined: 26 Dec 2016
Posts: 238

PostPosted: Wed Jul 05, 2017 6:40 am    Post subject: Reply with quote

Hu wrote:
The problem is that the configuration parser as shipped disagrees with the common understanding of the configuration file by end users.

I agree with you! I wanted to mean that the developers of systemd could have cooperated with the developers of the software involved in the problem.
Thus, a suitable solution would have been proposed and users could have apprehended the functioning of systemd services.

Naib wrote:
more bugs, more locks

Their communication should be more conciliatory. However, GitHub seems to be their bug tracking system: "editorial" criteria are tightened in bug reports.

On their mailing list, someone has opened the discussion about the user issue discussed in this thread.
Back to top
View user's profile Send private message
krinn
Watchman
Watchman


Joined: 02 May 2003
Posts: 5968

PostPosted: Wed Jul 05, 2017 7:37 am    Post subject: Reply with quote

Oh i think i understand finally the main reason of all that shit!
https://lists.freedesktop.org/archives/systemd-devel/2017-July/039157.html wrote:
When new configuration options are added, the same unit file can
almost always be used with older systemd, and it'll just warn & ignore
the parts it doesn't understand.


First i was thinking: WTF anyone would care about new options and unit reject by an older buggy systemd?
But on second thinking: it would allow them to break configurations "abi" at will too ; and an unit for systemd v1000 is working with any systemd <1000 because they will just ignore new options they aren't aware of ; and the compatibility they are wishing to keep is that : having a newer unit able to be run under an old systemd, just to remove any need to made versioned unit.

So they are marking this as notabug, because if systemd use the only safe and logical choice to refuse to run an unit with something in it that is not know by your systemd, it would be reject and the unit would fail to work.
Meaning that if anyone is making a unit for a specific systemd version using a keyword this version and newer handle, all previous systemd would fail to work with it.

LOL like if bash 4 would run specific bash 4 command in a script and bash 3 and below will just ignore them "for compatibility"
What a broken design!
In this sense, it really seems not a bug, but a wanted behaviour.
Back to top
View user's profile Send private message
R0b0t1
Apprentice
Apprentice


Joined: 05 Jun 2008
Posts: 218

PostPosted: Wed Jul 05, 2017 8:18 am    Post subject: Reply with quote

krinn wrote:
LOL like if bash 4 would run specific bash 4 command in a script and bash 3 and below will just ignore them "for compatibility"
What a broken design!
In this sense, it really seems not a bug, but a wanted behaviour.
This makes the most sense when you have a developer using newer packages than their users, who are on Debian, Ubuntu, etc. Unfortunately there are far better ways to do it than the way they have chosen, and an implementation that isn't a bug would probably avoid default values that most people do not want.
Back to top
View user's profile Send private message
Zucca
l33t
l33t


Joined: 14 Jun 2007
Posts: 956
Location: KUUSANKOSKI, Finland

PostPosted: Wed Jul 05, 2017 8:25 am    Post subject: Reply with quote

tld wrote:
"If the name of your library is lib<my-daemon-name> you're doing it wrong".
That sums up some good ideas in once sentence.

krinn wrote:
Oh i think i understand finally the main reason of all that shit!
https://lists.freedesktop.org/archives/systemd-devel/2017-July/039157.html wrote:
When new configuration options are added, the same unit file can
almost always be used with older systemd, and it'll just warn & ignore
the parts it doesn't understand.


First i was thinking: WTF anyone would care about new options and unit reject by an older buggy systemd?
But on second thinking: it would allow them to break configurations "abi" at will too ; and an unit for systemd v1000 is working with any systemd <1000 because they will just ignore new options they aren't aware of ; and the compatibility they are wishing to keep is that : having a newer unit able to be run under an old systemd, just to remove any need to made versioned unit.
At some point in future, this design philosophy will kick back hard.
Ignore unknown syntax --> use default values --> run the service. What could possibly go wrong?
It's only matter of time until someone (black hat) finds a severe security flaw from this behaviour and shit starts to hit the fan.
_________________
..: Zucca :..
This space is not for rent.
Back to top
View user's profile Send private message
steveL
Advocate
Advocate


Joined: 13 Sep 2006
Posts: 4809
Location: The Peanut Gallery

PostPosted: Wed Jul 05, 2017 12:26 pm    Post subject: Reply with quote

krinn wrote:
You know what is really good with sh scripts?

You don't depends on Pottering to fix any and do it yourself, and it's like raising your stupid badly broken sh script security by like 200%
LOL.
tld wrote:
Don't even get me started about all this FUD regarding the horrors of shell scripts.
Yes, the position whereby "We cannot write shell, so trust us to write C.."
Shell is just very forgiving: it has to be, since its primary purpose is as an interface between an interactive user and UNIX; so it does the best it can to accept whatever input you throw at it.
That this makes it easy to throw together scripts which aren't well thought-out is not shell's fault. It really is by design, and there is a valid reason for it. (I'm amazed that is seemingly so hard to understand.)

You can write a crap program in any language. It's funny that here we are, 40 years later, still using sh. That is because the underlying design of UNIX was very well thought-through: a stark contrast to the kitchen-sink approach of systemdbust, and so many others that are also best forgotten.

Take some pride in the work, ffs.
Back to top
View user's profile Send private message
Naib
Watchman
Watchman


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

PostPosted: Wed Jul 05, 2017 1:59 pm    Post subject: Reply with quote

tld wrote:
Don't even get me started about all this FUD regarding the horrors of shell scripts. Even in the slashdot post that Naib quoted (where the guy is in fact very critical of how this one was handled) he says "systemd is a key part of the GNU/Linux infrastructure, and it exists for a reason: to remove the reliance on shitty, fragile, shell scripts that were all-too-easily made insecure through ignorance or haste.".

According to who? What the HELL does that even mean? More importantly does it mean that you're better off inserting the functional equivalent of the Windows OS...the epitome of shitty and fragile written with the most clueless ignorance out there...between the kernel and everything else?

Even Redhat doesn't believe any of that shit, and anyone paying attention knows as much.

Tom


the key part in what he wrote was: to remove the reliance on shitty, fragile, shell scripts that were all-too-easily made insecure through ignorance or haste

he and others were not saying all shell scripting is shitty, just that there is. Its a bit of a misdirection because a shitty coder will write shit in whatever they use.
Maybe redhat had an abundance of shitty shell writers ... maybe they had mostly C writers and only a few loosely knew shell...

What probably facilitated Systemd being accepted as a RH project was the fact the low-level code is in C and they quite possibly had a lot more quality C coders (ie to deal with libc etc...) than they did sh coders (who prob only hacked to get things done).

The issue is the architecture of systemd is flaky...




On the username issue... what I find amusing is RedHat, the employer of Pottering, has coreutils that permits a username starting with a numeric character
_________________
The best argument against democracy is a five-minute conversation with the average voter
Great Britain is a republic, with a hereditary president, while the United States is a monarchy with an elective king
Back to top
View user's profile Send private message
mrbassie
Guru
Guru


Joined: 31 May 2013
Posts: 481

PostPosted: Wed Jul 05, 2017 2:39 pm    Post subject: Reply with quote

Naib wrote:


On the username issue... what I find amusing is RedHat, the employer of Pottering, has coreutils that permits a username starting with a numeric character


coreutilsd on the way?
Back to top
View user's profile Send private message
Zucca
l33t
l33t


Joined: 14 Jun 2007
Posts: 956
Location: KUUSANKOSKI, Finland

PostPosted: Wed Jul 05, 2017 7:29 pm    Post subject: Reply with quote

mrbassie wrote:
coreutilsd on the way?
I guess you meant systemd-coreutils(d)? :P
_________________
..: Zucca :..
This space is not for rent.
Back to top
View user's profile Send private message
Hu
Moderator
Moderator


Joined: 06 Mar 2007
Posts: 11431

PostPosted: Thu Jul 06, 2017 1:28 am    Post subject: Reply with quote

tld wrote:
Even in the slashdot post that Naib quoted (where the guy is in fact very critical of how this one was handled) he says "systemd is a key part of the GNU/Linux infrastructure, and it exists for a reason: to remove the reliance on shitty, fragile, shell scripts that were all-too-easily made insecure through ignorance or haste.".
I feel a bit guilty for posting this, but this one is such an easy target. By adopting systemd, we avoid relying on fragile shell scripts that are made insecure through ignorance or haste, and instead get nicely constrained systemd unit files that are made insecure by deliberate design (ignoring security-relevant attributes because there is no way to mark them as a mandatory directive).

On a serious note: I have hinted at this a few times, and I think at least some of the people posting here are thinking along the same lines (in particular krinn's remarks on versioning): the systemd unit file parser needs to have a distinction of advisory directives versus mandatory directives. The unit file parser can ignore unknown advisory directives, but must fail a unit file which has an unknown mandatory directive. Preferably, it would always fail a directive that was known but unacceptable (such as an ill-formed username, or passing a string where a number is expected, etc.). There are several ways that the mandatory versus advisory split could be done.
  • The simplest is to declare all directives mandatory and refuse units which use any unknown directives. The systemd maintainers have already declared they do not like that approach. I agree that this form is a bit limited.
  • They could instead include a version number, and commit to increasing the version number whenever new mandatory directives are added to the language. If systemd encounters a file with unknown directives, and the version number exceeds its own, then this file requires a newer systemd and must be abandoned. If it encounters an unknown directive and the version number is not greater, then this directive can be assumed to be advisory and the unit file accepted.
  • They could divide the namespace, such as by saying that directives with a leading ! are important and are always mandatory. Directives without a leading ! are advisory.
Other possibilities may exist. These are just some quick ones to provide ways to version the file without needlessly removing compatibility with old versions.

Of course, the best solution according to the general systemd design philosophy is that they need to add a new component, provisionally named systemd-packaged, that will automatically update systemd to the latest code tagged by systemd upstream, so that they need never worry about the existence of downlevel installations. Since systemd already runs with privilege, it could update itself out-of-band of the normal distribution packaging system, bypassing distribution maintainers who may take hours or even days to ship new versions and users who might wait until a scheduled downtime to install the new version.
Back to top
View user's profile Send private message
ct85711
Veteran
Veteran


Joined: 27 Sep 2005
Posts: 1397

PostPosted: Thu Jul 06, 2017 1:46 am    Post subject: Reply with quote

Quote:
Of course, the best solution according to the general systemd design philosophy is that they need to add a new component, provisionally named systemd-packaged, that will automatically update systemd to the latest code tagged by systemd upstream, so that they need never worry about the existence of downlevel installations. Since systemd already runs with privilege, it could update itself out-of-band of the normal distribution packaging system, bypassing distribution maintainers who may take hours or even days to ship new versions and users who might wait until a scheduled downtime to install the new version.


This sounds really close to what M$ is doing with windows 10... With their mandatory update on their schedule (regardless that the patches are not well tested, evidenced by the number of major issues that frequently pop up from the updates). Sure they say it's all about keeping people updated to fix security vulnerabilities, but it does the same thing as you said; takes control out of the System admin's hands and puts it in some corporation's hands that only think their use cases matter.

Either way, I think this idea is a really terrible thing...
Back to top
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


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

PostPosted: Thu Jul 06, 2017 9:06 am    Post subject: Reply with quote

Hu,

Hu wrote:
Of course, the best solution according to the general systemd design philosophy is that they need to add a new component, provisionally named systemd-packaged, that will automatically update systemd to the latest code tagged by systemd upstream, so that they need never worry about the existence of downlevel installations. Since systemd already runs with privilege, it could update itself out-of-band of the normal distribution packaging system, bypassing distribution maintainers who may take hours or even days to ship new versions and users who might wait until a scheduled downtime to install the new version.


Err ... No. Replace one buggy version with another and nobody knows.
What about air gapped installs?
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
Back to top
View user's profile Send private message
steveL
Advocate
Advocate


Joined: 13 Sep 2006
Posts: 4809
Location: The Peanut Gallery

PostPosted: Thu Jul 06, 2017 3:38 pm    Post subject: Reply with quote

Naib wrote:
the key part in what he wrote was: to remove the reliance on shitty, fragile, shell scripts that were all-too-easily made insecure through ignorance or haste
Yes, "we've been writing crap shell, so let's not bother learning the implementation language," let's just switch to C programs that are all-too-easily made insecure through ignorance, lack of domain knowledge, haste and ill-conceived design.
Only now we've made it a helluva lot harder for the admin to exercise any real control over the machines they're liable for. Funny, that; almost like a bot-farm.
Quote:
he and others were not saying all shell scripting is shitty
It certainly sounded like it.
At best then, in your version of events, they were saying that their own shell scripting is shitty; which is hardly news to #bash regulars.
And hardly a reason to ditch shell; more of a reason to swallow your pride and learn from people who know what they're doing. (Or hire some.)
Quote:
Its a bit of a misdirection because a shitty coder will write shit in whatever they use.
That's why it's hardly a reason to ditch shell.
If you don't understand your implementation language, the answer is not to blame the language, but to do your fscking job and learn it properly.
Quote:
The issue is the architecture of systemd is flaky...
and it would be flaky in any language, because it's not about what it does at language-level, but about its overall design and the "strategic aims" of RedHat.

That meme about not understanding UNIX? A large part of understanding UNIX is about grokking the shell, and why it's always been a central part of the design.
Nor can you separate C from UNIX, in terms of grokking the language and the standards. C is designed to be called from shell; the distinction of shell preparing (globbing and separating) arguments, and the C runtime using them: that's UNIX, tying together independent processes to achieve the end-result the user wants.
That it seems old-hat, and why would you do anything different, etc, is simply testament to the solidity of the design, which won out against various other competing models in the 1970s. (Winbloze still leaves it to individual programs to eg: glob arguments, or not, which is one of the ways it is so woefully broken by design.)

Nubs who want to parade their ignorance by vilifying shell only show themselves up as ingenues.

Let's not apologise for them, as if they weren't really saying what they were saying.
Even more importantly, let's not follow them into that broken by design vision of the future, where we're no longer admins and users, but just passive consumers, grateful for whatever the Corporation has "rented" us of our own shared work.
Back to top
View user's profile Send private message
tld
Veteran
Veteran


Joined: 09 Dec 2003
Posts: 1222

PostPosted: Thu Jul 06, 2017 5:41 pm    Post subject: Reply with quote

steveL wrote:
(Winbloze still leaves it to individual programs to eg: glob arguments, or not, which is one of the ways it is so woefully broken by design.)
Oh man...do NOT even get me started on that mess. We suffer from that to this day, even for example, with the Linux version of unzip, where you need to use:
Code:
unzip "*.zip"
...to unzip multiple archives, because unzip itself handles the glob itself apparently. Let's not forget Mac OS <= 9 that arguably did Windows one better with no concept of a CLI at all and...if I'm not mistaken...no concept of stdin or stdout. Yuk.
Back to top
View user's profile Send private message
depontius
Advocate
Advocate


Joined: 05 May 2004
Posts: 3250

PostPosted: Thu Jul 06, 2017 6:34 pm    Post subject: Reply with quote

tld wrote:
...with no concept of a CLI at all and...if I'm not mistaken...no concept of stdin or stdout. Yuk.


I know I'm crossing the line between Mac, Windows, and systemd here, but...

The systemd people have been doing away with the command line, communicating over dbus instead of stdin/stdout. I wonder if we'll even recognize mainstream Linux in five or ten years.
_________________
.sigs waste space and bandwidth
Back to top
View user's profile Send private message
ct85711
Veteran
Veteran


Joined: 27 Sep 2005
Posts: 1397

PostPosted: Thu Jul 06, 2017 6:45 pm    Post subject: Reply with quote

One thing I find rather interesting is, wasn't the Systemd devs one of the people that was complaining quite loudly that dbus is slow and needs to be replaced. This is even though they are more reliant to dbus and shove even more stuff, including the kitchen sink through dbus (which supposedly is soo slow)...
Back to top
View user's profile Send private message
Zucca
l33t
l33t


Joined: 14 Jun 2007
Posts: 956
Location: KUUSANKOSKI, Finland

PostPosted: Thu Jul 06, 2017 7:28 pm    Post subject: Reply with quote

Off-Topic:

tld wrote:
Let's not forget Mac OS <= 9 that arguably did Windows one better with no concept of a CLI at all and...if I'm not mistaken...no concept of stdin or stdout. Yuk.
I've used Mac OS 9 in the past for many years. So far it's the most unstable OS I've ever used and at the same time the worst. The earlier Mac OS 8 was quite bad too. But before that (System 7) Apple had something there. Apple even had A/UX. Sadly not many applications ran on it. I wish it was more succesful, but Apple pulled the plug, I guess. Later they actually partly funded the MkLinux project (the site is still up :o), which was great, but sadly the provided image didn't recognize my networking interface (some tower PowerMac), so I gave up.
_________________
..: Zucca :..
This space is not for rent.
Back to top
View user's profile Send private message
Ant P.
Advocate
Advocate


Joined: 18 Apr 2009
Posts: 4528

PostPosted: Thu Jul 06, 2017 8:15 pm    Post subject: Reply with quote

depontius wrote:
I wonder if we'll even recognize mainstream Linux in five or ten years.

If their track record stays consistent, GNOME and KDE in ten years will superficially resemble OSX and Windows five years from now, will have system requirements 20 years ahead of Moore's Law, and embody all the maintainability and engineering wisdom of enterprise software written in the late 90s.
The desktop arguments will be stronger than ever by then, everyone having had to go back to native apps after browsers and browserapps begin requiring a small nuclear reactor to render a HTML hello world...
_________________
*.ebuild // /etc/service/*
Back to top
View user's profile Send private message
Hu
Moderator
Moderator


Joined: 06 Mar 2007
Posts: 11431

PostPosted: Fri Jul 07, 2017 12:58 am    Post subject: Reply with quote

ct85711 wrote:
This sounds really close to what M$ is doing with windows 10...

Either way, I think this idea is a really terrible thing...
For the record, my last paragraph was a joke inspired by the past pattern of systemd subsuming components that ought to remain separate. While I won't be surprised if a systemd maintainer one day tries to do what I described, I don't think it's a good idea for them to supplant distributions.
Back to top
View user's profile Send private message
mrbassie
Guru
Guru


Joined: 31 May 2013
Posts: 481

PostPosted: Fri Jul 07, 2017 9:57 am    Post subject: Reply with quote

Saw this on the BSDNow podcast: https://marc.info/?l=openbsd-tech&m=149902196520920&w=2
Back to top
View user's profile Send private message
Zucca
l33t
l33t


Joined: 14 Jun 2007
Posts: 956
Location: KUUSANKOSKI, Finland

PostPosted: Sat Jul 08, 2017 12:45 pm    Post subject: Reply with quote

mrbassie wrote:
Saw this on the BSDNow podcast: https://marc.info/?l=openbsd-tech&m=149902196520920&w=2
Cold day in hell...
_________________
..: Zucca :..
This space is not for rent.
Back to top
View user's profile Send private message
berferd
n00b
n00b


Joined: 13 May 2004
Posts: 57

PostPosted: Sun Jul 09, 2017 6:07 pm    Post subject: Reply with quote

Never has a patch made me laugh so hard...
Back to top
View user's profile Send private message
Naib
Watchman
Watchman


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

PostPosted: Mon Jul 10, 2017 12:32 pm    Post subject: Reply with quote

helecho wrote:
Hu wrote:
The problem is that the configuration parser as shipped disagrees with the common understanding of the configuration file by end users.

I agree with you! I wanted to mean that the developers of systemd could have cooperated with the developers of the software involved in the problem.
Thus, a suitable solution would have been proposed and users could have apprehended the functioning of systemd services.

Naib wrote:
more bugs, more locks

Their communication should be more conciliatory. However, GitHub seems to be their bug tracking system: "editorial" criteria are tightened in bug reports.

On their mailing list, someone has opened the discussion about the user issue discussed in this thread.

I have been following the ml around this and they just don't get it... (well some do)

Some are saying username starting with a number should be blocked by Systemd (this is countered by others that SysD should not restrict this)
Some are saying such usernames are invalid (others point out that thats not the case, equally Windows permits it thus samba must THUS linux needs to support it otherwise samba won't work on systemd systems)
Some are saying that the unitfile will run as the UID of the leading number (yet the bug actually states My systemd v232 says: Invalid user/group name or numeric ID, ignoring: 7oz and starts the service as root also. Likely because the 7oz as a whole is not a valid number.)
Some are pulling the usual its systemd-bashing bandwagon so ignore it
Some are saying it isn't a bug...
_________________
The best argument against democracy is a five-minute conversation with the average voter
Great Britain is a republic, with a hereditary president, while the United States is a monarchy with an elective king
Back to top
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


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

PostPosted: Mon Jul 10, 2017 1:29 pm    Post subject: Reply with quote

How many Microsoft engineers does it take to change a lightbulb ...

Its much the same with systemd
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Gentoo Chat All times are GMT
Goto page Previous  1, 2, 3, 4 ... 10, 11, 12  Next
Page 3 of 12

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