281–290 of 332 posts
Systemd is like Windows. A monolithic one size fit all big shit. Most people will tell you that they are perfectly fine and the system is great. But they are just used to all the issues they are encountering or don't realize that they are caused by that. Lots of people are not surprised when you tell them that pulseaudio was created by the same author. Because it is kind of working in most cases. But there are always…
Earlier quoted context omitted.
> the monoculture created by systemd systemd became the de-facto default init sys because Distro Maintainers have chosen it. I posted this link here before, but I will happily post it again: https://www.reddit.com/r/archlinux/comments/4lzxs3/why_did_a... Such a thing doesn't happen if the thing offered isn't an improvement over what was before. As a matter of fact, this doesn't even happen if the thing offered is onl…
> Such a thing doesn't happen if the thing offered isn't an improvement over what was before. It does happen sometimes. GNOME3 and GTK3 didn't offer much to Linux desktop users, yet they were adopted. And improvement is subjective. Maybe systemd made maintainers' lives better. But it also introduced big nasty software full of bugs that discourages hacking by users. Many users consider that a deterioration of the Linu…
Are we thinking of the same thing? GTK3 had a much better theming system, new widgets, support for high DPI displays, improved rendering, support for animations, and a lot of other things. GNOME 3 had a much more streamlined design too. You may not have liked them but there were plenty of new features to offer.
>I'll take wrestling a bug in a 400-line shell script to wrestling a bug in the systemd C code and compiling my fixed version.
I wouldn't, once you fix the bug in the C code it's fixed for everything. The bugs in the shell scripts keep needing to be fixed over and over again, because copying code around in shell scripts is really common. There is also a line to be drawn where low-level code should be written in C and I think this is well past that line. Service script code is usually privileged and runs as root so the utility of making it hackable seems pretty small. I expect you'd agree running bash scripts inside the kernel is a bad idea too.
Earlier quoted context omitted.
> the monoculture created by systemd systemd became the de-facto default init sys because Distro Maintainers have chosen it. I posted this link here before, but I will happily post it again: https://www.reddit.com/r/archlinux/comments/4lzxs3/why_did_a... Such a thing doesn't happen if the thing offered isn't an improvement over what was before. As a matter of fact, this doesn't even happen if the thing offered is onl…
> systemd became the de-facto default init sys because Distro Maintainers have chosen it. Because they were forced to choose it due to vendorlock and many other projects became dependent on systemd. Unsystemding everything would be very expensive. Same problem will be with snap and flatpak.
Snap and flatpak are essentially just package managers, I can't see why you would expect those to be worse than any other package manager.
Earlier quoted context omitted.
I'm an open source hacker and I like systemd. Once I took the time to learn its APIs I found it does everything I expect. Your issues with XFCE and libinput don't seem to be related to systemd. I can't see how airing grievances against other unrelated projects would be a constructive place to take this discussion. Complaining about open source projects only supporting some use cases is also confusing to me. A lot of…
I have no issues with XFCE. I personally would never use i, but it also leaves me alone and it's developers don't exhibit this mentality. I have a problem with Jon McCann's famous quote, who was at the time a lead developed of GTK+, who did not know what XFCE, one of the biggest consumers of the library, even was when he made a change that broke about anything outside of GNOME. — What his language suggested was that…
https://trac.transmissionbt.com/ticket/3685
The ticket is about GNOME 3 removing support for status icons from the GNOME panel. GTK3 still has the status icon API, although they're deprecated and don't work on Wayland. That shouldn't have any effect on XFCE or any other shell with an old panel that supports the old X11 status icons. I think you can also restore the functionality to GNOME with an extension.
Also, if you check further down the issue you'll see this clarification:
>There should be no change in behavior for non-GNOME platforms.
Earlier quoted context omitted.
I have no issues with XFCE. I personally would never use i, but it also leaves me alone and it's developers don't exhibit this mentality. I have a problem with Jon McCann's famous quote, who was at the time a lead developed of GTK+, who did not know what XFCE, one of the biggest consumers of the library, even was when he made a change that broke about anything outside of GNOME. — What his language suggested was that…
This is a peculiarity of the GTK developers, not anything to do with systemd or fd.o. I maintained a popular GTK-but-explicitly-not-GNOME application long before the days of systemd and they had the same attitude.
Poettering has come with very similar claims that betray that he does not understand what people outside of his small circle want and need, the same can be said for Wayland developers, DBus, NetworkManager, PulseAudio and all such other infamous projects.
Earlier quoted context omitted.
People are writing code. The difference is that everyone outside of Red Hat an Freedesktop isn't creating artificial dependencies on each other's projects to “gently push them” so people outside of it again have to write more code to decouple them again. They did write the code to fork elongind in such a way that it no longer required systemd; they did write the code so that GNOME could run without logind like every…
> They did write the code to fork elongind in such a way that it no longer required systemd; they did write the code so that GNOME could run without logind like every other system; they did write the code to fork of udev from systemd again so that it could run without glibc. It sounds to me like the bazaar system is working fine qua its own standards, then. Red Hat writes what they need to solve their problems, party…
The difference is that Red Hat's problem is not making enough money, and everyone's problem is software not working because Red Hat breaks functionality to make more money.
Red Hat's “problems” are similar to the “problem” Apple experienced that that heir hardware was interoperable with third party hardware, so they made sure to use proprietary cables that only work with Apple hardware.
> Except: It sounds like what you really want is for Red Hat to solve your problems, not only their problems. That's definitely not how this stuff shook out historically. And it opens a door you might not want to open, because now you need to ask yourself why users liked systemd, and what obligations you have to support beyond your own needs in your own software.
No, what I want is for Red Hat to stop product tying, which you conveniently ignored and didn't address.
What they're doing isn't solving any technical problems any more than Apple is doing by using proprietary cables when standard cables suffice.
The only bit about SystemD I'm not fully sold on is D-Bus. I love that everything is exposed via D-Bus, but the C API is incredibly difficult to reason about. I've tried writing some higher-level bindings for it and it's still pretty difficult to get right. Perhaps at some point they'll switch to something that's established instead of maintaining their own IPC protocol.
- GDBus, if you're developing for GNOME
- QtDBus, if you're developing for KDE
- sd_bus, if you're writing low-level C
- zbus, if you're using Rust
For other languages, you'll want to look for bindings to one of those libraries, instead of bindings to libdbus.
Earlier quoted context omitted.
This is a peculiarity of the GTK developers, not anything to do with systemd or fd.o. I maintained a popular GTK-but-explicitly-not-GNOME application long before the days of systemd and they had the same attitude.
I believe it is common to pretty much all Red Hat and Freedesktop developers. Poettering has come with very similar claims that betray that he does not understand what people outside of his small circle want and need, the same can be said for Wayland developers, DBus, NetworkManager, PulseAudio and all such other infamous projects.
Earlier quoted context omitted.
I believe this issue of Turing complete config language vs simpler declarative configuration is one of the basic thing for which there exist no good universal solution. I face the very same issue in my day job where I'm struggling to cut the right balance between a featureful data manipulation language with which the customer can implement whatever he needs, as long as he is OK with a bit of programming, or a more li…
> I believe this issue of Turing complete config language vs simpler declarative configuration is one of the basic thing for which there exist no good universal solution. Indeed there isn't. And people that want simpler declarative configuration files can have them as far as I'm concerned. My ire is the mentality common of Red Hat employees that I am wrong for wanting traditional Unix-style flexible configuration and…
In my experience, that is what they're doing. Their software just happens to be adopted by more users because in a lot of cases it is better and does represent the future. You have that advantage when you support a lot of commercial users over a long period of time. Red Hat also has a policy of contributing a lot to upstream so that also adds to why they have success with other projects.
>If various Red Hat projects didn't find a way to create dependencies on systemd to encourage it's adoption
I think this is an exaggeration. I haven't seen any projects that have anything more than a trivial dependency on systemd to enable some optional functionality.
Earlier quoted context omitted.
> They did write the code to fork elongind in such a way that it no longer required systemd; they did write the code so that GNOME could run without logind like every other system; they did write the code to fork of udev from systemd again so that it could run without glibc. It sounds to me like the bazaar system is working fine qua its own standards, then. Red Hat writes what they need to solve their problems, party…
> It sounds to me like the bazaar system is working fine qua its own standards, then. Red Hat writes what they need to solve their problems, party X writes what they need to solve their problems, the code is shared, everyone gets what they want. The difference is that Red Hat's problem is not making enough money, and everyone's problem is software not working because Red Hat breaks functionality to make more money. R…