Announcement

Collapse
No announcement yet.

Why Linux Appears Fragmented:

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

  • #31
    Bring us teh heretic's head!!!!! >



    Comment


    • #32
      The question 'which format to use' was answered many years ago.

      Read the LSB.

      It is rpm.

      Comment


      • #33
        Originally posted by monraaf View Post
        He's a smart man. The last thing Ubuntu could use is more friction between Ubuntu and the rest of the Linux community.
        Heh... There's wisdom there in his remark- and you caught it as did I.

        Comment


        • #34
          Originally posted by energyman View Post
          The question 'which format to use' was answered many years ago.

          Read the LSB.

          It is rpm.
          And nobody cares about that part of the LSB. Doesn't really solve anything, does it? The question may have been answered by someone, but no action was taken. Ubuntu has the market share to actually force the decision.

          LSB is currently like XHTML. The biggest player doesn't care about it. The W3C learned that they had to listen to the actual parties involved to create a standard that everybody wants to implement. The most important thing about HTML 5 is specifying Internet Explorer's actual behaviour. The most important thing about the LSB will also have to be specifying actual behaviour.

          Comment


          • #35
            Originally posted by nanonyme View Post
            Actually iirc Linux Standard Base agreed on using RPM as the de facto package type, this just made Debianists scream so loudly that DEB was added too although RPM is still primary package type. Then again, LSB seems to have died off too.
            Unfortunately, LSB didn't fix any of the REAL problems that a proprietary developer would face shipping binaries to a large suite of people.

            All it did was insure that you had a defined packaging format, a defined directory structure and explicit places for binary and config files, and a rigidly defined minimum set of .so's and command binaries that one could expect to be on the system if it was in an LSB compliant configuration. In and of itself, that sort-of/sort-of-not helps a developer. For starters, someone could be trimming their system down- LSB makes a system configuration HUGE. Carrier Grade Linux could be VASTLY smaller if it weren't for the braindead mass LSB presents- because there's no subsets of things. It's all LSB or not. And that doesn't get into the fact that LSB wasn't designed with an end-user in mind, though it mostly worked out that way- it was intended for server stuff.

            Now, you've got this whole lot. After dragging all sorts of crap you don't need and the server world does (and vice-versa after a fashion...) you'd think that you'd be able to ship binaries to more than Red Hat, SuSE, and so forth, right? WRONG. An LSB compliant RPM MIGHT work out well, might not. What's the problem? Well...as an example, you might have libpng on there, but instead of 1.2, they have 1.4 on there (heh...)- and your binary is looking for or linked against 1.2. Your binary will FAIL at that point. So, they make binaries against each of the LSB compliant distributions or make a single one and cross their fingers- or they do the additional steps of doing what we've done with Caster or similar stuff to ensure the binary works.

            Packaging is the least of your concerns and all LSB really does is insist upon a packaging and a place to put things- and provides what MIGHT be the right mix for your application upon install.

            Comment


            • #36
              Originally posted by Svartalf View Post
              Packaging is the least of your concerns and all LSB really does is insist upon a packaging and a place to put things- and provides what MIGHT be the right mix for your application upon install.
              That's why this cadence plan of Mark Shuttleworth is so important. And that's something the LSB should specify, too: an annual or biannual release of the LSB which specifies which versions of packages have to be supported. Other versions can be provided as well, but the LSB specifies a baseline.

              Comment


              • #37
                Originally posted by Remco View Post
                That's why this cadence plan of Mark Shuttleworth is so important. And that's something the LSB should specify, too: an annual or biannual release of the LSB which specifies which versions of packages have to be supported. Other versions can be provided as well, but the LSB specifies a baseline.
                It's specifying too LARGE of a baseline. It's monolithic where it needs to be in chunks. Basline verss server versus desktop profile- with it being snap-together so that if you wanted both server and desktop (WHY?) you could easily expect it to all work. As it currently stands, it's useless to anyone other than pretty much Red Hat, CentOS, MontaVista, etc. (And it's not overly useful there...I can assure you of that. I had Pigeon Point hand me something LSB compliant and it wouldn't at all run on a MontaVista CGE 5.1 system to save it's life.)

                If they'd done that and then followed what Shuttleworth's proposing, it might've gone somewhere quicker.

                Comment


                • #38
                  Originally posted by Remco View Post
                  And nobody cares about that part of the LSB. Doesn't really solve anything, does it? The question may have been answered by someone, but no action was taken. Ubuntu has the market share to actually force the decision.

                  LSB is currently like XHTML. The biggest player doesn't care about it. The W3C learned that they had to listen to the actual parties involved to create a standard that everybody wants to implement. The most important thing about HTML 5 is specifying Internet Explorer's actual behaviour. The most important thing about the LSB will also have to be specifying actual behaviour.
                  ubuntu is completely irrelevant in that regard.

                  RHEL and SLED/SLES are the important distros out there. They use rpm. Problem solved. It is not their fault that ubuntu sucks.

                  Comment


                  • #39
                    Originally posted by Svartalf View Post
                    It's specifying too LARGE of a baseline. It's monolithic where it needs to be in chunks. Basline verss server versus desktop profile- with it being snap-together so that if you wanted both server and desktop (WHY?) you could easily expect it to all work. As it currently stands, it's useless to anyone other than pretty much Red Hat, CentOS, MontaVista, etc. (And it's not overly useful there...I can assure you of that. I had Pigeon Point hand me something LSB compliant and it wouldn't at all run on a MontaVista CGE 5.1 system to save it's life.)

                    If they'd done that and then followed what Shuttleworth's proposing, it might've gone somewhere quicker.
                    I don't believe that the LSB should specify which packages should be installed. That's way too inflexible. It should just do what distributions do: specify dependencies for each package. This is why it's important to settle the package format debate.

                    So, basically what happens is this: the LSB specifies the package versions that Linux distributions have to offer in 2011. Then, Debian Unstable will create the biggest repository in existence, and all distributions will derive from that (but that's not required). Fedora will have more bleeding edge stuff added to it, and all is good.

                    Then comes along Maya 2012, which is an LSB-2011 compliant package. It will work just like a normal distribution package, except that it won't depend on the bleeding edge stuff from Fedora for example. It will still just install everything it needs, and all dependencies will be there.

                    Comment


                    • #40
                      Originally posted by energyman View Post
                      ubuntu is completely irrelevant in that regard.

                      RHEL and SLED/SLES are the important distros out there. They use rpm. Problem solved. It is not their fault that ubuntu sucks.
                      Excuse me...

                      1) Using terms like "sucks" is BS and fanboy-ish. DROP IT.

                      2) RHEL and SLED/SLES are TWO of the important distros out there. But, unfortunately for YOU, they're not the only ones. Amongst the others is Debian, Ubuntu, Mandriva, MontaVista, Angstrom, MeeGo, and Android (yes). As an observation, only PART of those distributions use RPM. RPM isn't that great a packaging system. It's a good answer for servers and maybe desktops, but it's BLOATED for things like mobile devices.

                      RPM doesn't fix the problems I mentioned in the slightest. So, problem NOT solved.

                      Comment


                      • #41
                        Originally posted by Remco View Post
                        I don't believe that the LSB should specify which packages should be installed. That's way too inflexible. It should just do what distributions do: specify dependencies for each package. This is why it's important to settle the package format debate.
                        Actually, what you're proposing isn't any better. I'll get to that in a moment...

                        So, basically what happens is this: the LSB specifies the package versions that Linux distributions have to offer in 2011. Then, Debian Unstable will create the biggest repository in existence, and all distributions will derive from that (but that's not required). Fedora will have more bleeding edge stuff added to it, and all is good.

                        Then comes along Maya 2012, which is an LSB-2011 compliant package. It will work just like a normal distribution package, except that it won't depend on the bleeding edge stuff from Fedora for example. It will still just install everything it needs, and all dependencies will be there.
                        Actually no, it won't. You didn't catch the thing I was telling everyone when I posted earlier on the subject.

                        libpng12. It's on the current crop of distributions, but NOT on Arch and a few other of the latest. They've went to libpng14. You don't want the old stuff lurking around for a LONG time, so they removed it on some of the distributions and deprecated it (i.e. compat package...). Caster 1.1 (which is what you'd get when you buy right at the moment...) will install and NOT work on the latest Arch and a few others without you compiling or installing an unsupported "compat" package. In the LSB story you're saying, you'd have to have a RAFTLOAD of stuff lying about just to support this and that. When 2.0 ships, I'll be forcing SDL_image to not dlopen the png and jpeg libs and load them like any other .so by normal linkage- and then forcing it to use libpng14 in my ./libs dir to avoid this problem. LSB wouldn't FIX this. Your idea of LSB might fix it with a lot of other issues (i.e. some of the stuff won't live nicely together on the same system...). RPM doesn't fix this. Directory structures doesn't fix this. Specifying a library doesn't fix this unless we have a lot more consistent versioning in about 1/3 or so of the libraries in the Linux system space.

                        LSB is a solution by someone who didn't grok what the problem really was- it's a partial solution and a clumsy one at that.

                        Comment


                        • #42
                          Originally posted by Svartalf View Post
                          Actually, what you're proposing isn't any better. I'll get to that in a moment...



                          Actually no, it won't. You didn't catch the thing I was telling everyone when I posted earlier on the subject.

                          libpng12. It's on the current crop of distributions, but NOT on Arch and a few other of the latest. They've went to libpng14. You don't want the old stuff lurking around for a LONG time, so they removed it on some of the distributions and deprecated it (i.e. compat package...). Caster 1.1 (which is what you'd get when you buy right at the moment...) will install and NOT work on the latest Arch and a few others without you compiling or installing an unsupported "compat" package. In the LSB story you're saying, you'd have to have a RAFTLOAD of stuff lying about just to support this and that. When 2.0 ships, I'll be forcing SDL_image to not dlopen the png and jpeg libs and load them like any other .so by normal linkage- and then forcing it to use libpng14 in my ./libs dir to avoid this problem. LSB wouldn't FIX this. Your idea of LSB might fix it with a lot of other issues (i.e. some of the stuff won't live nicely together on the same system...). RPM doesn't fix this. Directory structures doesn't fix this. Specifying a library doesn't fix this unless we have a lot more consistent versioning in about 1/3 or so of the libraries in the Linux system space.

                          LSB is a solution by someone who didn't grok what the problem really was- it's a partial solution and a clumsy one at that.
                          The obvious solution is to keep libpng12 around in the repositories for as long as you support the LSB version for which libpng12 is required. It requires consistent naming and versioning, yes. Consistency like this is achieved with a comprehensive LSB spec, and evangelizing the goals of the LSB to upstream projects. The absence of such consistency is a serious bug, which makes life difficult for distribution developers and independent software vendors alike.

                          Maybe it would be a good idea to start a bit smaller. For example, Debian and Ubuntu tried to decide on common versions of certain important packages for their next releases. This didn't succeed, but I think they need to keep trying. A widely implemented LSB won't be built in one day.

                          Comment


                          • #43
                            Originally posted by Svartalf View Post
                            libpng12. It's on the current crop of distributions, but NOT on Arch and a few other of the latest. They've went to libpng14. You don't want the old stuff lurking around for a LONG time, so they removed it on some of the distributions and deprecated it (i.e. compat package...).
                            Hence my initial rant about binary packages coming from upstream being a terrible idea because upstream by all likelihood doesn't want to keep porting the program to newest libraries especially if it's the normal kind of a commercial game where there's an initial fee after which the game maker can move on to the next product. Some idealistic opensource coder might be doing this forever but it's imo completely unrealistic to expect this from commercial companies since it stops being cost-efficient after a certain time.

                            Comment


                            • #44
                              Originally posted by nanonyme View Post
                              Hence my initial rant about binary packages coming from upstream being a terrible idea because upstream by all likelihood doesn't want to keep porting the program to newest libraries especially if it's the normal kind of a commercial game where there's an initial fee after which the game maker can move on to the next product. Some idealistic opensource coder might be doing this forever but it's imo completely unrealistic to expect this from commercial companies since it stops being cost-efficient after a certain time.
                              Indeed. And this is part of the reason why the idea of LSB is nice, but it's execution will be a nightmare somewhere, somehow. I'm side-stepping the issue by pushing select managed .so's that are known to work fine with everything distributed at the time and use an RPATH to point the application (in this case, a game..) to the custom, controlled .so's. Having the LSB versioning, the way things have went for the last 5-7 years would have you keeping all sorts of junk lying around- JUST to support "compatibility". If you want the honest truth, it's little different on the Windows side of things, and actually faintly worse.

                              Comment


                              • #45
                                Svartalf, At risk of going off topic a bit, I'd like to ask you a question.

                                I've moved away from K/Ubuntu to Sabayon because I liked the rolling release nature of a Gentoo based distro and hated the "Forced Upgrade" nature of Ubuntu (ie. once the repos for your version are no longer supported, you have to upgrade the whole system, which may or may not work), but I'm not by any stretch of the imagination a linux wiz. I'm just an end user with enough know how to create a symlink, which I've had to do on occasion to statisfy versioning requirements of one or two programs

                                My question is, why bother using versioning? I mean yes update lib's and such, and by all means refer to the version number in tarballs and package managers, but why not use the same name once installed eg 'libxyz1.2' -> 'libxyz1.3' when installed would just be 'libxyz'. Would this not solve the compatability issue when a program is asking for a particular lib but can only find the updated version? This would also mean that all updates would need to be backward compatible with its older versions.

                                Comment

                                Working...
                                X