Announcement

Collapse
No announcement yet.

Docker Images Are Moving From Ubuntu To Alpine Linux

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

  • Docker Images Are Moving From Ubuntu To Alpine Linux

    Phoronix: Docker Images Are Moving From Ubuntu To Alpine Linux

    Docker is reportedly going to be migrating all of their official images from an Ubuntu base to now using Alpine Linux...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    Why not systemd? It would support more dynamic things and cgroups. Also GNU libc is more battle tested and better license than musl's incompatible BSD. /ducks

    Comment


    • #3
      Originally posted by caligula View Post
      Why not systemd? It would support more dynamic things and cgroups. Also GNU libc is more battle tested and better license than musl's incompatible BSD. /ducks
      Even a cut down systemd is likely larger than openrc is. They are shooting for a sizepoint where every kilobyte matters
      All opinions are my own not those of my employer if you know who they are.

      Comment


      • #4
        Originally posted by caligula View Post
        Why not systemd? It would support more dynamic things and cgroups. Also GNU libc is more battle tested and better license than musl's incompatible BSD. /ducks
        How is BSD (or MIT, which is the musl license, I believe) incompatible? It can be paired with literally almost any license. LGPL is fine for most people, but still less compatible.

        Comment


        • #5
          Awesome, Natanael

          Comment


          • #6
            Originally posted by Palu Macil View Post
            How is BSD (or MIT, which is the musl license, I believe) incompatible? It can be paired with literally almost any license. LGPL is fine for most people, but still less compatible.
            The GNU extensions. POSIX compatible libraries only assume POSIX and not the GNU extensions. musl has wanted to keep the size down and does not include stupid additions. Users might appreciate the robustness of GNU bloat.

            Comment


            • #7
              I do not understand what images are they talking about, all official images I've being using and exploring internals used debian:jessie

              Comment


              • #8
                Originally posted by caligula View Post

                The GNU extensions. POSIX compatible libraries only assume POSIX and not the GNU extensions. musl has wanted to keep the size down and does not include stupid additions. Users might appreciate the robustness of GNU bloat.
                Depends on your definition of robustness.

                As this comparison chart shows, musl's main weak spots relative to glibc lie in not being in a hurry to implement stuff that's either legacy or of little value to a Docker container anyway, like pre-Unicode encoding support, Sun RPC, and support for processor architectures like Sparc, Alpha, and S/390.

                In fact, it's actually more robust when it comes to resource exhaustion behaviour and the reason it doesn't do symbol versioning when glibc does is because, unlike glibc, it guarantees forwards compatibility and atomic upgrades.

                (And, speaking of robustness, you may remember that, at one point, musl's creator spoke out against SystemD for being unreliable... which turned out to be because he has such high standards for reliability in system components that most developers outside the SQLite team consider them unreasonable.)

                Or, to put it another way, here's a quote from the musl fAQ:

                Is musl compatible with glibc?

                Yes and no. At both the source and binary level, musl aims for a degree of feature-compatibility, but not bug-compatibility, with glibc. When applications that work with glibc fail to compile against musl, the cause will usually be one of the following:
                • Assuming that including one header will cause symbols from another unrelated header to be exposed. This is an application bug, and fixing it is as simple as adding the missing #include directives.
                • Using implementation details from the glibc headers which were not meant to be exposed to applications. This is also an application bug, and it can usually be fixed by search-and-replace (e.g. replacing __pid_t with pid_t in the source).
                • Use of an interface that’s not implemented in musl. This can only be fixed by making the application’s use of the interface optional, or by extending musl to support the missing interface.


                Binary compatibility is much more limited, but it will steadily increase with new versions of musl. At present, some glibc-linked shared libraries can be loaded with musl, but all but the simplest glibc-linked applications will fail if musl is dropped-in in place of /lib/ld-linux.so.2.

                Comment


                • #9
                  Originally posted by caligula View Post
                  Why not systemd? It would support more dynamic things and cgroups. Also GNU libc is more battle tested and better license than musl's incompatible BSD. /ducks
                  Openrc makes use of cgroups

                  Comment


                  • #10
                    Originally posted by caligula View Post

                    The GNU extensions. POSIX compatible libraries only assume POSIX and not the GNU extensions. musl has wanted to keep the size down and does not include stupid additions. Users might appreciate the robustness of GNU bloat.
                    Oh, ok. I thought you were talking licensing with your comment on compatibility.

                    Comment

                    Working...
                    X