| View previous topic :: View next topic |
| Author |
Message |
StoneC0ld
n00b
Joined: 27 Jul 2006
Posts: 56
|
 Posted: Sat Jun 14, 2014 8:30 pm Post subject: |
 |
|
| SDNick484 wrote: |
I ran into this as well; I think the cause was being on an older version of udev (I was on 208, and you appear to be as well) I had to:
1. emerge -C upower
2. emerge upower-pm-utils udev |
I have udev 212 installed. I did exactly this. It still wants to pull in systemd.
Do I need to mask systemd and the other 2 packages as mentioned on page 1, before doing this?
Last edited by StoneC0ld on Sat Jun 14, 2014 9:11 pm; edited 1 time in total |
|
| Back to top |
|
 |
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Sat Jun 14, 2014 8:39 pm Post subject: |
|
|
| StoneC0ld wrote: | | SDNick484 wrote: |
I ran into this as well; I think the cause was being on an older version of udev (I was on 208, and you appear to be as well) I had to:
1. emerge -C upower
2. emerge upower-pm-utils udev |
I have udev 212 installed. I did exactly this. It still wants to pull in systemd.
Do I need to mask systemd and the other 2 packages as mentioned on page 1, before doing this? |
If you know you never want systemd (or pkg-X) installed, it makes sense to hardmask it yes, as then portage has less possible dep-satisfiers to consider. |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Sat Jun 14, 2014 9:19 pm Post subject: |
|
|
| eccerr0r wrote: | | steveL wrote: | "We don't want every application to be allowed to shutdown or suspend the machine, since the ability is a security point; let's just let any (locally) logged-in user do that with whichever application they like."
Can you not see the contradiction? |
There is no contradiction. By using cgroups you are implicitly telling which applications the user is allowed to run (namely, what is forked from the DM). There needs to be an application agnostic API that allows these privileged commands that simply depends on being physically at the console.
|
But we've already established that no GUI app apart from the DE needs that ability. Granted it's usually run from xinitrc or some other mechanism after X, but it's a lot narrower in scope than "any process in this cgroup," and becomes part of the DM-DE protocol rather than some hacked-up mechanism across various tightly-coupled processes.
| Quote: | | And again I don't understand why there is confusion about issues between remote users should NOT have permissions to reboot the machine. As long as they stay remote, they should not be able to do these power operations. If they feel the need to physically relocate themselves to the console, they should then be allowed to reboot the machine. |
Which is why i didn't understand the distinction you were making between "console users" and "remote users who walk up to the console".
| Quote: | | Simple as that. The whole premise is whether they are at console or not, no dependencies on software, no dependencies on DM or DE, they should be able to reboot at console. BUT if they are NOT at the console, they should NOT have these privileges either. |
I feel obliged to point out that sometimes you have users in wheel or power, who ARE allowed to perform exactly that operation, and if not you just killed every remote reboot of a server-farmed host.
| Quote: | | Quote: | For instance, a lib function to ask "is this uid a locally-logged in user?" seems a lot simpler to me..
Isn't there stuff in pam for this?
|
Yes these things have been solved before by these kinds of hacks, but isn't it time to move on? |
I'm sorry what? Querying the OS via defined interfaces is a hack, but sending all this guff over the dbus and then through the various layers of spaghetti-lasagne, in order to replicate pam is a good thing?
| Quote: | An issue with the fork based authentication/shutdown is that once things are passed into the "helper app" that has the permissions of pam, etc.; is that it can only provide fixed feedback
..With an IPC solution it can still have the look and feel of the DE instead of being forced to have whatever the suid application gives you. Or it can totally ignore it for a console application. |
Huh? The DM runs a shutdown command, the most basic thing in the world, at the request of the DE. The DM communicates the status back to the DE, which can feed it back however it likes. This is hardly radical.
| Quote: | | Quote: | | As I said, it's not force though; it just feels like it when your previously-working choices are taken away from you. |
Sometimes it feels like it's a "GET OFF MY LAWN" syndrome going on here. It's not like I haven't had to deal with choices the Gentoo devs had made - I despise them as well, such as maintaining apache1 and running gnome2..
the ability to emerge --update world once more outweighs the pain... |
It's not that I can't cope with dep-changes. I simply don't understand why the easy option of using a new dependency for systemd, the soon-to-be-subsumed upower-systemd, wasn't taken. After all systemd is the package which is changing at a great pace, and the new upower has an inverse coupling on systemd, and can't run without it, so it's hardly the same package, in both usage and dependency terms. In terms of the tree and the distro, it isn't the same package at all, whatever name you give it.
It feels like either openrc users aren't as important as systemd ones, or the "gentle push" strategy is in effect, only it's much more noticeable in a source-based distro. |
|
| Back to top |
|
|
eccerr0r
Watchman
Joined: 01 Jul 2004
Posts: 9677
Location: almost Mile High in the USA
|
| Posted: Sat Jun 14, 2014 11:56 pm Post subject: |
|
|
| steveL wrote: |
I'm sorry what? Querying the OS via defined interfaces is a hack, but sending all this guff over the dbus and then through the various layers of spaghetti-lasagne, in order to replicate pam is a good thing? |
Consolekit/dbus/systemd is not just another pam, it can even use pam - and be more. One problem with Unix applications in the past is that two processes never communicate to each other unless it's a descendant process or they have negotiated a well defined channel ahead of time. Dbus makes a new, general purpose IPC that handles useful items at the console so that programs do not have to all be developed tightly together. The standard method of IPC through UNIX is through return codes, obviously the limited number of possibilities and the need for preset nonstandardized methods for two applications whether it be any arbitrary DE and the shutdown mechanism or two applications or any combination. The return code/shmem/named pipe methods and even sockets without dbus - well they all have the same problem prior to dbus - they're not standardized.
| Quote: | | Quote: | An issue with the fork based authentication/shutdown is that once things are passed into the "helper app" that has the permissions of pam, etc.; is that it can only provide fixed feedback
..With an IPC solution it can still have the look and feel of the DE instead of being forced to have whatever the suid application gives you. Or it can totally ignore it for a console application. |
Huh? The DM runs a shutdown command, the most basic thing in the world, at the request of the DE. The DM communicates the status back to the DE, which can feed it back however it likes. This is hardly radical. |
The DE has to know the exact DM communication mechanism ahead of time anyway, and nothing of this sort has been standardized. If there were, I'm sure it'd be fairly popular by now, but... there is not. But there is a new strategy that was proposed and implemented - having dbus/systemd available to do IPC - and it does much more than just allowing the DE to communicate with the DM - it can let arbitrary applications communicate directly to the DM as well. A lot of this is mainly for the user experience - so that the user does not have to deal with having to type optional passwords if the user chooses them to be saved in a password database, and then even allows for having the password database unlocked by yet another password.
| Quote: | | Quote: | Sometimes it feels like it's a "GET OFF MY LAWN" syndrome going on here. It's not like I haven't had to deal with choices the Gentoo devs had made - I despise them as well, such as maintaining apache1 and running gnome2..
the ability to emerge --update world once more outweighs the pain... |
It's not that I can't cope with dep-changes. I simply don't understand why the easy option of using a new dependency for systemd, the soon-to-be-subsumed upower-systemd, wasn't taken. After all systemd is the package which is changing at a great pace, and the new upower has an inverse coupling on systemd, and can't run without it, so it's hardly the same package, in both usage and dependency terms. In terms of the tree and the distro, it isn't the same package at all, whatever name you give it.
It feels like either openrc users aren't as important as systemd ones, or the "gentle push" strategy is in effect, only it's much more noticeable in a source-based distro. |
Unfortunately the limited bandwidth of having to tweak every single application to work with openrc is the biggest problem here. If you were tasked to rewrite Gnome3 to not require systemd (I know, bad example, but it can be anything that "now" requires it), even if you knew how to do it, it would still take a nontrivial amount of effort that needs to be replicated every time Gnome gets released. Nobody, unless they were paid to do it, would do this.
Now the other question is whether there is the feasibility of having a "systemd emulator" - something that fakes all the dbus services of systemd and translates as much as it can to openrc (and ignores the rest that cannot)... Could this be a solution to openrc users?
_________________
Intel Core i7 2700K/Radeon R7 250/24GB DDR3/256GB SSD
What am I supposed watching? |
|
| Back to top |
|
|
szatox
Advocate
Joined: 27 Aug 2013
Posts: 3131
|
| Posted: Sun Jun 15, 2014 12:58 am Post subject: |
|
|
| Quote: | | Now the other question is whether there is the feasibility of having a "systemd emulator" - something that fakes all the dbus services of systemd and translates as much as it can to openrc (and ignores the rest that cannot)... Could this be a solution to openrc users? |
Well... it's more like a prosthesis than a solution, and I'm afraid it would promote making everything in relation to systemd even though it's just damn init and no user program should care about it (just like user programs should not care whether their output goes to terminal or file or another program, yet many do just becouse they can often vrecking havoc being smarter than expected). At this point the only thing systemd is missing is a logo from some well-known-big-company-from-Redmond. The actually smart thing to do would be to drop support for systemd. Not because it's worse, but because it indeed is forced and breaks compatibility of other, unrelated things.
It breaks modularity, it makes layer-based design irrelevant and should be considered dangerous and thus avoided.
Such a prosthesis would still be better than having ONLY systemd, you could say it's similar to wine in purpose, except wine couldn't make it any worse than is already was, while this might.
Also, what makes calling another process by dbus better than calling another process by it's own socket? In both cases you call a particular service, and you want something specific to this service. You don't go on TV with an order like "bring me a pizza", you call vendor directly. So, if you make a service-specific call, why would you need something more generic than a socket?
Oh, and doesn't dbus use socket itself for talking to other processes? Well, dbus at least seems to be mostly harmless save for adding it's penny to already bloated software. Have a look at http://en.wikipedia.org/wiki/Inner-platform_effect |
|
| Back to top |
|
|
Killerchronic
Tux's lil' helper
Joined: 24 Apr 2007
Posts: 91
Location: UK
|
| Posted: Sun Jun 15, 2014 4:37 am Post subject: |
|
|
| genstorm wrote: | | Anon-E-moose wrote: | Note: I've pointed out before that when things like this happen, there needs to be a news article.
I personally didn't know that there was a monthly blog of what was going on, never seen it mentioned before. |
Well, users should know their way around gentoo.org, the forums, google and last but not least, their system. |
See this is where this distro is starting to fail quite badly. Users do know their way around the site/forums and google. But the point is we shouldn't need to. A distro that requires troubleshooting when the dev cba to release a news item because "something might be coming in the future" is stupid. Break the system but don't post about it so you don't post to many news articles? Really?
Follow the gentoo blog that closely even though mostly it is just utter shite just so i can keep a working system? Name any other distro that requires this, even ones that build from source, even Arch is more forthcoming and its based on gentoo ffs. |
|
| Back to top |
|
|
asturm
Developer
Joined: 05 Apr 2007
Posts: 8935
|
| Posted: Sun Jun 15, 2014 7:50 am Post subject: |
|
|
| Killerchronic wrote: | | See this is where this distro is starting to fail quite badly. Users do know their way around the site/forums and google. But the point is we shouldn't need to. A distro that requires troubleshooting when the dev cba to release a news item because "something might be coming in the future" is stupid. |
Since when was Gentoo that feelgood 'never have to think about' kind of distro? 
| Killerchronic wrote: | | Break the system but don't post about it so you don't post to many news articles? Really? |
Of course post about it. But think first. Post with manners. And without duplicating threads, as it happened here. No systems were broken by this; Updates blocked, yes, but I even showed you the way how to be able to ignore this for some time.
Even now, there seems to be a misunderstanding by some; 'upower-pm-utils' is no magical get-out-of-jail-free-card for upower, it is a dead end as long as no one cares about it upstream. Especially Gentoo users should be aware of the concept of dependencies, userspace packages moving on and depending on one or the other variant. Especially Gnome being on the forefront, it was in the news long enough now.
| Killerchronic wrote: | | Follow the gentoo blog that closely even though mostly it is just utter shite just so i can keep a working system? |
That is just you deliberately twisting words. Oh, the arrogance!
| Killerchronic wrote: | | even Arch is more forthcoming and its based on gentoo ffs. |
You're wrong. Also, Arch might break at any time, requiring time and effort to repair.
Really, you are up in arms because of a minor update process inconvenience?
Last edited by asturm on Sun Jun 15, 2014 8:32 am; edited 8 times in total |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6747
|
| Posted: Sun Jun 15, 2014 7:57 am Post subject: |
|
|
| eccerr0r wrote: | | Yes these things have been solved before by these kinds of hacks, but isn't it time to move on? |
"Yes, a simple clean working solution is known to exist, and the permission system has been developed and tested for years until finally most exploits have been removed. So, let's braek stuff again, build an ad-hoc permission system overridng the well-developed one with races and god-knows-what exploits."
Just systemd itself closed dozens of possible exploits with dbus communication, and these are of course only those reported or found by the developers; professional hackers certainly know a lot more which are still open.
And you doubt that it is ad-hoc? The ad-hoc solution was recognized to be insufficient after some years of polkit so that it is necessary to include java-script for hacking up the insufficient concept.
Now which of the two is what one would call a hack: A clean solution with one well-defined function or a monstrous complex stack of ad-hoc "solutions", permanently repairing the mistakes made in the previous "solution"?
And the real bad thing is: Even for servers or single-user systems which would not have any need even for the single library function, users are pressed with all means to install the ad-hoc solutions and open their system to all these exploits without any need. |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Sun Jun 15, 2014 8:31 am Post subject: |
|
|
| eccerr0r wrote: | | steveL wrote: | | Querying the OS via defined interfaces is a hack, but sending all this guff over the dbus and then through the various layers of spaghetti-lasagne, in order to replicate pam is a good thing? |
Consolekit/dbus/systemd is not just another pam, it can even use pam - and be more. |
I never said it was: it's clearly a whole lot more, an integrated set of components that are tightly integrated, and thus coupled.
| Quote: | | One problem with Unix applications in the past is that two processes never communicate to each other unless it's a descendant process or they have negotiated a well defined channel ahead of time. Dbus makes a new, general purpose IPC that handles useful items at the console so that programs do not have to all be developed tightly together. |
IOW a well-defined channel ahead of time. I know what you're saying but a) it is, and b) even if it's a multiplexor, have you seen the pathnames? You realise they can, and do, change at any point, I take it. So you have multiple fixed-protocols over a single well-defined channel, instead of a single protocol per well-defined channel. Only they're not fixed, except in the bad sense that leads to coupling aka things being tightly developed together.
The "console" part makes me laugh though; it reminds me of the way this upstream follow the age old One True Way path of trying to integrate everything.
BTW, you really do sound like you've drunk the kool-aid. ;)
| Quote: | | The standard method of IPC through UNIX is through return codes, |
No it's not. With respect, blanket statements like this (and your earlier "you have to fork to talk to the kernel") make it hard to take the rest of what you say seriously.
Then again, I don't know that much about the desktop area.
| Quote: | | The return code/shmem/named pipe methods and even sockets without dbus - well they all have the same problem prior to dbus - they're not standardized. |
You have this completely the wrong way round, as well as missing a few out. Nonetheless they're all standardised, across operating systems, not just distros.
systemdbug_kitchen-sink is the thing that is very much not standardised, and further comes from an upstream famous for breaking both ABI and end-user interfaces. They're also hostile to other projects in the same area, unless they can coopt them and cripple them a couple of releases later.
At best, the work is pre-production level, and their record on testing is abominable.
Can we stick to this use-case, please? I'm quite enjoying exploring the problem domain without getting bogged-down in philosophy.
| Quote: | | Quote: | | The DM runs a shutdown command, the most basic thing in the world, at the request of the DE. The DM communicates the status back to the DE, which can feed it back however it likes. This is hardly radical. |
The DE has to know the exact DM communication mechanism ahead of time anyway, and nothing of this sort has been standardized. If there were, I'm sure it'd be fairly popular by now, but... there is not. But there is a new strategy that was proposed and implemented - having dbus/systemd available to do IPC - and it does much more than just allowing the DE to communicate with the DM - it can let arbitrary applications communicate directly to the DM as well. |
Yes developers are very susceptible to getting grandiose ideas, especially when it's the second attempt at something. KDE agreed to drop their rather nice DCOP in order to collaborate on dbus. At that stage lots of ideas were flowing around, but not much judicious design, by the looks of it.
I'm not sure why you want arbitrary apps talking to the DM, and not the DE they run under, via the toolkit, unless that's a typo. (seems unlikely.)
A password wallet is not an example that makes any sense to me; KWallet works fine here, as does ssh-agent and gpg-agent, when I use them.
On the broader point, it makes more sense to extend the DM protocol, from a software design pov. I assume there is one, or we couldn't mix and match DM with DE; if not I'd rather go back and see what the X Protocols say, and work from there.
| Quote: | | Quote: | It's not that I can't cope with dep-changes. I simply don't understand why the easy option of using a new dependency for systemd, the soon-to-be-subsumed upower-systemd, wasn't taken. After all systemd is the package which is changing at a great pace, and the new upower has an inverse coupling on systemd, and can't run without it, so it's hardly the same package, in both usage and dependency terms. In terms of the tree and the distro, it isn't the same package at all, whatever name you give it.
|
Unfortunately the limited bandwidth of having to tweak every single application to work with openrc is the biggest problem here.
.. |
This has got nothing at all to do with what I wrote above. The easy thing for Gentoo to do would have been to leave the old upower ebuild that worked under openrc in the tree, and use a different package name for the new upower fork that disables any possibility of working without systemd. That's a systemd module, not a standalone package any more.
It's actually less work than the path chosen.
Nor does the question of a systemd-emulator, which strikes me as a waste of time. When you try and discuss what capabilities are actually needed from systemd, the ultimate answer is "none." |
|
| Back to top |
|
|
asturm
Developer
Joined: 05 Apr 2007
Posts: 8935
|
| Posted: Sun Jun 15, 2014 8:38 am Post subject: |
|
|
| steveL wrote: | | and use a different package name for the new upower fork that disables any possibility of working without systemd. |
Except there was no fork. Upstream dropped hibernate and suspend support in a new version, simple as that, and since when does Gentoo mask upstream changes to its users? Also, the new version does not require systemd per se. |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Sun Jun 15, 2014 9:01 am Post subject: |
|
|
| genstorm wrote: | | steveL wrote: | | and use a different package name for the new upower fork that disables any possibility of working without systemd. |
Except there was no fork. :roll: |
I'm using fork to mean a point in time where development diverges. Fair enough though, there isn't continuing development from that upstream on the other fork, but when we try to discuss exactly what we need to do, we either get slated as complainers, or the merry-go-round of the usual sales-pitch that has nothing to do with the problem at hand. It's like dealing with a cult.
| Quote: | | Upstream dropped hibernate and suspend support in a new version, simple as that, and since when does Gentoo mask upstream changes to its users? |
Since when does Gentoo kowtow to upstreams? A distro's first responsibility is to its users. Not to upstreams.
| Quote: | | Also, the new version does not require systemd per se. |
Weasel words, afaic, that I've heard far too many times.
In any event, from the pov of openrc users, that package, or the combination, is borked in its current form, afaic. Or we wouldn't have all these people desperately trying to stop systemd being pulled in.
And again, Gentoo should be the buffer between users and upstreams: that's why people got together and made distributions in the first place.
Also, can we get back to talking about the substantive points, rather than quibbling about single statements, please. |
|
| Back to top |
|
|
asturm
Developer
Joined: 05 Apr 2007
Posts: 8935
|
| Posted: Sun Jun 15, 2014 9:14 am Post subject: |
|
|
| steveL wrote: | | genstorm wrote: | | steveL wrote: | | and use a different package name for the new upower fork that disables any possibility of working without systemd. |
Except there was no fork. |
I'm using fork to mean a point in time where development diverges. Fair enough though, there isn't continuing development from that upstream on the other fork, but when we try to discuss exactly what we need to do, we either get slated as complainers, or the merry-go-round of the usual sales-pitch that has nothing to do with the problem at hand. It's like dealing with a cult. |
Did you call xorg-server a fork when it dropped support for HAL? Did you call KDE a fork when it dropped support for DCOP? Your choice of words in this case is wrong, deliberately, only to help your agenda.
| steveL wrote: | | Quote: | | Upstream dropped hibernate and suspend support in a new version, simple as that, and since when does Gentoo mask upstream changes to its users? |
Since when does Gentoo kowtow to upstreams? A distro's first responsibility is to its users. Not to upstreams.
| Quote: | | Also, the new version does not require systemd per se. |
Weasel words, afaic, that I've heard far too many times.
In any event, from the pov of openrc users, that package is borked in its current form, afaic. Or we wouldn't have all these people desperately trying to stop systemd being pulled in. |
Again, wrong. I am an openrc user and I can use the latest upower just fine, because I do not use suspend/hibernate at all. I still chose to emerge upower-pm-utils because I didn't want to lose that theoretical functionality - which also worked just fine, because I'm not using any package that would require >=upower-0.99. The case where systemd is pulled in is a completely unrelated dependency problem (likely caused of a strange combination of [outdated] {virtual,sys-fs}/udev masks und use flags), and I really assumed you had the capability to distinguish that. But again, I think you choose not to, in order to continue to write lengthy posts about what everyone should do or not - helping no one. |
|
| Back to top |
|
|
Anon-E-moose
Watchman
Joined: 23 May 2008
Posts: 6097
Location: Dallas area
|
| Posted: Sun Jun 15, 2014 10:38 am Post subject: |
|
|
If anyone wants to use systemd, then use it.
If anyone doesn't want to, then don't use it.
Just leave everyone else alone to make their own decisions about it.
_________________
PRIME x570-pro, 3700x, 6.1 zen kernel
gcc 13, profile 17.0 (custom bare multilib), openrc, wayland |
|
| Back to top |
|
|
eccerr0r
Watchman
Joined: 01 Jul 2004
Posts: 9677
Location: almost Mile High in the USA
|
| Posted: Sun Jun 15, 2014 4:40 pm Post subject: |
|
|
| steveL wrote: | The "console" part makes me laugh though; it reminds me of the way this upstream follow the age old One True Way path of trying to integrate everything.
BTW, you really do sound like you've drunk the kool-aid. ;) |
Call it what you want to call it, but systemd/dbus has been documented and not DE/DM/Application specific. It helps with usability on the desktop, and you're even using dbus behind the scene. So in your words, you started sipping as well.
| Quote: | | Quote: | | The standard method of IPC through UNIX is through return codes, |
No it's not. With respect, blanket statements like this (and your earlier "you have to fork to talk to the kernel") make it hard to take the rest of what you say seriously.
Then again, I don't know that much about the desktop area. |
You're taking statements out of context once again. With context it makes perfect sense. If you're using a sudo helper app, this is in fact what happens - sudo plus the power program will give a return code when it exits. Yes you could just write yet another file to do additional data, but has it yet been done? Could you go ahead and design this that beats the speed of IPC? And it also sounds like you're focusing only on server/single "power" user usage. There lies the problem. More later (though I've already hinted at it).
| Quote: | | Quote: | | The return code/shmem/named pipe methods and even sockets without dbus - well they all have the same problem prior to dbus - they're not standardized. |
You have this completely the wrong way round, as well as missing a few out. Nonetheless they're all standardised, across operating systems, not just distros.
systemdbug_kitchen-sink is the thing that is very much not standardised, and further comes from an upstream famous for breaking both ABI and end-user interfaces. They're also hostile to other projects in the same area, unless they can coopt them and cripple them a couple of releases later.
At best, the work is pre-production level, and their record on testing is abominable.
Can we stick to this use-case, please? I'm quite enjoying exploring the problem domain without getting bogged-down in philosophy.
|
Of course the low level routines for IPC is POSIX standardized but not power and UI usability/standardization routines. Agreeably the API/ABI is still in flux, that's growing pains but unfortunately it's how software is being developed nowadays. That's a whole different problem and deserves its own thread. But unfortunately software moves on, it's up the users, influenced by the packagers to decide whether or not to use systemd/dbus. If you look at the old Linux distributions and compare to the new distributions, the usability factor has gone up quite a bit as software started communicating amongst each other, not having to worry about having to manually change something in multiple places. There's still a long way to go.
| Quote: | A password wallet is not an example that makes any sense to me; KWallet works fine here, as does ssh-agent and gpg-agent, when I use them.
On the broader point, it makes more sense to extend the DM protocol, from a software design pov. I assume there is one, or we couldn't mix and match DM with DE; if not I'd rather go back and see what the X Protocols say, and work from there. |
Here's the thing: ssh-agent and gpg-agent are irrelevant here as they are only for their specific application - ssh and gpg obviously. Now we look at KWallet. Now I wonder how KWallet works... It's so nice, it looks very well integrated with KDE - same libraries, etc. Hmm... I wonder how it works. I really wonder... Hmm... could it be... No it couldn't because...
The reason why KWallet works the way it does is because non power users rather have it this way. They want the passwords saved but still locked - and not only this, the KWallet GUI is the KWallet GUI, not some custom gui like ssh-agent. Users want just one application to handle all their passwords. This clearly is a usability issue that's not easily solved by traditional methods (hey, let's write the password to disk (or even shmem) as IPC! Nothing ever possibly could go wrong!).
| Quote: | | Quote: |
Unfortunately the limited bandwidth of having to tweak every single application to work with openrc is the biggest problem here.
.. |
This has got nothing at all to do with what I wrote above. The easy thing for Gentoo to do would have been to leave the old upower ebuild that worked under openrc in the tree, and use a different package name for the new upower fork that disables any possibility of working without systemd. That's a systemd module, not a standalone package any more.
It's actually less work than the path chosen.
|
In the long term the new Upower is the new Upower. Forks, which would be offshoots of the main line, are the modules that should change names. How would you like it if you wrote an application and someone decided to call it shitty-yourapp because they don't like the new version. And when newcomers see the shitty-yourapp.ebuild they think it really is that shitty. It's very disrespectful hence that was not done. This is the curse of opensource, don't you wish you could do this to closed source software, like reboxing windows8 "shitty-windows" and start selling that alongside windows 7? I'm sure M$ will happily let you, at least you bought it and only hurting yourself. Not so much for the poor OSS writer.
BTW - yes you should go complain to the upower devs, not here.
Forking is the right solution for now, that's the proper way to complain about something that changed that isn't desirable. As above the proper way is to make a new name for the software you didn't start writing.
| Quote: | | Nor does the question of a systemd-emulator, which strikes me as a waste of time. When you try and discuss what capabilities are actually needed from systemd, the ultimate answer is "none." |
And if it does nothing useful, it'd make writing such very easy, the whole point is to redirect to /dev/null any feature you don't want or need - it's just a "compatibility layer" that will let "stupid new applications that require systemd" to install and run.
Obviously you're complaining about having to deal with systemd. If you don't want to use systemd, then just don't use systemd and please don't complain about it with pedantic arguments. If you want to fix Gentoo, then go ahead, fix the problem by offering a solution that will continue to work for everyone as time goes on (go ahead and be the maintainer for this package, just don't offer a solution that works for now and breaks for a particular type of usage down the road claiming "It's not how I like it"!). Maybe you can even go ahead and fork Gentoo and call it Gentoo and call the current Gentoo "that-crappy-gentoo-thats-stuck-with-systemd".
All in all I am in no way pro-systemd/dbus, but I do see desktop/general purpose usage enhancements provided.
_________________
Intel Core i7 2700K/Radeon R7 250/24GB DDR3/256GB SSD
What am I supposed watching? |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Sun Jun 15, 2014 10:51 pm Post subject: |
|
|
I'm not getting into arguments I didn't make. Nor am I interested in the egoistic brow-beating which passes for discussion in this thread, and so many like it. I tried to be upfront about not knowing this area inside-out, which was the whole point of discussing it, and I thought it was fairly clear that I was trying to find a way forward.
Getting bogged down in who said what, and trying to follow vague references to information not provided, only to read that my sole purpose is to complain about systemd, isn't my idea of fun, especially when I'm being lectured in application development from someone who doesn't even know the basics of POSIX.
Still, that's what happens every time you try to discuss the actual use-case, and not the inturgrated mess: you get emotive and hostile reaction instead of clear technical discussion.
Good luck with that, and thanks for confirming that the DE-DM use-case is totally borked: by design.
Makes sense though, you can't get a "windows-lite"^W^W "hal32" ^W C:\Windows\System32^W systemd business-strategy going without the desktop, and it's much easier to take control of everything else from there. After all, it worked for Microsoft..
I look forward to the day when console login is outlawed as being a "security hole" for the above bs reasons given as to why we even need logind, I mean c'mon everyone uses an xterm, only crusty traditionalists still want console login, and they can still download and build everything, so long as they extract 15 tarballs from Our Great Leader's git3K repo (cos ordinary git just wasn't cutting it) but ofc you can only build any of it on an already running system of ours, as we inturgrated the compiler 20 years ago (I mean, forking to an executable? Nonsense, run it over the spangle-bus..) |
|
| Back to top |
|
|
eccerr0r
Watchman
Joined: 01 Jul 2004
Posts: 9677
Location: almost Mile High in the USA
|
| Posted: Mon Jun 16, 2014 1:00 am Post subject: |
|
|
Agreed, I dislike seeing arguments against things that simply are not true, including making up statements just to prove the point that statements are "hard take seriously" because of an out of context statement can be construed as false. It's not fun having to constantly write rebuttals to clarify the issue just because that person misconstrued the true meaning of the statement. It does not add any value to the discussion trying to point out every single possible mistake by taking things out of context and even trying to bend the truth just to discredit the original posting, without referring to the real evidence - or at least giving benefit of the doubt.
I'm merely making the point that there obviously is a benefit to the crap we have to deal with, else we would have other solutions implemented that use traditional methods that work exactly the same, or ideally, even better with what we had - but there isn't. In fact there were all sorts of different things like ORBit that existed before dbus. But it looks like dbus won out. However in this new system, clearly there is a potential for multiple security holes. Do I think it's secure? In theory, actually, yes; in practice, who knows and sure I'd much rather use the tried and true way as suggested - completely avoiding systemd... at least until the kinks are straightened out. In all new things there are unfortunately risks, but without these risks cannot come innovation. And without innovation comes stagnation.
All in all, unfortunately those people who desire a tightly integrated desktop are clearly winning. I see posts on f.g.o all the time people expect their desktops to be tightly integrated with their devices, not to type in their password umpteen million times, not have to sudo to mount their USB disks and wondering why their scanner doesn't work when connected to console and have to sudo. Granted yes there are some people who find a "traditional" solution that works for them and are happy with it, but there may be yet another another solution that's even more tightly integrated with dbus that would make their life easier (granted, fixing their problem can be infinitely hard because debugging dbus issues just makes life miserable :)) Even people who don't want systemd or dbus still want tightly integrated desktops such as with gnome-keyring and their analogs. I suppose it's damned if you do, damned if you don't, might well just join the party and drink the spiked kool-aid, which unfortunately is what I chose to do. Luckily Gentoo has done a fairly good job and getting the dependency chain right and actually started fixing config problems... now that's a godsend...
_________________
Intel Core i7 2700K/Radeon R7 250/24GB DDR3/256GB SSD
What am I supposed watching? |
|
| Back to top |
|
|
Budoka
l33t
Joined: 03 Jun 2012
Posts: 777
Location: Tokyo, Japan
|
| Posted: Mon Jun 16, 2014 6:27 am Post subject: |
|
|
| eccerr0r wrote: | ...
And as a end user admin it's your duty to prevent systemd from installing, not the distribution - you control what's on your computer. And yes on most of my init machines:
| /etc/portage/packages.mask/general.mask wrote: | sys-apps/systemd
|
Goes a long way from accidental installs. And it's not the distribution packager's fault for certain applications that require any particular package, it's all upstream. |
Until the dust settles on the systemd debate or I have a better enough understanding of it that I can make an informed decision I masked systemd too. I had already had it "-" in my uses.
I read the portage section in the manual and I created the file package.mask in /etc/portage and added sys-apps/systemd. Will this get the job done or do I need to create | Quote: | | /etc/portage/packages.mask/general.mask"]sys-apps/systemd |
as you did? |
|
| Back to top |
|
|
eccerr0r
Watchman
Joined: 01 Jul 2004
Posts: 9677
Location: almost Mile High in the USA
|
| Posted: Mon Jun 16, 2014 6:58 am Post subject: |
|
|
The directory there is optional. You can create a file as package.mask or make a file in the directory called package.mask. I have a directory there so I can keep the different reasons for masks separate (I had one there to specifically mask gnome3 but now it's gone.)
This mechanism isn't completely foolproof. It's only to tell portage to take a step back and basically warn the user if there's a configuration that would install systemd. Whether the current config can support it or not - it's still up to you (and coaxing of the Gentoo devs) but at least it will make portage bomb if it found no choice but to install systemd.
_________________
Intel Core i7 2700K/Radeon R7 250/24GB DDR3/256GB SSD
What am I supposed watching? |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6747
|
| Posted: Mon Jun 16, 2014 8:13 am Post subject: |
|
|
| steveL wrote: | | Nor am I interested in the egoistic brow-beating which passes for discussion in this thread, and so many like it. |
I am not sure whether you mean my posting here; my concern about security implications is serious. It seems to me that systemd itself will be reasonably secure after a while - essentially, there is only the dbus/kdbus communication which is perhaps a danger of controllable size, especially since even in case of failure systemd can not easily be misused to do arbitrary tasks - but concerning policykit, I think it is a bottomless pit. Partly due to the mentality of the maintainers, but mainly because the whole thing is so severely broken by concept: Security-wise you can do nothing worse than running a complex permission system, especially if it overrides an existing simple permission system. Sorry if this was not formulated clear enough. |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Mon Jun 16, 2014 2:39 pm Post subject: |
|
|
| mv wrote: | | I am not sure whether you mean my posting here; my concern about security implications is serious. |
No, I didn't; it doesn't matter whom I meant though. The security of the whole design is broken imo. ISTR tuomov mentioning the XDMCP a few years ago, in that light.
| Quote: | | It seems to me that systemd itself will be reasonably secure after a while - essentially, there is only the dbus/kdbus communication which is perhaps a danger of controllable size, especially since even in case of failure systemd can not easily be misused to do arbitrary tasks |
Heh, I've heard that one before ;) wrt kdbus, I think it's a crying shame to build a single-app mechanism into the kernel. Frankly I'm amazed Torvalds hasn't come down hard on the idea, but then he's always had a soft spot for Greg K-H. In any event a broadcast mq has so many more applications, I can't understand why no-one just listened to the networking people when they suggested methods to implement.
No doubt systemd will eventually get many wrinkles out; just like PulseAudio, it has many people sweating on it across distros. Indeed that's Poetterring's biggest skill: getting others to do his job for him, and taking credit for all of that, because he wrote the crappy initial app that took 5 years of multi-distro work to get functioning, sort of. Nonetheless you're still stuck with a pig of an idea, and have to listen to tedious explanations of how traditional methods are broken, yet required for his crap to work.
| Quote: | | - but concerning policykit, I think it is a bottomless pit. Partly due to the mentality of the maintainers, but mainly because the whole thing is so severely broken by concept: Security-wise you can do nothing worse than running a complex permission system, especially if it overrides an existing simple permission system. Sorry if this was not formulated clear enough. |
It does read a lot better like that. And I have to agree, wholeheartedly.
If you're not thinking about security from the beginning, and all the way through, then you're not coding securely. OFC for most programs you're only running as a normal user, on their files, and you can just rely on the Unix security model. If you want to manage the whole of userland though, firstly you have conceptual problems, and secondly you'd better be as uptight about security as Theo/oBSD. A random hacker who throws out spurious ideas for other people to fix ain't it. |
|
| Back to top |
|
|
depontius
Advocate
Joined: 05 May 2004
Posts: 3509
|
| Posted: Mon Jun 16, 2014 2:56 pm Post subject: |
|
|
It's going to be really interesting to watch RH7 deploy.
So far the systemd rollout has pretty much all been to the desktop and for desktop reasons. Even where it may be in Debian and applicable to servers, I'm betting that most server admins are conservative enough that they really haven't moved to it yet. The RH7 rollout will be the first time it's really been pushed into that market, and even there I suspect that the traditional server conservatism will delay things somewhat.
It will be interesting.
Personally I suspect that the massive systemd rollout will be a lot like the pulseaudio rollout. It will go everywhere and there will be massive troubles and complaining. What will be interesting is what will come after. For pulsaudio sysadmins weren't that close to the target audience, because they really don't give a hoot about sound. In fact, once the bugs were worked out it was good for admins, because it stopped user complaints. However systemd is going to hit them where they live.
In the long run the comparison to pulseaudio may be interesting. Pulseaudio has become pervasive, but not universal. It is simply insufficient an incable of low-latency audio, so anyone serious about that uses JACK. There is a small, but never-to-be-diplaced non-pulseaudio niche. I wonder how systemd and servers will pan out.
_________________
.sigs waste space and bandwidth |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6747
|
| Posted: Mon Jun 16, 2014 3:40 pm Post subject: |
|
|
| steveL wrote: | | wrt kdbus, I think it's a crying shame to build a single-app mechanism into the kernel. |
I never had the time to follow this discussion, so maybe my knowledge is wrong.
As I understand it, it is a mechanism like mmap which can do data "duplication" without actual duplication, thus programs like dbus or other programs communicating lots of data between different tasks can profit from it. If it really turns out that almost all applications using this mechanism do it through the dbus interface, one should not blame the kernel. This happened also in other situations, e.g. almost all programs use libattr or libcap to access the corresponding kernel interface, and such a "single" userspace abstraction is not necessarily a bad thing.
I do not know the suggestions of network people you mentioned, but I guess things are decided now, anyway.
| Quote: | | If you're not thinking about security from the beginning, and all the way through, then you're not coding securely. |
I would not even argue that the policykit developers did not do this in their basic ideas how policykit should be working. The problem is just that due to the mere complexity of the code necessary to implement that concept, there might be so many new ways of exploits possible which nobody could even think about when such a complex thing did not exist.
The step to insanity was reached in the moment a complex language interpreter which can do anything runs with root permissions, even if, of course, it is supposed to run only trusted programs: Every security hole in the complex thing which allows injection of any data actually becomes immediately a privilege escalation security issue, i.e. every small bug means the worst possible security implication. It is like running a web browser with root permissions: You are rather safe from accidentally doing a serious damage, and if there are absolutely no bugs, things are not a problem. But in practice, any malevolent attacker spending reasonable resources can get the full control over your system after a while. |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6747
|
| Posted: Mon Jun 16, 2014 3:53 pm Post subject: |
|
|
| steveL wrote: | | Quote: | | It seems to me that systemd itself will be reasonably secure after a while - essentially, there is only the dbus/kdbus communication which is perhaps a danger of controllable size, especially since even in case of failure systemd can not easily be misused to do arbitrary tasks |
Heh, I've heard that one before  |
Which part of the argument do you doubt: Do you think that it is (or will be) easy to cause systemd to do arbitrary things when you have control over dbus/kdbus? Or do you think that it will remain easy to control dbus/kdbus when you are not root?
Both must happen simultaneously to become a security issue, and at least currently the first is not the case AFAIK; concerning the second I do not have much experience (but the closing of more and more bugs suggests to me that eventually a safe state might be reached.)
Perhaps it is a bit optimistic, but I am mainly thinking in comparison with policykit...
The strange thing is that despite these facts, I see many people opposing systemd but not so many opposing policykit: Otherwise threads like this would not have been started. Really, I do not understand this. |
|
| Back to top |
|
|
tld
Veteran
Joined: 09 Dec 2003
Posts: 1816
|
| Posted: Mon Jun 16, 2014 3:54 pm Post subject: |
|
|
| depontius wrote: | It's going to be really interesting to watch RH7 deploy.
|
Boy you're not kidding. I keep hearing vague arguments to the contrary, but I still don't see any advantages of systemd for servers, and I do see the potential for a world of hurt. Parallel start up??...How many servers are even usable before everything is started anyway? The irony is that, having worked with RH and Gentoo, a move to OpenRC would in fact have been a quantum leap forward for any Redhat derivative servers compared to the existing init scripts etc. RH themselves clearly have motivations for the systemd move, but it's a little hard to imagine the admins in the trenches being too fired up about it. What's especially scary is the potential in all that complex code for vulnerabilities that don't get discovered...or at least discovered by the people you want to find them.
In recent months (actually years) I've been far too busy to really actively follow the whole thing. I almost couldn't even stomach the discussion once I heard about stuff like the binary log format. I mean for the love of all that is holy. I used to use the Windows event log, a logging system that can effectively only be read on a running system, as a textbook example of how insane the design of Windows is as compared to Linux. So much for that. There just are no words.
Tom |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Mon Jun 16, 2014 4:30 pm Post subject: |
|
|
| mv wrote: | Which part of the argument do you doubt: Do you think that it is (or will be) easy to cause systemd to do arbitrary things when you have control over dbus/kdbus? Or do you think that it will remain easy to control dbus/kdbus when you are not root?
Both must happen simultaneously to become a security issue, and at least currently the first is not the case AFAIK; concerning the second I do not have much experience (but the closing of more and more bugs suggests to me that eventually a safe state might be reached.)
Perhaps it is a bit optimistic, but I am mainly thinking in comparison with policykit... |
I doubt the whole thing, and I doubt the upstream quite severely based on their prior behaviour, and their attitude toward breaking things; the latter is fine in a pre-production project in testing, but counter-productive for software you entrust your system to. The design is terrible, and worse you have lots of integrated parts from one upstream pushing its One True Way, for what i can only see as business reasons, not software ones. From a software engineering pov, inverse coupling means you've failed hard, in my book.
From a user pov, idiot-boxes don't work. They make power-users feel like idiots, and frustrate any attempt to fix what's happening, since the idiot-box thinks it knows better than you do. They keep new users in the dark, rather than incrementally introducing them to the myriad approaches they can use should they want to tweak things, all kept in simple plaintext configs, properly managed via dispatch-conf. Couple that with amateur kernel-rejects who also think they know better than their admin-users, and I simply don't want to know, in the same way that as someone who's worked in audio-engineering, I'd never even dream of using PulseFail.
It doesn't bother me what other people want to do, never has. I refuse to be told I can't express an opinion on someone else's software or approach though, just like a doctor can comment on the work of another, or a plumber can tell you that the guy who thinks he doesn't need to know what a wrench is, is not someone you want working on your boiler, however many books he's read. IMO modularity (and no that doesn't mean modularity within a project, as essential as that is to that project) is just as basic as a wrench.
Question tradition all you like, but inappropriate coupling, and this whole approach (ad-hoc javascript using v8, on top of polkit, on top of dbus, with systemd trying to pretend this isn't Unix), is like mixing electricity and water, afaic. Anyone I consulted for would be advised in no uncertain terms what I thought, right before I quit to avoid the professional liability/reputation damage. Sometimes it's better just to walk away.
| Quote: | | The strange thing is that despite these facts, I see many people opposing systemd but not so many opposing policykit: Otherwise threads like this would not have been started. Really, I do not understand this. |
Threads like this are going to keep cropping up, since afaict, the systemd strategy is to arm-twist distros into requiring systemd for more and more things, via sympathetic developers and the dep-tree. Anyone who demurs gets labelled a hater, and then you're into the polarising "debate" with vipers who ignore the substantive points, and focus instead on anything they can nit-pick and exaggerate to question your standing, instead of addressing the point head-on. That gets tiring for anyone who has things to do.
Since we're a from-source distro, and indeed the only from-source Linux that can actually be used on a day-to-day basis, our users are going to notice those moves in the deptree, and rightly complain when their default install is treated as a second-class citizen. After all UberLord was a Gentoo developer when he wrote openrc, and some of us are rightly proud that such a project, and such a developer, were nurtured within Gentoo.
Even if we are a bit dismayed by the commit history since he left, and the moves its lead makes to subsume its interests to the systemd camp.
As ever, just my opinion, though I only realised the latter when someone else pointed the pattern out. |
|
| 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
|
|
Portage & Programming
