| View previous topic :: View next topic |
| Do you want systemd as default on Gentoo? |
| I <3 systemd!! I want Gentoo to switch!! |
|
12% |
[ 26 ] |
| Get that horse-crap away from Gentoo as far as possible! |
|
87% |
[ 186 ] |
|
| Total Votes : 212 |
|
| Author |
Message |
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
 Posted: Fri Nov 07, 2014 10:45 am Post subject: |
 |
|
| steveL wrote: | | Like I said, all that's needed to avoid the copy is to have a slightly different API to message-queues. That would be much more generically useful, across the board, for every application, and also as a candidate for standardisation. |
| RazielFMX wrote: | This.
As I'm reading about kdbus and its ability to be a messaging bus and pass fds around, I can't help but think why not just improve the API for Posix Message Queues and Unix Domain Sockets (respectively). These are supported across operating systems (though the interfaces and capabilities due vary slightly; standardization of an API around these proven mechanisms wouldn't hurt). |
Agreed, we should look at sorting out a clean API, along the lines of LADSPA, for both what we want to do in userspace (like email notifications) and for a broadcast-capable message queue that returns the address where the data is on recv, rather than copying into a userland-nominated buffer.
There's precedent for the latter; getline() which should have been in the first C standard really (though that likely would have returned just an integer.)
From there we could use a UDP or named socket along with the message queue, for control vs data. Oh and we'd have to specify that the queue descriptor is a standard fd, that can be poll()'ed. |
|
| Back to top |
|
 |
uudruid74
n00b
Joined: 21 Jun 2014
Posts: 30
|
| Posted: Fri Nov 07, 2014 5:09 pm Post subject: |
|
|
| steveL wrote: |
All you've shown is why a userland multiplexor is necessarily less efficient than the kernel. What you appear to be missing is that the kernel is a multiplexor, so that effectively what dbus does is reimplement part of the kernel in userland. Now we're pushing an impl of the kernel that is limited, constrained, and inflexible by comparison into the kernel.
That's why this is insane.
|
Calm down. I'm not defending them, just explaining the reasoning. I was quite clear that I don't agree with their methods.
| steveL wrote: | And incidentally you've ignored what I wrote in response to you above: the reason they want to push it into kernel is primarily business-oriented (to lock the kernel into supporting the RH monoculture for all time.) The pretext given is because namespaces (which has no basis in reality) and we all know that internally the systemdiots have told themselves it will "solve" their performance problems. However these problems are the equivalent of using an O(N^3) algorithm when you could be using an O(log N) algorithm; they are down to plain old vanilla stupidity, and an unwillingness to admit error, which is fatal for a designer (and indeed a programmer.)
|
I specifically ignored it because my response wasn't directed to you. As for them wanting to push it into the kernel specifically to lock in some sort of RedHat evil, I think you need to lay off the drugs. They are making you paranoid. Saying things like that doesn't help your argument at all. It just shows that you have a fear of change and an emotional attachment to this issue rather than looking at it from a purely technical stand-point ... which is why I didn't quote you in my response and decided to move on. However, you aren't letting me, so I'll give you this last reply to show why. You are putting your emotions in here and being quite insulting - to people who are supporting you no less.
| steveL wrote: |
You keep going on about directory services, and it's just wrong. You sound like as much of a Windows wannabe as Poeterring from what I've read so far.
|
Again ... the only people that resort to name calling are people who feel threatened and can't make an argument with valid points. You took Logic 101 in college, so you know this.
Incidently, I've never used Windows as my primary OS, nor DOS. Before switching to Linux at home I used an Atari/68K based machine running MiNT (similar to Unix but compatible with the original Atari TOS applications - and before that 8 bit machines back to the TRS-80 model 1) as well as an AT&T 3B2 SysVr3.2 machine (which I just sold to a museum yesterday - might have been r3.1 back then) and worked as a SCO admin at the time. Back then Linux meant Slackware on a huge stack of floppies, but I put it on a few test servers which were shown to be more reliable than anything we had at the time. They ended up being production servers, although by that time, an early release of RedHat was installed on them. I've used Windows at work as a contractor where I wasn't allow to reload the machine with Linux, and thats about it. I even put Linux on SUN servers, SGI machines, my NeXT, and I think a few others. I don't dual-boot my machines with Windows either, its all Linux. I've given Windows a chance, but I just don't like it and don't have a need to run it. Remember, I'm the one that started off saying I don't like dbus or gconf (aka Windows registry for Linux). So, your statement is totally ridiculous. You are shooting arrows into the wind my friend.
| steveL wrote: | | uudruid74 wrote: | | This keeps it out of the kernel and its just as efficient, and your service mapping can be implemented in userspace. |
On even in /etc/services like we always have. |
No, a static mapping to a set of TCP numbers is not going to be flexible enough here, nor do I want to pollute the TCP port list for a possibly unlimited number of services that might be provided over the bus. You'd get all sorts of problems - such as collisions when two different developers both decided to use the same port and add themselves to /etc/services. Perhaps the portmapper used for RPC would work ok, but I haven't looked into all its details other than running it for NFS. I actually don't even think TCP would be best - UDP could be faster and plenty reliable enough considering we're not attempting to leave the machine.
| steveL wrote: | | uudruid74 wrote: |
The only thing it won't do is a true broadcast, but I think thats a bad design. |
Oh that's all right then; since you don't know that sockets can broadcast, anyone who wants to broadcast events must necessarily have the wrong idea.
|
No, I didn't say all uses of broadcast sockets is a bad design. I didn't say that sockets can't broadcast. I said the alternative that I laid out, opening ports to specific services, can't do broadcast. Your use of /etc/services wouldn't either. You aren't going to broadcast to multiple ports. I claimed that random applications broadcasting data to all other applications on a bus (assuming wide acceptance, all processes on your system) would be a bad design. I didn't say all uses of broadcast sockets, and you know this.
Is there some reason you decided to take a post I made (which was AGAINST systemd) and attack it as if I was defending it? Just because I mentioned some reasoning behind their madness you feel so threatened that you resort to name calling and trying to make it sound like I said things I didn't.
| steveL wrote: | | uudruid74 wrote: | | I think of it like how high speed servers changed over to switching fabrics because of the bandwith limitations of bus protocols. Why emulate an old ISA bus in the kernel when we know efficiency requires PCIe? |
PCIe is a bus. It's just serial, rather than parallel.
I'd explore netlink first since it's meant to be usable from userland, for userland communications. Though personally I really like SCTP; its semantics are a very good fit for what's happening here. And I would not shove data down it, beyond minimal metadata. |
PCIe isn't switched? Care to Google that before you blatantly call me stupid?
| Wikipedia wrote: | | A key difference between PCIe bus and the older PCI is the bus topology. PCI uses a shared parallel bus architecture, where the PCI host and all devices share a common set of address/data/control lines. In contrast, PCIe is based on point-to-point topology, with separate serial links connecting every device to the root complex (host). Due to its shared bus topology, access to the older PCI bus is arbitrated (in the case of multiple masters), and limited to one master at a time, in a single direction. Furthermore, the older PCI clocking scheme limits the bus clock to the slowest peripheral on the bus (regardless of the devices involved in the bus transaction). In contrast, a PCIe bus link supports full-duplex communication between any two endpoints, with no inherent limitation on concurrent access across multiple endpoints. |
source http://en.wikipedia.org/wiki/PCI_Express
Now everyone can see what I was talking about and can see the reasoning behind what I'm saying. A bus topology is being emulated, and I think it should be a switched (if it's done at all, its simply a better design in software for the same reasons its a better design in hardware), which would make it just as fast in user-space as the kernel (counting task switches and such as my reference, being in the kernel could speed it up slightly, but not appreciably once your remove the bus-topology), which means there is very little reason left for them to put it in the kernel. That was my whole argument. My post added some reasoning behind it so people could see where I was coming from. It had nothing to do with you.
So .. do you want to continue attacking each other? If we attack each other, we help LP. |
|
| Back to top |
|
|
Dorsai!
Apprentice
Joined: 27 Jul 2008
Posts: 285
Location: Bavaria
|
| Posted: Sat Nov 08, 2014 3:52 am Post subject: |
|
|
I guess soon he will be whining on G+ about Gentoo users threatening him and making evil sexist/racist fun about smashing his head in with a hammer. |
|
| Back to top |
|
|
avx
Advocate
Joined: 21 Jun 2004
Posts: 2152
|
| Posted: Sat Nov 08, 2014 7:05 am Post subject: |
|
|
Joey Hess, Deb-dev since 1996 and more on the pro-systemd side announces to leave Debian. Not because of systemd itself, but because of the way they are handling the situation.
https://lists.debian.org/debian-devel/2014/11/msg00174.html
No matter his personal believes I think it's sad that a long standing and accomplished dev now drops the ball because of politics 
_________________
++++++++++[>+++++++>++++++++++>+++>+<<<<-]>++.>+.+++++++..+++.>++.<<+++++++++++++++.>.+++.------.--------.>+.>. |
|
| Back to top |
|
|
NeddySeagoon
Administrator
Joined: 05 Jul 2003
Posts: 54236
Location: 56N 3W
|
| Posted: Sat Nov 08, 2014 10:40 am Post subject: |
|
|
Locked while I set up Why is Gentoo not switching to systemd? Part 2
At 31 pages, the forums begin to break and moderation becames more and more difficult.
I couldn't find a lull or natural break over the last few pages, so this is as good a place for the join as any.
Please continue at Why is Gentoo not switching to systemd? Part 2
_________________
Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
| 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
