Announcement

Collapse
No announcement yet.

Ubuntu Still Talking About A Stable App API/ABI

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

  • Ubuntu Still Talking About A Stable App API/ABI

    Phoronix: Ubuntu Still Talking About A Stable App API/ABI

    Ubuntu developers are still exploring the possibility of coming up with a stable API/ABI for its apps...

    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
    I like the idea of releases after a LTS to be a stable API/ABI. So 14.04 would start a stable cycle including 14.10, 15.04, 15.10. 16.04 the next LTS would start the next cycle of a stable API/ABI.

    But, I don't know enough about programming to know if this would work. How would PPA's that update packages work? Would your system just have the stable API/ABI and any updates packages in a seperate folder, so at least the base was stable? Would that be a good compromise between stable while allowing newer packages?

    Comment


    • #3
      Originally posted by dh04000 View Post
      I like the idea of releases after a LTS to be a stable API/ABI. So 14.04 would start a stable cycle including 14.10, 15.04, 15.10. 16.04 the next LTS would start the next cycle of a stable API/ABI.

      But, I don't know enough about programming to know if this would work. How would PPA's that update packages work? Would your system just have the stable API/ABI and any updates packages in a seperate folder, so at least the base was stable? Would that be a good compromise between stable while allowing newer packages?
      well basically is really hard to accomplish, basically you have to freeze every library that will be exposed to devs forever and to reach ABI stability you cannot allow any new symbol to be exposed at runtime carelesly or the linker will throw exception due to undefined symbols in the binary.

      to reach this you only have 3 realistic solutions:
      1.) multi version libraries at build like windows[mega mess of libraries + im not sure elf support it at all]
      2.) canonical create an unique library that expose the desired API to hide all symbols changes behind[LOOOOOT of work and high chances of hell breaking loose in the future]
      3.) force the package process when building apps to deep static build[LOOOOOOOT of redundancy and disk waste]

      ofc they can pull a redhat and change the LTS release cycle to 5 years and expose their paid apps store only on LTS versions of ubuntu

      Comment


      • #4
        What about static binaries, with FS deduplication support. I really like how Golang works.

        Comment


        • #5
          Originally posted by Drago View Post
          What about static binaries, with FS deduplication support. I really like how Golang works.
          that could work but i think normal dedup won't work effectively on binaries especially with different symbol versions of the same libraries, vtables, mangles, etc

          Comment


          • #6
            This is exactly why a modern windows installation hits the 20 gigabytes...

            Comment


            • #7
              or you could just write programs using GLFW and GLes
              90% problems solved

              Comment


              • #8
                Originally posted by doom_Oo7 View Post
                This is exactly why a modern windows installation hits the 20 gigabytes...
                Yes, and the dynamic linker on windows does a LOT of work dealing with the DLL hell.
                A stable ABI sounds a good idea but to me it is just unrealistic for most communities -- they really don't have so many people to maintain a stable interface.

                Comment


                • #9
                  Originally posted by zxy_thf View Post
                  Yes, and the dynamic linker on windows does a LOT of work dealing with the DLL hell.
                  A stable ABI sounds a good idea but to me it is just unrealistic for most communities -- they really don't have so many people to maintain a stable interface.
                  It looks like we're between a rock and a hard place here because:
                  A changing ABI is just unrealistic for most communities -- they really don't have so many people to maintain all the programs, packages when something changes to update them to the new ABI, API.

                  Comment


                  • #10
                    "Forever" is stupid, a smart promise is like 5-15 years.

                    Comment

                    Working...
                    X