Ubuntu To Get Its Own Package Format, App Installer

[Thetargos]

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.

[tuuker]

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

[erendorn]

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.

[ворот93]

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.

[GreatEmerald]

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

[LightBit]

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.

[jayrulez]

wake up, fanboi. your reality check has bounced.

Chill out fangirl. No need to get your panties in a bunch.

[energyman]

Would you like cheese with your whine?

wake up, fanboi. your reality check has bounced.

[GreatEmerald]

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.

[JS987]

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.