Announcement
Collapse
No announcement yet.
Kdbus Will Likely Be Merged Into The Kernel This Year
Collapse
X
-
Originally posted by tomato View Postavahi is implementation of Apple protocol, Bonjour, and while it is nice, it is a security nightmare
early implementations of Pulseaudio were very, very, very buggy, to the point that people were considering piping to /dev/dsp was actually an improvement
systemd is just "Waah, waah, my world is changing and I don't like it! I don't want to learn new stuff that will make my life easier in the medium to long term!"
PA wasn't responsible for those breaks, mostly, it only exposed problems with alsa. The far better state alsa is in now can be attributed, somewhat at least, to correctness of PA.
Comment
-
I have seen in internet trolls against lenart pottering, the most of them are mad, seriously, they tend to argument with some crap like "I'm in linux since 15 years ago, i admin thousand of machines, etc." and are so rage always ( Could be the same guy look the debian cmte list for an example )
I have learned about unix socket and are very good, i guess this is something diferent, i hope they will come with improvement, i loved the IPC of posix systems
Comment
-
Originally posted by clementl View PostBit of a newby here. What is so bad about any of those?
PA really saved sound on Linux when it came; there where no functional system-wide sound system at the time, and everything sound related was hard to program for and to use too.
Avahi is the standard Linux implementation of zeroconf. It just works and is used by all the major Linux distros I know of.
systemd is the new de facto Linux plumbing system; it is both a technical superior init-system, but is also a new distro agnostic compatibility layer for all user programmers to target. So all the major Desktop Environments, like KDE, Gnome, LXQT etc, are starting to develop against it.
Some people don't like systemd, or PA, so they have for years tried a smearing campaign against lead Linux developer Lennart Poettering. The huff and puff, and rant and sneer, and troll, and troll, and troll. But people just laugh at them, since they are all rant and no coding skills whatsoever.
They don't like systemd, but they are unable to develop any alternative to it, and most pathetic off all, unable to even maintain critical existing infrastructure like ConsoleKit. If you don't want to use systemd on your Desktop PC, you have to use ConsoleKit, but no-one have bothered to maintain it for +1? years. It shows that the systemd opponents just a small noisy bunch with very limited technical abilities.
Kdbus is the newest addition to the future Linux development stack, that consist of systemd, Wayland, cgroups, and soon, kdbus too. Kdbus is developed with the help of the systemd developers, which is the reason why the systemd-detractors hates it even though they barely know what it is.
Anyway, kdbus will be used to (among many things), sandboxing applications, so even though you browser gets hijacked, the Trojan is unable to escape from there. Good stuff.
Comment
-
not sure about you guys but this is great
Kdbus has been very helpful in my system control experiments with the leap motion controller, work everything in your api and then simply call the dbus command to kde/window manager
being built into the kernal makes it great for simmilar programs to make calls
on a side note though it would be better for something on top to take care of this so i dont need to update everything every time a dbus command changes on the system
Comment
-
I do not like PA because plain ALSA fully meets my needs. IMO, a mixing software that has builtin functionality to send audio over the internet is just a security hole waiting to be exploited.
but then I'm fine with it because I am free to not use it.
My problem with systemd it is that it is pretty much imposed. I haven't checked myself but I have read that udev is pretty much coupled with systemd making it hard to offer and maintain an alternative.
systemd itself is doing his job correctly but I wish that it would be respectful to the unix philosophy.
The fact that it just keep growing and takes over many critical system functionnality without making it easy to cherrypick alternatives is what is pissing me off and probably many other systemd haters. This is what makes it being call a cancer.
It should be easy to use systemd as a init process while keep using syslog.
Heck, glibc dev delibarate for weeks before changing internal details to not break valgrind or other system tools.
Why can't the systemd devs be more considerate with people that do not want everything centralized into a single point of failure like Windows like they seem to aim?
Comment
-
Originally posted by lano1106 View PostIt should be easy to use systemd as a init process while keep using syslog.
It doesn't make sense for systemd to support both journald and syslog directly. If you expect every journald client to support two logging interfaces, then that's a whole lot of code duplication. The abstraction should really be shared between all journald clients.
The proper way to do it would be to write a journald shim which exposes the journald interface, but throws out the extra information and outputs syslog files.
That should be fairly trivial. All you need to do is find somebody interested in doing it. The fact that no such person has materialized perhaps suggests that there's not really a lot of interest in using systemd with syslog.
Comment
-
Originally posted by Annabel View PostI will not continue this, you started making non-arguments and strawman arguments ignoring everything I said
goodbye
Originally posted by lano1106I do not like PA because plain ALSA fully meets my needs. IMO, a mixing software that has builtin functionality to send audio over the internet is just a security hole waiting to be exploited. but then I'm fine with it because I am free to not use it.
Originally posted by lano1106My problem with systemd it is that it is pretty much imposed. I haven't checked myself but I have read that udev is pretty much coupled with systemd making it hard to offer and maintain an alternative.
Originally posted by lano1106systemd itself is doing his job correctly but I wish that it would be respectful to the unix philosophy.
Journald and logind are seperate daemons, the later, however, is nowadays tightly coupled for technical reasons.
Originally posted by lano1106The fact that it just keep growing and takes over many critical system functionnality without making it easy to cherrypick alternatives is what is pissing me off and probably many other systemd haters. This is what makes it being call a cancer.
Originally posted by lano1106It should be easy to use systemd as a init process while keep using syslog.
systemctl enable rsyslogd
systemctl start rsyslogd # or reboot
Done! At this point both journald and syslog will do the logging. You can disable journald's storage in it's configuration file if you wish, then it keeps some log lines in memory, only for output at e.g.
systemctl status rsyslogd
Originally posted by lano1106Heck, glibc dev delibarate for weeks before changing internal details to not break valgrind or other system tools.
Why can't the systemd devs be more considerate with people that do not want everything centralized into a single point of failure like Windows like they seem to aim?Last edited by oleid; 14 February 2014, 03:07 AM.
Comment
-
Originally posted by oleid View PostBut why should the systemd developers do the programming for people which don't want to use systemd? It's as if you ask the Ubuntu developers to create a port of their file manager to the toolkit "TK" in order to make Annabel happy.
But, if one doesn't like systemd, will it be possible to use Linux (in the very near future), without being forced to used systemd?
Currently, it is possible. But, the way things are going, I am not sure if it will be possible in the future.
Comment
Comment