Announcement

Collapse
No announcement yet.

Ubuntu To Get Its Own Package Format, App Installer

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

  • #91
    Originally posted by Ericg View Post
    And in 1990 i'd agree...but this is 2013, storage is cheap. I can (and did) go out and get a 1TB external USB3.0 HDD for $75, so who cares? They're all being kept in their own app's folder so its not even like theyre all flooding /usr/lib
    hdd might be cheap. Your empty bank account thanks to Canoniocals idiocy is not.

    People who haven't learnt from history repeat its errors. And Canonical is just on its way for an epic fuck up.

    Why? To become the one and only distri. The 'canonical' solution.

    What a bunch of insufferable jerks.

    Comment


    • #92
      Originally posted by energyman View Post
      hdd might be cheap. Your empty bank account thanks to Canoniocals idiocy is not.

      People who haven't learnt from history repeat its errors. And Canonical is just on its way for an epic fuck up.

      Why? To become the one and only distri. The 'canonical' solution.

      What a bunch of insufferable jerks.
      Would you like cheese with your whine?

      Comment


      • #93
        Originally posted by Ericg View Post
        And in 1990 i'd agree...but this is 2013, storage is cheap. I can (and did) go out and get a 1TB external USB3.0 HDD for $75, so who cares? They're all being kept in their own app's folder so its not even like theyre all flooding /usr/lib
        When application has private copy of library memory taken by library can't be shared among applications and it slows down start-up of application because library isn't cached.
        When security bug is found in library, all applications with private copy have to be updated.

        Comment


        • #94
          Originally posted by LightBit View Post
          I think /bin and /sbin should be statically linked.
          What. Statically linking to anything in /sbin would mean security issues ahoy (and, well, they are binaries, not libraries, you don't link to them anyway, you link to the libraries they use). Also, both /bin and /sbin are not supposed to exist any more, anyway.

          Comment


          • #95
            Originally posted by jayrulez View Post
            Would you like cheese with your whine?
            wake up, fanboi. your reality check has bounced.

            Comment


            • #96
              Originally posted by energyman View Post
              wake up, fanboi. your reality check has bounced.
              Chill out fangirl. No need to get your panties in a bunch.

              Comment


              • #97
                Originally posted by GreatEmerald View Post
                What. Statically linking to anything in /sbin would mean security issues ahoy (and, well, they are binaries, not libraries, you don't link to them anyway, you link to the libraries they use). Also, both /bin and /sbin are not supposed to exist any more, anyway.
                NO! Of course there is no libraries in /sbin and /bin, and you can't link two binaries.
                Binaries in /sbin and /bin should be statically linked to libraries they use (mostly libc.a). Of course this means, if bug is found in libc all binaries have to be rebuild.
                FHS requires /bin and /sbin (they can be symlinks), but I agree it doesn't make sense to have them, if binaries are dynamically linked.

                Comment


                • #98
                  Originally posted by LightBit View Post
                  NO! Of course there is no libraries in /sbin and /bin, and you can't link two binaries.
                  Binaries in /sbin and /bin should be statically linked to libraries they use (mostly libc.a). Of course this means, if bug is found in libc all binaries have to be rebuild.
                  FHS requires /bin and /sbin (they can be symlinks), but I agree it doesn't make sense to have them, if binaries are dynamically linked.
                  Oh, so you meant that (only the?) binaries which are usually put into /bin and /sbin should be statically linked to the libraries they use. All right. You should be a bit clearer on those things next time

                  Comment


                  • #99
                    Originally posted by jayrulez View Post
                    Oh noes! It's the rabid wolves out to get Ubuntu again. If the many existing solutions were perfect or just needed a bit of work to be acceptable then why hasn't anyone done it yet? Why fault Ubuntu for trying to solve an obvious problem?

                    I've learned that Ubuntu is damned if they do and damned if they don't so they might as well ignore you bunch and try to accomplish their goals.
                    The last thing that I want to happen is Canonical start paying attention to moronix forums. MS has the vision which he should implement, not get distracted by local attention whores.

                    Comment


                    • Originally posted by Ericg View Post
                      And in 1990 i'd agree...but this is 2013, storage is cheap. I can (and did) go out and get a 1TB external USB3.0 HDD for $75, so who cares? They're all being kept in their own app's folder so its not even like theyre all flooding /usr/lib
                      good luck putting your 1TB drive into a tablet, or storing you programs on external USB drives...
                      One of my Windows vista installations ended up filling its (system only) 32Gb partition (because system dlls would be added over time for "compatibility", up to 10 to 15 Gb of extra space used in Windows directory).
                      I hope they are doing better with Windows 8, because if not, the 32Gb surface RT might become a little less nice when you can't install apps on it anymore after a few years.

                      Comment


                      • finally no dependency fuzz, this is another hit against Windows downfall.

                        Comment


                        • Originally posted by Ericg View Post
                          A well written python app will be just as fast as a C or C++ app unless you optimize the C or C++ app in some way (beyond just best practices). Also python is easier for maintenance so theres a bump in its direction. This flies directly at the same age old argument... do you use a custom written hand tuned algorithm thats fast, but a nightmare to maintain. Or do you go for a slightly slower one, that still gets the job done, thats easier to maintain? Personally, I prefer longterm maintenance benefits from easy to read code.
                          Python also has the ugly problem of its huge memory foot-print. Though not a vis-a-vis comparison, for the longest time I called python Linux's Java (back when Java was a PITA to get working on Linux and there was no IcedTea to cool things off). You may argue that RAM is a non issue... For desktop use, try the confinements of embedded or terminal systems with limited amounts of RAM, then the snake rolls over those limited resources. C/C++ is much a much better solution, for all. Prototyping in python would be a good idea, sadly usually the process stops with the prototype and loses the 'proto' part to be the 'type'.

                          As for the issue at hand, I don't think that we should waste any more e-pages beating on this dead horse.
                          Last edited by Thetargos; 05-12-2013, 07:33 PM.

                          Comment

                          Working...
                          X