Announcement

Collapse
No announcement yet.

Kdbus Will Likely Be Merged Into The Kernel This Year

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #41
    Originally posted by clementl View Post
    That last argument was pretty understandable. I?ve worked in a computer service store for some time, and we were required to install Dutch versions of operating systems. A lot of our customers could not speak English.
    I agree about the last argument

    Originally posted by Delgarde View Post
    Stop feeding the troll!
    the troll is you (and some other fanboys)

    Comment


    • #42
      Originally posted by tomato View Post
      avahi 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!"
      I recall reading from one of the guys behind bonjour (I think it was Marc) that avahi was more nicely implemented than bonjour with regards to handling mdns, so it's far from crap software.
      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


      • #43
        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


        • #44
          Originally posted by clementl View Post
          Bit of a newby here. What is so bad about any of those?
          Nothing, each of them are superb. PulseAudio (PA) is the de facto Linux sound system (daemon). It does all kind of great stuff, like allowing per application sound levels; letting you play an old dos-game in dosbox with sound effects, while listening to music on your music player at the same time; attach some bluetooth headphone and it will magically work; it lets you stream music and do soundmixing etc. etc. So all serious desktop Linux distro's uses PulseAudio, and have done for years.

          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


          • #45
            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


            • #46
              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


              • #47
                Unity in low level areas is actually a good thing and it is what has kept Windows high up there when it comes to high performance applications.

                Comment


                • #48
                  Originally posted by lano1106 View Post
                  It should be easy to use systemd as a init process while keep using syslog.
                  Let's consider how something like that would be implemented.

                  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


                  • #49
                    Originally posted by Annabel View Post
                    I will not continue this, you started making non-arguments and strawman arguments ignoring everything I said
                    goodbye
                    You mean me? I'm sorry I brought up some arguments


                    Originally posted by lano1106
                    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.
                    Software mixing in ALSA is quite bad and uses a lot of CPU time, software mixing in pulseaudio works more ressource efficient. But I agree, one could have fixed dmix if this was the only point. By default, network access of pulseaudio is disabled. All communication is done via UNIX sockets, TCP sockets by default would be a huge waste.


                    Originally posted by lano1106
                    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.
                    No, udev is only developed in the same repository, however, can be compiled just fine without systemd support. Check how the debian package is build.

                    Originally posted by lano1106
                    systemd itself is doing his job correctly but I wish that it would be respectful to the unix philosophy.
                    Is it not? It's one tool to do it's job (and only it's job), but that very good. systemd is only about launching services in the best possible way, including socked-activated and time-triggered services.

                    Journald and logind are seperate daemons, the later, however, is nowadays tightly coupled for technical reasons.

                    Originally posted by lano1106
                    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.
                    So far, it only took over unmaintained packages (udev). The most prominent candidate which recently gained systemd-internals was logind. But then, logind has a well-defined dbus-API so it should be easy to replace.

                    Originally posted by lano1106
                    It should be easy to use systemd as a init process while keep using syslog.
                    It's not easy, it's trivial! Just enable it!

                    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 lano1106
                    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?
                    I guess systemd cares for it's users the same way. But 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.
                    Last edited by oleid; 14 February 2014, 03:07 AM.

                    Comment


                    • #50
                      Originally posted by oleid View Post
                      But 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.
                      What a bullshit argument. systemd is being shoved down everyone's throats. If someone doesn't like ubuntu's file manager, they can use one of the dozens other file managers.

                      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

                      Working...
                      X