2 ms·

>GNOME3 and GTK3 didn't offer much to Linux desktop users, yet they were adopted. Are we thinking of the same thing? GTK3 had a much better theming system, new

by awrmc 5y ago

>GNOME3 and GTK3 didn't offer much to Linux desktop users, yet they were adopted. 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.

posix_me_less 5y ago
That was mostly feature expansion. I meant improvement of existing workflows. Maybe high DPI would count. I didn't have high DPI monitor back then, but those who did maybe were pleased. Fixing a bug in shell script, even if 30 times, is still much easier than downloading, understanding modifying and compiling and deploying 4000 files and 1.6 million lines of systemd C code. There is an obvious cost/benefit factor here. If systemd fixed just init and basic service management in correct and minimalistic way, maybe fixing its C code here and there by power users would be rational. Not with the ever-expanding pile of prototype-level software we got. I'm not reading that code, not even for money.
- awrmc 5y ago
  >That was mostly feature expansion. I meant improvement of existing workflows For desktop app developers? There were a lot of API refinements and enhancements to the widgets too, I didn't mention them all because there's far too many. >4000 files and 1.6 million lines of systemd C Just FYI these figures are incorrect, you're likely including the tests, documentation and data files. Running cloc on the current systemd code base I get around 2100 .c and .h files and 520,000 lines of C. That also includes all the other components too, not just the service manager. The service manager is a small fraction of that, it's only around 150 files including the headers. >There is an obvious cost/benefit factor here. From the perspective of a distribution I think it's much more cost effective for them to fix this once in C. To you what looks like just 30 shell scripts can quickly multiply into the thousands when you have to consider this is across all users of that distribution who might all have the same buggy set of 30 shell scripts but with different ad-hoc fixes applied. >If systemd fixed just init and basic service management in correct and minimalistic way, maybe fixing its C code here and there by power users would be rational. I think if you actually look at it, you'll find this is already what it does. That's what I saw when I actually took a few hours to familiarize myself with the code.

by awrmc 5y ago

posix_me_less 5y ago

That was mostly feature expansion. I meant improvement of existing workflows. Maybe high DPI would count. I didn't have high DPI monitor back then, but those who did maybe were pleased. Fixing a bug in shell script, even if 30 times, is still much easier than downloading, understanding modifying and compiling and deploying 4000 files and 1.6 million lines of systemd C code. There is an obvious cost/benefit factor here. If systemd fixed just init and basic service management in correct and minimalistic way, maybe fixing its C code here and there by power users would be rational. Not with the ever-expanding pile of prototype-level software we got. I'm not reading that code, not even for money.

awrmc 5y ago
>That was mostly feature expansion. I meant improvement of existing workflows For desktop app developers? There were a lot of API refinements and enhancements to the widgets too, I didn't mention them all because there's far too many. >4000 files and 1.6 million lines of systemd C Just FYI these figures are incorrect, you're likely including the tests, documentation and data files. Running cloc on the current systemd code base I get around 2100 .c and .h files and 520,000 lines of C. That also includes all the other components too, not just the service manager. The service manager is a small fraction of that, it's only around 150 files including the headers. >There is an obvious cost/benefit factor here. From the perspective of a distribution I think it's much more cost effective for them to fix this once in C. To you what looks like just 30 shell scripts can quickly multiply into the thousands when you have to consider this is across all users of that distribution who might all have the same buggy set of 30 shell scripts but with different ad-hoc fixes applied. >If systemd fixed just init and basic service management in correct and minimalistic way, maybe fixing its C code here and there by power users would be rational. I think if you actually look at it, you'll find this is already what it does. That's what I saw when I actually took a few hours to familiarize myself with the code.