Announcement

Collapse
No announcement yet.

Ubuntu To Get Its Own Package Format, App Installer

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

  • phoronix
    started a topic Ubuntu To Get Its Own Package Format, App Installer

    Ubuntu To Get Its Own Package Format, App Installer

    Phoronix: Ubuntu To Get Its Own Package Format, App Installer

    While Ubuntu already has its own software store, Canonical developers are now working on their own application package installer and package format...

    http://www.phoronix.com/vr.php?view=MTM2Nzg

  • Thetargos
    replied
    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.

    Leave a comment:


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

    Leave a comment:


  • erendorn
    replied
    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.

    Leave a comment:


  • ворот93
    replied
    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.

    Leave a comment:


  • GreatEmerald
    replied
    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

    Leave a comment:


  • LightBit
    replied
    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.

    Leave a comment:


  • jayrulez
    replied
    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.

    Leave a comment:


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

    Leave a comment:


  • GreatEmerald
    replied
    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.

    Leave a comment:

Working...
X