| View previous topic :: View next topic |
| Author |
Message |
depontius
Advocate
Joined: 05 May 2004
Posts: 3522
|
 Posted: Mon Dec 01, 2014 9:08 pm Post subject: |
 |
|
| saellaven wrote: |
They are winning because you just concede the ground to them.
OpenRC already IS the better alternative.
If you want to play their game with shims, be prepared to be known for shoddy, buggy software, meaning you won't have the credibility to replace them because you'll always be second best. If the other mainline distributions want to drive over a cliff, you aren't obligated to follow and if you just want to follow, why not use one of the soon-to-be RH clone distros like debian?
|
I believe they're "winning" because the Linux ecosystem has been flooded with former Windows developers and users, bringing their Windows sensibilities with them. The old-time Linux developer and user base is so small that you don't need that many people coming from Windows to become the new majority. As part of that, these new people are also early adopters, notoriously prone to be fanbois.
I also believe "winning" may be largely a misnomer, because it has occurred in noise-space - AKA forums and such. I had previously felt that most of the backlash wouldn't start until systemd hit the real world - or the real world hit systemd, which might be a more appropriate way of putting it. But something new has happened as we watch kdbus try to get into the kernel. First feedback looked more like implementation issues, but as it goes, it gets more architectural. We've also now seen the Debian fork.
I suspect what is really happening is that the "silent majority" of the Linux userbase is awakening - the ones who just want to user their computers, want them to work reliably, have already reject Windows, and don't go on a forum until they have a problem.
As for shims, the unfortunately reality is that systemd has hijacked a lot of developement. I'm happy enough to write off GNOME, and call it software suicide. I don't use KDE, but I'd rather not see them sail off on the same ship. Originally there were many things I didn't like about Wayland, but I've mellowed my opinion. I'd like to not see the whole development ship sail off into systemd-land without a way back, once they get a dose of sanity. The purpose shims is two-fold. Most important, it gives those projects a way back, away from systemd. More conveniently, it lets us say modern where appropriate or desirable, instead of degenerating into codger-space.
I have a similar story. I used to use Wirth-family languages, which have pretty much withered away. Once upon a time I was on the Oberon2 newsgroup, asking how I could manipulate legacy binary data with Oberon2. I've done so fairly extensively with both Pascal and Modula2, both extended versions. The response on the Oberon2 newsgroup was that I should forget legacy binary data, and get everyone on my projects to migrate to Oberon2, then the problem would go away. With that response, I went away, and so did Oberon2.
When in a minority situation, there is always a need to work with the majority, if only to maintain one's own way of working. If systemd becomes the disaster we all think it will, we need to help people get back.
_________________
.sigs waste space and bandwidth |
|
| Back to top |
|
 |
