View previous topic :: View next topic |
Author |
Message |
bstaletic Apprentice

Joined: 05 Apr 2014 Posts: 225
|
Posted: Mon Mar 30, 2015 6:04 pm Post subject: |
|
|
depontius,
How nice of them! They're going to leave linux users alone and can use they're own systemdOS. |
|
Back to top |
|
 |
Anon-E-moose Advocate


Joined: 23 May 2008 Posts: 4343 Location: Dallas area
|
Posted: Mon Mar 30, 2015 6:33 pm Post subject: |
|
|
It would be for the best if it wasn't a joke.
That would fix all the problems, for those that want they could run Pottering OS
and the rest of us could continue on with the linux we've known for a long time. _________________ Asus m5a99fx, FX 8320 - nouveau, oss4, rx550 for qemu passthrough
Acer laptop E5-575, i3-7100u - i965, alsa
---both---
5.0.13 zen kernel, profile 17.1 (no-pie & modified) amd64-no-multilib
gcc 8.2.0, eudev, openrc, openbox, palemoon |
|
Back to top |
|
 |
ct85711 Veteran

Joined: 27 Sep 2005 Posts: 1726
|
Posted: Mon Mar 30, 2015 7:17 pm Post subject: |
|
|
Hopefully what they will do next, is make it so only Red Hat can use systemd, forcing everyone that wants to use Gnome & systemd has to use Red Hat's distro, so everyone can finally forget about this trash and get on with having a system that actually works. |
|
Back to top |
|
 |
grot n00b

Joined: 17 Dec 2014 Posts: 33
|
|
Back to top |
|
 |
Anon-E-moose Advocate


Joined: 23 May 2008 Posts: 4343 Location: Dallas area
|
Posted: Tue Mar 31, 2015 9:56 am Post subject: |
|
|
http://lkml.iu.edu/hypermail/linux/kernel/1503.3/04981.html
Quote: | In general, there seems to be a number of misconception in this thread
about what kdbus is supposed to be. We're not inventing something new
here with a clean slate, but we're moving parts of an existing
implementation that has tons of users into the kernel, in order to fix
issues that cannot be fixed otherwise in userspace (most notably, the
race gaps that exist when retrieving per-message metadata). Therefore,
we have to keep existing semantics stable, otherwise the exercise is
somewhat pointless. |
They simply want to shove the crappy dbus code into the kernel "hoping" that it will make dbus faster.
They refuse to try and rewrite dbus to make it faster instead hammering on getting dbus-crap into the kernel.
*sigh* _________________ Asus m5a99fx, FX 8320 - nouveau, oss4, rx550 for qemu passthrough
Acer laptop E5-575, i3-7100u - i965, alsa
---both---
5.0.13 zen kernel, profile 17.1 (no-pie & modified) amd64-no-multilib
gcc 8.2.0, eudev, openrc, openbox, palemoon |
|
Back to top |
|
 |
steveL Watchman

Joined: 13 Sep 2006 Posts: 5153 Location: The Peanut Gallery
|
Posted: Tue Mar 31, 2015 4:10 pm Post subject: |
|
|
Anon-E-moose wrote: | They simply want to shove the crappy dbus code into the kernel "hoping" that it will make dbus faster.
They refuse to try and rewrite dbus to make it faster instead hammering on getting dbus-crap into the kernel. |
Ah but we're in the world of shifting goalposts, and pretext rather than craft since this is all about "modern" business-methods (and "strategy"), not about delivering great software.
Now the reason it "must" be in kernel is "race gaps that exist when retrieving per-message metadata", which arise from dbus' idiotic implementation in userland, and reimplementing a borked "semantic" that must be preserved even though it flies in the face of all sense. As discussed to death in earlier iterations, including when the networking guys told them five years ago, just to use TIPC.
The simple truth is that Linux already has a much better "kdbus" in-kernel, well-designed and tested for 7 years before it even came near the kernel in 2000.
The sad fact is that the self-styled "kernel experts" who are in fact kernel-rejects and a documentation guy, have no clue about userland programming either, and thus are still trying to "fix" their broken metaphor by pushing it into kernel-space, a la Windoze -- when they should be rethinking their userland lunacy ("because userland can do crazy things, we do all of them.")
The only reason RedHat are pursuing it, is so that dbus GPL-evasion is baked into the kernel, and supported forever more (never to be questioned again.)
After all, they control the userland now, what with the pretty much "industry"-wide capitulation to systemd in bindists. Oh wait. ;) |
|
Back to top |
|
 |
