3 ms·

It's what you consider nicer. I consider dialog windows to be a slow and frustrating way to configure anything and on top of that in this case it loses me the a

It's what you consider nicer. I consider dialog windows to be a slow and frustrating way to configure anything and on top of that in this case it loses me the ability for my computer to do what I want it to when I close my lid. And if it simply remained at that, but left me alone I wouldn't be so irate, but I don't feel left alone and “Who would not prefer a better looking desktop?” already borders on this “My way, of the highway.” philosophy of Freedesktop, whose developers all too often tell one that one's subjective likings are wrong and that one is somehow “wrong” or “outdated” for favoring a machine that is fast to configure and does what one wants. It also doesn't help much that on a purely visual level there design choices look ugly to me, and that these are also the same people that remove theme options lest the holy “brand identity” be compromised, as well as that their design blasts too much bright white light into my face when I'm already tiring my eyes out trying to learn to read a language that's not written in a script I'm accustomed to.

rixed 5y ago
I now realize the sarcasm was unfortunately not obvious, and I have to apologize. -- Sent from my terminal
rixed 5y ago
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 limited one for which we have a GUI... and that GUI itself has to be tested, and I'm also currently reviewing QA tools to help testing GUIs, and they basically fall in two camps: those that require one to spend a week learning how to program them, and those that are much more limited but come with a straightforward GUIs... Before systemd the same conflict happened with network-manager: my network setups were usually custom and out of reach from network-manager that I despised and purged of my desktops first thing after a fresh install. Yet with time network-manager supported more and more use cases and I'm now happy to use it. Maybe one day systemd will also make it possible to add the bits of hackery here and there and we will all be satisfied with it. For now, if so many users have it easier thanks to systemd, which seems to indeed be the case, then it's still something.
- Blikkentrekker 5y ago
  > 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 their dependency politics to try to get others to switch over. If they just designed their software how they want to and otherwise let it be, such as KDE and XFCE are doing, then they would not be drawing the same criticism, but they have a tendency of coming with a dismissive attitude to everyone who wants it different than they do and insist their way is the future and when people point out that their way does not offer functionality they need either for convenience, or their livelihood they dismiss it. > For now, if so many users have it easier thanks to systemd, which seems to indeed be the case, then it's still something. If various Red Hat projects didn't find a way to create dependencies on systemd to encourage it's adoption and systemd was simply there for the people that wanted it but left those that didn't alone, then it wouldn't be so controversial. What I quoted was “Who wouldn't want [...]”; that's the Red Hat mentality, that everyone who has subjective ideals than they either does not exist, or is wrong.
  - awrmc 5y ago
    >If they just designed their software how they want to and otherwise let it be 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.

rixed 5y ago

I now realize the sarcasm was unfortunately not obvious, and I have to apologize. -- Sent from my terminal

rixed 5y ago

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 limited one for which we have a GUI... and that GUI itself has to be tested, and I'm also currently reviewing QA tools to help testing GUIs, and they basically fall in two camps: those that require one to spend a week learning how to program them, and those that are much more limited but come with a straightforward GUIs... Before systemd the same conflict happened with network-manager: my network setups were usually custom and out of reach from network-manager that I despised and purged of my desktops first thing after a fresh install. Yet with time network-manager supported more and more use cases and I'm now happy to use it. Maybe one day systemd will also make it possible to add the bits of hackery here and there and we will all be satisfied with it. For now, if so many users have it easier thanks to systemd, which seems to indeed be the case, then it's still something.

Blikkentrekker 5y ago
> 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 their dependency politics to try to get others to switch over. If they just designed their software how they want to and otherwise let it be, such as KDE and XFCE are doing, then they would not be drawing the same criticism, but they have a tendency of coming with a dismissive attitude to everyone who wants it different than they do and insist their way is the future and when people point out that their way does not offer functionality they need either for convenience, or their livelihood they dismiss it. > For now, if so many users have it easier thanks to systemd, which seems to indeed be the case, then it's still something. If various Red Hat projects didn't find a way to create dependencies on systemd to encourage it's adoption and systemd was simply there for the people that wanted it but left those that didn't alone, then it wouldn't be so controversial. What I quoted was “Who wouldn't want [...]”; that's the Red Hat mentality, that everyone who has subjective ideals than they either does not exist, or is wrong.
- awrmc 5y ago
  >If they just designed their software how they want to and otherwise let it be 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.