6 ms·

A number of developers from RedHat were once very involved in the project. However, these developers had a very arrogant attitude towards Docker: They wanted do

A number of developers from RedHat were once very involved in the project. However, these developers had a very arrogant attitude towards Docker: They wanted docker changed so that it would follow their design ideas for RHEL and systemd. They often made pull requests with poorly written and undocumented code and then they became very agressive when those pull requests were not accepted, saying "we need this change we will ship a patched version of Docker and cause you problems on RHEL if you don't make this change in master." They were arogant and agressive, when at the same time, they had the choice of working with the Docker developers and writting quality code that could actually be merged. THIS. It was both amusing and sad to watch this happen time and time again. My favorite is what happened (or, rather, didn't happen) around CoW filesystems and how they decided to just use a FUSE-based one instead.

rconti 11y ago
Upvoted because every opportunity for me to vote against RedHat's insistence on the nightmare that is systemd is a good opportunity. Stop breaking Linux's usefulness as a server OS in a misguided attempt to make it a desktop OS. (see: systemd, networkmanager, etc)
- ambrice 11y ago
  Why do you think that systemd is not useful on a server OS?
  - nisa 11y ago
    I don't want to start this discussion but it largely comes down to taste. Some people don't want to run dbus or have no use for journald. If you put your daemons into runit you can have a small and lean image without dbus. Personally I loathe network manager in RHEL7 but that's not a systemd problem.
    - cwyers 11y ago
      I understand that there are people who don't have a use for journald. It strikes me as odd to look at journald's feature set and conclude that this is being driven primarily by desktop support to the exclusion of servers, though.
      - digi_owl 11y ago
        Frankly i suspect journald is one bother backing the other. The basic concepts journald is built on is lifted straight out of a doctorate thesis written by Lennart Poettering's brother. Thinking about i don't think systemd really have a goal. It seems to be a hodgepodge of Poettering itch scratching, Gnome/Fedora/Freedesktop NIH-ing, and a bunch of "because we can" sub-projects.
    - ambrice 11y ago
      If you don't like systemd in general that's one thing, but to claim that systemd only benefits desktops is just wrong. I'm just tired of the "systemd only goal is boot speed" argument. Too many people want to join the crowd and get their old-school linux user credentials by bashing systemd without understanding or acknowledging the benefits. sysvinit maintainers must love systemd. Before systemd came along there were lots of complaints about what a terrible hack sysvinit is. Now it's a paragon of simplicity and stability without having actually changed any..
      - erpellan 11y ago
        Yes, wouldn't a server want to depend on the DESKTOP BUS? Ok, snarky, yes. Still want to know the answer :) Also, why is it that the ONLY alternative ever mentioned is sysvinit? Systemd is not the 2nd init system ever invented, nor even the 4th or 5th. There are simpler alternatives. Binary log files? Don't even get me started.
        ambrice 11y ago
        You think if it wasn't for systemd your server wouldn't need dbus? You wouldn't be running docker on that server either..
      - crdoconnor 11y ago
        If I had a dollar for every time a systemd supporter compared it to upstart without provocation, I'd have exactly zero dollars. If I had a dollar for every time a systemd supporter reminded us that we need systemd because runsv was a terrible hack, on the other hand...
        colanderman 11y ago
        As a neutral party, one thing I'll say about systemd is at least they understand what a dependency is. I still haven't figured out why the upstart people think it's a good idea for a service to magically start just because its dependencies are fulfilled. Maybe they think system services are like proteins or something.
  - rconti 11y ago
    Because it does nothing that anyone in my organization has ever asked for, nor does it do anything that anyone in any organization I've ever worked for has asked for, in 20 years of working on Linux systems. I've never heard of any problems it solves other than things described in abstract terms that might make sense to a developer but that makes no sense to Operations/DevOps teams. Nobody likes learning something new for zero benefit. I keep trying, though. But the more I am forced to learn about it, the more arcane it gets. It's not a learning curve, as far as I can tell. It's a learning wall with no payoff. It makes everything we do more difficult, the commands make no sense, and it brings no tangible benefit. It's change for change's sake. It reminds me of DJB's insistence on making logs in hex "just because". Just a simple example. Why is it "systemctl list-unit-files"? What the hell are unit files? How is this in any way logical? Why is this an argument and not a flag? Why is it that I can use a systemctl command, and it tells me to use the -l flag to view non-ellipsized output, but then when I use the flag, it gives me an arcane error that tells me nothing about what happened? It's the tip of the iceberg in an endless string of junk that simply doesn't make any sense or work properly. So, I like to vote against it whenever I can, because supporters like to keep insisting that it's the way of the future, and implying anyone who hates it is a luddite.
    - yrro 11y ago
      > Why is it "systemctl list-unit-files"? What the hell are unit files? How is this in any way logical? I suggest you read systemd.unit(5), which begins as follows: "A unit configuration file encodes information about a service, a socket, a device, a mount point, an automount point, a swap file or partition, a start-up target, a watched file system path, a timer controlled and supervised by systemd(1), a temporary system state snapshot, a resource management slice or a group of externally created processes." > Why is this an argument and not a flag? Multi-use programs with a good CLI accept the argument(s) determining what they do positionally rather than as flags. Flags should be used for options that somehow modify the behaviour of the command. > Why is it that I can use a systemctl command, and it tells me to use the -l flag to view non-ellipsized output, but then when I use the flag, it gives me an arcane error that tells me nothing about what happened? I don't know what you mean. For me, 'systemctl list-units -l' works fine.
    - 11y ago
- tw04 11y ago
  Why on earth would you think Redhat, of all companies, wants Linux to become a desktop OS? They literally make all of their revenue on Linux server deployments.
digi_owl 11y ago
ouch, like i was not already suspicious of RH activity. Their threat sounds almost Microsoft. I have run into various claims where companies were worried they had to bend to MS wishes, or MS would start shipping a clone product.
- scurvy 11y ago
  Sounds like Microsoft from 15-20 years ago, not in the past decade.
fatherlinnux 11y ago
Red Hat does not use a FUSE based file system. It's LVM Thin-p based....

rconti 11y ago

Upvoted because every opportunity for me to vote against RedHat's insistence on the nightmare that is systemd is a good opportunity. Stop breaking Linux's usefulness as a server OS in a misguided attempt to make it a desktop OS. (see: systemd, networkmanager, etc)

ambrice 11y ago
Why do you think that systemd is not useful on a server OS?
- nisa 11y ago
  I don't want to start this discussion but it largely comes down to taste. Some people don't want to run dbus or have no use for journald. If you put your daemons into runit you can have a small and lean image without dbus. Personally I loathe network manager in RHEL7 but that's not a systemd problem.
  - cwyers 11y ago
    I understand that there are people who don't have a use for journald. It strikes me as odd to look at journald's feature set and conclude that this is being driven primarily by desktop support to the exclusion of servers, though.
    - digi_owl 11y ago
      Frankly i suspect journald is one bother backing the other. The basic concepts journald is built on is lifted straight out of a doctorate thesis written by Lennart Poettering's brother. Thinking about i don't think systemd really have a goal. It seems to be a hodgepodge of Poettering itch scratching, Gnome/Fedora/Freedesktop NIH-ing, and a bunch of "because we can" sub-projects.
  - ambrice 11y ago
    If you don't like systemd in general that's one thing, but to claim that systemd only benefits desktops is just wrong. I'm just tired of the "systemd only goal is boot speed" argument. Too many people want to join the crowd and get their old-school linux user credentials by bashing systemd without understanding or acknowledging the benefits. sysvinit maintainers must love systemd. Before systemd came along there were lots of complaints about what a terrible hack sysvinit is. Now it's a paragon of simplicity and stability without having actually changed any..
    - erpellan 11y ago
      Yes, wouldn't a server want to depend on the DESKTOP BUS? Ok, snarky, yes. Still want to know the answer :) Also, why is it that the ONLY alternative ever mentioned is sysvinit? Systemd is not the 2nd init system ever invented, nor even the 4th or 5th. There are simpler alternatives. Binary log files? Don't even get me started.
      - ambrice 11y ago
        You think if it wasn't for systemd your server wouldn't need dbus? You wouldn't be running docker on that server either..
    - crdoconnor 11y ago
      If I had a dollar for every time a systemd supporter compared it to upstart without provocation, I'd have exactly zero dollars. If I had a dollar for every time a systemd supporter reminded us that we need systemd because runsv was a terrible hack, on the other hand...
      - colanderman 11y ago
        As a neutral party, one thing I'll say about systemd is at least they understand what a dependency is. I still haven't figured out why the upstart people think it's a good idea for a service to magically start just because its dependencies are fulfilled. Maybe they think system services are like proteins or something.
- rconti 11y ago
  Because it does nothing that anyone in my organization has ever asked for, nor does it do anything that anyone in any organization I've ever worked for has asked for, in 20 years of working on Linux systems. I've never heard of any problems it solves other than things described in abstract terms that might make sense to a developer but that makes no sense to Operations/DevOps teams. Nobody likes learning something new for zero benefit. I keep trying, though. But the more I am forced to learn about it, the more arcane it gets. It's not a learning curve, as far as I can tell. It's a learning wall with no payoff. It makes everything we do more difficult, the commands make no sense, and it brings no tangible benefit. It's change for change's sake. It reminds me of DJB's insistence on making logs in hex "just because". Just a simple example. Why is it "systemctl list-unit-files"? What the hell are unit files? How is this in any way logical? Why is this an argument and not a flag? Why is it that I can use a systemctl command, and it tells me to use the -l flag to view non-ellipsized output, but then when I use the flag, it gives me an arcane error that tells me nothing about what happened? It's the tip of the iceberg in an endless string of junk that simply doesn't make any sense or work properly. So, I like to vote against it whenever I can, because supporters like to keep insisting that it's the way of the future, and implying anyone who hates it is a luddite.
  - yrro 11y ago
    > Why is it "systemctl list-unit-files"? What the hell are unit files? How is this in any way logical? I suggest you read systemd.unit(5), which begins as follows: "A unit configuration file encodes information about a service, a socket, a device, a mount point, an automount point, a swap file or partition, a start-up target, a watched file system path, a timer controlled and supervised by systemd(1), a temporary system state snapshot, a resource management slice or a group of externally created processes." > Why is this an argument and not a flag? Multi-use programs with a good CLI accept the argument(s) determining what they do positionally rather than as flags. Flags should be used for options that somehow modify the behaviour of the command. > Why is it that I can use a systemctl command, and it tells me to use the -l flag to view non-ellipsized output, but then when I use the flag, it gives me an arcane error that tells me nothing about what happened? I don't know what you mean. For me, 'systemctl list-units -l' works fine.
  - 11y ago
tw04 11y ago
Why on earth would you think Redhat, of all companies, wants Linux to become a desktop OS? They literally make all of their revenue on Linux server deployments.

digi_owl 11y ago

ouch, like i was not already suspicious of RH activity. Their threat sounds almost Microsoft. I have run into various claims where companies were worried they had to bend to MS wishes, or MS would start shipping a clone product.

scurvy 11y ago
Sounds like Microsoft from 15-20 years ago, not in the past decade.

fatherlinnux 11y ago

Red Hat does not use a FUSE based file system. It's LVM Thin-p based....