Ant P. Watchman

Joined: 18 Apr 2009 Posts: 6044
|
Posted: Tue Mar 31, 2015 6:12 pm Post subject: |
|
|
Anon-E-moose wrote: | They refuse to try and rewrite dbus to make it faster instead hammering on getting dbus-crap into the kernel. |
Of course they won't - improving the userspace DBus would give all Unixes an equal playing field, and Redhat is currently trying to murder the competition through tighter and tighter bundling.
Very Microsoft of them. |
|
Back to top |
|
 |
Anon-E-moose Advocate


Joined: 23 May 2008 Posts: 4343 Location: Dallas area
|
Posted: Wed Apr 01, 2015 10:08 am Post subject: |
|
|
http://lkml.iu.edu/hypermail/linux/kernel/1503.3/06122.html *hmm*
Quote: | I've heard the following use cases for per-connection metadata:
- Authenticating to dbus1 services.
- Identifying connected users for admin diagnostics.
I've heard the following use cases for per-message metadata:
- Logging.
- Authenticating to kdbus services that want this style of authentication.
The only reasonable conclusion I've been able to draw is that the dbus
community intends to use *both* per-connection and per-message
metadata for authentication. This means that, as a general rule,
dropping privileges while you have an open kdbus connection has poorly
defined effects.
It's particularly alarming that, when I express a concern about
logging, the kdbus authors cite authentication as an alternate
justification, and, when I cite a concern about authentication, the
kdbus authors cite logging as an alternative justificaiton. |
*chuckle* moving the goal post seems to be the kdbus peoples forte
Quote: | This all feels to me like a total of about four people are going to
understand the tangle that is kdbus security, and that's bad. I think
that the kernel should insist that new security-critical mechanisms
make sense and be hard to misuse. The current design of kdbus, in
contrast, feel like it will be very hard to use correctly. |
I don't think they want people (other than themselves) to understand the code.
And of course they have no desire to use it correctly.
It's their wedge to get into the kernel, since Linus has slapped Kay's hand far too often
and they need a way to "bypass" Linus saying "no" to their requests.
I do believe that Linus and others will see this for what it is,
and make them either do the right thing or abandon kdbus completely. _________________ Asus m5a99fx, FX 8320 - nouveau, oss4, rx550 for qemu passthrough
Acer laptop E5-575, i3-7100u - i965, alsa
---both---
5.0.13 zen kernel, profile 17.1 (no-pie & modified) amd64-no-multilib
gcc 8.2.0, eudev, openrc, openbox, palemoon |
|
Back to top |
|
 |
pjp Administrator


Joined: 16 Apr 2002 Posts: 18168
|
Posted: Thu Apr 02, 2015 2:13 am Post subject: [split] chaff from kdbus in the kernel |
|
|
[split] chaff from kdbus in the kernel _________________ Those who know what's best for us must rise and save us from ourselves. |
|
Back to top |
|
 |
Shamus397 Apprentice


Joined: 03 Apr 2005 Posts: 218 Location: Ur-th
|
|
Back to top |
|
 |
asturm Developer


Joined: 05 Apr 2007 Posts: 7220 Location: Austria
|
Posted: Fri Apr 10, 2015 6:10 pm Post subject: |
|
|
That is from two weeks ago, so nothing new just now. kdbus is in linux-next to receive more testing, but that doesn't mean it automatically goes into mainline. _________________ backend.cpp:92:2: warning: #warning TODO - this error message is about as useful as a cooling unit in the arctic |
|
Back to top |
|
 |
