| View previous topic :: View next topic |
| Author |
Message |
KuroNeko
n00b
Joined: 08 Oct 2014
Posts: 23
|
 Posted: Mon Oct 20, 2014 6:13 pm Post subject: logind is next |
 |
|
Edit: Scratch the part below. I just want to know more about how you would implement an alternative to logind, if kde on wayland is going to depend on it. Please post suggestions or if there is already a solution. Solving the problem myself would certainly be too much 
Previous Post:
Hah, so I really don't want to post this...
Hello, there!
I'm sure some of you already read it. KWin will depend on logind on wayland.
It isn't as bad, as it first sounds. it will only depend on the dbus interface at runtime, if you want a secure input stack and use libinput. But I think, we all want that right?
And i can understand Martin, if he doesn't want to support multiple interfaces and doesn't have the manpower or time alone to implement an alternative, that doesn't depend on systemd.
So we get no wayland on OpenRC?
Well, it doesn't have to be that way. He's willing to use only a subset of the logind interface and would even maintain a wrapper to provide the dbus api in a kde repository, if I didn't misread it?
But this doesn't work, if none steps up, to do the work, to implement such a wrapper, daemon, whatever...
So, I really don't want to say this and DON'T QUOTE ME, HOPE I'LL DO IT OR DEPEND IN ANY WAY ON THE FOLLOWING WORDS!
I'm willing to look into write such a whatever, that provides at least the needed subset of the logind interface, maybe not on dbus directly, if there's is a more sensible way, to expose the api, but at last make it easy to wrap.
But here's the catch:
I just started going to university -> I don't have much time...
I don't have any experience in writing C (only did C++, Python, Java...) -> As I said, don't depend on me!
I have never coded a daemon or anything similarly low level -> I think, you see the problem!
So to sum up: I've got much to learn and look into and the result may or may not be functional, but I've got no choice, if I want to continue being able to not like systemd very much
Why do I even bother to write this?
Well, maybe there is anyone out there, who wants to do something similar? (Looking at you, OpenBSD guys, you seem to know your stuff and I saw something about a linux port on the ML)
Maybe someone can provide me some pointers? (what should I avoid in C, when interfacing with udev, answer some questions, should they arise, etc...)
Maybe someone didn't have the confidence to step up him/herself and wants to collaborate, discuss, whatever or has more time available?
Maybe someone wants to tell me, that all my efforts will be futile? (Won't listen, lalala!)
What do i have?
Nothing. Probably not even time for it. But someone has to and I always wanted to give something back to the community and it's certainly a good exercise, if even a little to tough...
Any thoughts, anyone? Please someone step up to do it instead of me!
Neko
PS: If you take this message up, Phoronix or likeminded, you're doing something wrong! Do it, when I actually achieved something! Thanks!
Last edited by KuroNeko on Mon Oct 20, 2014 9:01 pm; edited 2 times in total |
|
| Back to top |
|
 |
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Mon Oct 20, 2014 6:36 pm Post subject: Re: logind is next |
|
|
| KuroNeko wrote: | | He's willing to use only a subset of the logind interface and would even maintain a wrapper to provide the dbus api in a kde repository, if I didn't misread it? |
The problem is that both logind and the use of dbus for everything is borked.
dbus is pushed because it's an end-run round the GPL. Technically it's a terrible idea to use dbus for DE-specific, privileged operations which should go via the DM, just as it is to use it everywhere else instead of a simple API.
| Quote: | I just started going to university -> I don't have much time...
I don't have any experience in writing C (only did C++, Python, Java...) -> As I said, don't depend on me!
I have never coded a daemon or anything similarly low level -> I think, you see the problem! |
Yes. Forget it.
By all means help with QA: testing, bug-reports and trying patches. |
|
| Back to top |
|
|
KuroNeko
n00b
Joined: 08 Oct 2014
Posts: 23
|
| Posted: Mon Oct 20, 2014 7:00 pm Post subject: Re: logind is next |
|
|
| steveL wrote: | | KuroNeko wrote: | | He's willing to use only a subset of the logind interface and would even maintain a wrapper to provide the dbus api in a kde repository, if I didn't misread it? |
The problem is that both logind and the use of dbus for everything is borked.
dbus is pushed because it's an end-run round the GPL. Technically it's a terrible idea to use dbus for DE-specific, privileged operations which should go via the DM, just as it is to use it everywhere else instead of a simple API. |
Don't know about that, as dbus seems to make it easy to authenticate the user of the api and there has to be a reason, that it becomes so widely adopted. And as kde already has a dependency on dbus, one more use of it, shouldn't cause the world to fall apart, I repeat shouldn't!
And I thought about using dbus only as a wrapper of a non dbus api, but then I (or someone else) has to design that api and deal with breaking it eventually, while you could shove the responsibility to systemd, if you don't do it that way.
| Quote: |
| KuroNeko wrote: | I just started going to university -> I don't have much time...
I don't have any experience in writing C (only did C++, Python, Java...) -> As I said, don't depend on me!
I have never coded a daemon or anything similarly low level -> I think, you see the problem! |
Yes. Forget it.
By all means help with QA: testing, bug-reports and trying patches. |
You're right, but that sadly doesn't solve the problem. I'll at least look into it, if there is an easy way or if someone else will do it. If none does, where will my cool KDE on wayland go? 
And it's not like it's totally impossible, just as hard as climbing up to the moon with only your tongue... or something like that...
Neko |
|
| Back to top |
|
|
creaker
l33t
Joined: 14 Jul 2012
Posts: 651
|
| Posted: Mon Oct 20, 2014 7:29 pm Post subject: |
|
|
| Quote: | | Hah, so I really don't want to post this... |
So why do you post it if you really don't want to post it?
Seems guys like you are join to forum just to throw shit at the fan.
To mods:
may be it worth to block/remove such a provocative posts? We have it enough already. |
|
| Back to top |
|
|
KuroNeko
n00b
Joined: 08 Oct 2014
Posts: 23
|
| Posted: Mon Oct 20, 2014 7:58 pm Post subject: |
|
|
| creaker wrote: | | Quote: | | Hah, so I really don't want to post this... |
So why do you post it if you really don't want to post it?
Seems guys like you are join to forum just to throw shit at the fan.
To mods:
may be it worth to block/remove such a provocative posts? We have it enough already. |
Easy one!
Because I want a solution. Talking alone doesn't solve anything, but I don't want to force someone to write code for my convenience!
So should I close/delete/whatever the topic, because it doesn't help anything?
Fine by me, I really don't feel good, that I posted this, because it's only work for me, certainly pissing off someone and I will probably disappoint anyone, who set hopes on me.
Well, I'll think about it, if you answer "Yes"
Edit: I also don't know enough about the whole stack, if a solution is really needed. Would be awesome to know about that and using systemd or not using kde is not a solution, I'd like to see. Sticking to Xorg and hoping for the best, is probably the alternative? |
|
| Back to top |
|
|
NeddySeagoon
Administrator
Joined: 05 Jul 2003
Posts: 54578
Location: 56N 3W
|
| Posted: Mon Oct 20, 2014 8:08 pm Post subject: |
|
|
KuroNeko,
Gnome needs systemd
KDE nay be sucked in soon but its not there yet.
By all means discuss systemd and its alternatives and how to 'fix' things that depend on systemd.
As you rightly say, unless some code is forthcoming, it will stay just talk.
_________________
Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
| Back to top |
|
|
KuroNeko
n00b
Joined: 08 Oct 2014
Posts: 23
|
| Posted: Mon Oct 20, 2014 8:19 pm Post subject: |
|
|
| NeddySeagoon wrote: | KuroNeko,
Gnome needs systemd
KDE nay be sucked in soon but its not there yet.
By all means discuss systemd and its alternatives and how to 'fix' things that depend on systemd.
As you rightly say, unless some code is forthcoming, it will stay just talk. |
Thanks for the encouragement!
Martin seems to be open about supporting alternatives, so at least we don't have to worry, that work to provide alternatives will be useless. Let's hope, there'll be a solution.
I will at least look at what I can do, but probably this thread is more about looking for someone else, who can solve the puzzle, than me being any help. Sorry about that!
Sidenote: http://quickgit.kde.org/?p=kwin.git&a=blob&h=2b9aaca9139715a7040099fba3e923e66b3db71b&hb=015c59d9fd65d9f84bdffdaf9720238c434f7ae7&f=logind.cpp shows the usage of logind by kwin, if anyone is interested... |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Mon Oct 20, 2014 8:20 pm Post subject: Re: logind is next |
|
|
| KuroNeko wrote: | | steveL wrote: | The problem is that both logind and the use of dbus for everything is borked.
dbus is pushed because it's an end-run round the GPL. Technically it's a terrible idea to use dbus for DE-specific, privileged operations which should go via the DM, just as it is to use it everywhere else instead of a simple API. |
Don't know about that, as dbus seems to make it easy to authenticate the user of the api and there has to be a reason, that it becomes so widely adopted. |
Which is where we part ways, since afaic that doesn't have any content in it.
Good luck with your exploration. :-) |
|
| Back to top |
|
|
KuroNeko
n00b
Joined: 08 Oct 2014
Posts: 23
|
| Posted: Mon Oct 20, 2014 8:43 pm Post subject: Re: logind is next |
|
|
| steveL wrote: | | KuroNeko wrote: | | steveL wrote: | The problem is that both logind and the use of dbus for everything is borked.
dbus is pushed because it's an end-run round the GPL. Technically it's a terrible idea to use dbus for DE-specific, privileged operations which should go via the DM, just as it is to use it everywhere else instead of a simple API. |
Don't know about that, as dbus seems to make it easy to authenticate the user of the api and there has to be a reason, that it becomes so widely adopted. |
Which is where we part ways, since afaic that doesn't have any content in it.
Good luck with your exploration.  |
Thanks, tough if you look ever look at this answer:
I'm only expanding on the idea, that communication should go through the DM:
Do you think, it is possible to write a library that does the logind stuff, and the DM would expose an api, if DEs need it? The blogposts by Poettering and other posts about logind suggested that it would have to be implemented as a separate daemon, though it wouldn't be the first time, Lennard would tell that something is impossible. It seems logical to ask your DM for device access, but it would be duplicated effort, to implement that in every DM, although you could probably minimize the needed calls into the lib. Still, a standalone daemon would loosen up that coupling... (especially if some DEs don't need it or use systemd-logind, it's only wasted effort)
It's probably not possible either way, as I believe logind has to react to devices and that would seem complicated.
Mhm, it's interesting, if you look at the stack from the other side, than you usually do |
|
| Back to top |
|
|
i92guboj
Bodhisattva
Joined: 30 Nov 2004
Posts: 10315
Location: Córdoba (Spain)
|
| Posted: Mon Oct 20, 2014 9:12 pm Post subject: |
|
|
| creaker wrote: | To mods:
may be it worth to block/remove such a provocative posts? We have it enough already. |
Quote the "provocative" part, report the provocation, and we will take care of it, if it in fact turns to be er.... provocative, or problematic in some other way. 
I fail to see how he is attacking anyone and this section is called "Gentoo chat" for a reason. He has started a debate which might be interesting for some people. If the debate is not interesting for some people, well, it's their choice to follow or not to follow it, isn't it?
KuroNeko, of course, you are free to debate as much as you wish as long as you don't break any forum rule (which as far as I can tell you haven't) and you are respectful to other members (which, as far as this thread goes is the case as well). It really doesn't matter if you are willing to write the code or not, much less taking into consideration this is just Gentoo chat. You can virtually debate about anything Linux rated here. If the thread turns into some other kind of generic thing I or some other moderator will move it wherever it belongs. |
|
| Back to top |
|
|
djdunn
l33t
Joined: 26 Dec 2004
Posts: 812
|
| Posted: Tue Oct 21, 2014 4:22 am Post subject: |
|
|
I don't ever think kde will require logind as long as its just kde and X, it really only matters when it comes down to wayland and kde. and imo a total wayland replacement of X is a bit too far off to make any predictions about kde hard depending on logind. imo by the time that happens systemd will be a dead project.
the kde devs have said you will never need logind to run kde and systemd wont ever be a requirement and says that only parts of logind will be used but doesnt have to be logind, could be systemd-shim, or openbsd's in process plan (imo looks better than shim does) or something else.
being scared that kde will follow suit on gnome is all FUD. Especially in the time it takes wayland to reach widespread adoption. That showstopping remote privilege escalation bug might be found in systemd that cant be fixed without totally re-engineering 90% of it before wayland is ready for widespread adoption.
_________________
“Music is a moral law. It gives a soul to the Universe, wings to the mind, flight to the imagination, a charm to sadness, gaiety and life to everything. It is the essence of order, and leads to all that is good and just and beautiful.”
― Plato |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Tue Oct 21, 2014 10:46 am Post subject: Re: logind is next |
|
|
| KuroNeko wrote: | I'm only expanding on the idea, that communication should go through the DM:
Do you think, it is possible to write a library that does the logind stuff, and the DM would expose an api, if DEs need it? |
Sure it is. But first you have to question what logind is doing, and why it's so important that we have to twist the rest of the stack around it.
To my mind there's simply no point in trying to do the "multi-seat" crapfest; effectively they're arguing that Unix isn't capable as a multi-user system, despite 40 years of industry experience that proves the opposite.
| Quote: | | It seems logical to ask your DM for device access, but it would be duplicated effort, to implement that in every DM, although you could probably minimize the needed calls into the lib. Still, a standalone daemon would loosen up that coupling... (especially if some DEs don't need it or use systemd-logind, it's only wasted effort) |
It's logical to ask the DM to do privileged operations, since by definition it is privileged, and further it is in a unique relationship with the DE (or should be.) Thus shutdown, suspend, hibernate, reboot et al are much better handled via the DE-DM protocol (and if there isn't one, there should be) with the DE taking care of the GUI in a non-privileged process. The privileged set of operations we're talking about are both small, and outside the scope of "normal usage". As such they're normally provided as a DE-specific button or cmd in any case.
Whether it's a good idea to ask it for device access is another matter. In fact it's a bad idea to change permissions on device nodes at all, especially to chown logged-in-user. There's a video on youtube somewhere of a German net-admin who'd spent over a year trying to make consolekit/policykit work. It's usually quoted as an example of how unpleasant Poettering can be (since he spends much of the lecture heckling the presenter, effectively, and does his level best to take over the presentation.) I found it interesting because the admin had clearly done his best to make things work, and knew what he was talking about. The conclusion was that changing permissions like that is simply broken, however you do it. (Consider a process that's left running with access to a device.)
As for "coupling", a shared lib doesn't couple you that closely, unless it also enforces dependencies which is the systemdiots' favourite method of "gentle persuasion". That's the part people who aren't that interested or knowledgeable about development miss: it's not just a "convenient API"; the real goal is to enforce lock-in. More and more projects that were perfectly viable and useful in their own right, are subsumed into systemd, and each one is then inturgated until using a small part of the formerly-viable ecosystem, pulls in the whole kitchen-sink.
It is more than just stupid: it is actively malevolent; consciously and deliberately so. If you want examples, udev itself, and recent upower changes that make absolutely no sense for the project, only for systemd; usb and pci hwdbs, that are projects built solely from user and community work, now proprietarised to systemd and RedHat. (Don't give me that it's GPL: vendor lock-in is vendor lock-in.)
| Quote: | | It's probably not possible either way, as I believe logind has to react to devices and that would seem complicated. |
You do that from udev, which originally was supposed to be nothing more than a very simple userland mux (multiplexor); again though it's a really bad idea to mess with device permissions in the way they do.
Reacting to events in general is nothing new. Device changes etc are simply more events, and again this should be confined to very specific software; not used as justification to change the whole stack across the board.
| Quote: | | Mhm, it's interesting, if you look at the stack from the other side, than you usually do :) |
Indeed; when you do, and review the whole thing as a design (discussion with others on these forums has helped me in that regard) you start to realise that there are some truly crap decisions, that have only been made to open Linux and the GPL userland to leeching.
The tail wagging the elephant. |
|
| Back to top |
|
|
KuroNeko
n00b
Joined: 08 Oct 2014
Posts: 23
|
| Posted: Tue Oct 21, 2014 3:30 pm Post subject: |
|
|
| djdunn wrote: | I don't ever think kde will require logind as long as its just kde and X, it really only matters when it comes down to wayland and kde. and imo a total wayland replacement of X is a bit too far off to make any predictions about kde hard depending on logind. imo by the time that happens systemd will be a dead project.
the kde devs have said you will never need logind to run kde and systemd wont ever be a requirement and says that only parts of logind will be used but doesnt have to be logind, could be systemd-shim, or openbsd's in process plan (imo looks better than shim does) or something else.
being scared that kde will follow suit on gnome is all FUD. Especially in the time it takes wayland to reach widespread adoption. That showstopping remote privilege escalation bug might be found in systemd that cant be fixed without totally re-engineering 90% of it before wayland is ready for widespread adoption. |
You're probably right about that, but that means, I will probably miss out wayland for quite some time. I gave up on that, since plasma on wayland will also depend on systemd for startup, if I read his comment today right.
But on the other side, Xorg is somewhat not as bad anymore as it seemed to me a few years ago. Actually it's pretty tame at the moment.
| steveL wrote: | | KuroNeko wrote: | I'm only expanding on the idea, that communication should go through the DM:
Do you think, it is possible to write a library that does the logind stuff, and the DM would expose an api, if DEs need it? |
Sure it is. But first you have to question what logind is doing, and why it's so important that we have to twist the rest of the stack around it.
To my mind there's simply no point in trying to do the "multi-seat" crapfest; effectively they're arguing that Unix isn't capable as a multi-user system, despite 40 years of industry experience that proves the opposite.
| Quote: | | It seems logical to ask your DM for device access, but it would be duplicated effort, to implement that in every DM, although you could probably minimize the needed calls into the lib. Still, a standalone daemon would loosen up that coupling... (especially if some DEs don't need it or use systemd-logind, it's only wasted effort) |
It's logical to ask the DM to do privileged operations, since by definition it is privileged, and further it is in a unique relationship with the DE (or should be.) Thus shutdown, suspend, hibernate, reboot et al are much better handled via the DE-DM protocol (and if there isn't one, there should be) with the DE taking care of the GUI in a non-privileged process. The privileged set of operations we're talking about are both small, and outside the scope of "normal usage". As such they're normally provided as a DE-specific button or cmd in any case.
|
But that's the problem, that kde is trying to solve using logind. They want to render and process input events in kwin, because it is needed to be done by the compositor on wayland. And both is only allowed with root rights, but they don't want kwin running as root. So they use logind to open the file descriptor and they don't need root for that.
Implementing that in the DM would make it do multiple things, it was not intended to and that doesn't seem to be a good idea.
Also the above was no problem in X because it usually runs as root, but as it is huge, it has a considerably large attack surface.
| Quote: |
Whether it's a good idea to ask it for device access is another matter. In fact it's a bad idea to change permissions on device nodes at all, especially to chown logged-in-user. There's a video on youtube somewhere of a German net-admin who'd spent over a year trying to make consolekit/policykit work. It's usually quoted as an example of how unpleasant Poettering can be (since he spends much of the lecture heckling the presenter, effectively, and does his level best to take over the presentation.) I found it interesting because the admin had clearly done his best to make things work, and knew what he was talking about. The conclusion was that changing permissions like that is simply broken, however you do it. (Consider a process that's left running with access to a device.)
As for "coupling", a shared lib doesn't couple you that closely, unless it also enforces dependencies which is the systemdiots' favourite method of "gentle persuasion". That's the part people who aren't that interested or knowledgeable about development miss: it's not just a "convenient API"; the real goal is to enforce lock-in. More and more projects that were perfectly viable and useful in their own right, are subsumed into systemd, and each one is then inturgated until using a small part of the formerly-viable ecosystem, pulls in the whole kitchen-sink. |
That's the problem a logind replacement should solve. (You wouldn't have to use systemd) But if you are right and logind in itself is a bad idea, it would only further push adoption of it, even if it's broken by design.
On the other side, I didn't think about it, but you really can replace a lib with another one, if they provide the same api. I probably read to much of the dbus documentation, so I forgot about that.
| Quote: |
It is more than just stupid: it is actively malevolent; consciously and deliberately so. If you want examples, udev itself, and recent upower changes that make absolutely no sense for the project, only for systemd; usb and pci hwdbs, that are projects built solely from user and community work, now proprietarised to systemd and RedHat. (Don't give me that it's GPL: vendor lock-in is vendor lock-in.)
| Quote: | | It's probably not possible either way, as I believe logind has to react to devices and that would seem complicated. |
You do that from udev, which originally was supposed to be nothing more than a very simple userland mux (multiplexor); again though it's a really bad idea to mess with device permissions in the way they do.
Reacting to events in general is nothing new. Device changes etc are simply more events, and again this should be confined to very specific software; not used as justification to change the whole stack across the board. |
What other way would make it possible to run the compositor without root rights? Changing the device permissions may be a bad idea, because it would make it easier to let maleware listen to your keyboard or fake input, but I thought logind had abandoned the concept and would provide only the requested process a fd, that it can write to and relates to the actual device, without changing its permissions. Don't know, how it does that atm, but that was, what I wanted to look into, as it's the only thing needed by kwin right now. Multiseat ala logind isn't.
But having dbus call into the DM sounds complicated, if you like to switch your DM and even more so, if you let it call into the compositor, but I don't know about that.
| Quote: |
| Quote: | | Mhm, it's interesting, if you look at the stack from the other side, than you usually do |
Indeed; when you do, and review the whole thing as a design (discussion with others on these forums has helped me in that regard) you start to realise that there are some truly crap decisions, that have only been made to open Linux and the GPL userland to leeching.
The tail wagging the elephant. |
I don't think, dbus is really a good way to work around the GPL, isn't it just wrapping the function call? Shouldn't it be disallowed to use a thin piece of middle ware, just that you can use a GPL licensed function call? If it isn't, then dbus is really a broken concept, spitting in the face of everyone, who does license his software under the GPL, to prevent such a thing... |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Wed Oct 22, 2014 1:38 am Post subject: |
|
|
| Sorry, too much confusion. |
|
| Back to top |
|
|
Navar
Guru
Joined: 20 Aug 2012
Posts: 355
Location: usa
|
| Posted: Fri Oct 24, 2014 9:54 pm Post subject: |
|
|
| SteveL wrote: | | There's a video on youtube somewhere of a German net-admin who'd spent over a year trying to make consolekit/policykit work. It's usually quoted as an example of how unpleasant Poettering can be [...] |
For reference and entertainment: http://www.youtube.com/watch?v=skPOeOPGpwM Titled, 27c3: Desktop on the Linux (and BSD of course) |
|
| Back to top |
|
|
WWWW
Tux's lil' helper
Joined: 30 Nov 2014
Posts: 143
|
| Posted: Mon Dec 01, 2014 8:30 am Post subject: |
|
|
AWSOME!!
This is great, eudev, openrc now logind!! Go gentoo devs!!
There's a lot at stakes for the future of linux: destroyers vs creators.
I wish I could help. Can I do something if I don't know how to code? Or is there some easy tasks I could help with? |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Mon Dec 01, 2014 5:48 pm Post subject: |
|
|
Hmm apologies KuroNeko; there was a question in there, which I missed: | Quote: | | What other way would make it possible to run the compositor without root rights? |
Why not just pass it the fd when you start it up? In the simplest case this can be done via fd inheritance. |
|
| Back to top |
|
|
truekaiser
l33t
Joined: 05 Mar 2004
Posts: 804
|
| Posted: Mon Dec 01, 2014 6:12 pm Post subject: |
|
|
| Navar wrote: | | SteveL wrote: | | There's a video on youtube somewhere of a German net-admin who'd spent over a year trying to make consolekit/policykit work. It's usually quoted as an example of how unpleasant Poettering can be [...] |
For reference and entertainment: http://www.youtube.com/watch?v=skPOeOPGpwM Titled, 27c3: Desktop on the Linux (and BSD of course) |
The whole thing? or when does this happen in the video? |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Mon Dec 01, 2014 6:15 pm Post subject: |
|
|
| truekaiser wrote: | | The whole thing? or when does this happen in the video? |
Heh I just watched it again (thanks for finding it Navar.) Not got whole way through, but Poeterring starts interrupting about 18 minutes in; I recall the discussion toward the end being about the device nodes, but it's definitely worth watching imo, since the guy clearly is a serious admin. |
|
| Back to top |
|
|
truekaiser
l33t
Joined: 05 Mar 2004
Posts: 804
|
| Posted: Mon Dec 01, 2014 6:53 pm Post subject: |
|
|
| steveL wrote: |
| truekaiser wrote: | | The whole thing? or when does this happen in the video? |
Heh I just watched it again (thanks for finding it Navar.) Not got whole way through, but Poeterring starts interrupting about 18 minutes in; I recall the discussion toward the end being about the device nodes, but it's definitely worth watching imo, since the guy clearly is a serious admin. |
Oh god, the real good stuff starts in the 20 min range.
'you're behind the times.'
'thats not the world we live in.'
similar and so on... |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Mon Dec 01, 2014 7:05 pm Post subject: |
|
|
| truekaiser wrote: | Oh god, the real good stuff starts in the 20 min range.
'you're behind the times.'
'thats not the world we live in.'
similar and so on... |
Man is that what he's saying? I couldn't hear him for most of it, last time I saw it as well, apart from when he's on the mic. I did wonder what the laughter was about.
No wonder people quote it as an example of how obnoxious he is.
I just found the analysis of nubkit device permissions interesting.
It does give the lie to his recent protestations at being "hounded" by "trolls"; he's been one for a long time, and encourages group-mob mentality amongst his "followers," precisely to drown out technical discussion. |
|
| Back to top |
|
|
truekaiser
l33t
Joined: 05 Mar 2004
Posts: 804
|
| Posted: Mon Dec 01, 2014 7:09 pm Post subject: |
|
|
| steveL wrote: |
| truekaiser wrote: | Oh god, the real good stuff starts in the 20 min range.
'you're behind the times.'
'thats not the world we live in.'
similar and so on... |
Man is that what he's saying? I couldn't hear him for most of it, last time I saw it as well, apart from when he's on the mic. I did wonder what the laughter was about.
No wonder people quote it as an example of how obnoxious he is.
I just found the analysis of nubkit device permissions interesting. |
Oh thats the best part.
The guy on the stage shows the bad behavior. LP says 'it's not console kit. it's linux' and later just tells him 'consolekit doesn't kill people, people kill people.' |
|
| Back to top |
|
|
KuroNeko
n00b
Joined: 08 Oct 2014
Posts: 23
|
| Posted: Mon Dec 01, 2014 11:07 pm Post subject: |
|
|
| steveL wrote: | Hmm apologies KuroNeko; there was a question in there, which I missed: | Quote: | | What other way would make it possible to run the compositor without root rights? |
Why not just pass it the fd when you start it up? In the simplest case this can be done via fd inheritance. |
Yep, that seems to be the nicest solution.
I'm currently thinking about, how you would do sane session switching(tm), but wait! Where do you start a session? The DM? Why don't you let the DM handle that? /sarcasm (I think)
Maybe in the wayland world, the DM could provide a simple render surface and play the part of the system compositor. Not that I really spend my time thinking about that. I'll get there, when I have nothing more to script without a graphical session running. 
The deeper I dig, the more the CoreOS feels like madness! Why do they want to take my ability to play?
That's the reason I chose linux, not some usability crap, that makes me unable to use my pc, my personal computer (for playing around with system components)!
Luckily there are enough components, that don't seem to be affected that much by systemd. Or did I miss the bash systemd-integration patch? (I mean you really need it started with socket activation, so you can start your shell scripts  )
Oh, and thanks for giving me some directions. I also found some really nice linux users in my university now. Linux is becoming more and more fun every day! 
Neko |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Tue Dec 02, 2014 6:55 pm Post subject: |
|
|
| steveL wrote: | | Why not just pass it the fd when you start it up? In the simplest case this can be done via fd inheritance. |
| KuroNeko wrote: | Yep, that seems to be the nicest solution.
I'm currently thinking about, how you would do sane session switching(tm), but wait! Where do you start a session? The DM? Why don't you let the DM handle that? /sarcasm (I think) |
Hehe; no it's exactly right: go back to what's actually happening, and do it as simply as possibly. It's not like these things haven't been done before.
| Quote: | | Maybe in the wayland world, the DM could provide a simple render surface and play the part of the system compositor. Not that I really spend my time thinking about that. I'll get there, when I have nothing more to script without a graphical session running. |
I prefer to think of DM-DE as akin to getty-login pair. Former is privileged and hands over to latter running as user; on login changes uid and execs the shell (ergo same pid so parent can track it and be notified when it exits.)
There was an existing protocol, XDMCP which is for the DM-remote-host (X "client", what the user thinks of as "server" running their progs) interaction (it just needs to be run over ssh.) Having discussed this with mv, the DM-DE interaction is where we should add privileged ops like shutdown or suspend. After all the DM is already privileged, by definition, and is in first-gatekeeper position wrt the hardware (since it starts up the user-mode DE, at least for the local case we're concerned with.)
So it seems to me XDMCP is where we should be looking. (I recall tuomov cursing fdo and mentioning XDMCP, and never quite knew why.)
| Quote: | | The deeper I dig, the more the CoreOS feels like madness! Why do they want to take my ability to play? |
They want to turn your computer and internet connection into a broadcast channel, like television, whereby they can monetise users as an "income-stream" which means we're the product, not the consumers, whose details are sold on for marketing, and we have no choice about crappy advertising etc, let alone what content we really want (choice in a walled-garden is not freedom.)
Nowadays your television and your console are both powerful computing devices, that you paid for, which you cannot control in most cases, as is your phone.
From Red-Hat's perspective, I believe their execs are simply trying to replicate the monetarily-successful Windows business-model. Their main competition is actually Google, imo. Both are using the Linux kernel, and trying to enforce their effectively-proprietary userland.
| Quote: | | I also found some really nice linux users in my university now. Linux is becoming more and more fun every day! :D |
Excellent :D That's what it's about: fun and collaboration, not coercion and control. |
|
| Back to top |
|
|
Navar
Guru
Joined: 20 Aug 2012
Posts: 355
Location: usa
|
| Posted: Fri Dec 05, 2014 7:01 am Post subject: |
|
|
| steveL wrote: | | No wonder people quote it as an example of how obnoxious he is. |
You must have thought I was kidding in the past. Although I had to dig to find this more recent gem via your slight reference (I had not seen it and I'd seen enough from him being a speaker in past videos in prior years). Unfortunately, he's not alone. I need to re-find a particular link from the f.d.o. lot w.r.t. their view of 'security' such as with browser certs. |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Gentoo Chat
