Announcement

Collapse
No announcement yet.

Devuan 4.0 Alpha Builds Begin For Debian 11 Without Systemd

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #91
    Originally posted by SilverFox View Post

    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.
    You are an odd cookie indeed. Brexit was brought up by me from the beginning when I explained where your misinformation about the democracy of EU came from. And I never said that you accused me of being a remainer, I specifically wrote "seemed" to point to that I was making a guess there.

    Originally posted by SilverFox View Post
    I 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.
    You have been accused of spreading myths because that is what you did in your post about democracy in the EU and about how systemd knew better than you how to run your system. I've never accused you of being a Brexiter though, I've accused you of straw-manning because you argued against arguments that I never made (you know the very definition of a straw-man).

    Originally posted by SilverFox View Post
    Yet 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.
    That Russian troll factories where behind the EU myth that you wrote about is fact. That I've been admining servers and desktops for several years is fact (it's been my line of work since 1997), that they count in the thousands are fact, that I never ever once encountered the specific problem that you described (locked out of the tty for 2mins and then your machine having a forced reboot) are facts, but then you decided to perform a straw-man that you now continue in this very comment where you pretend that my comments where about the reported issues on GitHub even though that was something that you brought up long after I wrote the comment that you are referring to.

    Originally posted by SilverFox View Post
    So, as for Straw-manning, That's all on you. You look for confrontation, Steer the argument somewhere else, And go PwN'd!
    Go read our entire comment history in this thread and you will see that the straw-manning is all on your side and the "steer the argument somewhere else" aka moving the goalposts are also all on your side. Lot's of projection going on in this post of yours.

    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


    • #92
      You've just proven what an arsehole you are. Well done. Last word is yours, Keep turning those tables.

      Comment


      • #93
        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.
        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.
        Last edited by k1e0x; 20 April 2021, 04:55 PM.

        Comment


        • #94
          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.
          So.

          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


          • #95
            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?
            GNOME issues are GNOME issues. They are not always related to GTK. So it's not like you can easily blame GTK for every GNOME issue. GNOME Shell is not even using GTK to draw interface. Of course that doesn't mean GTK is perfect - it also has issues (for example file chooser dialog).

            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


            • #96
              Originally posted by jacob View Post

              So.
              Yep, so. Do the same thing in the general sense. In general they do the same thing / can preform the same functions. You want to get into specifics and I can oblige but it's not really important in the broad scope and it's minutia to the larger issue.

              Originally posted by jacob View Post
              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.
              Kernel threads are included. User threads BSD has about 12. Linux has over 100. And when the question comes up "What is this thing doing?" It is quite a relief to see those 12 threads and know what each one is.

              Originally posted by jacob View Post
              Add equivalent capabilities to BSD and the process count will go up too.
              Nowhere near as much because it's not running 100+ systemd processes.

              Originally posted by jacob View Post
              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.
              In some sense you are right, to fully understand all the abstraction levels would be very difficult for anyone, if possible at all, who here knows real mode? Right? As a sysadmin though I can take it to the system call level so I can get a very deep level of understanding on what exactly those are doing. (or are supposed to be doing according to the programmer documentation, this is not always the same thing. lol). FreeBSD also includes a man page for each and every system call and dtrace to help you find them. Linux not so much / insert 3rd party. But... you know you don't care, that is ok. You don't have to care just understand I do, I want to know as much as I can about what a system under my control is doing. i think that is very reasonable given my job and therefore I find systemd's complexity quite unsettling. Despite using it every day.

              Originally posted by jacob View Post
              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.
              I haven't seen a line count... but I would imagine that systemd has more lines of code than FreeBSD's userland and kernel combined. But is it enough code? It appears to be. Large industries use FreeBSD in production as well. vs. Linux its better at some things, worse at others but used. For instance it's very common to see Linux VM's on NetApp's OnTap (FreeBSD based) storage arrays.

              Originally posted by jacob View Post
              Bloatware means having to deal with components and issues that are irrelevant to the task at hand.
              That is a great definition and yes, I would say a large part of systemd applies there. It *could* be used.. if someone wanted the pain and suffering but usually not. Does anyone really use homed or dozens of the other weird things in systemd? typically I bet no.

              Originally posted by jacob View Post
              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.
              ...? umm you just bloated netcat, congrats?


              Originally posted by jacob View Post
              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.
              I really don't understand this, yes you want to write code to actually daemonise the program. OpenBSD's NTPD is a good model for doing this correctly and securely and very fast and lean.. and no it is not "scripts calling scripts calling scripts" It is C. Where did you even get that idea? Probably from junk Linux stuff. I think you need to care just a little bit more about how the system works so you better understand it. Some of your opinions on things may change if you do. -- My guess is what you are thinking here is piping some shell script through a systemd socket..? like no... just.. please, you're making my head hurt. It's a very programmer way to think. "Oh, I'll just plug my gear into their gear and away I go, next task" .. and ya, thats less work.. but it's not always the most efficient approach.


              Originally posted by jacob View Post
              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.
              Or you could use a jail. BSD solved this problem 20 years ago. Linux popularized it in the last 5 years and think they invented it. Jails are *still* a better more complete, more secure sandbox than anything that exists on Linux. The more you know. - You are making the argument that you *need* systemd to do this and that is wrong. You do not. (OpenRC can do it too in Linux)


              Originally posted by jacob View Post
              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.
              BSD uses the borune shell. It's the predecessor to bash (before the GNU got it and loaded it down with god knows what) .. does it have this ability? Not sure. You aren't complete wrong here though. Personally I'm a fan of OpenRC and I support replacing RC with OpenRC in FreeBSD. (RC is already more advanced than sysVinit that Linux used though) - OpenRC is a good choice, it has the right license, it is very lean and is "just an init" not a system layer. Will this happen, it may.. many people have already used projects with OpenRC on FreeBSD (such as GhostBSD and FreeNAS) and it gives a good feature base nearly identical with the init functions of systemd like service dependencies, parallel startup, service supervision etc. Originally OpenRC was created on NetBSD also, so it's original design is BSD inspired. Gentoo has maintained it for a very long time however. If you were wondering.. No OpenRC is not "scripts on scripts" it is C.

              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 Post
              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.
              Yes, that said postfix is used to process huge amounts of email (doesn't Yahoo run it?) and it's very very popular so before you go out to reinvent all email you might want to consider what they did right, many many others tried and failed. Postfix is a survivor in a graveyard of tears.

              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.

              Comment

              Working...
              X