steveL Watchman

Joined: 13 Sep 2006 Posts: 5153 Location: The Peanut Gallery
|
Posted: Mon Apr 13, 2015 5:28 am Post subject: |
|
|
Yeah nothing to worry about; just keep looking into my eyes, not around the eyes..
After all, it's not like anyone would dream of turning around later and saying "Well you had your chance; no-one responded to the 5th round of sales-pitch, so we put it in, you should have spoken back then" and other variants on "it's all your fault, suckers!"
Just deal with it, move on, etc; all the things we don't do, when we want to make y'all get in line. |
|
Back to top |
|
 |
asturm Developer


Joined: 05 Apr 2007 Posts: 7220 Location: Austria
|
Posted: Mon Apr 13, 2015 8:03 am Post subject: |
|
|
I was merely preventing the thread from entering a sub-loop duplicating from this comment by repeating what Anon-E-moose had said himself. But if you disagree, go on! _________________ backend.cpp:92:2: warning: #warning TODO - this error message is about as useful as a cooling unit in the arctic |
|
Back to top |
|
 |
Anon-E-moose Advocate


Joined: 23 May 2008 Posts: 4343 Location: Dallas area
|
Posted: Mon Apr 13, 2015 9:42 am Post subject: |
|
|
I'm still seeing a couple of kernel devs who aren't too thrilled with kdbus as it is at the moment, so I doubt that it will go in until things get hammered out.
And again, just because it's up for review that does not mean automatic inclusion in the kernel _________________ Asus m5a99fx, FX 8320 - nouveau, oss4, rx550 for qemu passthrough
Acer laptop E5-575, i3-7100u - i965, alsa
---both---
5.0.13 zen kernel, profile 17.1 (no-pie & modified) amd64-no-multilib
gcc 8.2.0, eudev, openrc, openbox, palemoon |
|
Back to top |
|
 |
asturm Developer


Joined: 05 Apr 2007 Posts: 7220 Location: Austria
|
Posted: Mon Apr 13, 2015 7:22 pm Post subject: |
|
|
Now, that happened: https://lkml.org/lkml/2015/4/13/645 _________________ backend.cpp:92:2: warning: #warning TODO - this error message is about as useful as a cooling unit in the arctic |
|
Back to top |
|
 |
depontius Advocate

Joined: 05 May 2004 Posts: 3406
|
Posted: Mon Apr 13, 2015 8:11 pm Post subject: |
|
|
IIRC, it's been in linux-next for less than a month, unless the pull request I saw only a few weeks ago wasn't the first. Does someone really need to look this up? _________________ .sigs waste space and bandwidth |
|
Back to top |
|
 |
Anon-E-moose Advocate


Joined: 23 May 2008 Posts: 4343 Location: Dallas area
|
Posted: Mon Apr 13, 2015 10:20 pm Post subject: |
|
|
Reading it now.
Some of the kernel devs don't like kdbus (or the people working on it) much.
Andy L says
Quote: | Kdbus is very much a port of userspace dbus to the
kernel, and it appears to be a port designed to preserve some
questionable design decisions instead of learning from them. |
Pretty much what a lot of us have been saying.
Will see how GKH responds to his critique.
A gem from Andy
Quote: | The fact that some existing userspace does awful things does *not*
justify adding new kernel mechanisms with which to repeat those
mistakes. |
He's had to tell the kdbus devs this several times and now he's having to tell GKH (WTF) _________________ Asus m5a99fx, FX 8320 - nouveau, oss4, rx550 for qemu passthrough
Acer laptop E5-575, i3-7100u - i965, alsa
---both---
5.0.13 zen kernel, profile 17.1 (no-pie & modified) amd64-no-multilib
gcc 8.2.0, eudev, openrc, openbox, palemoon |
|
Back to top |
|
 |