saellaven
l33t
Joined: 23 Jul 2006
Posts: 654
|
| Posted: Mon Dec 01, 2014 9:43 pm Post subject: |
|
|
| truekaiser wrote: | | saellaven wrote: |
They are winning because you just concede the ground to them.
OpenRC already IS the better alternative.
If you want to play their game with shims, be prepared to be known for shoddy, buggy software, meaning you won't have the credibility to replace them because you'll always be second best. If the other mainline distributions want to drive over a cliff, you aren't obligated to follow and if you just want to follow, why not use one of the soon-to-be RH clone distros like debian?
|
They seem to have gotten this far without people using shims. And windows has not gained from the loss of linux from the shim / emulator that is wine. |
WINE will never have parity with Windows... just a simple fact as Windows is always a moving target. systemd is the same situation.
| Quote: |
I also agree open-rc is a better alternative, but i can't deny the fact that the LP idiots are winning. If we are going to at least survive this split between linus-linux and LP-linux we must adapt.
Shim's will be temporary stepping stones to allow us to come out with a better system without making it easy for the LP crew to demonize us to their customers for being too 'old' |
Temporary shims will become permanent shims if we cede the ground to them... and I have no doubt that many of these shims will become tomorrow's security nightmares.
| Quote: |
| Quote: |
Pretty much already exists... I've been using Linux since 1994 and the only thing I ever needed special permissions for was mounting (and that is easily fixed too), just simply add users to the appropriate groups (like audio) automatically/by default on account creation. For systems more complex than grandma at home, which is fine with grandma in the audio group, someone SHOULD know what they are doing or else there is going to be a lot of available attack surface exposed.
|
Like what? Edev? few distributions offer it and even GENTOO doesn't push it as default and THEY are the ones that made it. Even then it is based off an older version of udev that still has some critical bugs that were fixed in later versions. Those later versions are not yet hard coded to need systemD so there is no need to use it.
To be clear once udev does get hard code linked i will be switching to eudev. This flexibility is why i stay with gentoo. |
Most of it can be done by simply letting the console user have access to everything... grandma isn't likely to be sshing into her box and someone that is NEEDS to know what they are doing.
| Quote: |
And what about fast user switching? Accessibility? All i have seen are hacks that require technical knowledge past the targeted user-base. While in contrast those poorly made and non documented *kits seem to work 'automaticly' with the big desktops from an end user perspective. |
Does grandma need fast user switching? What's wrong with the existing system of logout/switch user? When did GUI accessibility suddenly require an init system given it's already been available for nearly 20 years? Again, you're ceding the ground that their ideas are right.
| Quote: |
You can't just declare 'that program has no 'real' use and is poorly made' without providing an alternative that fulfills those metrics with the same ease of use. That includes cases in which you are right! Which is the case with the *kit's software and all of LP's work while he runs them. |
and again, you're trying to back-justify what they want using their logic... it's a solution in search of a problem.
| Quote: |
| Quote: |
| Quote: |
A non professional level audio mixing system other than Pulseaudio to handle muxing and per application volumes. IE something other than jack. |
ALSA does mixing natively and there have been plenty of audio demons (esd, arts, etc) in the past that have done it too. It wouldn't be too terribly hard to create a library or demon for handling per application volume adjustments. |
esd is dead
arts has been dead for several years.
While i agree alsa does a great job of mixing on it's own, for the majority of users that involves knowing alsa specific syntax and editing text files. Sadly well beyond the target user base in which Pulseaudio as sadly taken dominance.
Oh and if you want to support Steam in bringing games to linux you pretty much have to run pulse-audio. |
and yet, I use steam without pulse or systemd without any problems...
I used esd and arts as examples of the fact that this functionality has existed for long before LP decided to start mucking up the system... lets not pretend he's some revolutionary here to fix things. He's a hack at best, he just happened to get hired at a place where he gets to force his vision onto the world.
Last edited by saellaven on Mon Dec 01, 2014 9:50 pm; edited 1 time in total |
|
| Back to top |
|
|
saellaven
l33t
Joined: 23 Jul 2006
Posts: 654
|
| Posted: Mon Dec 01, 2014 9:49 pm Post subject: |
|
|
| depontius wrote: |
I believe they're "winning" because the Linux ecosystem has been flooded with former Windows developers and users, bringing their Windows sensibilities with them. The old-time Linux developer and user base is so small that you don't need that many people coming from Windows to become the new majority. As part of that, these new people are also early adopters, notoriously prone to be fanbois. |
They are "winning" because they're operating out of the largest single player in the Linux development ecosystem... RedHat. If they didn't have RH's backing, nobody would take them seriously... and it's through RH's upstream ownership of other projects like GNOME that they are forcing people to acquiesce.
| Quote: |
I suspect what is really happening is that the "silent majority" of the Linux userbase is awakening - the ones who just want to user their computers, want them to work reliably, have already reject Windows, and don't go on a forum until they have a problem. |
I again reiterate my story that I didn't care one whit about systemd until WilliamH abused his power to intentionally cripple the systems of people NOT using systemd because of systemd's shortsighted and arrogant self-imposed technical limitations. Break your system all you want and I don't care, but break my system and I have a problem.
| Quote: |
As for shims, the unfortunately reality is that systemd has hijacked a lot of developement. I'm happy enough to write off GNOME, and call it software suicide. I don't use KDE, but I'd rather not see them sail off on the same ship. Originally there were many things I didn't like about Wayland, but I've mellowed my opinion. I'd like to not see the whole development ship sail off into systemd-land without a way back, once they get a dose of sanity. The purpose shims is two-fold. Most important, it gives those projects a way back, away from systemd. More conveniently, it lets us say modern where appropriate or desirable, instead of degenerating into codger-space. |
So, we'll compromise what actually works in the hopes that people will come back to what works when they irrevocably bork things... only to find that the shims and everything else are completely borked themselves, leaving us a giant pile of rubbish. I'd rather abandon evolutionary paths that don't work out.
| Quote: |
When in a minority situation, there is always a need to work with the majority, if only to maintain one's own way of working. If systemd becomes the disaster we all think it will, we need to help people get back. |
then why ever develop Linux in the first place? If the goal isn't to make the best software, but to kludge things up to emulate the worst software, why bother at all? |
|
| Back to top |
|
|
truekaiser
l33t
Joined: 05 Mar 2004
Posts: 804
|
| Posted: Mon Dec 01, 2014 10:21 pm Post subject: |
|
|
| saellaven wrote: |
and yet, I use steam without pulse or systemd without any problems...
|
And i think i can dismiss you right here.
While steam has no hard coded links to SystemD or pulse. Without the pulseaudio application or it's shim you will get no sound in any of the games. They are coded to either use pulse directly or only to use sdl's pulse output.
Sound is a critical component when playing video games so you are either using a shim or the application itself. You have stated you do not like shims but not that you were using one.
I on the other did state i have to use pulse(because i like sound in my games) even though i hate using it.
Because i was forced to use it i realized that despite how crap the code is, it provides something that nothing else does.
Those previous sound servers never worked out of the box, each app had to be set up to use it.
Alsa's dmix works but you have to edit text config files and know where to place them before that happens.
Pulseaudio worked, right out of the box, to use that phrase. And it has continued to work, despite a few hiccups on fringe applications, rather well despite how badly coded it is.
Do i want a better coded alternative? Yes, but it also has to be drop in compatible.
You think it's faulty logic to say to not use something without providing an alternative you can use? I realize it's as dumb as going up to someone and doing.
"hey don't use windows, it's crap software. written poorly and a security nightmare!"
They are going to ask what would you suggest, and if you have nothing then they will dismiss you. |
|
| Back to top |
|
|
saellaven
l33t
Joined: 23 Jul 2006
Posts: 654
|
| Posted: Mon Dec 01, 2014 10:44 pm Post subject: |
|
|
| truekaiser wrote: | | saellaven wrote: |
and yet, I use steam without pulse or systemd without any problems...
|
And i think i can dismiss you right here.
While steam has no hard coded links to SystemD or pulse. Without the pulseaudio application or it's shim you will get no sound in any of the games. They are coded to either use pulse directly or only to use sdl's pulse output.
Sound is a critical component when playing video games so you are either using a shim or the application itself. You have stated you do not like shims but not that you were using one.
I on the other did state i have to use pulse(because i like sound in my games) even though i hate using it. |
Pulse is masked on my system (and I have a USE=-pulseadudio plus apulse is not installed) and yet I get sound in every game I've played on steam. I'd like to see you substantiate this claim that I'm using pulseaudio...
Because i was forced to use it i realized that despite how crap the code is, it provides something that nothing else does.
| Quote: |
Those previous sound servers never worked out of the box, each app had to be set up to use it. |
each app had to be set up to use it just like each app has to be set up to use pulse... OR they could just work off the base sound system's mixer as has been available for more than a decade.
| Quote: |
Alsa's dmix works but you have to edit text config files and know where to place them before that happens. |
yet mine worked without any editing...
| Quote: |
Pulseaudio worked, right out of the box, to use that phrase. And it has continued to work, despite a few hiccups on fringe applications, rather well despite how badly coded it is. |
that despite the thousands of complaints about pulseaudio being broken out of the box and only recently becoming better if you don't count stuttering and other problems it causes... oh, and all pulseaudio really is, is a front end right back to ALSA... it, itself, is a crappy shim... you know, the very thing you're advocating more of.
| Quote: |
Do i want a better coded alternative? Yes, but it also has to be drop in compatible.
You think it's faulty logic to say to not use something without providing an alternative you can use? I realize it's as dumb as going up to someone and doing. |
The alternatives already exist... stop buying into the propaganda
| Quote: |
"hey don't use windows, it's crap software. written poorly and a security nightmare!"
They are going to ask what would you suggest, and if you have nothing then they will dismiss you. |
at one point, I could suggest Linux... Linux with systemd is going to make Windows look secure. Mark my words. |
|
| Back to top |
|
|
KuroNeko
n00b
Joined: 08 Oct 2014
Posts: 23
|
| Posted: Mon Dec 01, 2014 11:52 pm Post subject: |
|
|
I don't like programs, that work without configuration. That's not the same, as if the software works out of the box.
If it brings a configuration file, that works out of the box, that is ok. But if for whatever reason my system is missing a configuration file, I don't want that program to stamp over my whole system! I have a reason to provide my configuration and without stating my preferences, how should my system know about it?
Autoexing my USB sticks, when I plug them in? Oh, boy, we had that already!
Let the user change the network? Fine by me, as long as it isn't a machine, I want to have accessible from the internet all the time!
Distributions do a fine job of preconfiguring things, and if the resulting system doesn't work for you, you can always switch or build your own.
But it is not feasible to code the whole userspace yourself, because every program does only one thing, but does it wrong (in your opinion).
That's excatly, what some systemd followers get wrong.
Even if systemd does one thing and does it right, it can be wrong on my system. Adding one case after another will never work in every case. Providing easy configuration on the other side, can make that possible, altough it is harder on some users. (But that's, why we have distros)
Also it is amazing, how well some things work, that are told to be the worst piece of software and are in dire need of a replacement.
ALSA, X11, sysvinit (with custom rcs), you name it. They all mostly work, but some edge cases (audio over bluetooth, badly coded deamons die, when you try hard enough, without you noticing) aren't that nice. So you just replace it with a completly different software, that handles everything, but breaks your setup, because you do nothing or don't want to use it, as you don't need it.
I didn't try it, but dcop sounds awesome, for how it was. Script your desktop? Yes please!
I could even understand, that you would like to push some commands to a terminal (konsole) or to a text editor like kate, so they user can look over it, and decide what to do. That would be awesome for learning and customizing!
Could you do that with dcop? I found a few examples, where it had been done, but I didn't use KDE at that time, sadly...
Can you do that with dbus? Maybe? I have a hard time figuring out, how to handle dbus on the commandline. Where is KDCOP or whatever you would call it, and why isn't it actively promoted?
But why would I need extra low latency and high bandwith? Even if I have thousand apps open at the same time, that shouldn't be an issue!
And if I use a container? Well that could be an issue, but I have no need for it myself. I think I can trust my software, that I either compiled myself or get from a repo. If I can't, I have a much bigger issue...
And on servers, why not use TIPC? That sounds like a sound solution!
Sorry for the rant, but I don't need software, that thinks it is smarter than me, because maybe it's right, but it will never teach me and that's just unfair! 
Neko |
|
| Back to top |
|
|
Anon-E-moose
Watchman
Joined: 23 May 2008
Posts: 6148
Location: Dallas area
|
| Posted: Tue Dec 02, 2014 12:48 pm Post subject: |
|
|
Interesting commentary from Richard Yao again http://lkml.iu.edu/hypermail/linux/kernel/1412.0/01208.html
| Quote: | I had hoped that I could avoid reading through the code for yet another
IPC mechanism when I asked why we needed kdbus at LinuxCon Europe. In
hindsight, I should have just checked out the code and read it instead
of asking. However, what I did instead was ask and then do some thinking
based on that, mean to send an email and then sent it long after I
should have.
Our conversation now has lead me to realize my mistake and I have tried
to rectify it. I now see that kdbus is hooking into kernel interface to
implement KDBUS_ITEM_PAYLOAD_MEMFD in a way that we could only achieve
from userspace with UNIX domain sockets. I imagine that we could avoid
putting this code into the kernel through a combination of libev,
libfuse, memfds and UNIX domain sockets. |
| Quote: | That said, it is still not clear to me that dbus must be inside the
kernel to be able to perform multicast and zero copy using memfd. Is
there something that I have missed that make this not the case? |
Seems there are a few kernel devs that just aren't sold on the whole
dbus in the kernel is necessary brouhaha.
This is from a previous post in this thread.
| Quote: | >> P.S. I also mentioned my concern that having the shim in the systemd repository
>> would have a negative effect on distributons that use alterntaive libc libraries
>> because the systemd developers refuse to support alternative libc libraries. I
>> mentioned this to one of the people to whom Greg introduced me (and whose name
>> escapes me) as we were walking to Michael Kerrisk's talk on API design. I was
>> told quite plainly that such distributions are not worth consideration. If kdbus
>> is merged despite concerns about security and backward compatibility, could we
>> at least have the shim moved to libc netural place, like Linus' tree?
>
> Take that up on the systemd mailing list, it's not a kernel issue.
It became a kernel issue the moment that you proposed a kernel API with
corresponding library code in the systemd repository. Not that long ago,
the firmware loading code was moved into the kernel because there were
problems with systemd's stewardship over that mechanism in udev. Giving
the systemd developers the responsibility of maintaining the only
library for a proprosed kernel API so soon afterward seems unwise to me. |
and a previous post
| Quote: | >> told quite plainly that such distributions are not worth consideration. If kdbus
>> is merged despite concerns about security and backward compatibility, could we
>> at least have the shim moved to libc netural place, like Linus' tree?
>
> I would expect any other libc would fork the shim anyway (or just not
> bother with systemd in most cases).
If the shim were in glibc, then that would be reasonable, but the shim
is in systemd. That would make the systemd developers the gate keepers
ta kernel interface. If we are going to enforce Linus' stable API
policy, then the shim should be in a repository that has a track record
for interface stability, which the systemd developers simply do not
have. |
I'm thinking that what I bolded is what the sysd/dbus/kdbus cabal really wants.
_________________
UM780, 6.1 zen kernel, gcc 13, profile 17.0 (custom bare multilib), openrc, wayland |
|
| Back to top |
|
|
depontius
Advocate
Joined: 05 May 2004
Posts: 3522
|
| Posted: Tue Dec 02, 2014 1:59 pm Post subject: |
|
|
I found this thread on this morning's LKML scan - the whole thing was good reading. What I like is that now serious architecture as well as implementation questions are being asked by kernel devs - people of much greater weight than forum-watchers.
_________________
.sigs waste space and bandwidth |
|
| Back to top |
|
|
Anon-E-moose
Watchman
Joined: 23 May 2008
Posts: 6148
Location: Dallas area
|
| Posted: Tue Dec 02, 2014 2:11 pm Post subject: |
|
|
| depontius wrote: |
I found this thread on this morning's LKML scan - the whole thing was good reading. What I like is that now serious architecture as well as implementation questions are being asked by kernel devs - people of much greater weight than forum-watchers. |
Especially since many times the answers by kdbus devs to questions by kernel devs has been "quick put it in the kernel, we'll worry about implementation and fixing it later"
_________________
UM780, 6.1 zen kernel, gcc 13, profile 17.0 (custom bare multilib), openrc, wayland |
|
| Back to top |
|
|
depontius
Advocate
Joined: 05 May 2004
Posts: 3522
|
| Posted: Tue Dec 02, 2014 3:09 pm Post subject: |
|
|
| Anon-E-moose wrote: | | depontius wrote: |
I found this thread on this morning's LKML scan - the whole thing was good reading. What I like is that now serious architecture as well as implementation questions are being asked by kernel devs - people of much greater weight than forum-watchers. |
Especially since many times the answers by kdbus devs to questions by kernel devs has been "quick put it in the kernel, we'll worry about implementation and fixing it later" |
It's also good to see that while that answer is good enough for Phoronix, it's not good enough for kernel devs.
_________________
.sigs waste space and bandwidth |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Tue Dec 02, 2014 4:21 pm Post subject: |
|
|
| saellaven wrote: | Again, if you're going to advocate shims, then what you're saying is that systemd is doing the right things, just is implemented wrong... the implementation sucks but the design (or lack thereof) is totally wrong as well. Further, don't be surprised when they become totally hostile to your shims because their intent is to break as much as possible so you have to use their unified CoreOS to get things to work.
Anyone remember how long it took for WINE to become usable on a majority of applications? Anyone want to go count how many apps still don't work right with WINE at all? That is what shims would replicate, only it would be native software that is either outright broken or broken in subtle ways and always subject to playing catchup, only for something else to be intentionally broken again after that. |
| truekaiser wrote: | | Wrong or not, the fact remains they are winning. Which means OUR tactics must change. |
No it does not. They're fighting a propaganda campaign: by all means take them on in that arena if you want.
That does not change any of the technical facts. And I'd point out that on that front, you've completely ignored the issue of how many human hours would be wasted on what saellaven described above: playing catch-up with a sh1tty design none of us wants to code on, because it is so braindead, against a hostile upstream which much like M$ will be doing everything it can to break interoperability.
Those decisions will be propagandised as "looking after the user" when we all know the intent is the opposite: to dumb us down and feed us crap "entertainment" we have to pay for, despite the fact that we as a Community designed, coded, debugged and continue to maintain the underlying software infrastructure.
It's exactly the same battle as in the 80s and 90s, it's just changed venue.
| Quote: | | Using a shim allows us to be on a equal playing field WHILE we develop a better alternative. |
No it doesn't: it cripples us before we've even begun our generation's contribution to the collective commons.
| Quote: | | An updated Init system that learns from the past and leverages it rather than saying 'it's old so it's broken so lets completely throw it out' like systemD (openrc fits this imho) |
So that's done, and can only improve over time, providing we keep our wits about us.
| Quote: | | An alternative to *kits so users who are not interested in becoming developers can have stuff automagically work. I'm fine with having to manually mount stuff, I don't want to have to try to teach my mother how to use a console to mount that usb drive of hers for it's pictures.(to use a simple example.) |
Yeah this has all been done, for many of us already. Unless you were expecting your mother to handle a Gentoo install?
| Quote: | | A non professional level audio mixing system other than Pulseaudio to handle muxing and per application volumes. IE something other than jack. |
Nah, sorry. You will never convince me that we should base the next-gen desktop on anything other than jack for audio.
The only reason pro-audio programmers haven't addressed the "let me wander around with my bluetooth headset and automagically hear whatever is playing on the nearest device" use-case is that pro-audio users typically have zero interest in that.
They were happy to work on it with Poeterring, but he simply showed no inclination to listen to a bloody word, and his whole approach was woefully amateur from the beginning. You can't take someone like that seriously.
He got a knockback from pro-audio, same as he got a knockback from kernel folks when he first tried to be a kernel-dev.
edit: link to example of "braindead" design.
Last edited by steveL on Tue Dec 02, 2014 6:34 pm; edited 1 time in total |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Tue Dec 02, 2014 5:17 pm Post subject: |
|
|
| KuroNeko wrote: | I didn't try it, but dcop sounds awesome, for how it was. Script your desktop? Yes please!
I could even understand, that you would like to push some commands to a terminal (konsole) or to a text editor like kate, so they user can look over it, and decide what to do. That would be awesome for learning and customizing!
Could you do that with dcop? I found a few examples, where it had been done, but I didn't use KDE at that time, sadly...
Can you do that with dbus? Maybe? I have a hard time figuring out, how to handle dbus on the commandline. Where is KDCOP or whatever you would call it, and why isn't it actively promoted? |
When 4.x was being conceived, everyone wanted to collaborate across-desktops. So KDE agreed to use dbus, and forget about dcop.
It's a shame really, as dcop had been in-place since KDE-2 (if you know KDE, two series is a long time) and was much nicer.
For instance you had kommander which enabled quick and efficient scripting, which was a step up from kaptain (Qt based) to make nice user-interfaces.
Thanks for querying this; I had a bookmark for kaptain, but had deleted stuff about kommander. As you'll see the docs for the latter are rather threadbare (no tutorial examples.) The ALSA MIDI Kommander (which I just found) is a nice use-case.
So officially it's "dead" technology, and no doubt sneered at by dbus-fanbois. But it was so much more useful; as the last url shows, people actually used it to "applify" their desktop under their own control. I've not seen anything like the same sort of end-user adoption with dbus.
It rocked, and I was sorely disappointed when nothing similar appeared on 4.x, as I'd only discovered kommander during 3.5.x (which was a sweet spot, much like 4.10 without semantic-craptop.)
| Quote: | | But why would I need extra low latency and high bandwith? Even if I have thousand apps open at the same time, that shouldn't be an issue! |
Because nub-skool "designers" think it's a good idea to shove megablobs of data around the wrong bus. They're trying to enforce One True IPC so no-one will notice that LGPL-GPL combination in so many "dbus-only" 'services'.
| Quote: | | And on servers, why not use TIPC? That sounds like a sound solution! |
Well, why not use it everywhere, assuming you actually need pub/sub semantics.
Going back to TIPC, I missed out the description of sub-addressing earlier:
| Ying Xue wrote: | The basic unit of functional addressing within TIPC is the port name, which is typically denoted as {type,instance}. A port name consists of a 32-bit type field and a 32-bit instance field, both of which are chosen by the application.
Often, the type field indicates the class of service provided by the port, while the instance field can be used as a sub-class indicator. Further support for service partitioning is provided by an address type called port name sequence.
This is a three-integer structure defining a range of port names, i.e., a name type plus the lower and upper boundary of the instance range. This addressing schema is very useful for multicast communication.
For instance, as you mentioned, D-Bus may need two different buses, one for system, another for user. In this case, when using TIPC, it's very easy to meet the requirement:
We can assign one name type to system bus, and another name type is to user bus. Under one bus, we also can divide it into many different sub-buses with lower and upper.
For example, once one application publishes one service/port name like {1000, 0, 1000} as system bus channel, any application can send messages to {1000, 0, 100} simultaneously.
One application can publish {1000, 0, 500} as sub-bus of the system bus, another can publish {1000, 501, 1000} as another system sub-bus.
If a process sends a message to port: {1000, 0, 1000}, it means the two applications including published {1000, 0, 500} and {1000, 501, 1000} both receive the message. |
So I guess you would want to provide a minimal lib that does the client side, along with a daemon ORB (assuming it were in fact necessary to optimise userland dcop.)
| Quote: | | If you use this schema, a central daemon is not necessary. Any application can directly talk to any other: one-to-one, one-to-many, and many-to-many. |
|
|
| Back to top |
|
|
KuroNeko
n00b
Joined: 08 Oct 2014
Posts: 23
|
| Posted: Wed Dec 03, 2014 1:24 am Post subject: |
|
|
Thanks for the links, SteveL!
That's sounds a lot, like some things, that I feel, are missing on my desktop sometimes.
Quickly hacking together a gui for a command line application or connecting a few application in e.g. krunner. Why isn't that possible on dbus? 
Also a question: Letting every application spawn their own bus/IPC interface/whatever sounds good (if there are simple to use libs), but how would you know, if you're really talking to the program, you think, you are talking to?
Maybe you could solve that with a setgid bit? Then every trusted application would run in the message group, or similiar.
Scanning for available services would be a simple lookup of all applications running as the current user and in the message group.
A central daemon really isn't needed there anymore.
I hope, I'm not missing something... |
|
| Back to top |
|
|
Anon-E-moose
Watchman
Joined: 23 May 2008
Posts: 6148
Location: Dallas area
|
| Posted: Wed Dec 03, 2014 10:55 am Post subject: |
|
|
| Quote: | Allow me to be more specific:
> - performance: fewer process context switches, fewer copies, fewer
> syscalls, larger memory chunks via memfd. This is really important
> for a whole class of userspace programs that are ported from other
> operating systems that are run on tiny ARM systems that rely on
> hundreds of thousands of messages passed at boot time, and at
> "critical" times in their user interaction loops.
What are some examples of these programs? Are any of them examples of
good software design? |
They need kdbus because they expect "hundreds of thousands of messages passed at boot time"
That's fricking insane, along with a hellaciously exaggerated lie I would hope.
If they're going to push stupid arguments like the above then I would hope that kdbus never gets into the kernel.
Good question from R Yao though, "Are any of them examples of good software design"
We know that anything connected with the LP cabal doesn't have a clue about software design good or bad.
http://lkml.iu.edu/hypermail/linux/kernel/1412.0/02144.html
| Quote: | > - being in the kernle closes a lot of races which can't be fixed with
> the current userspace solutions. For example, with kdbus, there is a
> way a client can disconnect from a bus, but do so only if no further
> messages present in its queue, which is crucial for implementing
> race-free "exit-on-idle" services
Is the current dbus daemon not supporting this this only thing
preventing us from doing it in userspace? |
I'm at a loss as to how kdbus would improve on dbus in this supposed race generating condition.
I bet that Richard will pretty much say the same thing.
| Quote: | > Of course, some of the bits above could be implemented in userspace
> alone, for example with more sophisticated memory management APIs, but
> this is usually done by losing out on the other details. For example,
> for many of the memory management APIs, it's hard to not require the
> communicating peers to fully trust each other. And we _really_ don't
> want peers to have to trust each other.
Does being in the kernel solve this in a way that using memfds in
userspace does not? |
Again, lets take code that supposedly would need clients to trust each other in a dbus implementation
and let them not trust each other in kdbus. WTF?
| Quote: | > Another benefit of having this in the kernel, rather than as a userspace
> daemon, is that you can now easily use the bus from the initrd, or up to
> the very end when the system shuts down. On current userspace D-Bus,
> this is not really possible, as this requires passing the bus instance
> around between initrd and the "real" system. Such a transition of all
> fds also requires keeping full state of what has already been read from
> the connection fds. kdbus makes this much simpler, as we can change the
> ownership of the bus, just by passing one fd over from one part to the
> other.
Why do we want to start D-Bus inside the initramfs? |
A darned good question.
WHY does one need dbus to start in an initramfs, BEFORE THE USER CAN EVEN LOG IN and any user programs are started?
If this is the best justification that people like GKH and the LP cabal can come up with then we really don't need kdbus.
They need to go back and design dbus and do it right.
_________________
UM780, 6.1 zen kernel, gcc 13, profile 17.0 (custom bare multilib), openrc, wayland |
|
| Back to top |
|
|
depontius
Advocate
Joined: 05 May 2004
Posts: 3522
|
| Posted: Wed Dec 03, 2014 1:26 pm Post subject: |
|
|
| Anon-E-moose wrote: |
| Quote: | > Another benefit of having this in the kernel, rather than as a userspace
> daemon, is that you can now easily use the bus from the initrd, or up to
> the very end when the system shuts down. On current userspace D-Bus,
> this is not really possible, as this requires passing the bus instance
> around between initrd and the "real" system. Such a transition of all
> fds also requires keeping full state of what has already been read from
> the connection fds. kdbus makes this much simpler, as we can change the
> ownership of the bus, just by passing one fd over from one part to the
> other.
Why do we want to start D-Bus inside the initramfs? |
A darned good question.
WHY does one need dbus to start in an initramfs, BEFORE THE USER CAN EVEN LOG IN and any user programs are started?
If this is the best justification that people like GKH and the LP cabal can come up with then we really don't need kdbus.
They need to go back and design dbus and do it right. |
Come on, you know the answer to that. They've even as much as said that they want to completely wrap the kernel. I believe the words were, "systemd writes to the kernel, and everyone else writes to systemd". Getting into the initrd is simply another step upstream, and readily goes along with getting kdbus into the kernel.
Here's the interesting question... At what point will they pursue getting the userspace dbus daemon into the initrd? I suspect that right now all efforts are at getting into the kernel, and they won't easily accept defeat. But clearly getting anything into the initrd would have been another "logical" step for them.
Now for a funny conspiracy theory...
I suspect that pretty much everyone here is comfortable on the command line. I know I pretty much use my GUI as a way to push xterms around and manage my display space,as well as run GUI apps, which I'll admit that I prefer. (I don't use a tiling WM because I like to use window overlap to my advantage.)
Let's pretend that "the crowd" moving from Windows to Linux have a deep-seated inferiority complex, because they're not comfortable with the command line. Perhaps this is the reason they push dbus so hard - it's an attempt to render the command line obsolete. Take those old-school greybeard "experts" and turn them into dinosaurs.
But you know, what's a command line, what's a shell? It's basically the simplest way to take user input and translate it into a command to the computer. With dbus it's simply a different way of specifying command and parameters, and I might add that the parameters are certainly more verbose, so I'd hate to type all of that crap in on any command line. But let's say someone came out with a bunch of executables that did nothing with a command line, perhaps exited with a "Meant to be called using dbus!" error message. It would be no big problem to build a "dbus command wrapper" that would take its command line and turn it into dbus messages. Take the generic wrapper and symlink it to specific command names, rather like busybox does. At the simplest level, it would need a configuration file to tell it how to build dbus messages for each type of command line. Perhaps more complex, but more general, I believe the "introspection" capability could be used to do that stuff automagically, with a truly generic wrapper. At that point we're most of the way to a "dbus shell" - perhaps it could be tacked into .bashrc or something like that, and then our systems run the way we like again, even after the dbus crowd has its way.
_________________
.sigs waste space and bandwidth |
|
| Back to top |
|
|
Anon-E-moose
Watchman
Joined: 23 May 2008
Posts: 6148
Location: Dallas area
|
| Posted: Wed Dec 03, 2014 1:31 pm Post subject: |
|
|
Even though I use windows (occasionally) I still have a cmd (dos shell) icon on the desktop for ease of use. 
_________________
UM780, 6.1 zen kernel, gcc 13, profile 17.0 (custom bare multilib), openrc, wayland |
|
| Back to top |
|
|
Naib
Watchman
Joined: 21 May 2004
Posts: 6065
Location: Removed by Neddy
|
| Posted: Wed Dec 03, 2014 1:57 pm Post subject: |
|
|
| Anon-E-moose wrote: | | Even though I use windows (occasionally) I still have a cmd (dos shell) icon on the desktop for ease of use. |
at least install msysgit to get UNIX coreutils & sh/bash
_________________
| Quote: | | Removed by Chiitoo |
|
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Wed Dec 03, 2014 3:27 pm Post subject: |
|
|
| depontius wrote: | | But you know, what's a command line, what's a shell? It's basically the simplest way to take user input and translate it into a command to the computer. With dbus it's simply a different way of specifying command and parameters, and I might add that the parameters are certainly more verbose, so I'd hate to type all of that crap in on any command line. But let's say someone came out with a bunch of executables that did nothing with a command line, perhaps exited with a "Meant to be called using dbus!" error message. It would be no big problem to build a "dbus command wrapper" that would take its command line and turn it into dbus messages. Take the generic wrapper and symlink it to specific command names, rather like busybox does. At the simplest level, it would need a configuration file to tell it how to build dbus messages for each type of command line. Perhaps more complex, but more general, I believe the "introspection" capability could be used to do that stuff automagically, with a truly generic wrapper. At that point we're most of the way to a "dbus shell" - perhaps it could be tacked into .bashrc or something like that, and then our systems run the way we like again, even after the dbus crowd has its way. |
Ugh that is horrible. You really need to let go of the idea that we can "all just get along."
You cannot "get along" with someone who is trying to intimidate and control you. You can submit, fight or walk away.
I choose to walk away, as it's less noise and less wasted time. The latter is more and more important to me, the older I get. |
|
| Back to top |
|
|
depontius
Advocate
Joined: 05 May 2004
Posts: 3522
|
| Posted: Wed Dec 03, 2014 3:43 pm Post subject: |
|
|
| steveL wrote: | | depontius wrote: | | But you know, what's a command line, what's a shell? It's basically the simplest way to take user input and translate it into a command to the computer. With dbus it's simply a different way of specifying command and parameters, and I might add that the parameters are certainly more verbose, so I'd hate to type all of that crap in on any command line. But let's say someone came out with a bunch of executables that did nothing with a command line, perhaps exited with a "Meant to be called using dbus!" error message. It would be no big problem to build a "dbus command wrapper" that would take its command line and turn it into dbus messages. Take the generic wrapper and symlink it to specific command names, rather like busybox does. At the simplest level, it would need a configuration file to tell it how to build dbus messages for each type of command line. Perhaps more complex, but more general, I believe the "introspection" capability could be used to do that stuff automagically, with a truly generic wrapper. At that point we're most of the way to a "dbus shell" - perhaps it could be tacked into .bashrc or something like that, and then our systems run the way we like again, even after the dbus crowd has its way. |
Ugh that is horrible. You really need to let go of the idea that we can "all just get along."
You cannot "get along" with someone who is trying to intimidate and control you. You can submit, fight or walk away.
|
Sorry I wasn't clear, you mistake my meaning. This was a worst-case theoretical argument, not a practical suggestion.
I'm just saying that even if systemd completely "won" and managed to wipe out the classical command line from every single upstream project, replacing it all with some sort of dbus-based GUI, we could still get a command line back.
The command line is a philosophy, not a specific implementation. Philosophically, the command line is the least distance between me and invoking a computer program to do work for me.
_________________
.sigs waste space and bandwidth |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Wed Dec 03, 2014 10:39 pm Post subject: |
|
|
| KuroNeko wrote: | That's sounds a lot, like some things, that I feel, are missing on my desktop sometimes.
Quickly hacking together a gui for a command line application or connecting a few application in e.g. krunner. Why isn't that possible on dbus? :( |
Because it's a crappy replacement for dcop, that is nowhere near as nice to code nor script against.
| Quote: | | Also a question: Letting every application spawn their own bus/IPC interface/whatever sounds good (if there are simple to use libs), but how would you know, if you're really talking to the program, you think, you are talking to? |
Either you started it up (in which case you know its pid) or it's running as a service on a known port, in most cases. If we're talking about pub/sub of just about anything, then I think we should look at some sort of easyipc lib, with configuration.
| Quote: | Maybe you could solve that with a setgid bit? Then every trusted application would run in the message group, or similiar.
Scanning for available services would be a simple lookup of all applications running as the current user and in the message group.
A central daemon really isn't needed there anymore. |
A central deamon isn't needed now: the basis of the permission system is the (mount) namespace. The kernel does the permission handling so we don't have to.
I'm not quite clear what problem you're trying to solve above. I agree groups can be useful, but I'd need a more specific case to have any idea what you're really getting at. One-size-fits-all solutions don't.
The beauty of having an ecosystem is that you have various ways of thinking cooperating; the thing to understand is that there are several mechanisms in POSIX, eg for IPC. Each are tuned for different scenarios, and trying to shove them all through one bottleneck is simply stupid.
Eg dbus keeps going on about not losing messages: POSIX supplies that semantic for message queues. However you simply don't need that for most cases (and as we've seen it's inappropriate at protocol level for general data), and again, trying to munge all the different types of communication into one, is exactly what led to the current snafu. Instead of stepping back and rethinking the design, they plow on with stubborn idiocy, and they've now made it about face. They clearly feel they would lose face if they admitted any flaws, which is fatal if you're a programmer.
It's simply blinkered thinking, which is what you get from inexperienced people. Especially the ones who think they don't need to do their research before blanket-declaring everything they can't get their heads around as useless. |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Wed Dec 03, 2014 10:48 pm Post subject: |
|
|
| depontius wrote: | | Sorry I wasn't clear, you mistake my meaning. This was a worst-case theoretical argument, not a practical suggestion. |
Well that was a lot of text, so it seemed important to you.
| Quote: | | I'm just saying that even if systemd completely "won" and managed to wipe out the classical command line from every single upstream project, replacing it all with some sort of dbus-based GUI, we could still get a command line back. |
I'd rather use that as an opportunity to pre-filter out the crap; call it self-selective evolution ;) however..
| Quote: | | The command line is a philosophy, not a specific implementation. Philosophically, the command line is the least distance between me and invoking a computer program to do work for me. |
systemd is never going to get rid of invoking a program with exec*, which is the basis for the thinking behind the command-line and most particularly having a Unix-style shell.
The latter means C programs don't have to worry about splitting and globbing, in particular, which they do on Windoze (unless you're using a ported shell.)
I understand your point that you could theoretically wrap dbus idiocy. But to my mind, if you've got to that point, you've lost your machine already. It's no longer yours, nor is it one I'd have any interest in using.
My interest is in getting rid of dbus altogether. I'm fine with the GUI I had in 1999; the most I'd want is to be able to plug in a usb-stick or device, and that's not exactly a problem. |
|
| Back to top |
|
|
sitquietly
Apprentice
Joined: 23 Oct 2010
Posts: 150
Location: On the Wolf River, Tennessee
|
| Posted: Wed Dec 03, 2014 10:51 pm Post subject: |
|
|
| steveL wrote: | .....You really need to let go of the idea that we can "all just get along." You cannot "get along" with someone who is trying to intimidate and control you. You can submit, fight or walk away.
I choose to walk away... |
I do too. I know something about how control can be imposed. I worked for a company that obtained a contract to build systems for the U.S. Air Force. That became a significant proportion of our revenue, as military and nsa contracts are now a significant proportion of the revenue for Red Hat. We didn't even realize, certainly I didn't realize, how much control the Air Force had gained over us by virtue of a contracted system that is "vital to the national interest." Our system was in fact important to the security of several military bases, but it was probably not as vital as Red Hat systems that run our entire nuclear submarine force.
The Air Force exercised their right to take direct control of the management of our company -- if you falter on the schedule or attaining the goals of such a military contract they have the right to assume direct control over your company. I ended up with an Air Force lieutenant occupying the office beside my workspace, I had to pass a security clearance, and the Air Force gained the right to direct not only our management decisions but also our engineering decisions.
I had designed a very capable embedded controller. I had built it as an unapproved skunkworks project, working with a fellow engineer in my home development lab, and then produced my working system in a high level meeting with the consultant who was being paid huge sums to build this "Entry Control Unit". It was impossible to dismiss my design since it was siting on the table working! It had lots of analog and digital i/o, timers, monitored voltages to detect attempts to tamper with the external circuits, and a really sweet private RS-485 network that I designed with a distributed database that enabled continuation of secure operations even in face of loss of the host communications. All in mere kilobytes of EPROM. The documentation was the best I've ever written and the system was my proudest work.
I liked it!  So did the Air Force. 
The Air Force needed a large number of "Entry Control Units" for their massive systems and mine, though designed by me for the commercial product that I was in charge of getting to market, was grabbed for their use.
I had done the Unix-thing and used plain ascii for the command language and an extensible protocol, i.e. a dictionary and a command interpreter. It was easy to understand, efficient, and extensible. Lets say, to stretch my point, that it was like Linux was before Red Hat and Poettering. The Air Force would have none of that. Their edict was that the data and commands must be kept in an unreadable binary format, just like Red Hat has for some reason started forcing on the Linux system logs. They hired their own consultant to obfuscate my code -- yes they actually said that they wanted to make the code harder to understand. For some months I worked in a locked steel Faraday cage assisting in the transformation of my system into a properly binary and obfuscated mess for the Air Force.
My point is not really about my particular experience or whether I liked or disliked the Air Force's redesign of my system. It is that Red Hat is known to be dominated by American military and security agencies -- their main income is from military contracts and a Chairman of the Joint Chiefs of Staff became the Chairman of the Board of Red Hat. I know from my experience that Red Hat products (e.g. kdbus, systemd) _could_ be directly engineered by those national agencies.
We are entering a period in which the heart of Linux is re-engineered by Red Hat. I don't trust that re-engineering to produce the system that I want to use or work on.
Gentoo seems to be one of the best cultures in which to bring along the best engineering of systems that follow The Linux Philosophy. I sure hope that we can continue to make it possible to run a Gentoo linux system as a large set of simple tools...which can be connected with well specified interfaces...which are usually textual data streams.
Thanks to every Gentoo developer who makes it possible for me to run a very capable hardened workstation with
USE="-avahi -consolekit -dbus -gnome -policykit -pulseaudio -systemd" |
|
| Back to top |
|
|
Navar
Guru
Joined: 20 Aug 2012
Posts: 355
Location: usa
|
| Posted: Fri Dec 05, 2014 6:51 am Post subject: |
|
|
| Anon-E-moose wrote: | If this is the best justification that people like GKH and the LP cabal can come up with then we really don't need kdbus.
They need to go back and design dbus and do it right. |
While I stepped away from Linux (and *nix in general) pre-Gnome/RHEL emergence days, it seems they've wanted this for quite some time, almost a decade.
I wasn't a fan of working with CORBA quite awhile ago but, this was interesting, from a performance aspect. Personally, it would have caused me to avoid dcop/dbus from the get go. |
|
| Back to top |
|
|
Anon-E-moose
Watchman
Joined: 23 May 2008
Posts: 6148
Location: Dallas area
|
| Posted: Sun Dec 07, 2014 12:51 pm Post subject: |
|
|
Here's a fun read, it's about dbus, but makes one ponder the "need" for kdbus.
http://gentooexperimental.org/~patrick/weblog/archives/2014-11.html#e2014-11-23T09_26_01.txt
From the end of the blog
| Quote: | While this exercise has been quite educational in many ways I am surprised that this undocumented early-alpha quality code base is used for anything serious. Many concepts are either not defined, or defined by the behaviour of the implementation. The APIs are ad-hoc without any obvious structure, partially redundant (what's the difference between Terminate and Kill ?), and not documented in a way that allows a reimplementation.
If this is the future I'll stay firmly stuck in the past ... |
And they want to push their alpha level (at best) undesigned code into the kernel. 
_________________
UM780, 6.1 zen kernel, gcc 13, profile 17.0 (custom bare multilib), openrc, wayland |
|
| Back to top |
|
|
tld
Veteran
Joined: 09 Dec 2003
Posts: 1845
|
| Posted: Sun Dec 07, 2014 2:40 pm Post subject: |
|
|
Oh...my...f*****g God. That's one of the most painful things I've ever read. It actually makes any Windows technical scavenger hunt I've ever dealt with look almost elegant.
I recall reading elsewhere that, in spite of being out there in the field, for example in RHEL7 (as in E for Enterprise), the DBUS API definition itself if documented as being "beta"...which essentially means you can't communicate with it in a way that isn't guaranteed not to break in the future. I guess that's how they "get off the hook" when the break your shit later on.
That really is an amazing read...no words. |
|
| 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
|
|
Kernel & Hardware
