Originally posted by F.Ultra
View Post
Announcement
Collapse
No announcement yet.
Devuan 4.0 Alpha Builds Begin For Debian 11 Without Systemd
Collapse
X
-
-
Originally posted by k1e0x View Post
Sure.
FreeBSD 13: ps -A | wc -l
42
Ubuntu Server: ps -A | wc -l
237
All default, no extras added.
Comment
-
Originally posted by SilverFox
Now, who's straw manning? Brexit was never brought up until now by yourself, And nowhere in my posts have i accused you of being a remainer. There are other countries in the EU that have plenty of dislike for Brussels, Other than the UK.
Originally posted by SilverFoxI compared systemd, Because of the issue I've mentioned, And I've been accused of spreading Myths and lies, being a brexiter and straw-manning because of it.
Originally posted by SilverFoxYet there you are, Spreading myths and lies about Brexit, (Russian involvement), And the FUD you made over several years and thousands of system's that somehow have managed to bypass all of those issues reported to systemd's git, Some of those have been very important security issues that would off affected all of those systems.
Originally posted by SilverFoxSo, as for Straw-manning, That's all on you. You look for confrontation, Steer the argument somewhere else, And go PwN'd!
Perhaps you should just pause for a moment and realise that you cannot just throw out accusations left and right just because you are angry or that you don't agree with what was written. Or you can, but they you will be called out for it.
Comment
-
Originally posted by jacob View Post
And.....? Firstly you are counting the total number of processes in the OS, which has basically nothing to do with whether systemd us "bloated" or not. Secondly if your point is that somehow less processes=better then your ideal is obviously MS-DOS.
And both systems can do the same job. Same job + less complex is yes, less bloated.Last edited by k1e0x; 20 April 2021, 04:55 PM.
Comment
-
Originally posted by k1e0x View Post
It's just the complexity of the system. I can say for sure I know what all 42 process on FreeBSD are doing. The same isn't true for any systemd system.. And that is unsettling to me, I like knowing exactly what the system is doing.. don't you?
And both systems can do the same job. Same job + less complex is yes, less bloated.
On Linux systems, "ps -A" includes kernel threads. I don't know whether it does on FreeBSD; if not, the comparison is meaningless from the start. Whether the systems "can do" the same job is also meaningless, what counts is whether they *do* the same job at the same time. An out of the box Ubuntu Server installation has various things enabled including Avahi etc, it runs systemd-logind so that it can finally have a sane notion of user sessions, etc. Add equivalent capabilities to BSD and the process count will go up too.
Do I care about each precise service running on my system? No, not particularly. I don't know and neither do you what each individual kernel routine does (nobody in the world does because the complexity exceeds the comprehension capabilities of a human brain), which is infinitely more important than some random userland process. What matters is whether what is running is open source, i.e. do I have the ability to audit it should I have any concerns. The answers is YES in both cases and that's enough for me. You don't know what these services are doing anyway unless you audited their code, did you? There are some thing I did audit because they have a particular importance in my use case; for the rest I'm happy with the knowledge that all the source code is there in the open.
Then you seem to be coming from the idea that more services implies more code implies bloatware, but to a large degree, that is a fallacy. Bloatware means having to deal with components and issues that are irrelevant to the task at hand. If I want to write a TCP server that expects a "hello" message and responds "world", on Ubuntu I simply accept a socket from systemd, wait for input and send a response. On a non-systemd OS including ***BSD, I have to write the whole code to actually daemonise the program, open and manage the socket, all of which is notoriously brittle and error prone. Of course every single service does it its own way and differently and it's implemented in scripts calling scripts calling scripts rather than declaratively. That's real bloatware for you. If I want the service to run with low privileges and sandboxed (which is common sense), with systemd it's done declaratively in a matter of seconds. In BSD there is no obvious way to do that except again hack it together in a sticky tape script. Having to use a Turing complete language for a task like that would be bad enough but not only is the unix shell the most insecure and error prone programming language ever devised, it also includes its own built-in job manager and even networking capabilities (at least bash on Linux absolutely does, I don't know about BSD shells), all that to start or stop a service - which it can't really identify, so it needs to keep PID files that may or may not be correct depending on your race condition lottery chances. Now we're talking bloatware.
If you want to see some real world class bloatware, check out postfix: while it doesn't do half of what a modern MTA should (DKIM validation, SPF, DMARC etc.), it must implement its own socket manager, its own service supervisor and even its own poor man's sandbox/container ersatz. With systemd, the OS provides all those features out of the box to anyone who needs them and postfix could focus on being an actual fully functional MTA that doesn't need tons of additional bloatware on top of its own to be usable.
Comment
-
Originally posted by skeevy420 View Post
Both. There's enough overlap in regards to their design trends and developers working on them that they come off as one and the same; especially if you're a casual.
It's their responsibility up to a point. Much like KDE and Qt have tried to cater to GTK and GNOME, GNOME and GTK have to try to cater to others. That's why in KDE you can change one theme and both Qt and GTK programs will be themed. Best with GNOME is flipping on Dark Mode. KDE also comes with a built-in tool that brings in themes from all sorts of developers, not just themes from the KDE devs (it's hit and miss if we're being honest, but it's there by default). On GNOME I have to know about the right packages to install, the right web site, install web browser plugins, and then install themes and stuff (and like KDE: it's hit and miss if we're being honest). So to answer the question of "Why would you limit yourself to the things created by GNOME developers?": Because that's how GNOME developers want it done. They don't include the tools to tweak it.
Why blame them for CSD? Because people have tried to bring up SSD work in the past and upstream never accepts. Libadwaita is also a very recent thing that I am very excited for and was created to address a lot of the complaints I'm raising. While yes it does exist, it hasn't been around long enough to matter in a significant manner. Perhaps in a year's time that'll be more of an argument one way or the other -- we just have to wait and see what all happens. But that exists because enough people have had the same complaints that I'm having. Hopefully it will revert the G in GTK from GNOME back to GIMP. Would be cool if libadwaita spearheaded GTK4 to pick up things like libwindows, libqt, libefl, and other things where a properly written program could change system UI styles and increase how cross-platform GTK is. Like I said, that's actually something I'm excited for.
This is just me and I'm not trying to start something here, but something about MATE and Cinnamon just feels off. It's weird because I like that design style, but just not those environments. I think most of it is because cut my teeth on GNOME2 and the GNOME2 style in GTK3 is just weird to me. It just never has seemed right. I suppose I get nostalgic for the old way I preferred and just have to use something else. Does that make sense?
I agree with you on that. But the fact GNOME developers don't want to improve other toolkits integration with GNOME is not GTK issue. Yes, GNOME developers are not willing to support things outside their vision but they won't block you from using them. It's still possible to change GTK appearance by themes. It's still possible to change GNOME appearance or behavior by extensions. It's still there and I think it won't go nowhere in near future. So why the fact GNOME developers want something else than you would block you from doing it your way anyway? Do you need their permission or support to use desktop like you want? No, you don't need it and they won't block you from doing things your way.
GTK never removed SSD support - there is environmental variable GTK_CSD - but I thinks it works only for applications that aren't using headerbar. As far I know patches like gtk3-nocsd forced SSD usage on all applications using headerbar widget and it was probably not accepted upstream because headerbar sense heavily relies on CSD. I can agree with you with this one because I think GTK_CSD option should also force SSD on headerbar applications. But also the fact is there is no any requirement to use headerbar widget. It's not even enabled by default, if you want it in your application you have to enable it. Nothing stops you from ignoring it and making traditional GTK application - that's what MATE and Cinnamon desktops applications are doing. On GTK4 situation looks the same and there were even some changes to make creating toolbars easier. Libadwaita won't remove CSD and headerbar support from GTK because there is no reason to remove optional things. CSD is also not GNOME invention. It was used before GNOME and it still used in other environments.
Of course GNOME is popular desktop and that's why many independent developers decide to follow GNOME style in their applications. Same goes for Qt applications - if you prefer Qt applications then you would probably be more comfortable with Qt desktop.
Comment
-
Originally posted by jacob View Post
So.
Originally posted by jacob View PostOn Linux systems, "ps -A" includes kernel threads. I don't know whether it does on FreeBSD; if not, the comparison is meaningless from the start.
Originally posted by jacob View PostAdd equivalent capabilities to BSD and the process count will go up too.
Originally posted by jacob View PostDo I care about each precise service running on my system? No, not particularly. I don't know and neither do you what each individual kernel routine does (nobody in the world does because the complexity exceeds the comprehension capabilities of a human brain), which is infinitely more important than some random userland process.
Originally posted by jacob View PostThen you seem to be coming from the idea that more services implies more code implies bloatware, but to a large degree, that is a fallacy.
Originally posted by jacob View PostBloatware means having to deal with components and issues that are irrelevant to the task at hand.
Originally posted by jacob View PostIf I want to write a TCP server that expects a "hello" message and responds "world", on Ubuntu I simply accept a socket from systemd, wait for input and send a response.
Originally posted by jacob View PostOn a non-systemd OS including ***BSD, I have to write the whole code to actually daemonise the program, open and manage the socket, all of which is notoriously brittle and error prone. Of course every single service does it its own way and differently and it's implemented in scripts calling scripts calling scripts rather than declaratively. That's real bloatware for you.
Originally posted by jacob View PostIf I want the service to run with low privileges and sandboxed (which is common sense), with systemd it's done declaratively in a matter of seconds. In BSD there is no obvious way to do that except again hack it together in a sticky tape script.
Originally posted by jacob View Postnot only is the unix shell the most insecure and error prone programming language ever devised, it also includes its own built-in job manager and even networking capabilities (at least bash on Linux absolutely does, I don't know about BSD shells). all that to start or stop a service - which it can't really identify, so it needs to keep PID files that may or may not be correct depending on your race condition lottery chances. Now we're talking bloatware.
FreeBSD does have plains for system layer improvements also, but those improvements are being done in the kernel itself, this is actually preferred because for instance if a message transport is in the kernel and not userland you can trust the uid calling a process. DBUS has a lot of problems being in userland also. So ideas are out there on ways to do this better than systemd.
Originally posted by jacob View PostIf you want to see some real world class bloatware, check out postfix: while it doesn't do half of what a modern MTA should (DKIM validation, SPF, DMARC etc.), it must implement its own socket manager, its own service supervisor and even its own poor man's sandbox/container ersatz. With systemd, the OS provides all those features out of the box to anyone who needs them and postfix could focus on being an actual fully functional MTA that doesn't need tons of additional bloatware on top of its own to be usable.
Again all not that important to the larger scope of things and I revert to my original point of.. it's just overly complicated and I don't like it.
I don't know many sysadmins that do. Programmers seem to like it, sysadmins in my experience hate it. Unfortunately programmers write this stuff.Last edited by k1e0x; 22 April 2021, 08:24 PM.
- Likes 1
Comment
Comment