depontius Advocate

Joined: 05 May 2004 Posts: 3406
|
Posted: Mon Apr 13, 2015 11:38 pm Post subject: |
|
|
Anon-E-moose wrote: |
A gem from Andy
Quote: | The fact that some existing userspace does awful things does *not*
justify adding new kernel mechanisms with which to repeat those
mistakes. |
He's had to tell the kdbus devs this several times and now he's having to tell GKH (WTF) |
Oh, he's just a hater!
(Some people would take a statement like that seriously, and consider it reason to discount Andy's statement. That's sad.) _________________ .sigs waste space and bandwidth |
|
Back to top |
|
 |
Naib Watchman


Joined: 21 May 2004 Posts: 5713 Location: Removed by Neddy
|
Posted: Mon Apr 13, 2015 11:43 pm Post subject: |
|
|
depontius wrote: | Anon-E-moose wrote: |
A gem from Andy
Quote: | The fact that some existing userspace does awful things does *not*
justify adding new kernel mechanisms with which to repeat those
mistakes. |
He's had to tell the kdbus devs this several times and now he's having to tell GKH (WTF) |
Oh, he's just a hater!
(Some people would take a statement like that seriously, and consider it reason to discount Andy's statement. That's sad.) | this is when the CoC is thrown in his face to dismiss his statement _________________ The best argument against democracy is a five-minute conversation with the average voter
Great Britain is a republic, with a hereditary president, while the United States is a monarchy with an elective king |
|
Back to top |
|
 |
steveL Watchman

