| View previous topic :: View next topic |
| Author |
Message |
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
 Posted: Sat Aug 01, 2015 3:06 pm Post subject: |
 |
|
I have no idea what that's about. It appears to be a criticism, but if so, it's badly-delivered.
As for implementation, turns out mactab in-kernel is not quite so simple as notadev thought, but we'll see what he comes up with.
It's for fun, not for money nor status, so no-one's pressured or obligated to do anything, and we have quite a lot of other work to be dealing with atm in any case, so we don't much care about what anyone thinks wrt implementation timeliness either.
On a more cogent note, the suckless sinit code is nice and clean. |
|
| Back to top |
|
 |
geki
Advocate
Joined: 13 May 2004
Posts: 2387
Location: Germania
|
| Posted: Sat Aug 01, 2015 4:05 pm Post subject: |
|
|
no, no criticism. edited my former post.
you and/or notadev work on it as I understand. good to know.
I just thought you welcomed others to implement ubus.
then, many people have a hard time with a technical discussion about code. 
_________________
hear hear |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Sun Aug 02, 2015 9:28 am Post subject: |
|
|
| geki wrote: | no, no criticism. edited my former post.
you and/or notadev work on it as I understand. good to know. |
Well I wouldn't say we're working on it as yet; too much other stuff that takes priority atm, so neither of us has dived in yet.
I need to wait for him in any case: if we can't do it in-kernel, much of the above goes out the window; certainly the fun stuff, in code terms.
While it's perfectly feasible simply to use TICP for a desktop-bus, that's pure userland coding, and nothing a competent POSIX programmer would find particularly hard, certainly not if they have any networking experience.
It wouldn't be anything new, though it might seem new to Linux users, I suppose.
| Quote: | I just thought you welcomed others to implement ubus.
then, many people have a hard time with a technical discussion about code. ;) |
Hehe. That's more a "if you want to implement it, please do so: so we don't have to." ;-)
I've found the forums to be quite good when it comes to discussing code, so long as people give direct urls to the files they want to discuss, and then pull out snippets in code tags.
People who have no clue what the code means, don't tend to butt in, but generally code should be simple to read, and easy to understand just by looking at it. Or YDIW.
Actually now's a good time to put this in here, as it's essential background:
| Kernighan & Plauger wrote: | Good Programming is not learned from generalities, but by seeing how significant programs can be made clean, easy to read, easy to maintain and modify, human-engineered, efficient and reliable, by the application of common sense and good programming practices.
Careful study and imitation of good programs leads to better writing. |
(cover of "Software Tools", 1976)
Sorry for misreading, though. |
|
| Back to top |
|
|
judecn
n00b
Joined: 07 Jan 2015
Posts: 17
|
| Posted: Sun Aug 02, 2015 10:21 pm Post subject: |
|
|
(Adding my thoughts at Steve's request).
When I think of a "bus", I think of it as the software analog of a hardware bus.
* There are N processes, each of which produce messages to be consumed by up to N-1 other processes. Messages are sent 1-to-N.
* Each process consumes messages in the same order as all other processes--that is, the order of message consumption is sequentially consistent with the order of message production.
* There is a notion of "permission"--a producer can only send to a consumer if the consumer allows it, and a consumer can only receive a producer's message if the producer allows it.
* There is a notion of "notification"--a consumer will awoken by the OS when there are pending messages; it does not have to poll.
* There is a notion of a "message channel"--a producer or consumer can define and maintain multiple entry points for different classes of messages.
I think ubus as defined above meets these criteria, with the possible exception of mandating a particular data marshaling format (capnproto). I don't think enforcing a particular format matters, as long as the protocol is message-oriented and the producers and consumers are capable of extracting useful information out of it.
Popping up a level, I don't think the primary purpose of (k)dbus is to offer a bus in the above sense, but is instead to offer a way for processes to define various types of IPC state (buses, RPC endpoints, pub/sub endpoints, locks, launcher hooks, etc.) that will share fate with either the process that created them, or the process's login session. For example, a process can create a session-scoped RPC endpoint in dbus, crash, start up again, and re-claim the endpoint, and dbus will buffer up and forward intermittent pending requests to the resumed process to avoid loss of service. Once we think of (k)dbus that way--a repository of process-scoped and session-scoped IPC state--a lot of its creators' design decisions start to make sense. This isn't to defend or advocate using dbus, but just to help explain how and why (k)dbus got to where it is today in order to frame the discussion of ubus's design. Does ubus care about sessions? Will ubus try to keep track of per-session IPC state? Will ubus state outlive the process that created it, or will it share fate with the process (or process group) using it, or will the option be left to the application? |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Sun Aug 09, 2015 7:14 pm Post subject: |
|
|
Thanks for responding, Jude. I wanted to take a bit of time to gather my thoughts.
| judecn wrote: | When I think of a "bus", I think of it as the software analog of a hardware bus.
* There are N processes, each of which produce messages to be consumed by up to N-1 other processes. Messages are sent 1-to-N.
* Each process consumes messages in the same order as all other processes--that is, the order of message consumption is sequentially consistent with the order of message production.
* There is a notion of "permission"--a producer can only send to a consumer if the consumer allows it, and a consumer can only receive a producer's message if the producer allows it. |
This seems to mix up the layers; really the best time to enforce permission is at open(), which allows for an fd to be inherited, while permissions are dropped. This point was made (several times that I recall) on LKML wrt kdbus permission checks (and metadata iirc.)
| Quote: | | * There is a notion of "notification"--a consumer will awoken by the OS when there are pending messages; it does not have to poll. |
Since you can do this with any fd, and message-queues provide for RT signal notification, as well as thread startup if no other thread is already waiting on the queue (which is how it should be designed), I don't see this as really in-scope for the underlying use of a TICP socket.
It's just standard userland coding, commonly via libev or libevent.
| Quote: | | * There is a notion of a "message channel"--a producer or consumer can define and maintain multiple entry points for different classes of messages. |
Message queues are ofc priority-queues, though most code doesn't use priorities, simply sequence.
I snipped out the ubus-specific parts til the end, as we're still discussing the idea of a "bus", or a pub:sub channel.
| Quote: | | Popping up a level, I don't think the primary purpose of (k)dbus is to offer a bus in the above sense, but is instead to offer a way for processes to define various types of IPC state (buses, RPC endpoints, pub/sub endpoints, locks, launcher hooks, etc.) that will share fate with either the process that created them, or the process's login session. For example, a process can create a session-scoped RPC endpoint in dbus, crash, start up again, and re-claim the endpoint, and dbus will buffer up and forward intermittent pending requests to the resumed process to avoid loss of service. Once we think of (k)dbus that way--a repository of process-scoped and session-scoped IPC state--a lot of its creators' design decisions start to make sense. This isn't to defend or advocate using dbus, but just to help explain how and why (k)dbus got to where it is today in order to frame the discussion of ubus's design. |
Leaving aside the loginkit stuff (til the end, though I feel it's bad design to have this as part of "kdbus"), POSIX message-queues (standardised by 1994, formally 1995 iirc) offer a lot of what's discussed, in terms of prior-art, and TIPC, designed in the late 1990s, provides pub-sub semantics.
The only thing neither of them promise, is that they will allow you to consume as much RAM as you like, as that's plain dumb, as we discussed in one of the other threads (based on "earlier discussion with the networking folks" where the systemdiots ignored all the problems with dbus, as they now do with kdbus.)
The real problem is the munging together of everything; I prefer how POSIX gives you several components you can choose from, according to the task at hand. Specifically that gives us the ability to separate handling much better, as well as avoiding bottlenecks forced upon us by a bloat-heavy mishmash design ("is it a protocol, is it a transport, no it's both, and much more besides!") that promises what is undeliverable in the real-world.
While the TIPC developers were happy to consider adding fd-passing to TIPC, personally I don't think it really belongs there, and prefer keeping that to a separate control channel; again I like the ability to respond differently according to the role we're playing, and the context of the data at hand. Most code shouldn't need fd-passing in any case (really it should be handled by a userspace lib for the control stuff, only we'd need a proper ABI designed along the lines of LADSPA.)
| Quote: | | I think ubus as defined above meets these criteria, with the possible exception of mandating a particular data marshaling format (capnproto). I don't think enforcing a particular format matters, as long as the protocol is message-oriented and the producers and consumers are capable of extracting useful information out of it. |
We're not particularly concerned either; the main reason to have it in-kernel is so we can ignore most of the events without context-switching, or indeed consideration by the TIPC bus.
It just makes sense to use a) a format for userspace, as mv raised (linked in OP) and b) the format specifically recommended by Litomirski for modern IPC. Though as discussed above, plaintext is good too.
Which kind of brings me to what I wanted to ask you: does it make sense to you to transmit directly via TIPC from kernel (given that TIPC is already in-kernel)?
That it's stable and well-designed relates more to preference over kdbus, than to transmission from in-kernel after BPF.
The alternative is ofc simply to continue with something like eudev listening to rt-netlink, though it seems a shame to send it back out over TIPC (instead of a kdbust) which simply means more kernel tx, of what we should be able to redirect automatically after setup.
| Quote: | | Does ubus care about sessions? Will ubus try to keep track of per-session IPC state? Will ubus state outlive the process that created it, or will it share fate with the process (or process group) using it, or will the option be left to the application? |
I haven't checked what TIPC does, but it seems unlikely that it would lose state simply because a sending pid drops out after transmission; that's essentially the point of pub:sub N:N communication (where neither end really knows what's on the other.)
Certainly all POSIX named-IPC channels, keep state as long as the system is up (or until explicitly unlinked); including shared-memory (all references must be dropped before the memory is released, after unlink, as with files.)
As for loginkit stuff, no, that's up to whatever is in userland, such as "edev" in the above diagram, which would be a userland mux on the lines of udev as originally conceived, though it's not doing the mux, only the setup and allowing TIPC to do the rest (we hope.)
Personally if you can't do it with PAM, or the existing POSIX APIs, I don't think it's interesting, though I'd be happy to shown why I'm wrong. From an admin pov, you also have to show why visudo can't cover it, either.
Essentially PAM is where you plugin whatever policy you like (though most people really don't need to tweak anything given a reasonable distro) so polickyshit is woefully ill-conceived afaic, before we get to the nubskull impl, such as: using js instead of admitting there's a reason UNIX has sh, and indeed that js shouldn't even be needed for "wheel", as it isn't for sudo.
"edev" would need to what eudev/vdevd does, in terms of actions, I guess, but that area is really someone else's bailiwick (there are what, four "device managers" around now?)
If forced, we'd try adapting vdevd first, since it's free of contamination, aims for portability (though that should just be of higher-level ABI;) and has a decent lead.
Though I'm not sure whether running scripts for everything is performant enough, it's SEP ;) and can be optimised where needed.
An easyIPC lib (channels configured by the admin) seems more and more attractive, though again it's userland, and a long way away, both in time, and from a specific usage of TIPC for an ORB (as the top-level would be, really, which is why capnproto is a good fit.) |
|
| Back to top |
|
|
CasperVector
Apprentice
Joined: 03 Apr 2012
Posts: 156
|
| Posted: Tue Aug 25, 2015 12:48 pm Post subject: |
|
|
In case someone does not know it but may nevertheless be interested, openwrt already has a message bus called ubus; you can also read this for fun.
_________________
My current OpenPGP key:
RSA4096/0x227E8CAAB7AA186C (expires: 2020.10.19)
7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Thu Aug 27, 2015 3:01 pm Post subject: |
|
|
| CasperVector wrote: | | In case someone does not know it but may nevertheless be interested, openwrt already has a message bus called ubus; you can also read this for fun. |
Hey, Casper; thanks for the heads-up and the links.
I got sidetracked by gmake shenanigans of the sort I used to get lost in, but the high-level ubus abstraction (your first link) seems reasonable, though I have a few quibbles (ofc;)
I also sidetracked into a link to their (now-obsolete) hotplug "daemon"; more a collection of shell.
Probulator is interesting, though, when we consider it alongside the simpler-init idea: it demystifies the whole thing.
Somehow this took me onto procd, the init-manager which is afaict meant to handle the hotplug side, though I might be misinterpreting. Read this all yesterday, so don't recall exactly where.
Give me a bit and I'll write up thoughts; main one is that, firstly we're definitely going to use dhcpcd, so all this netifd stuff is superfluous, which got me onto wondering why on earth we need to make the networking/ip commands available over a "userland-app bus" at all.
Don't get me wrong: it's done comprehensively enough. I just don't think it's something we want to do at all, in the first place.
By all means, show me what it enables that's so amazing, which can't simply be done by executing the relevant commands in the first place, perhaps via a script or from a desktop app, assuming group permissions or PAM/visudo allow access.
In no event do I see it as a "mainstream" use-case by any means; right now it looks like a gaping attack-vector, and not much else.
OFC that's only the network.part, some of which is fine, but again, I don't know why it's relevant at all to the desktop user.
If we do provide it, it'll be under net. in naming terms, and it'll be related to dhcpcd, nothing else; that is ofc portable to at least *BSD, to my knowledge. And I sincerely doubt we'll be opening up admin-tasks to xbus (or w/e.)
Similarly there's a "mountd" thing under packages/system (where procd, rpcd is as well) but this is overall distro build; the relevant codebases are elsewhere.
I'm not sure we even need such a thing; again I'm happy to hear otherwise, but only from admins and first-line Gentoo users, not from some developer with delusions-of-grandeur, nor some documentation bod, nor indeed a "clueless end-user" all this is supposedly aimed at.
They can use w/e tools they like, preferably coded by programmers, and bug-wrangled well.
Climbing down from my high-horse ;-), those are all simply applications using ubus, ofc, and don't speak to the actual bus-impl itself.
I just don't want to bake security-holes into the base-system.
Though it would be good to provide the other parts, and consider working on either a shared or cloned-then-solidified ABI.
Either way we can certainly use some cross-fertilisation, so thanks again. :)
I really think TIPC makes more sense than anything else, with a fallback to localhost SCTP or UDP where unavailable (but that's a while away, given that we've done nothing at all on this so far..)
Point being to use the separation of transport and protocol to our advantage, though ofc certain things are going to be trickier if we don't have TIPC, which is why working out how to achieve w/e minimal semantics are needed in that situation, would be a phase2 goal.
Still want to explore X really, as XDMCP is great, and it's supposed to have a desktop-apps channel already (ie: dbust was already part of X.)
Forking and letting a dupe handle solely that (under user-id), not the rest of what the X server is multiplexing, might be a better fallback, or indeed a much better place to start, when it comes to the desktop bus. |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Fri Jan 29, 2016 8:10 pm Post subject: |
|
|
Just pulling in another bit of prior discussion, so we don't have to reiterate it.
wrt "the shim as a weaning path instead of legitimizing"
| steveL wrote: | No: you're still legitimizing the whole practice of leech-RPC, which I want nothing to do with, for one. I see it as threatening the very ecosystem on a much more fundamental level: by making the GPL irrelevant (which is further pushed via "modern" projects pretending that BSD-2/MIT is cool, because it allows companies to rip us off by selling us back our own work, proprietarised.)
I'd much rather go back to dcop for the desktop; you simply don't need to worry if you're not shoving mega-blobs of data around, but only control metadata, which is application data as far as the kernel and userspace plumbing are concerned (not control.) There were already examples of people scripting "apps" in modern phone-parlance, which was totally killed by the move to dbus in KDE-4.x.
But I do find TIPC exciting, as it's such a clean and mature IPC impl, already in the kernel for over a decade. No doubt Ericsson use it for erlang nodes; either way it's just what's needed, if we were going to implement a dbus: but why not just keep them app-specific, much like a named socket or a fifo. Essentially we already have a "libdbus" and a kdbus, which are proven.
What would be cool is an easyipc lib that allowed the admin to configure what mechanisms are used for what, in the local application domain (a bit like /etc/services). Not sure how necessary it is, but it'd be fun. :-) |
The non-technical part above, would still be raised were we consulting for someone, considering the various technologies; that's why it's included here.
I've stated elsewhere that we would never recommend a client firm opening itself up to the legal liabilities involved ("I wouldn't like the exposure" or some such), quite apart from the point of how to destroy its own ecosystem, is never a good idea for an organism or species to pursue.
Getting back to the technical, and the reason I posted, which needed context, a while later, on the same subject: | tclover wrote: | This shouldn't be difficult to implement with such an easy API... I remove the "difficult API" said previously! I second a lib for that kind of things... to give at least a "named service" (string) translated to a (TIPC) "named port" {TYPE,INSTANCE} (two 32-bits integer.) It will certainly help... What about a "bearer" (link) implementation?
I'm yet to finish reading the specs, but, so far so good. The API looks almost more easy to grasp... for even the "simpler" (than D-Bus) kDbus, minus the "bearer" link left to be implemented (which a TCP-like or not choice.) And the ZONE/CLUSTER/NODE address space & one-to-many(multicast+broadcast)/many-to-one/one-to-one(unicast (low latency)) make kDbus' domain/bus/connection counterpart... almost a toy.
(Some facts: kernel(good config)+JACK gives a ~20ms latency; or ~<10ms for RT kernel.)
Direct peer-to-peer (or one-to-one) communication (for low latency) on ~weak~ hardware achieve a ~100us for Round Trip Time (send+receive message) is not that bad... (The 4us of kDbus is not trustworthy considering the politics of systemD cabals.)
PS: I added net-misc/tipcutils-2.0.3 to my overlay (it has a cmdline utils for AF_TIPC ("ports") sockets creation compared to version 2.0.0 available in the official tree); and dev-perl/IO-Socket-TIPC in order to test a few things for those interested... |
(link added) |
|
| Back to top |
|
|
depontius
Advocate
Joined: 05 May 2004
Posts: 3509
|
| Posted: Fri Jan 29, 2016 10:41 pm Post subject: |
|
|
| steveL wrote: | Just pulling in another bit of prior discussion, so we don't have to reiterate it.
wrt "the shim as a weaning path instead of legitimizing"
| steveL wrote: | | No: you're still legitimizing the whole practice |
|
In case you hadn't noticed, nobody is looking to anyone to legitimize it, least of all people like us. That's already been done, like it or not, and mainstream is already dbus, systemd, and all that crap. We're the fringe. However I'll take away my term "weaning path" and make it "recovery path", because at some point that's what it will need to be, and because by that point the crap will be so deeply entrenched that it'll be almost impossible to get a "modern desktop" off of it. We're also off-mainstream by rejecting GNOME, I think KDE is now systemd-encumbered, etc. I only use GNOME at work because that's the official client, I just use a bare WM at home, and my wife uses xfce. When systemd has its catastrophe, how many people will seek "Classic Linux" and how many will just go back to Windows?
_________________
.sigs waste space and bandwidth |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Sat Jan 30, 2016 4:20 am Post subject: |
|
|
| depontius wrote: | | When systemd has its catastrophe, how many people will seek "Classic Linux" and how many will just go back to Windows? |
To be blunt, I don't really care. "Market-share" is irrelevant to a niche operating-system, besides which I don't see any point in chasing fashion to get that nebulous "benefit."
This sounds like a rehash of the "ohNoes! All the Gentoo users are leaving because they didn't like the graphical installer!" drama.
So what? They were never interested in it, anyway, or they'd have configured it post-install, but they didn't bother because that's the type of user who wants a graphical installer, and refuses anything else.
Fashions never last; that's kind of the point of them.
In any event, I do not want to get into that argument, as such (about shims), again (that's why i didn't quote you); I was just pointing out that a knowing end-run around the GPL, has relevance to any choice of technology, by companies we'd normally consult for.
Simply put, one cannot pretend you do not know that it is a violation, if you are actually in the position to specify a "convenience" layer, that is in fact slower by design than the standard practice of simply calling a function, perhaps via an ORB.
The typical business I am thinking of, for this case, would be in the embedded arena, delivering product meant to be forgotten about as far as the end-user is concerned. They are very used to IP concerns in their area of expertise, even if that is not software per-se, and typically employ programmers in any case; as such they can hardly feign ignorance of licensing and the legalities (that's what their legal depts are for, fgs. You know how long it takes to get a contract agreed? .. QED ;)
If we didn't alert clients to such wider concerns, as well as delivering sound technological insight, we'd never get repeat business, nor would we have any sort of reputation even to be considered; I presume it's the same for most of my fellow users, who are typically in their 30s or older, not their 20s, and typically already working in IT professionally (based on polls and discussion.)
You point out pitfalls as well as benefits to any approach, or you're really a salesperson.
We'd be remiss if we didn't share that same level of professionalism, ie: alerting to the wider consequences of any choices made, rather than just "will it work, this week?", for any FLOSS project we might be involved with.
Besides anything else, we gain a lot from the community, and don't really fancy going back to the bad old proprietary hell-choices we used to face as our only options. (So much wasted time, wrestling with crap..)
We MUST NOT make the same mistake of allowing license evasion over any bus we might (possibly, one day..;) implement. (In fact, all we're really talking about is using TIPC, not implementing anything ourselves as such.)
We have prior art in the kernel to point at, should anyone want to make a fuss about how we're "restricting the freedom" to rip our community off.
Sorry if I poked you unnecessarily; my opinion on a shim remains that it is simply rebaking a bad design, and leaves you in the position of playing ABI catchup with people who don't want you alongside, and have a monetary interest in breaking your, and any other alternative, project, as well as the resource to make that happen, and keep on making it happen. No-one thanks you for it (most users don't even care about the code, remember) and it really is a demoralizing way to spend your hours.
The industry wasted far too much time on that in the 90s, for us even to contemplate it now.
Not saying you want to legitimize it; but such efforts are only used as justification for how great the supah-turd is; or why would everyone else be imitating it?
Even if you don't like the version from bigcorporationX, there must be some underlying utility or point to the design; or again, why would you need to reimplement it?
So they end up lending legitimacy or credence, irrespective of what was intended.
And that really is counter-productive, especially given how little time we have by comparison; let's not waste it on that.
Oh look I got into it again.. Blame my age. ;-)
I really meant it when I said I'd like to see what you'd specify as use-cases for a userland pub-sub channel, beyond "desktop bus"; not how, but what it would be used for, partitioned by domain. So audio and video are out, as they're much better handled already.
Desktop notification is one thing, which is really a fancy name for systray, whatever edge of the window (or mobile display) it's on. So again, a simple ABI spec, starting with a few scribbles, would be great.
Research into what's being done, and was done in dcop, for whatever area you might choose, is always useful; but it's not like we need to rush, or there's any pressure on any one.
IME this is the point where everyone goes silent; which just goes to show, that end-users don't really care how their desktop app talks to whatever it talks to, so long as everything works, and they get notifications as and when they want them.
Personally, I think it's nicer to presume if people want conky, they've got it; the most I'd do is make sure it's installed, but really that's down to the admin.
On the wider issue, let the desktop bods sort it out, at the toolkit side. ATM that means dbus for most "mainstream" ones; but if the toolkit is worth using, it'll be easy enough to change the module that does that part, to use something else. Preferably a stable cross-platform ABI the next time around (or just X), instead of a platform-specific ever-changing, ever-expanding, bloated bottleneck, only pushed to "obsolete" the GPL.
In fact all the "standardisation" I've read about so far, is really about simple ABIs for desktop environments to perform sysadmin-related tasks. Firstly it's a real cop-out not to simply wrap that behind a platform-generic layer, already; maintaining it really isn't that difficult, though it's fair enough to have one project handle a domain; so long as it's easy enough to swap out. dhcpcd is the archetype, really (any other aspect, such as power-management, is much less complex overall.)
Secondly, the rest of the desktop apps, the ones people actually care about running, should not and need not care, so modularity and parsimony dictate that they must not care, for ease of maintenance and use, as well as implementation.
About the only case where I've heard that might apply, is notifying the desktop that you're streaming audio or video, so don't turn off the display. Again, this is toolkit-level, and nothing more than a few functions at most, so the brouhaha seems most unwarranted.
It's not many programs we're talking about in any case; streaming video players, and browsers, audio utils; all pretty comprehensively handled in terms of people working on them, for decades now. And again, handled at toolkit or support-lib level, or YDIW.
Games ofc don't care, as the user interacts via input devices, so it's never an issue. |
|
| Back to top |
|
|
depontius
Advocate
Joined: 05 May 2004
Posts: 3509
|
| Posted: Mon Feb 01, 2016 4:40 pm Post subject: |
|
|
I'll simply say that as systemd has taken over more of the Linux ecosystem it's been possible to say, "I just won't run xxx program that needs systemd," or "I'll stick with the back-level version that doesn't need system." I've been running that way, for is it two or three years now?
However that path is showing some creakiness. I'm still running gdm-2.20.11-r1, for instance. I've been running gdm for many years, and it was convenient to freeze it at the pre-systemd version. I'm not sure if it's getting creakier or if I'm just noticing it more, but feels as if it's misbehaving more often - failing to do a shutdown when requested, primarily. I see more programs "adopting systemd", even where we would both argue that an ordinary user program shouldn't care what init system it's running under - but it does.
I have some fear of being painted into a corner, avoiding systemd. In addition to giving others a "return from insanity" path I see shims as a way to be less constrained, myself.
_________________
.sigs waste space and bandwidth |
|
| Back to top |
|
|
Naib
Watchman
Joined: 21 May 2004
Posts: 6051
Location: Removed by Neddy
|
| Posted: Mon Feb 01, 2016 4:47 pm Post subject: |
|
|
| depontius wrote: | I'll simply say that as systemd has taken over more of the Linux ecosystem it's been possible to say, "I just won't run xxx program that needs systemd," or "I'll stick with the back-level version that doesn't need system." I've been running that way, for is it two or three years now?
However that path is showing some creakiness. I'm still running gdm-2.20.11-r1, for instance. I've been running gdm for many years, and it was convenient to freeze it at the pre-systemd version. I'm not sure if it's getting creakier or if I'm just noticing it more, but feels as if it's misbehaving more often - failing to do a shutdown when requested, primarily. I see more programs "adopting systemd", even where we would both argue that an ordinary user program shouldn't care what init system it's running under - but it does.
I have some fear of being painted into a corner, avoiding systemd. In addition to giving others a "return from insanity" path I see shims as a way to be less constrained, myself. |
why not use lightdm or even slim
_________________
| Quote: | | Removed by Chiitoo |
|
|
| Back to top |
|
|
depontius
Advocate
Joined: 05 May 2004
Posts: 3509
|
| Posted: Mon Feb 01, 2016 5:58 pm Post subject: |
|
|
| Naib wrote: | | depontius wrote: | I'll simply say that as systemd has taken over more of the Linux ecosystem it's been possible to say, "I just won't run xxx program that needs systemd," or "I'll stick with the back-level version that doesn't need system." I've been running that way, for is it two or three years now?
However that path is showing some creakiness. I'm still running gdm-2.20.11-r1, for instance. I've been running gdm for many years, and it was convenient to freeze it at the pre-systemd version. I'm not sure if it's getting creakier or if I'm just noticing it more, but feels as if it's misbehaving more often - failing to do a shutdown when requested, primarily. I see more programs "adopting systemd", even where we would both argue that an ordinary user program shouldn't care what init system it's running under - but it does.
I have some fear of being painted into a corner, avoiding systemd. In addition to giving others a "return from insanity" path I see shims as a way to be less constrained, myself. |
why not use lightdm or even slim |
I'm looking. A few years back I looked into this and ended up doing nothing. At the time my requirements were:
1 - Ability to shutdown/reboot from login screen. (xdm lacks this)
2 - Remote X - surprisingly, at least some of those alternatives are set up for local-only X.
3 - Autologin, to simplify life for my wife.
4 - xdcmp - This was the big limiter, and for the few that had it, one of the others above was lacking it, which kept me with gdm
Since then I've dropped xdcmp, but I haven't re-located the feature comparison link that I'd used a few years ago. I looked a bit this weekend, but other things were more pressing.
Still, for my original point, the login manager is just one aspect of the platform consolidation around systemd. There are many other components doing so also, even though as has been stated before, they should be init system agnostic.
_________________
.sigs waste space and bandwidth |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Tue Feb 02, 2016 5:02 pm Post subject: |
|
|
@depontius: A replacement ABI is a shim. But first it needs to specified and hammered-out so it is as simple as it can be, and as complex as it must.
We're both quite happy to help out on such things, but it takes more than just a couple of coders (or one coder and a scripter) fixing up the backend of whatever module so it's no longer insane.
Before any implementation can happen, we need a clear spec of exactly what it is you want implemented.
(That doesn't mean a long document, btw.)
And no: "the same ABI as loginkitd", or whatever other god-awful hell-"design" from the systemdiots is not saying it.
In the main, I haven't seen anything that would interest the average desktop application; only stuff that might possibly be of use if you were implementing a DE, or some other sysadmin-level tool.
And in each of those cases, it looks more like a gaping attack-vector than anything else, opening up root-level tasks to just about any process, since any of them can write to the dbust, and oh look, udev rules set everything to world-writeable.
No, my text editor does not need to know about network filesystems, nor about how to shutdown the machine; and neither does virtually everything else running. An error return code from read(), though more likely fgets(), or whatever else, is enough, should an error happen with the underlying FS.
Before we tread forward, we should be checking the X Protocol, and xclib, and the IDL bindings, to make sure we're not simply replicating a much-better designed wheel. (For instance in terms of telling the X server not to blank/suspend the display, or replicating its own, pre-extant, inter-app protocol.)
That's presuming we're actually doing the spec side, and associated research.
XDMCP is definitely something we want to keep going. |
|
| Back to top |
|
|
CasperVector
Apprentice
Joined: 03 Apr 2012
Posts: 156
|
| Posted: Fri Mar 16, 2018 2:57 am Post subject: |
|
|
FYI, I just noticed this... (I know it has existed for some time, but the git repo seems to be online not until recently.)
_________________
My current OpenPGP key:
RSA4096/0x227E8CAAB7AA186C (expires: 2020.10.19)
7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C |
|
| 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
