| View previous topic :: View next topic |
| Author |
Message |
Anon-E-moose
Watchman
Joined: 23 May 2008
Posts: 6098
Location: Dallas area
|
 Posted: Thu Mar 13, 2014 11:57 am Post subject: |
 |
|
I can accept something like emacs as a kitchen sink.
But I want and expect the init system to do one thing, to start services.
Whether it has monitoring capablilties or restart ability is important, but covered by other programs.
Having awareness of cgroups, and system logging is also fine in init.
That doesn't mean that the functionality of managing cgroups or logging should be part of init though.
Awareness is not management.
Things like dbus and gui login management don't belong there either
as they aren't really useful or necessary until something like X/wayland is started.
Init is such a vital piece of keeping the system running that it should be as simple and bullet proof as possible.
People that have run some flavor of windows are intimately familiar with the BSOD.
This is the type of problem that is always possible with an overly ambitious piece of
software that trys to take on too many non system functions and mix them with
other functions that are necessary to the health of a running system.
Just some thoughts.
_________________
PRIME x570-pro, 3700x, 6.1 zen kernel
gcc 13, profile 17.0 (custom bare multilib), openrc, wayland |
|
| Back to top |
|
 |
ArneBab
Guru
Joined: 24 Jan 2006
Posts: 429
Location: Graben-Neudorf, Germany
|
| Posted: Fri Mar 14, 2014 2:49 pm Post subject: |
|
|
| depontius wrote: | | Anon-E-moose wrote: |
An editor does editing, a mail program handles mail, a compiler compiles and creates programs. |
Perhaps a poor example - there's always emacs, oft cited as the ultimate case of creeping functionality. |
I take (a bit of) offense in this comparison of systemd and Emacs.
This is equivalent to calling python a functionality creep - Emacs is an environment which runs elisp programs and provides a text-based user-interface. The editor-part is simply an application running in that environment - which becomes apparent when you see that people reimplemented vi in emacs lisp ☺
Would you call Android programs functionality creep, because they also use a shared runtime and can register the features they provide (like emacs hooks, just about 15 years late)?
The separation between elisp programs in emacs is different from those written in C, because they can use "buffers" to share data directly and because they can reuse each others functions (as C programs can, when they link to a shared library). But it still provides separate programs: You can even start a second emacs and run the second program there (a second VM). People just don’t normally do that, because then they would lose lots of the high integration you get with emacs. Also many elisp programs simply provide a user interface for interacting with external processes. When you use Emacs to program in Python, emacs does not implement a new python parser for checking programs. Instead it simply calls pyflakes and reads its output. And when you run mu4e, it shows the output from the mu mail indexer.
Rather than as an example for creeping functionality, I see Emacs as an example how to provide the features of a modern desktop for a text-based environment while providing useful structures to keep interacting programs manageable. And you could even use it from vim for exporting org-mode files - by simply running an org-mode parsing elisp script. I for example often start a new emacs from within emacs to run code-snippets: I have a convenience function for that which tells the second emacs to open the file, go to the correct line and then execute the snippet - and exit when it’s done.
But you won’t see Emacs handling login-sessions or implementing a file-system. And if it needs to access remote files, it just shells out to ssh or an ftp-client.
With dbus on the other hand, modern desktop sessions are actually more entangled than emacs (which I painfully realize whenever I get IO-pressure because that can drive up dbus latency to several seconds). Guess what systemd swallowed early on…
Try to put the features of a desktop environment and of Emacs side-by-side. This is the function of Emacs: It provides a text-based desktop environment in which you can run elisp programs (which can run other, non-elisp programs).
Different from that, systemd is one program which you as user should explicitly not change. It is no small core which enables lots of great applications, but rather a big, intransparent core, which allows you to push some of its buttons. They explicitly do not want scripts, so users can always only push buttons instead of making systemd do what they need.
_________________
Being unpolitical means being political without realizing it. - Arne Babenhauserheide ( http://draketo.de )
pkgcore: So fast that it feels unreal - by doing only what is needed. |
|
| Back to top |
|
|
TomWij
Retired Dev
Joined: 04 Jul 2012
Posts: 1553
|
| Posted: Fri Mar 14, 2014 3:45 pm Post subject: |
|
|
| ArneBab wrote: | | Different from that, systemd is one program which you as user should explicitly not change. It is no small core which enables lots of great applications, but rather a big, intransparent core, which allows you to push some of its buttons. They explicitly do not want scripts, so users can always only push buttons instead of making systemd do what they need. |
systemd consists of a lot of programs, around ~70 of them; the list:
| Code: | | 50-depmod.install, 90-loaderentry.install, accelerometer, ata_id, bootctl, cdrom_id, collect, hostnamectl, journalctl, kernel-install, localectl, loginctl, machinectl, mtd_probe, scsi_id, systemctl, systemd, systemd-ac-power, systemd-activate, systemd-analyze, systemd-ask-password, systemd-backlight, systemd-binfmt, systemd-bootchart, systemd-cat, systemd-cgls, systemd-cgroups-agent, systemd-cgtop, systemd-coredump, systemd-coredumpctl, systemd-delta, systemd-detect-virt, systemd-efi-boot-generator, systemd-fsck, systemd-fstab-generator, systemd-getty-generator, systemd-gpt-auto-generator, systemd-hostnamed, systemd-inhibit, systemd-initctl, systemd-journald, systemd-localed, systemd-logind, systemd-machine-id-setup, systemd-machined, systemd-modules-load, systemd-multi-seat-x, systemd-notify, systemd-nspawn, systemd-quotacheck, systemd-random-seed, systemd-readahead, systemd-remount-fs, systemd-reply-password, systemd-run, systemd-shutdown, systemd-shutdownd, systemd-sleep, systemd-stdio-bridge, systemd-sysctl, systemd-system-update-generator, systemd-timedated, systemd-tmpfiles, systemd-tty-ask-password-agent, systemd-udevd, systemd-update-utmp, systemd-user-sessions, systemd-vconsole-setup, timedatectl, udevadm, v4l_id |
The core /usr/lib/systemd/systemd is only 1.1M, which is a small enough core for the systems it targets; it is also reasonable compared to all the programs that are brought along. There are a lot of buttons in the configuration files as well as the unit files. Many of the programs brought along can be enabled or disabled by simply enabling or disabling their service. A lot of these programs can also be changed by replacing them by a different program if you found another implementation; or alternatively, changing the source code of the program in question. If you want to go more extensive than that, scripts can be done.
Last edited by TomWij on Fri Mar 14, 2014 3:49 pm; edited 2 times in total |
|
| Back to top |
|
|
depontius
Advocate
Joined: 05 May 2004
Posts: 3509
|
| Posted: Fri Mar 14, 2014 3:46 pm Post subject: |
|
|
| ArneBab wrote: | | depontius wrote: | | Anon-E-moose wrote: |
An editor does editing, a mail program handles mail, a compiler compiles and creates programs. |
Perhaps a poor example - there's always emacs, oft cited as the ultimate case of creeping functionality. |
I take (a bit of) offense in this comparison of systemd and Emacs. |
I was merely seeing a bit of irony in mentioning "editor" and "mail program" in that context, in the same sentence. The moment you have an extension language, the sky's the limit. Really, I would rather see an extension language start full-fledged, as elisp is, than to begin as a limited language that gets awkwardly extended.
Applying this thought to systemd - right new they eschew init scripts, and have their own limited configuration scheme. Anyone want to bet how many years down the road it will take before the systemd configuration scheme becomes Turing complete? Along that line, I really ought to learn more about Lua, some time. I get the impression that it's meant to be an embedded configuration language, Turing complete from the outset. But I haven't really read about it or studied it - it just gets pulled in by portage to support something else.
_________________
.sigs waste space and bandwidth |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Fri Mar 14, 2014 9:15 pm Post subject: |
|
|
| depontius wrote: | | I was merely seeing a bit of irony in mentioning "editor" and "mail program" in that context, in the same sentence. |
Feature-creep is nothing new and in this context, "The Law of Software Envelopment" (from 1995/6) is relevant:
| Code: | | Every program attempts to expand until it can read mail. Those programs which cannot so expand are replaced by ones which can. |
Speaking for most programmers, feature-creep is not our fault! It's you pesky users who insist that "yes, but I really just need to send it, and get back to work" ;-)
| Quote: | | The moment you have an extension language, the sky's the limit. Really, I would rather see an extension language start full-fledged, as elisp is, than to begin as a limited language that gets awkwardly extended. |
Agreed, though.. (swapping for sense):
| Quote: | | Along that line, I really ought to learn more about Lua, some time. I get the impression that it's meant to be an embedded configuration language, Turing complete from the outset. But I haven't really read about it or studied it - it just gets pulled in by portage to support something else. |
It's really designed to script C and C++: it's main market is scripting for game engines. It's a lovely language under the hood: you should try it.
In that regard, a language doesn't have to do lots, if it provides decent access to an underlying platform. (clojure is an example; running on a JVM, it enables you to do things you can't do in Java, as well as making Java facilities an awful lot nicer to use.) The best way to do that is with a small, cohesive core, extensibility (at language-level) and robust core libs, that anyone can extend. The key is to separate out what really must be in the language, and what really doesn't need to be, which is why language people spend so long obsessing about the "best" methods (or "purity".) It's not so much about forcing one way to do it, as not adding things that are really syntactic sugar to the core, but leaving them as sugar so they can be reworked. Haskell is very good at this, though a bit too much like perl sometimes, for my liking.
Essentially, the interesting languages tend to be functional, mainly because to learn them in any depth, you have to have read SICP which will blow your mind if you haven't already read it (you can download it there, but I really do recommend buying it, as it's essential.) Scheme (the original SCM tyvm) the language it uses to describe just how simple a LISP is while enabling complexity, is really impressive. Anyhow the book is all about language and computation.
(I don't actually like the LISPs, but that's another argument..;)
| Quote: | | Applying this thought to systemd - right new they eschew init scripts, and have their own limited configuration scheme. Anyone want to bet how many years down the road it will take before the systemd configuration scheme becomes Turing complete? |
It already has: polkit relies on javascript, which is ofc a much more stable and robust platform than sh. What could go wrong? </sarcasm>
Just think: a whole new language for busy admins to learn, which uses a completely different metaphor than any language they're used to, and which is notoriously difficult to do right. So much so, that someone had to write a book on how to use it without blowing things up. Short version: treat it as a LISP.
And so we come full circle: the new One True Way.. same as the old. |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6747
|
| Posted: Fri Mar 14, 2014 9:40 pm Post subject: |
|
|
| steveL wrote: | | It already has: polkit relies on javascript |
Fortunately, polkit is not systemd. Let us hope that the developers have at least the sanity to keep these things separate. |
|
| Back to top |
|
|
Anon-E-moose
Watchman
Joined: 23 May 2008
Posts: 6098
Location: Dallas area
|
| Posted: Fri Mar 14, 2014 9:57 pm Post subject: |
|
|
| mv wrote: | | Let us hope that the developers have at least the sanity to keep these things separate. |
The track record of them having common sense is woefully lacking.
_________________
PRIME x570-pro, 3700x, 6.1 zen kernel
gcc 13, profile 17.0 (custom bare multilib), openrc, wayland |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Sat Mar 15, 2014 9:53 pm Post subject: |
|
|
| mv wrote: | | Fortunately, polkit is not systemd. Let us hope that the developers have at least the sanity to keep these things separate. |
As Anon-E-Moose pointed out, sanity when it comes to avoiding coupling is not this upstream's strong suit. Further, all I've seen recently is more and more discussion of how to tweak polkit using js (eg to allow a certain group to do something, usually the standard ones we already had, like plugdev); that makes me think it's very much seen as part of the "One True Userland"; things like logind already rely on it to know whether you are allowed to shut the machine down, iirc. (lul.) |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6747
|
| Posted: Sun Mar 16, 2014 8:07 am Post subject: |
|
|
| steveL wrote: | | As Anon-E-Moose pointed out, sanity when it comes to avoiding coupling is not this upstream's strong suit. |
This is true, but nevertheless systemd's ./configure currently knows --disable-policykit, and AFAIK there are no plans to change this. So, at least to say, "it has already happened " is not correct.
| Quote: | | makes me think it's very much seen as part of the "One True Userland" |
The "One True Userland" is not decided by one person alone.
I am sure that in the moment when systemd unconditionally requires polkit, all the distributions which jump now on the systemd train will leave it again, because it is so obvious to everybody that with polkit it is impossible to have a secure system. I hope that this will put enough pressure to upstream to keep polkit optional.
It cannot be said often enough: The true dangerous thing of this "one true way" is polkit/udisks2 and not systemd. |
|
| Back to top |
|
|
krinn
Watchman
Joined: 02 May 2003
Posts: 7470
|
| Posted: Sun Mar 16, 2014 9:03 am Post subject: |
|
|
| mv wrote: | | I am sure that in the moment when systemd unconditionally requires polkit, all the distributions which jump now on the systemd train will leave it again, because it is so obvious to everybody that with polkit it is impossible to have a secure system. |
Well, i'm far less sure than you, at first, everyone doesn't like to put work & time on something just to drop it few moment later, adding systemd is putting time & effort to make it work, instead of dropping those for a problem, they would like to put some more to fix it.
And so, even if you didn't think about that prior to making the switch ; we've seen many times stupidity has no limit...
And i don't see why they should be scared about security : just adopting systemd is the biggest security issue for any distro.
If all distros are going to support systemd only, this will be the biggest challenge as now any attacker (put name you wish here: script-kiddy, trojan, gov agency...) are limited to only analyze and breach systemd.
And it means any attacker able to break fedora thru systemd will be able to break into any other distro (the debian server stability and security fame time is running short)...
So now you've got many distros that would be per default running a beta init system that change and will continue to change because even you think "The One True Userland" is not decided by one person, in real, you could see it is by two and those two like to change anything & anytime for no sane reason. Just like the renaming of files & moving files has shown on recent udev ; it's simply something not acceptable for a stable major critical part of a system : but for a two guys beta program it's something done without even a warning. |
|
| Back to top |
|
|
asturm
Developer
Joined: 05 Apr 2007
Posts: 8936
|
| Posted: Sun Mar 16, 2014 9:15 am Post subject: |
|
|
| krinn wrote: | And i don't see why they should be scared about security : just adopting systemd is the biggest security issue for any distro.
If all distros are going to support systemd only, this will be the biggest challenge as now any attacker (put name you wish here: script-kiddy, trojan, gov agency...) are limited to only analyze and breach systemd. |
That claim is equally idiotic as security by obscurity.
The discussion hasn't evolved at all it seems. You guys could go back a few weeks, months and just copy/paste your existing posts.
Last edited by asturm on Sun Mar 16, 2014 9:25 am; edited 2 times in total |
|
| Back to top |
|
|
krinn
Watchman
Joined: 02 May 2003
Posts: 7470
|
| Posted: Sun Mar 16, 2014 9:19 am Post subject: |
|
|
| genstorm wrote: | | That claim is equally idiotic as security by obscurity. |
Time will tell... |
|
| Back to top |
|
|
666threesixes666
Veteran
Joined: 31 May 2011
Posts: 1248
Location: 42.68n 85.41w
|
| Posted: Sun Mar 16, 2014 9:46 am Post subject: |
|
|
gentoo is pro choice....
all in favor of a systemd abortion say aye....
aye! |
|
| Back to top |
|
|
Anon-E-moose
Watchman
Joined: 23 May 2008
Posts: 6098
Location: Dallas area
|
| Posted: Sun Mar 16, 2014 11:02 am Post subject: |
|
|
| mv wrote: | | It cannot be said often enough: The true dangerous thing of this "one true way" is polkit/udisks2 and not systemd. |
So they don't require polkit and udisks (as separate pkgs) but instead
just put the guts of those into systemd without many changes, then what?
One still has the same problem but now it's even more intertwined with everything.
_________________
PRIME x570-pro, 3700x, 6.1 zen kernel
gcc 13, profile 17.0 (custom bare multilib), openrc, wayland |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Mon Mar 17, 2014 3:42 am Post subject: |
|
|
| mv wrote: | | This is true, but nevertheless systemd's ./configure currently knows --disable-policykit, and AFAIK there are no plans to change this. So, at least to say, "it has already happened " is not correct. |
Trust me that is much less reassuring on a development level, and much weaker language than "You will continue to be able to build and use udev without systemd with no changes," ever was. AFAIC it's part of the same strategy, from the same upstream, no from the same team.
| Quote: | | The "One True Userland" is not decided by one person alone. |
It's one small team, backed by one very large, very rich company which has near-monopoly position in a very large, very lucrative market: enterprise Linux, and now wants to head off home-entertainment using Linux. They already have huge mind-share, and kudos from their early days: no corporation can ever resist the fiduciary responsibility to shareholders though: that's ALL it's about (or the directors get fired, er retire with a golden handshake and a massive pension pot, while the workers get laid off to "slimline the operation.")
| Quote: | | I am sure that in the moment when systemd unconditionally requires polkit, all the distributions which jump now on the systemd train will leave it again, because it is so obvious to everybody that with polkit it is impossible to have a secure system. I hope that this will put enough pressure to upstream to keep polkit optional. |
Yeah and everybody stopped buying Microsoft when the security flaws had been proven.. ;p
| Quote: | | It cannot be said often enough: The true dangerous thing of this "one true way" is polkit/udisks2 and not systemd. |
No the real danger is the very conception of "one true way" which is why we've been warned about it again and again by the people who invented and handed down the legacy we now hold in our hands for the next generation. It enables all kinds of idiocy as you just describe, and people will focus on the minutiae of the detail about which package it's in, as if that were the real problem: another form of misdirection, just like the "you want processes, we've got processes, roll up roll up, one distro gets you 70! For FREE man, c'mon man we're giving you this stuff for FREE."
It's not about technology: it's about psychology, conditioning and cognitive dissonance. All "soft", "boring" subjects, but they do affect our lives, whether we like it or not. At least if you're conscious of it, you have some chance to step back from it and gain some perspective and control back.
@genstorm: Don't blame me, most of my post was about languages, and I cut the LISP argument out, as it was about as long again :)
Strangely no-one wants a code language discussion..
People are chatting on a internet forum thread, shock horror: I think it's pretty clear by now that Gentoo is not "switching to systemd" as default in the near (1) or even medium-term (2-4 years). There's no benefit to not being able to provide both, that would be a regression in overall capability of the distro. And why on earth would anyone want to build (at distro side) and install a systemd stage, simply to rip it out and go through all those linkage problems, when you can start with an openrc one that works, and easily install whatever you need by setting your profile and emerging world? And meantime we don't lose flexibility, nor do we put all our eggs in one vendor-locked basket, which protects the longer-term interests of our community, as well as being more in line with the Gentoo philosophy.
If the mods feel it's worth splitting a new thread (not for the sake of form, but because there's an interesting discussion, the positive action they usually take by themselves) they will. They don't need us to do their jobs for them, just to leave them to get on with it, in the background keeping things jiggy ;p
How about a new topic explaining how you've set everything up in 5 minutes after install, since all the daemon scripts are written by upstream, and how you got through the inevitable hiccups inherent in every new software project? Document the process and the hiccups you found tricky, so others can get past them and perhaps even improve the underlying software, or at least the distro.
BTW you're ignoring the concept of "attack vector" (combine with bindist for fun and profit;)
OFC if anyone wants to defend a LISP, I'm more than happy to go into why I don't like them, ultimately ;> |
|
| Back to top |
|
|
Anon-E-moose
Watchman
Joined: 23 May 2008
Posts: 6098
Location: Dallas area
|
| Posted: Mon Mar 17, 2014 10:18 am Post subject: |
|
|
| steveL wrote: | | People are chatting on a internet forum thread, shock horror: |
I have never understood people saying they don't like others discussing some subject
but they're always in the middle of such a discussion whining about it and how it shouldn't exist.
Are they not smart enough to realize that they don't have to click on that thread and open and read it?
_________________
PRIME x570-pro, 3700x, 6.1 zen kernel
gcc 13, profile 17.0 (custom bare multilib), openrc, wayland |
|
| Back to top |
|
|
ulenrich
Veteran
Joined: 10 Oct 2010
Posts: 1480
|
| Posted: Mon Mar 17, 2014 10:19 am Post subject: |
|
|
| steveL wrote: | | mv wrote: | | I am sure that in the moment when systemd unconditionally requires polkit, all the distributions which jump now on the systemd train will leave it again, because it is so obvious to everybody that with polkit it is impossible to have a secure system. I hope that this will put enough pressure to upstream to keep polkit optional. |
Yeah and everybody stopped buying Microsoft when the security flaws had been proven.. ;p |
| mv wrote: | | It cannot be said often enough: The true dangerous thing of this "one true way" is polkit/udisks2 and not systemd. |
@mv,
firstly, I don't buy yet your policykit assessment in a previous thread regarding the javascript engine is generally unsafe: It was developed to handle undefined input (internet). Here, for polkit purpose, it processes well defined upstream distributed statements.
secondly, I know polkit will be needed by kDbus. If you have watched the Googles hangout conference of Ubuntu developers talking about their systemd transition, you have seen their desire to have kDbus in a year from now.
For me this your new expectation ("will put enough pressure to upstream") is flawed from the beginning, like a year ago, when all predicted systemd to die, because of bad quality of code/concept. Thus rejecting this my statements as pure propaganda like last year, I would feel like a non-believer caught in a religiously motivated campaign ...
Just for the record:
I second what steveL talks about the untrue one way.
Propagating wrong expectations just to see the apocalypse in a year from now is religion like. |
|
| Back to top |
|
|
TomWij
Retired Dev
Joined: 04 Jul 2012
Posts: 1553
|
| Posted: Mon Mar 17, 2014 9:51 pm Post subject: |
|
|
| steveL wrote: | | And why on earth would anyone want to build (at distro side) and install a systemd stage, simply to rip it out and go through all those linkage problems, when you can start with an openrc one that works, and easily install whatever you need by setting your profile and emerging world? |
A systemd stage3 is being talked about, as well as worked towards (see https://bugs.gentoo.org/show_bug.cgi?id=482702 for instance); it would help in such way that a migration becomes superfluous, such that you can start with a systemd stage3 that works and easily install whatever you need by setting your profile and emerging world. If you think this through; in the short term OpenRC continues to act as default, but long term it will feel as that the concept of a default will fade away. This is something I think Gentoo should work towards; for example, that can even mean that another option could become a Olde Fashioned Gentooee flavored stage3. To base this on more actual data; grepping case insensitive for "OpenRC" and "init" through all Council meeting logs and summaries, it has never been brought up as a default, as favored or something along those lines. |
|
| Back to top |
|
|
NeddySeagoon
Administrator
Joined: 05 Jul 2003
Posts: 54237
Location: 56N 3W
|
| Posted: Mon Mar 17, 2014 10:01 pm Post subject: |
|
|
TomWij,
hehe. I'd settle for an Olde Fashioned Gentooee stage1 right now. :)
_________________
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: Tue Mar 18, 2014 1:30 am Post subject: |
|
|
| steveL wrote: | | There's no benefit to not being able to provide both, that would be a regression in overall capability of the distro. And why on earth would anyone want to build (at distro side) and install a systemd stage, simply to rip it out and go through all those linkage problems, when you can start with an openrc one that works, and easily install whatever you need by setting your profile and emerging world? |
| TomWij wrote: | | A systemd stage3 is being talked about, as well as worked towards (see https://bugs.gentoo.org/show_bug.cgi?id=482702 for instance); it would help in such way that a migration becomes superfluous, such that you can start with a systemd stage3 that works and easily install whatever you need by setting your profile and emerging world. |
You talk of "migration" as if it were a big thing: you can already do exactly what you said from an openrc stage. In fact you're just repeating what I wrote above. So lots of work for zero benefit.
However a systemd stage is only really of interest to systemd users, since it's going to be a lot of hassle ripping it all out, and you'd still likely have remnants of it. For instance, landley mentioned a while back on IRC, that systemd udev rules need to be removed if you are going to do a fair comparison, since they slow the machine down when systemd is not actually in use. So "migration" from a systemd stage to openrc is a big thing, yes, but not the other way round, which is a doddle.
So a systemd stage3, is much less capable than an openrc stage3 which can be used for both. By all means do one, no-one's stopping you.
| Quote: | | If you think this through; in the short term OpenRC continues to act as default, but long term it will feel as that the concept of a default will fade away. |
In your head perhaps, not in mine, for the reasons given. If you don't want to acknowledge those, that's fine, too. It won't stop them being factors in the decision-making.
| Quote: | | This is something I think Gentoo should work towards; |
Yes your agenda of "pushing Gentoo forward". Unfortunately the reasoning is often flawed, afaic, so I won't be following that agenda. IMO it's just "shiny, shiny" and we've dealt with that lots of times in Gentoo; it's antarus' expression, ask him to explain it to you if you like.
| Quote: | | for example, that can even mean that another option could become a Olde Fashioned Gentooee flavored stage3. |
That's just typical pretext afaic. What you talk about is already being worked on, but it could never be recommended as what people download for their first install.
| Quote: | | To base this on more actual data; grepping case insensitive for "OpenRC" and "init" through all Council meeting logs and summaries, it has never been brought up as a default, as favored or something along those lines. |
That's not real data at all. It's just mock-statistics imo (I specialised in Probability and Statistics) and you're presenting that to assert "it's never been considered a default" as if it gives weight or precedence to your argument, which is essentially that we need a systemd stage, nothing else.
You're then trying to conflate that into some sort of "forward direction" of no default, presenting it as "good for everyone" bringing in Olde-Fashioned Gentooee as something you care about, when in fact it is a total and utter rejection of that upstream.
We don't need any such thing, since it's easy to set your profile (which you have to do anyway) and emerge what you need from the stage3 releng already provides. And it's bad software engineering not to have a stage3 that must be working at all times, from which you can install any setup you like without major inconvenience. It'd be awful for Gentoo afaic.
But very good for RedHat.
*still hoping someone's gonna step up for LISP*
Last edited by steveL on Tue Mar 18, 2014 1:39 am; edited 1 time in total |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6747
|
| Posted: Tue Mar 18, 2014 1:38 am Post subject: |
|
|
| ulenrich wrote: | | firstly, I don't buy yet your policykit assessment in a previous thread regarding the javascript engine is generally unsafe: It was developed to handle undefined input (internet). |
Just have a look at [Browser of your choice supporting javascript] and you have a proof that javascript never ever had any bugs allowing for exploits. And if some malevolent person should ever have found such a bug, it is for sure that this bug was squashed many years ago, and certainly no browser can suffer from such exploits since dozens of years, since this was the main design goal of javascript.
This is why everybody recommends you to run your web browser as root and scripts activated, since javascript is so enormously safe that you can trust it blindly. And this is why this practically happening when running polkit is absolutely safe.
However, it is not javascript per se which is the danger of polkit - as you say correctly, it should be running only trusted input - it is the sheer complexity of polkit which with the introduction of a complex language interpreter even the developers themselves do not have the slightest chance to understand in all detail. It is exactly such complexity which made windows (whose permission is far less complex) so buggy, because there are so many unexpected side effects which you would have to understand in all details - including having the fantasy of all hackers to exploit the craziest unexpected things (just think about the recent exploits in ssl which is trivially simple compared to polkit) - if you dream of even a halfway safe system. Just think of all the exploits of using all sorts of race conditions to dbus (polkit already has suffered from a lot of bugs of this type).
| Quote: | | secondly, I know polkit will be needed by kDbus. |
No. A sane system of policies is required if you use kDbus, not necessarily a system which is implemented over the polkit insanity.
| Quote: | | conference of Ubuntu developers |
Ubuntu aims at the desktop. They use polkit already. You cannot expect a safe Ubuntu server.
| Quote: | | For me this your new expectation ("will put enough pressure to upstream") is flawed from the beginning |
Maybe, but it is hard to believe that all distributions (even those not driven by power interests) completely throw sanity over board and ignore the experience of security experts.
| Quote: | | Propagating wrong expectations just to see the apocalypse in a year from now is religion like. |
I know, in your eyes everybody pointing out the nonsense going on does this just because he is a religious fanatic.
I still have hope that sanity might take over. Otherwise, indeed, I have to quit using linux, because I am not going to use a system which is inherently less secure than windows. |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Tue Mar 18, 2014 1:57 am Post subject: |
|
|
| mv wrote: | | Quote: | | Propagating wrong expectations just to see the apocalypse in a year from now is religion like. |
I know, in your eyes everybody pointing out the nonsense going on does this just because he is a religious fanatic.
I still have hope that sanity might take over. Otherwise, indeed, I have to quit using linux, because I am not going to use a system which is inherently less secure than windows. |
Ulenrich was actually discussing the adherents of a "one true way" in this case the systemd fanatics who propagandise unrealistic expectations, after which everyone gets let-down but has already put in too much work; that's when the cognitive dissonance steps in and people refuse to believe they've been duped and rather that it's all the fault of someone else, or even that they just don't understand because they're not worthy, or something.
It's very similar to the scams that have been run in the past, such as debt on state currency owed to private interests, or the various cult leaders in recent US history. Instead of realising it's a scam, even when told about it, people prefer to go along with it, and eg: blame the poor or the immigrants, or high taxation, while ignoring the trillions going out the door via that fraud and the billions being lost every month through tax-evasion-we-call-it-avoidance-so-thats-ok-then. To do otherwise would be to admit that they've been duped, and the "leaders" they look up to are in fact kleptocrats, and people would rather not do that.
Cognitive dissonance is summed up in the Wizard's First Rule:
"People are stupid. We believe what we want to believe, even in the face of massive and overwhelming conflicting evidence."
And a confidence trick is a lot like a magician's illusion: it relies on misdirection, so you're watching the lovely assistant and the shiny stage, and don't see what goes on in the dark, or under the stage. And on your telling yourself that you know what's going on, when in fact everything you believe is a complete fraud, made up specifically so you will believe that you know what's going on, and to keep you thinking of the "payoff" while the real action goes on where you can't even see it.
It certainly won't be discussed with you, that's for sure. In the political world that's called "real-politik" and just means the real reasons governments do things, as opposed to the pretexts given out to the great unwashed. But you're beholden to those pretexts, which means it's always easy to get rid of someone. |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6747
|
| Posted: Tue Mar 18, 2014 2:07 am Post subject: |
|
|
I have not much time now and do not want to spend it on political discussions.
However, the question of whether systemd is going to depend/merge polkit is very important IMHO, even if my time is limited, because it can mean that I must change systems urgently.
One point which might support my opinion that polkit merging is not a current aim is that also NetworkManager was not merged: If I interpret the comments correctly, networkd was exactly introduced because even Kai Sievers argued that this is too complex to include into an init system. Moreover, in the systemd-211 ChangeLog, I find
| Quote: | * When systemd is compiled with kdbus support, basic support
for enforced policies is now in place. (Note that enabling
kdbus still voids your warranty and no API compatibility
promises are made.) |
It is not explicitly said how these "enforced policies" are done, but since polkit is still optional, I hope that polkit is not used for this. |
|
| Back to top |
|
|
miket
Guru
Joined: 28 Apr 2007
Posts: 488
Location: Gainesville, FL, USA
|
| Posted: Tue Mar 18, 2014 2:44 am Post subject: |
|
|
| mv wrote: | | No. A sane system of policies is required if you use kDbus, not necessarily a system which is implemented over the polkit insanity. |
You know, if a set of policy declarations is good enough for systemd (and good enough for udev, for that matter), they darn well ought to be good enough for polkit too. Polkit+javascript is *way* off the rails. |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Tue Mar 18, 2014 2:50 am Post subject: |
|
|
| mv wrote: | | I have not much time now and do not want to spend it on political discussions. |
That's fine, but you completely misinterpreted what ulenrich said. |
|
| 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
|
|
Other Things Gentoo