Joined: 13 Sep 2006 Posts: 5153 Location: The Peanut Gallery
|
Posted: Tue Apr 14, 2015 3:38 am Post subject: |
|
|
Anon-E-moose wrote: | Will see how GKH responds to his critique. |
By talking past his points, instead of addressing them, casting aspersions on the "doubter" wrt dodgy benchmarks (ironic when you consider on whom he's casting doubt) and neatly excising the summary and NAK so he can pretend they didn't happen.
Andy Lutomirski wrote: | The fact that some existing userspace does awful things does *not*
justify adding new kernel mechanisms with which to repeat those
mistakes. |
Quote: | He's had to tell the kdbus devs this several times and now he's having to tell GKH (WTF) |
Kroah-Hartman's approach to dissenting opinion isn't very programmer-like, imo. Thankfully, Lutomirski was having none of it in the mail you quoted:
Quote: | Then I'll have to find a way to embolden my NACK further.
The design is bad, full stop. | (ordering changed)
The only bit that concerns me is where he stated "I generally like the concept of having a better in-kernel IPC mechanism" as it implies he isn't aware of TIPC, nor the previous discussion in 2012, when the networking people advised them to use it.
ie: there already is a better in-kernel IPC mechanism. (cf also: SOCK_RDM.) |
|
Back to top |
|
 |
Anon-E-moose Advocate


Joined: 23 May 2008 Posts: 4343 Location: Dallas area
|
Posted: Tue Apr 14, 2015 9:28 am Post subject: |
|
|
The biggest thing I've noticed is that some of the kernel devs have mentioned (several times)
that dbus could possibly be speeded up with a look at how it's implemented internally.
The *bus devs have been refusing to do this.
So it's obvious, at least to me, that they want kdbus in the kernel not for any real speedup but for other reason.
And yes, many of them have been brought up in these threads, ie bypassing the gpl, etc.
I doubt that I'm the only one that is seeing things this way.
And we've yet to hear Linus' view on kdbus.
Of course he may be waiting to see if it even makes muster, ie gets past the kernel devs with the NAKs. _________________ Asus m5a99fx, FX 8320 - nouveau, oss4, rx550 for qemu passthrough
Acer laptop E5-575, i3-7100u - i965, alsa
---both---
5.0.13 zen kernel, profile 17.1 (no-pie & modified) amd64-no-multilib
gcc 8.2.0, eudev, openrc, openbox, palemoon |
|
Back to top |
|
 |
depontius Advocate

Joined: 05 May 2004 Posts: 3406
|
Posted: Tue Apr 14, 2015 3:31 pm Post subject: |
|
|
Greg KH's pull request says kdbus has been in linux-next "for several months". This seems disingenuous to me. A quick check with Google, and it appears that the pull request for linux-next was around March 15, just under one month ago. The initial patches appear to have been first submitted back in October, about six months ago.
All else aside, does anyone know what the "average latency" is for a new large-ish feature to get added to the kernel? Six months from first patch actually seems kind of fast.
To be honest, I (sadly) expect kdbus to go in, maybe on 4.1, maybe on 4.2. I expect the real fireworks to happen when they expect to treat the kernel code with all of the stability of the rest of systemd. Come to think of it, I don't know how stable userspace dbus has been, if it's been more stable than the rest of systemd. _________________ .sigs waste space and bandwidth |
|
Back to top |
|
 |
mv Watchman


Joined: 20 Apr 2005 Posts: 6296
|
Posted: Tue Apr 14, 2015 3:38 pm Post subject: |
|
|
depontius wrote: | All else aside, does anyone know what the "average latency" is for a new large-ish feature to get added to the kernel? Six months from first patch actually seems kind of fast. |
For unionfs/unionmount/aufs/overlayfs it took about 10-15 years or so - despite being used (and needed to be patched in) by dozens of distributions since many years - I think nobody ever had any doubts that this feature is useful - and still only the most primitive of these (overlayfs) is in the kernal, finally.
Similarly, compression for ext2 took so many years of continuous request that the maintainer finally gave up.
squashfs with lz4 took a year, even after squashfs+lz4 was in the tree.
I never understood, why such useful features needed so many years to become included (I mean: after they have been written and been well-tested).
Then everybody knows how it was with reiser4 which is still not in the kernel, and probably will never be.
Of course behind these, there was not the pressure of money and power. |
|
Back to top |
|
 |
Naib Watchman


Joined: 21 May 2004 Posts: 5713 Location: Removed by Neddy
|
Posted: Tue Apr 14, 2015 4:07 pm Post subject: |
|
|
mv wrote: |
I never understood, why such useful features needed so many years to become included (I mean: after they have been written and been well-tested).
|
Its a very passive way to prove whether what is being requested to be added (till the end of time) is actively being used AND is stable from a userspace point of view.
That has at least been a constant push from the kernel lot - don't break userland. If a kernel module has been around for years AND is being used/depended upon & only the kernel facing API/ABI breaks & is updated then that is a very nice tick.
cgroups was a nice idea but (poorly implemented and now there is talk of a parallel implementation so userland depending on cgroups is not broken...) do we really want that from kdbus which is soo needed applications just do not work _________________ The best argument against democracy is a five-minute conversation with the average voter
Great Britain is a republic, with a hereditary president, while the United States is a monarchy with an elective king |
|
Back to top |
|
 |
mv Watchman


Joined: 20 Apr 2005 Posts: 6296
|
Posted: Tue Apr 14, 2015 6:24 pm Post subject: |
|
|
Naib wrote: | That has at least been a constant push from the kernel lot - don't break userland. If a kernel module has been around for years AND is being used/depended upon & only the kernel facing API/ABI breaks & is updated then that is a very nice tick. |
Concerning the mentioned filesystems/filesystem features, they satsified all these conditions for many years and nevertheless haven't been included for many years.
Compared to this, I was really surprised how quickly cgroups had been included.
And now seeing something being pushed through, practically untested, actually undesired, when the same thing is already implemented better in the kernel (as SteveL pointed out here, several times) - it is really unbelievable and only explainable through the enormous market power of RedHat.
Edit: Fixed typo in the first sentence which made it not understandable.
Last edited by mv on Wed Apr 15, 2015 1:12 pm; edited 1 time in total |
|
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
|
|