Announcement

Collapse
No announcement yet.

Linux Kernel Developers Fed Up With Ridiculous Bugs In Systemd

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

  • Originally posted by GreatEmerald View Post
    I always assumed there were argument parsing libraries out there? Most command-line utilities seem to have pretty unified argument passing rules.
    But yea, writing those is annoying. I usually end up with some pretty lame things, like (in D) if (args.canFind("-h")) writeln("Usage: -h Display this help string"); which means that having "-h" anywhere in the argument line would cause it to display a message and quit (and I usually can't be bothered to come up with more sophisticated methods for simple programs).
    hm, actually I don't know on that front, I typically just parse them using a method like you're using in the main loop. I've never actually thought to look for a library for it.

    That said I was actually talking string parsing as a general input methodology, not just the command line args, but things like commands at a prompt (at least GUIs let me apply input masks), and loading in files. You can rather quickly devolve into parser hell where you're fighting off endless corner cases if you're having to read in a non-standardized or even broken formatting (I can only begin to imagine the pain of those who have to write parsers for HTML...) with documents that aren't well formed. Even worse if some asshat decided that he wanted to write all of the input by error-prone hand in a basic text editor instead of doing machine generation or at the very least a validating editor.

    This is where XML and JSON come in, they're nice (and most importantly) strictly standardized data formats with serializers/deserializers available for most if not all of the important languages out there, and if you use data contracts in your classes things become even nicer still. Using DataContract{Json,Xml}{Serializer,Deserializer}s in C# is just awesome, all you have to do is annotate your class and it works, and really... what reason do you have with text files to not being using one or the other?

    Comment


    • Originally posted by chrisb View Post
      You have a problem. So you add XML to the kernel. Now, you have two problems.

      echo 1 > /proc/sys/net/ipv4/ip_forward

      It's simple, it works across languages, and is easy to do from an interactive shell. I don't want to have to write structured binary data, or well formed XML or JSON, in order to change a simple kernel setting.
      because you can't be bothered to open up a text editor to change a property?

      Although the real answer here is for you to not be manipulating it directly by hand in an error-prone fashion but for tools to be written to handle this that handle the actual manipulation of kernel settings safely for you. Something along the lines of:
      Code:
      procctl set sys.net.ipv4.ip_forward enable
      .

      Comment


      • Originally posted by curaga View Post
        Did you hear the kernel oopses will be output as QR codes in the future?
        heh to be honest as long as the kernel infrastructure is set up to take automatic bug reports based off of them, and you can get it to be read reliably enough by a smartphone that's actually not that bad of an idea.

        Comment


        • Originally posted by Luke_Wolf View Post
          because you can't be bothered to open up a text editor to change a property?

          Although the real answer here is for you to not be manipulating it directly by hand in an error-prone fashion but for tools to be written to handle this that handle the actual manipulation of kernel settings safely for you. Something along the lines of:
          Code:
          procctl set sys.net.ipv4.ip_forward enable
          .
          You can do this today with sysctl. That is the UNIX way of doing it.

          Comment


          • Originally posted by RahulSundaram View Post
            I wouldn't call that toleration. It is a basic requirement. In any open source community, no individual contributor should be allowed to dictate what others maintain. This is especially true of integration projects where there are no defaults.
            We were not talking about me. We were talking about every other Gentoo developer. If every other Gentoo developer did not think like me, you can be certain systemd would not be permitted in the tree. Myself and many others are willing to tolerate systemd because we do not believe in trying to force our choices on users. If we did, we would keep systemd out of the tree in favor of our own home grown replacement for sysvrc, which is where the actual criticisms belong. That would be much like how Redhat keeps alternative choices out of its distributions.

            Anyway, you might want to take a look at your own company with regard to individual contributors being allowed to dictate what others maintain. If you cannot find examples of that happening, you are blind. It happens at every company, including Redhat.
            Last edited by ryao; 03 April 2014, 07:05 PM.

            Comment


            • Originally posted by Ericg View Post
              Almost, if not EVERY, non systemd-core component of systemd can be turned off at compile time with a --disable-$XYZ flag except MAYBE the journal. I think a barebones systemd is like 2mb's. Thats always why all of us who support systemd have wanted to strangle everyone who shouts "Systemd is bloated! Systemd isn't modular!" because the reality is you can customize and cut down systemd to WHATEVER you need it to be. Want everything? Bam. Done. Got an embedded system that you just want systemd, journal and networkd? Bam. done.
              If your system has only 4MB of storage, 2MB is half of it. The kernel itself is typically 2-3MB on such systems. If you add systemd, your OS will no longer fit on the system. Also, it is not clear if the 2MB figure is just for systemd, or for systemd and all shared object dependencies.

              Anyway, you cannot do more than sysvinit, which is simply /sbin/init and /etc/inittab, while being competitive on space. It is not worth even trying.

              Comment


              • Originally posted by ryao View Post
                We were not talking about me. We were talking about every other Gentoo developer. If every other Gentoo developer did not think like me, you can be certain systemd would not be permitted in the tree.
                Regardless of who you were talking about, the fundamental principle still applies. As a project you can choose to exclude anything you want but as a individual noone should be allowed to dictate what other people do.

                PS: I don't work for Red Hat and even if it happens there (I noticed you didn't single out any examples), that is no excuse for any open source project to behave as if letting other maintainers do what they want to do is "toleration". If it doesn't affect you, it isn't tolerating anything. Period.

                Comment


                • Originally posted by ryao View Post
                  If your system has only 4MB of storage, 2MB is half of it. The kernel itself is typically 2-3MB on such systems. If you add systemd, your OS will no longer fit on the system.
                  Why would anyone install a full-blown init system on such minimal hardware? Systemd is designed for the needs of anything ranging from server clusters to mobile and IVI, but I doubt you'd be running anything complex enough on that 4MB system that couldn't be handled with a minimal, custom-made init. In other words your argument is purely academic.

                  Comment


                  • Originally posted by ryao View Post
                    If your system has only 4MB of storage, 2MB is half of it. The kernel itself is typically 2-3MB on such systems. If you add systemd, your OS will no longer fit on the system. Also, it is not clear if the 2MB figure is just for systemd, or for systemd and all shared object dependencies.

                    Anyway, you cannot do more than sysvinit, which is simply /sbin/init and /etc/inittab, while being competitive on space. It is not worth even trying.
                    An old project won't be upgrading to systemd, so thats out of the question. So, just as I brought up in a previous thread, lets assume a new project thats currently under development needs to place a bit of flash storage on itself. I have a router sitting next to me that has 256Mb's of RAM and 32mb's of flash storage. So let's call 32mb a bare minimum for what you can find in newly manufactured flash. Frankly I'm shocked its not higher.

                    If you are SO strapped for storage or size constraints that you are working off of 32mb's of storage... you probably won't be using systemd. Frankly at that size you have to be cutting and slashing as much of the kernel as you can. You are into highly specialized territory, and if you are -IN- that territory then you probably can roll your own init system, OR your entire process tree is like 3 processes top that you can just track yourself.

                    I have a thumb drive sitting next to me about the size of my thumb nail...its got 4gigs of storage available to it. If you're limiting yourself to 32mb's of storage its either because you KNOW what you're doing, or you're a masochist.

                    But lets assume you're right Ryao, just for sake of argument. Let's give you 4Mb's of storage space and lets be kind and say the kernel fits into 2mb's of that.. what the HELL are you doing with 2mb's? You can't write a secure web server in 2mb's of space, so thats out. 2mb's of storage you're into the "I'm coding in pure C and I need to start cherry-picking functions of the libraries I want to use, including them all in one header file with 1 C source file to handle everything and I need to make sure its written in as few lines as humanly possible." because 90% of the third party libraries on our systems that actually DO anything useful are prob more than 1mb in size, which even if the ONE you needed WAS 1mb in size that only gives you 1mb to play around with to do whatever it is you need to do. Talk about single purpose hardware, and I don't say that with affection.

                    Also for the record, systemd depends upon the kernel and dbus and I think thats it. And as soon as kdbus lands it will be down to just "the kernel".
                    All opinions are my own not those of my employer if you know who they are.

                    Comment


                    • Originally posted by Ericg View Post
                      An old project won't be upgrading to systemd, so thats out of the question. So, just as I brought up in a previous thread, lets assume a new project thats currently under development needs to place a bit of flash storage on itself. I have a router sitting next to me that has 256Mb's of RAM and 32mb's of flash storage. So let's call 32mb a bare minimum for what you can find in newly manufactured flash. Frankly I'm shocked its not higher.

                      If you are SO strapped for storage or size constraints that you are working off of 32mb's of storage... you probably won't be using systemd. Frankly at that size you have to be cutting and slashing as much of the kernel as you can. You are into highly specialized territory, and if you are -IN- that territory then you probably can roll your own init system, OR your entire process tree is like 3 processes top that you can just track yourself.

                      I have a thumb drive sitting next to me about the size of my thumb nail...its got 4gigs of storage available to it. If you're limiting yourself to 32mb's of storage its either because you KNOW what you're doing, or you're a masochist.

                      But lets assume you're right Ryao, just for sake of argument. Let's give you 4Mb's of storage space and lets be kind and say the kernel fits into 2mb's of that.. what the HELL are you doing with 2mb's? You can't write a secure web server in 2mb's of space, so thats out. 2mb's of storage you're into the "I'm coding in pure C and I need to start cherry-picking functions of the libraries I want to use, including them all in one header file with 1 C source file to handle everything and I need to make sure its written in as few lines as humanly possible." because 90% of the third party libraries on our systems that actually DO anything useful are prob more than 1mb in size, which even if the ONE you needed WAS 1mb in size that only gives you 1mb to play around with to do whatever it is you need to do. Talk about single purpose hardware, and I don't say that with affection.

                      Also for the record, systemd depends upon the kernel and dbus and I think thats it. And as soon as kdbus lands it will be down to just "the kernel".
                      He was just trolling. I checked my router and it has 64 MB of flash. So.. machines that have 4 MB of storage are obsolete crap. Don't use them. You can't fit anything there, barely even the kernel fits. So buy bigger flash, it's cheap nowadays. Systemd fits nicely in 64 MB.

                      Comment

                      Working...
                      X