| View previous topic :: View next topic |
| Author |
Message |
P.Kosunen
Guru
Joined: 21 Nov 2005
Posts: 309
Location: Finland
|
 Posted: Tue May 12, 2015 4:52 pm Post subject: |
 |
|
| Quote: | | Prior to systemd, Poettering was the developer of PulseAudio, a sound server, and Avahi, a zeroconf protocol implementation for network device discovery. |
I wonder why these are not yet integrated in systemd. |
|
| Back to top |
|
 |
peter-dambier
n00b
Joined: 13 May 2015
Posts: 4
Location: Germany, County Bergstrasse
|
| Posted: Wed May 13, 2015 8:42 pm Post subject: |
|
|
Weston and Wayland, I have been told. I hope that is not true.
For me the ko about systemd is, it is not compatible with Unix. With systemd linux becomes yet another windows.
I have tried systemd but maybe living without gnome and without kde and starting X only when I need it, maybe that is the reason why it would not work on my system. Maybe I have not tried hard enough.
Cheers
Peter |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6781
|
| Posted: Thu May 14, 2015 7:27 am Post subject: |
|
|
| Tony0945 wrote: | | Quote: | | Prior to systemd, Poettering was the developer of PulseAudio, a sound server, and Avahi, a zeroconf protocol implementation for network device discovery. |
So he has a track record of producing opaque useless software that eventually gets junked. |
Not to forget the infamous HAL which he pressed through the whole xorg community because of its great new technology (XML config files!) only having to admit after some years that it has become a complex bulk which no-one can maintain.
He did not learn the slightest thing from his previous mistakes. At least, concerning programming... |
|
| Back to top |
|
|
Tony0945
Watchman
Joined: 25 Jul 2006
Posts: 5127
Location: Illinois, USA
|
| Posted: Thu May 14, 2015 1:25 pm Post subject: |
|
|
| Quote: |
Not to forget the infamous HAL which he pressed through the whole xorg community because of its great new technology (XML config files!) only having to admit after some years that it has become a complex bulk which no-one can maintain. |
I always felt uneasy adopting a system and concept that originated in Windows NT. Over the course of forty years in the business I have seen hardware interface layers come and go. The concept sounds good, but eventually the overhead becomes too great for applications that need to access the hardware NOW.
Last edited by Tony0945 on Fri May 15, 2015 2:10 am; edited 1 time in total |
|
| Back to top |
|
|
depontius
Advocate
Joined: 05 May 2004
Posts: 3530
|
| Posted: Thu May 14, 2015 3:20 pm Post subject: |
|
|
There seems to be a strange belief that just because something is plain old text and readily readable by ordinary human beings, that it's second-rate.
I suspect that's behind this strange wish to push stuff into XML or binary configs. The unwashed can't read them, so they must be better.
Similarly, interpreted languages, and shell script in particular, are also denigrated. I suspect that again part of this is because unwashed masses can read and perhaps understand the exact code being run. I suspect also that for those of Windows origins, they equate shell script to BAT files. The old DOS batch language was a horribly limited thing - possibly Turing-complete, but barely. Nor did it have enough sophistication to easily do much in the way of real work. Last I heard, Microsoft was working on improving their shell (and scripting?) capability. I wonder if shell scripts will become acceptable to systemd-aficionados once Windows catches up with its own scripting.
_________________
.sigs waste space and bandwidth |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6781
|
| Posted: Fri May 15, 2015 5:19 am Post subject: |
|
|
| depontius wrote: | | There seems to be a strange belief that just because something is plain old text and readily readable by ordinary human beings, that it's second-rate. |
Well, there is one good point in this: Such scripts can suffer from the fact that programs do not necessarily have a well-defined output format.
Thus, for instance, I have some portage wrappers, but in certain unusual situations, portage can output something which can confuse these wrappers. It is a pity that portage does not have a well-defined programming interface with full possibilities of emerge which would not cause such problems for scripting.
These people believe that if you just define some standard interface for all programs, then magically this interface would avoid these difficulties.
You can see this very well with the journald idea: They claim that you get a well-defined standard in which it is easy to search separately for the fields from syslog without having to care about special symbols which might be interpreted as field separators. They are not able to recognize that tihs idea is plain false, because field separators are really not a problem in log files, and if they are for some poorly written syslog daemons, you better work on this problem for that daemons - which is easy enough to solve by choosing appropriate escape conventions. You can still write an additional wrapper which "hides" these mechanisms and gives you all the "standardized" interface which these guys love so much - without all the disadvantages of a binary log (with unreadable messages in case of kernel panics etc).
MS had the same broken idea about their "new" scripting: They claim that scripting is broken, because you cannot pass true binaries arrays - as if it would be any difficulty to write a wrapper for exactly this.
I do agree, that it would be nice to have a standardized exchange format for binary arrays: Then programs could with some switch output this format, and most languages would provide a mean to read these binary arrays convenienty. But these guys believe that people should not use some convention but instead should be forced to use one library (which in the end does nothing else than force any such convention).
In some sense, we see here the idea of freedom defeating against the idea of a dictator: In MS world, there is a clear dictator, and some guys seem to be missing it. Since practically nobody can be forced to use the one true library, they at least want to bring all existing big projects in the line of the dictator. And the political propaganda which we see in the course of their acting corresponds exactly to the propaganda which one has seen in countries when free institutions are brought in line for a dictatorship. All these ideas really have nothing to do with technical facts, but it is all about power and forcing other people to program obeying according to the will of the dictator. |
|
| Back to top |
|
|
greyspoke
Apprentice
Joined: 08 Jan 2010
Posts: 175
|
| Posted: Fri May 15, 2015 7:49 am Post subject: |
|
|
| peter-dambier wrote: | Weston and Wayland, I have been told. I hope that is not true.
For me the ko about systemd is, it is not compatible with Unix. With systemd linux becomes yet another windows.
I have tried systemd but maybe living without gnome and without kde and starting X only when I need it, maybe that is the reason why it would not work on my system. Maybe I have not tried hard enough.
Cheers
Peter |
I tried Gnome/systemd but only installed Gnome light and not the whole bunch of utilities it expects to have there. I couldn't get rid of buttons and options which expected things to be there which weren't. Probably if I tried hard enough I could have ironed all this out. So I would say if you are going that way, you have to get the fries and milkshake along with your burger. Which illustrates the overall approach I guess. |
|
| Back to top |
|
|
Naib
Watchman
Joined: 21 May 2004
Posts: 6084
Location: Removed by Neddy
|
| Posted: Sat May 23, 2015 7:20 am Post subject: |
|
|
| Quote: | A new (currently still internal) API sd-device.h has been
added to libsystemd. This modernized API is supposed to
replace libudev eventually. In fact, already much of libudev
is now just a wrapper around sd-device.h. |
http://www.itrunsonlinux.com/desktopos/systemd-v220-released/
_________________
#define HelloWorld int
#define Int main()
#define Return printf
#define Print return
#include <stdio>
HelloWorld Int {
Return("Hello, world!\n");
Print 0; |
|
| Back to top |
|
|
Shamus397
Apprentice
Joined: 03 Apr 2005
Posts: 218
Location: Ur-th
|
| Posted: Tue May 26, 2015 4:46 pm Post subject: |
|
|
| So wait a minute--does this mean that udev is being abandoned by the SystemD cabal? |
|
| Back to top |
|
|
NeddySeagoon
Administrator
Joined: 05 Jul 2003
Posts: 55414
Location: 56N 3W
|
| Posted: Tue May 26, 2015 6:40 pm Post subject: |
|
|
Shamus397,
That has been their stated intent for a number of years. So yes.
Step one was to merge the udev codebase into systemd.
Its only the existence of eudev that has kept a separate udev alive this long.
_________________
Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
| Back to top |
|
|
depontius
Advocate
Joined: 05 May 2004
Posts: 3530
|
| Posted: Wed May 27, 2015 12:35 am Post subject: |
|
|
I've only gotten around to converting one system to eudev so far, but that was pretty painless. I need to get around to the others...
There was also the announced intention by the systemd people to remove the part where the kernel sends udev events by netlink, and rely exclusively on kdbus for that function. I'm sure Linus would be really happy to add the netlink-removal patch. I expect that assuming kdbus gets in someday, they will get an option to use that for udev events.
_________________
.sigs waste space and bandwidth |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6781
|
| Posted: Wed May 27, 2015 4:56 am Post subject: |
|
|
| depontius wrote: | | IThere was also the announced intention by the systemd people to remove the part where the kernel sends udev events by netlink, and rely exclusively on kdbus for that function |
In case that this should really be happening: Would it be that complicated to substitute the transfer protocol of eudev? |
|
| Back to top |
|
|
depontius
Advocate
Joined: 05 May 2004
Posts: 3530
|
| Posted: Wed May 27, 2015 3:12 pm Post subject: |
|
|
| mv wrote: | | depontius wrote: | | IThere was also the announced intention by the systemd people to remove the part where the kernel sends udev events by netlink, and rely exclusively on kdbus for that function |
In case that this should really be happening: Would it be that complicated to substitute the transfer protocol of eudev? |
Look at it for a moment... The systemd developers have announce that they want the Linux kernel to break userspace. Under separate discussions they've also suggested that the kernel and systemd should upgrade in lockstep. Think of the joys that would cause for userspace. The only way that has a prayer of working is if haters like us quit building our own kernels and userspace - we take binary upgrades from our distribution maintainers. In other words, turn Linux into Windows.
_________________
.sigs waste space and bandwidth |
|
| Back to top |
|
|
saellaven
l33t
Joined: 23 Jul 2006
Posts: 661
|
| Posted: Wed May 27, 2015 3:40 pm Post subject: |
|
|
| depontius wrote: | | mv wrote: | | depontius wrote: | | IThere was also the announced intention by the systemd people to remove the part where the kernel sends udev events by netlink, and rely exclusively on kdbus for that function |
In case that this should really be happening: Would it be that complicated to substitute the transfer protocol of eudev? |
Look at it for a moment... The systemd developers have announce that they want the Linux kernel to break userspace. Under separate discussions they've also suggested that the kernel and systemd should upgrade in lockstep. Think of the joys that would cause for userspace. The only way that has a prayer of working is if haters like us quit building our own kernels and userspace - we take binary upgrades from our distribution maintainers. In other words, turn Linux into Windows. |
Yet at the same time, venturing into OTW, you'll notice people are under the misconception that if they target systemd, their target won't ever move despite the fact that the systemd API is anything BUT stable, they want to tie systemd to a specific kernel (and who knows what else), etc, which will result in the very fragmentation problem that it is supposedly solving according to the systemd mantra.
So, as I posted there,
| saellaven wrote: |
until you get stuck in a new era of DLL hell because foo wants systemd-4219 tied strongly to kernel 4.17 while bar is stuck on systemd 3771 tied strongly to kernel 4.13, oh and 4.17 broke your baz driver anyway. Meanwhile, 73 other packages are dependent upon different interfaces that the systemd devs may have decided overnight to remove without even going through a deprecation phase because the devs changed their mind about something overnight and completely rewrote it. pfft, who needs stable interfaces anyway?
systemd does nothing to fix the interface hell precisely because they don't believe in stable interfaces. it's yet another one of the lies from LP's self-proclaimed cabal. |
|
|
| Back to top |
|
|
Naib
Watchman
Joined: 21 May 2004
Posts: 6084
Location: Removed by Neddy
|
| Posted: Wed May 27, 2015 4:36 pm Post subject: |
|
|
| mv wrote: | | depontius wrote: | | IThere was also the announced intention by the systemd people to remove the part where the kernel sends udev events by netlink, and rely exclusively on kdbus for that function |
In case that this should really be happening: Would it be that complicated to substitute the transfer protocol of eudev? |
Why does a device manager need a transfer protocol?
Systemd argued it so it could manage the creation of nodes in some magic controlled way that udev as an atomic entity couldn't be relied upon or trusted todo.
Userland applications do not need to know how a node was created just that it exists so it can be accessed as a file - the Unix way.
So why would an alternative dynamic device manager, that is atom need some communication bus interface
_________________
#define HelloWorld int
#define Int main()
#define Return printf
#define Print return
#include <stdio>
HelloWorld Int {
Return("Hello, world!\n");
Print 0; |
|
| Back to top |
|
|
NeddySeagoon
Administrator
Joined: 05 Jul 2003
Posts: 55414
Location: 56N 3W
|
| Posted: Wed May 27, 2015 5:22 pm Post subject: |
|
|
This site is 15 years old.
Other than the corporate entity name, it looks like its coming true.
_________________
Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
| Back to top |
|
|
davidm
Guru
Joined: 26 Apr 2009
Posts: 557
Location: US
|
| Posted: Wed May 27, 2015 6:38 pm Post subject: |
|
|
| NeddySeagoon wrote: | This site is 15 years old.
Other than the corporate entity name, it looks like its coming true. |
| www.mslinux.org wrote: | | Troubleshooting Daemon: Microsoft Linux includes a new Troubleshooting Daemon (crapd) that help you zero in on a solution if you ever have a problem. |
 |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6781
|
| Posted: Thu May 28, 2015 12:02 pm Post subject: |
|
|
| Naib wrote: | | Why does a device manager need a transfer protocol? |
The kernel must communicate to the device manager which device is attached/detached. Even if this does not require much information transfer, some channel of communication must be agreed upon. |
|
| Back to top |
|
|
Naib
Watchman
Joined: 21 May 2004
Posts: 6084
Location: Removed by Neddy
|
| Posted: Thu May 28, 2015 1:10 pm Post subject: |
|
|
| mv wrote: | | Naib wrote: | | Why does a device manager need a transfer protocol? |
The kernel must communicate to the device manager which device is attached/detached. Even if this does not require much information transfer, some channel of communication must be agreed upon. |
And that is what /sys is for. It is the kernel exposing information about drivers and hardware and udev walks/monitors it to populate /dev against a predefined ruleset. So lets assume for a moment there is value in having some form of userland<>kernel communications bus so the kernel can tell udev about the hardware that exists. Sure, we can get rid of /sys and libudev can provide an API so software can query more information about devices OR userland can just access /dev.
HOWEVER... why does an init system need to jack in between this so systemd pulls the information and then pushes it to udev (or sd-device)
_________________
#define HelloWorld int
#define Int main()
#define Return printf
#define Print return
#include <stdio>
HelloWorld Int {
Return("Hello, world!\n");
Print 0; |
|
| Back to top |
|
|
depontius
Advocate
Joined: 05 May 2004
Posts: 3530
|
| Posted: Thu May 28, 2015 3:21 pm Post subject: |
|
|
[quote="Naib"] | mv wrote: | | Naib wrote: | | Why does a device manager need a transfer protocol? |
The kernel must communicate to the device manager which device is attached/detached. |
Hmmmm... I realize that this approach requires an initrd, but...
Ignore the whole netlink/kdbus communication of udev events from the kernel. Instead, inside the initrd, start some sort of "udev daemon" that hangs an inotify on the appropriate spot(s) inside /sys. When device plugging happens, the kernel changes /sys, and udevd gets wakened by inotify to handle the change.
That's 30 seconds of thought talking, spurred by your first sentence.
_________________
.sigs waste space and bandwidth |
|
| Back to top |
|
|
Tony0945
Watchman
Joined: 25 Jul 2006
Posts: 5127
Location: Illinois, USA
|
| Posted: Fri May 29, 2015 12:04 am Post subject: |
|
|
| Apparently someone posted something new here but the censors took it down. Too bad, whatever it was. |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6781
|
| Posted: Fri May 29, 2015 7:19 am Post subject: |
|
|
| depontius wrote: | | Ignore the whole netlink/kdbus communication of udev events from the kernel. Instead, inside the initrd, start some sort of "udev daemon" that hangs an inotify on the appropriate spot(s) inside /sys. When device plugging happens, the kernel changes /sys, and udevd gets wakened by inotify to handle the change. |
This is one possibility, among many others, although I suppose that you will run into severe problems with races when using sysfs exclusively: For instance, if a new USB controller becomes visible and you start parsing its tree you must be very careful that the inotify rule is already in work to get the connected devices. Or if you are just parsing such a connected device and the USB controller becomes disconnected, etc. Perhaps all can be done reliably, but it is a delicate problem. It is probably not the simplest sort of protocol for this task.
As mentioned, you need at least one protocoll to transfer the information. A change in this protocol (sysfs(+inotify?) <-> netlink <-> kdbus) certainly requires some changes in eudev (I assume that the former needs more changes than the latter), but I suppose all should be doable. |
|
| Back to top |
|
|
dmpogo
Advocate
Joined: 02 Sep 2004
Posts: 3524
Location: Canada
|
| Posted: Fri May 29, 2015 1:00 pm Post subject: |
|
|
| mv wrote: | | depontius wrote: | | Ignore the whole netlink/kdbus communication of udev events from the kernel. Instead, inside the initrd, start some sort of "udev daemon" that hangs an inotify on the appropriate spot(s) inside /sys. When device plugging happens, the kernel changes /sys, and udevd gets wakened by inotify to handle the change. |
This is one possibility, among many others, although I suppose that you will run into severe problems with races when using sysfs exclusively: For instance, if a new USB controller becomes visible and you start parsing its tree you must be very careful that the inotify rule is already in work to get the connected devices. Or if you are just parsing such a connected device and the USB controller becomes disconnected, etc. Perhaps all can be done reliably, but it is a delicate problem. It is probably not the simplest sort of protocol for this task.
As mentioned, you need at least one protocoll to transfer the information. A change in this protocol (sysfs(+inotify?) <-> netlink <-> kdbus) certainly requires some changes in eudev (I assume that the former needs more changes than the latter), but I suppose all should be doable. |
Somewhat off-topic but what I always find remarkable, is that the problem is discussed in such a general architechtural terms, but the example is always USB hotplugging. Which is becoming more and more niche technology, like DVDs reader/writers. If I think when was the last time I stuck anything in my laptop USB port, it would be months ago. How many of us forgot where their last memory stick is hiding ? And I don't think I hotplugged anything in my desktop in the last couple of years. That leaves just tablet which I ideed connect to TV via USB port on a daily basis. |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Fri May 29, 2015 1:36 pm Post subject: |
|
|
| Tony0945 wrote: | | Apparently someone posted something new here but the censors took it down. Too bad, whatever it was. |
Eh, I censored myself, as it wasn't adding anything to the conversation, and I wanted to get some notes from work to show mv, which would actually add something. Though maybe they should go in their own topic.
Basically I was saying "30 seconds thought, and even less for the first comment, resulting in two bad ideas ;)" which seemed bitchy, and not adding any light to anything; though I still think the above is a bad idea, it's better to back that up with reasoning.
So apologies for confusion; I'm trying to be a better user, is all. I think there likely is something in the criticisms I've faced; I'm not as friendly as I used to be, that's for sure, and I don't really like feeling that.
So sorry for that too, to anyone I've offended in the last 18 months of Gentoo devhell.
Last edited by steveL on Fri May 29, 2015 1:41 pm; edited 1 time in total |
|
| Back to top |
|
|
Naib
Watchman
Joined: 21 May 2004
Posts: 6084
Location: Removed by Neddy
|
| Posted: Fri May 29, 2015 1:41 pm Post subject: |
|
|
| dmpogo wrote: | | mv wrote: | | depontius wrote: | | Ignore the whole netlink/kdbus communication of udev events from the kernel. Instead, inside the initrd, start some sort of "udev daemon" that hangs an inotify on the appropriate spot(s) inside /sys. When device plugging happens, the kernel changes /sys, and udevd gets wakened by inotify to handle the change. |
This is one possibility, among many others, although I suppose that you will run into severe problems with races when using sysfs exclusively: For instance, if a new USB controller becomes visible and you start parsing its tree you must be very careful that the inotify rule is already in work to get the connected devices. Or if you are just parsing such a connected device and the USB controller becomes disconnected, etc. Perhaps all can be done reliably, but it is a delicate problem. It is probably not the simplest sort of protocol for this task.
As mentioned, you need at least one protocoll to transfer the information. A change in this protocol (sysfs(+inotify?) <-> netlink <-> kdbus) certainly requires some changes in eudev (I assume that the former needs more changes than the latter), but I suppose all should be doable. |
Somewhat off-topic but what I always find remarkable, is that the problem is discussed in such a general architechtural terms, but the example is always USB hotplugging. Which is becoming more and more niche technology, like DVDs reader/writers. If I think when was the last time I stuck anything in my laptop USB port, it would be months ago. How many of us forgot where their last memory stick is hiding ? And I don't think I hotplugged anything in my desktop in the last couple of years. That leaves just tablet which I ideed connect to TV via USB port on a daily basis. |
That's a sample of one, anecdotal evidence.
Take me for instance, at work I daily use USB memory sticks to transfer data from scope or use a piece of hardware I designed for interrogating controller cards (ftdi chip back end)
At home I am using USB for mass storage or to access an arm cortex mbed card as I sort out a python interface to a CDC device (to replace the pods used at work with a cheaper and more capable platform)
_________________
#define HelloWorld int
#define Int main()
#define Return printf
#define Print return
#include <stdio>
HelloWorld Int {
Return("Hello, world!\n");
Print 0; |
|
| 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
