Ubuntu Developing Its Own Package Format, Installer

An anonymous reader writes "While complementing Debian APT/DPKG, Canonical is now developing their own package format. The new package format has promised highlights of having no dependencies between applications, each package would install to its own directory, root support wouldn't always be required, and overall a more self-contained and easier approach for developers than it stands now for Debian/Ubuntu packages. The primary users of the new packaging system would be those distributing applications built on the Ubuntu Touch/Phone SDK. The initial proof-of-concept package management system is written in Python and uses JSON representation." This quote from the post by Canonical's Colin Watson bears repeating: "We'll continue to use dpkg and apt for building the Ubuntu operating system, syncing with Debian, and so on."

Comments

Good

[MightyMartian]

Good, another reason to avoid Ubuntu like the plague.

Re:Good

[Penguinisto]

Indeed... this sentence:

The new package format has promised highlights of having no dependencies between applications

...tells me there's gonna be a whole shitload of bloat, duplicate binaries, and a performance hit from Hell.

I could be wrong, but...

Re:Good

[Jeremiah Cornelius]

Apple. NeXT.

Re:Good

[gandhi_2]

Oooh!
  A Modularity vs DRY argument!

Lets..... GetItOn!

Re:Good

[Penguinisto]

The presence and use of /Library on my MBP says differently. ;)

Re:Good

[buchner.johannes]

Also, this might be the dawn of malware for Linux on the PC.

Re:Good

[Jeremiah Cornelius]

Go open a mac .app sometime. Libraries and resources galore can be found. The Systme libraries and frameworks can be over-ridden. like having ~/Library on a per-app basis.

Re:Good

[Anonymous Coward]

...tells me there's gonna be a whole shitload of bloat, duplicate binaries, and a performance hit from Hell.

I could be wrong, but...

Apple. NeXT.

The presence and use of /Library on my MBP says differently. ;)

Well, interesting that you have experience with OS X, because if you unrolled the third-party contents under your /Library to each app under /Applications that needed it, and compare your OS X experience to the potentially "massive" library of 3rd party Linux software...
did you HONESTLY think you stood a chance of being right?

By all means show us an example from /Library/ if you have one, and I'm going to laugh if you say the JRE.

Re:Good

[K. S. Kyosuke]

...tells me there's gonna be a whole shitload of bloat, duplicate binaries, and a performance hit from Hell.

Hmmm, wouldn't it be possible to solve the duplicate binaries problem by simply reference-counting identical files?

Re:Good

[Anonymous Coward]

This is going to be the best thing for linux. Most users will enjoy and maybe switch to linux instead of windows. Dependecies that link multiple times to other dependancies get very convoluted. Normal peoples linux finally.

Re:Good

[hduff]

Good, another reason to avoid Ubuntu like the plague.

They've already farked up "Steam for Lin^H^H^HUbuntu", so this is not surprising.

Re:Good

[phantomfive]

The Systme libraries and frameworks can be over-ridden.

Really? How does that work? I would love to know.

Re:Good

[X0563511]

Sounds like the dynamic linker is going to need an overhaul to include data-deduplication. As well as the filesystem.

Re:Good

[Anonymous Coward]

Hmmm, wouldn't it be possible to solve the duplicate binaries problem by simply reference-counting identical files?

There is a story related to this, it goes:

Hmmm, wouldn't it be possible to solve the duplicate binaries problem by simply reference-counting identical files?

Re:Good

[pentalive]

http://www.gobolinux.org/

Re:Good

[Jeremiah Cornelius]

"Dunno if there's a way to specify that inside Xcode or not, but for our app we use a build script that includes some code like the following. The code uses Apple's install_name_tool utility to modify the application so that instead of pointing to /usr/lib/libsndfile.so, it points to a libsndfile.so path that is in the application's package instead.

Note this is just a cut-down script excerpt to give you an idea; it will probably require some tweaking before it works for you (and of course you'll need to modify it to operate on other libraries besides libsndfile if that is what you want):"

#!/bin/bash -e
 
BINARY="MyAppFolder/MyAppName"
FRAMEW_FOLDER="MyAppFolder/MyAppName/Contents/Frameworks/"
 
function DoInstallNameTool {
    xLIB="$1"
    xLIB_NAME="$2"
    xBINARY="$3"
    echo install_name_tool -change \"${xLIB}\" \"@executable_path/../Frameworks/${xLIB_NAME}\" \"${xBINARY}\"
    install_name_tool -change ${xLIB} "@executable_path/../Frameworks/${xLIB_NAME}" "${xBINARY}"
}
 
for LIB in $(otool -L "${BINARY}"|grep libsndfile|cut -d '(' -f -1)
do
    echo "Handling Lib: $LIB"
    LIB_NAME=$(basename "$LIB")
    echo " Adding ${LIB_NAME}"
    cp -Rf "${LIBSNDFILE_DIR}/src/.libs/${LIB_NAME}" "${FRAMEW_FOLDER}"
 
    DoInstallNameTool "$LIB" "$LIB_NAME" "$BINARY"
done

http://stackoverflow.com/questions/7470637/dynamic-library-in-application-bundle-mac-os-x

Re:Good

[Anonymous Coward]

Glad I wasn't the only one who thought "sounds like Gobo Linux" upon reading the snippet

Re:Good

[snadrus]

BTRFS has had online dedup proposed. That solves the disk & memory hit. What would the linker need?

Re:Good

[snadrus]

I always liked that setup.
No update-alternatives.
No tricky paths.
Parallel old/new installations.

With dedup, it would work even better since you won't need library mappings and could have parallel installations (though with a larger package size).

Re:Good

[king neckbeard]

Except for the fact that dependencies are already handled by package managers. It can already be done and is done transparently in Ubuntu Software Center.

Re:Good

[Anonymous Coward]

Except that you still have to "install" Steam per user, into a user's home directory, for fuck's sake!

Steam "for Linux" *runs* on Linux. That's about all. It *couldn't* be further from the proper Linux way in every other aspect!

It's like those morons did never even remotely comprehend how Unix systems work, and just slapped their Windows ways onto it.

And Canonical is doing the exact same shit. Tons of morons who only know and understand Windows and OS X, and think things work the same way on Linux. Idiots who never saw anything but GUI desktop environments that deliberately pretend to be as much like OS X (Gnome) or Windows (KDE) as possible.

All in the name of getting even more retards to use what they think is "Linux".

I, for one, think we don't fuckin' need morons. Linux is not a toy operating system! It is a PRO system for *professionals*. People with brains!

And I, for one, say Ubuntu is NOT Linux anymore. It tries extremely hard (attention whore style) to be an OS X and now iOS clone. So let's give it that "honor" and call it that!

UBUNTU = OS X clone != Linux

There. I said it.

Re:Good

[mr_shifty]

This. ^

Re:Good

[Electricity Likes Me]

Online dedup is the wrong solution to the problem since you have to keep the hash tables in memory. All you need is some install-time intelligence to reference count the files.

Re:Good

[Electricity Likes Me]

apt still has a tendency to create circular rings of dependencies ("remove one package, watch as it tries to remove your entire desktop environment"). Although within that context, this still feels like the wrong answer since the real issue is apt can be very silly about inspecting the operation you ask it to perform and concluding that everything will be fine (and there's no decent user tools to say "I'm breaking this, it's ok, let it stay broken").

Re:Good

[TheGoodNamesWereGone]

Flamebait??? C'mon people. Canonical seems to be hell-bent on digging their own grave.

Re:Good

[phantomfive]

thx

Re:Good

[John Bokma]

RISC OS, which has a common !System directory for modules (shared libraries). Installing an application could be as simple as drag & drop. Some applications required the !System directory to be updated, though. And, (IIRC) there could be only one version of a module in memory at a time which could cause a problem.

Re:Good

[rroman]

Actually, the "shitload of bloat duplicate binaries" is quite good. Nobody gives a damn about 10 MB of their disk space because the program takes it's libraries with it. However, everyone gives ten tones of damn when they can't install new application because of "dependency problem". Solving dependency problems costs time and hence money. Disk space is cheap.
Disclaimer: I'm not saying, that new Ubuntu does that, I'm just arguing against the philosophy of bad duplicate binaries.

Re:Good

[EvanED]

Tons of morons who only know and understand Windows and OS X, and think things work the same way on Linux.

I like how you just assume that they don't understand that what they're doing is contrary to Unix orthodoxy. But Unix orthodoxy is just that -- it's the way things currently are. Yes people should understand why Unix does things the way that it does. But at the same time, no way is it the be-all, end-all of computing. The Unix orthodoxy also has a lot of problems, many of which are seldom acknowledged by people such as yourself. (For instance, I can link to a rant I've written about why I think the Linux command line is due for a major overhaul if you'd like an example of one such class of problems that I see.)

Re:Good

[ChrisMaple]

And of course you never have two programs that require different versions of a library, which the package manager doesn't allow to coexist.

Re:Good

[Skrapion]

And that works reasonably well for popular open source projects, where volunteers can build new binaries to keep up with updated dependencies, but it's a real problem for closed-source projects.

Whether or not paving the way for closed-source projects on Linux is a good thing will depend on whom you ask, but I suspect that's one of the major motivations for this project.

Re:Good

[jampola]

Haven't used OSX in quite some time but isn't this how their .app files are maintained?

I can see some logic in this. Doesn't mean I agree with it but time will tell.

Re:Good

[king neckbeard]

If you remove a library that a lot of other programs are dependent upon, yes, it will do that. However, that is expected behavior. The only time its a problem is when packagers are a bit aggressive on what should be set as 'depends', and that's been a very rare problem for me.

Re:Good

[king neckbeard]

Pretty much, yeah. If a library is likely to be needed in different versions, it'll be something like python where you have different libraries in different directories for different major versions.

Re:Good

[smash]

Which, given most people have upwards of half a terabyte of storage, and the OS consumes only 1% of that, storage space is no longer at a premium.

The benefits of totally self contained packages are huge. You'll probably find that the vast majority of your application is NOT duplicated data anyhow. It will be graphic resources, it's own code, etc.

Couple that with de-dup in modern filesystems (inline still a major overhead, but scheduled de-dup isn't a major problem) and the advantages to just linking to libraries everywhere are not so clear cut anymore.

Having lived with the OS X way of packaging for a few years, and dealt with both Linux, FreeBSD and Windows since the early 90s, I know which method I prefer.

Re:Good

[smash]

Yes. ZFS will do this, as will HAMMER. However, I suspect the gains REALLY aren't there. The core OS binaries (including all libraries) on a modern system account for what... 1-2% of the disk space? If that? The bulk of the code in your new application will be the new application. Even more disk will be consumed by the resources used only for that app (graphics, widget layouts, etc.).

Disk today is cheap. Having dealt with both linking (Windows, Unix) and self contained Applications (OS X), I much prefer the latter. Installation / un-installation is way, way easier. Compatibility issues are less common.

Re:Good

[smash]

I suspect the memory/CPU overhead for dedup is far larger than the disk/memory overhead for self-contained applications. Disk is cheap. RAM is cheap. Most of the application will be its OWN CODE, anyhow.

Re: Good

[Anonymous Coward]

That already exists. It is called hard link.

Re: Good

[Anonymous Coward]

http://www.gobolinux.org

Re:Good

[Electricity Likes Me]

It does it when something is a "remove" and not an upgrade operation I've found. apt treats a remove and install for two packages that provide the same dependency as two separate operations - it tries to remove and normalize the system, before it installs the new one. So when it's something like xscreensaver it tries to remove the entire DE.

Re:Good

[TheRaven64]

No it doesn't. PC-BSD has had this model for application installs for ages. The installer hard links duplicate libraries and so on together. Hard links are already reference counted, and have been since the early days of UNIX, so you end up with one copy of each library. The logic in the installer is relatively complicated, but the uninstaller just has to delete the tree.

The way that the packages in the repository are built ensures that programs using the same library ship the same binary. If you upgrade just one program, then you'll have two copies of the library, until you upgrade all of them and then the old one's reference count will hit 0 and it will be gone from disk.

Re: Good

[garaged]

Tendency? I have yet to see something like that.

i have found a few dependency problems using unstable, like 1 every 1-2 years, and most of the time it could be avoided by investing some 10 seconds reading what would be installed/removed with the current try, but a circular dependency, Im pretty sure apt has enough validations to avoid that automagically

Re:Good

[marcello_dl]

especially this: Rootless GoboLinux

Re:Good

[rev0lt]

I could be wrong, but...

You are. PC-BSD's pbi format does exactly the same (http://www.pcbsd.org/en/package-management/), it is not a novel idea - at all. And as many other comments point out, other platforms do it too.

Re:Good

[Ash-Fox]

Except this is not for the PC operating system, as clearly highlighted by the summary. So, not really another reason.

Re:Good

[gbjbaanb]

except that they occasionalyl do not - I've seen packages suplied that expect a version of a dependancy that is not available on the distro I'm installing to, and the answer on the web is always - well get the source and build it. It's happened often enough for me to worry about installing some things.

Now, when the packages are available, all is well and apt or yum works beautifully. The trouble is that the real world complexity sometimes breaks it. This can also strike when you have an incompatible version already installed.

So in this case, I think what they're doing is saying - you deliver for the packages already installed in the base OS, and any special dependancies must be packaged up with your app. In a way, its the best of both worlds - 'guaranteed' system dependancies plus a way to easily slip your own in as well.

Maybe they could have updated the existing ones, but I doubt that would be politically possible - your comment shows why.

Re:Good

[BrokenHalo]

By all means show us an example from /Library/ if you have one...

Don't bother. Whatever Apple does is entirely irrelevant to this discussion.

Re:Good

[miknix]

Nobody gives a damn about 10 MB of their disk space because the program takes it's libraries with it.
(...)
Disk space is cheap.

What about the huge latency caused by the load of those libraries from teh HDD? What about RAM?
Unless everyone has SSDs and plenty of RAM, the performance impact will be quite noticeable. Otherwise, projects like prelink wouldn't ever exited.

and yes.. I run Gentoo :D

Re:Good

[BrokenHalo]

Disk space is indeed cheap, but RAM still is not. If you happen to have multiple versions of the same library kicking around in memory, then performance is going to take a hit.

Re:Good

[Anonymous Coward]

Why don't you just RTFA?

"So the scope of what I've been considering is purely leaf apps built on a fixed "base system", which in the case of the initial target of the Ubuntu phone/tablet work would be the run-time part of the Ubuntu SDK ... no dependencies between apps; single implicit dependency on the base system."

Re:Good

[tehcyder]

Also, this might be the dawn of malware for Linux on the PC.

Then it will truly be the year of Linux on the desktop, as Windows will lose its one remaining USP. Hold on a sec...

Re:Good

[Penguinisto]

Pretty enlightening... thank you!

Re:Good

[BradleyAndersen]

Clearly you've never used yum :)

Re:Good

[eric_herm]

That was indeed something quite visible on my old os X laptop. I was not able to run openoffice and mail.app without lots of swap, while doing the same on Fedora was ok. Maybe now with 4 to 8 Gigabit of ram, this would be less visible, but as we are also pushing to less power consumption, I think that using less memory, and less cpu, fetching less things from disk is gonna requires some work in this direction.

Re:Good

[X0563511]

That's all fine on the file system, but you still end up with your RAM full of copies of the same code.

Re:Good

[GPLHost-Thomas]

Actually, the "shitload of bloat duplicate binaries" is quite good. Nobody gives a damn about 10 MB of their disk space because the program takes it's libraries with it.

However, a lot of people cares about security, and it's really bad if we have 10 versions of the same library with a security hole, and have no way to know if a given app developer will care updating that lib.

However, everyone gives ten tones of damn when they can't install new application because of "dependency problem".

This is called "Q/A". In Debian, there is "piuparts" which can be used for this kind of check, and it would be trivial for Canonical to do such testings when an app is submitted.

Solving dependency problems costs time and hence money.

That's the role of the developer to do that kind of checks. With the proper tools, it's easy to do, so it doesn't cost so much time (and hence money).

Disk space is cheap.

But phone flash are usually very slow.

Disclaimer: I'm not saying, that new Ubuntu does that, I'm just arguing against the philosophy of bad duplicate binaries.

You are arguing very poorly, IMO.

Re:Good

[GPLHost-Thomas]

The fact that their are so many kinds of DLLs all around is one of the reason why Windows is unsafe, and probably one of the reason I will never trust it. If all this crap is brought to GNU/Linux, then it's time to find another platform.

Re:Good

[GPLHost-Thomas]

root@host>_ ~# apt-get remove sysv-rc
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following extra packages will be installed:
file-rc
The following packages will be REMOVED:
sysv-rc sysvinit
The following NEW packages will be installed:
file-rc
WARNING: The following essential packages will be removed.
This should NOT be done unless you know exactly what you are doing!
sysvinit sysv-rc (due to sysvinit)
0 upgraded, 1 newly installed, 2 to remove and 0 not upgraded.
Need to get 40.2 kB of archives.
After this operation, 329 kB disk space will be freed.
You are about to do something potentially harmful.
To continue type in the phrase 'Yes, do as I say!'

Re:Good

[Anonymous Coward]

*ahem!* Excuse me, sir!

...the dawn of malware for Ubuntu on the PC.

FTFY

Re:Good

[TheRaven64]

No you don't. The buffer cache is indexed by inodes, not by file paths. Both copies of the library resolve to the same inode and so when you mmap() the library you get one (CoW) copy of it that is shared between all processes that map it.

Re:Good

[rroman]

However, a lot of people cares about security, and it's really bad if we have 10 versions of the same library with a security hole, and have no way to know if a given app developer will care updating that lib.

I can imagine, that in some cases this scenario happen, but it would be rare. There will be far more likely a security problem in the application itself. For this scenario to happen you need:
1. Released stable library, that has security holes in some of its api
2. Application that uses this library and this api
3. The application has to be exposed to "hostile" environment (you don't care if a app has BO in it if you use it only yourself).
4. The hostile environment must be somehow able to go trough the application to exploit the vulnerable api.
1. 3. and 4. are extremely unlikely.

Solving dependency problems costs time and hence money.

That's the role of the developer to do that kind of checks. With the proper tools, it's easy to do, so it doesn't cost so much time (and hence money).

It really doesn't matter that much. Many developers write their software, test it and release it. They don't test it again when a new version of library appears (it costs them money). If the developer has more applications to maintain and the user base isn't big enough (many small but great application fall in this category) and compatibility problem appears, it could stay unfixed for long time, even forever. I'm talking from my own experiences - not making things up.

Re:Good

[rroman]

Not really. For example, I'm running right now about 10 different gui programs. If each of this programs used its own Qt library, it would cost me 100 MB in total. Right now, my firefox consumes about 700 MB of its own, thunderbird 200 MB. Don't tell me it is so much.
And as for the performance, I can't see the performance impact. If you have like 256 MB of ram and don't use any memory consuming program, you can have more swapping, that is true. But if you have normal computer with enough ram (say 2-3 GB), you won't notice anything.

Re:Good

[X0563511]

Well, I will admit to not knowing how it actually worked. I would have expected a file() be opened against the library and the data read out of the file.

Re:Good

[Anonymous Coward]

Amen. I've been waiting for Ubuntu to do something like this for awhile. I do think this may begin to draw more non-techy people into the Linux community.
The primary issue is, like everyone is saying, each program bringing it's baggage (what would have been dependencies) which allows it to bring in viruses and other crap. But at the same rate, the software could do that anyways - how's the innocent user supposed to know when they put it together? (I'm assuming here that are user is the I'm-new-to-Linux-from-Windows and not Joe Geek.)

Re:Good

[at_slashdot]

Only that from what I understand programs share libraries in memory, if each program uses their own libraries then the bloat will be in the memory where it counts not only on the disk... Also, if you fix a bug in a library you have to update all the programs that use that library instead of updating only that library. Doesn't sound efficient to me and if it's a security related bug then you can expect the system to be vulnerable because somebody will be lazy patching their program.

Re:Good

[king neckbeard]

I have a bit, but I was speaking more specifically about apt, since that's what Ubuntu uses.

Re:Good

[Burz]

Wow... spectacularly bad example! Do you know how many apps on OS X and Windows use Qt?

Almost vanishingly few.

That is because app developers for those platforms can count on a well-honed and tested GUI toolkit to be already built into each OS.

OTOH, if Qt's authors want to address this issue I'm sure there are ways to do it. This might involve some linking tricks or marketing Qt to users like Oracle does with Java (which is usually installed as a separate package by some app that needs it). Believe it or not, this is way more elegant *and* responsible to the users than expecting them to learn about DE's and toolkits so they don't end up with Gnone2 + Gnome3 + KDE3 + KDE4 (and now KDE5) libraries loaded in RAM.

Re:Good

[king neckbeard]

It's not the best of both worlds by any means. It throws lots of redundancy into the mix, and thus causes security risks. The problem occurs when packagers, typically third third parties, make the wrong assumptions about the software installed on a system. This causes a problem if someone wants to trim something away from a default install. Say a package depends on mono being installed, and some people prefer their systems without mono. If these new packages assume that it is guaranteed, it will be broken on their systems. This practice would cause problems far more common than what it fixes unless the assumption is absolutely barebones, in which case you are going to have 200MB packages for graphical text editors. Also, there's no need for a new package format to do this. These kinds of packages already exist, and they belong in /opt

Re:Good

[GPLHost-Thomas]

However, a lot of people cares about security, and it's really bad if we have 10 versions of the same library with a security hole, and have no way to know if a given app developer will care updating that lib.

I can imagine, that in some cases this scenario happen, but it would be rare.

This is not what the history of security shows in platforms such as Windows. The multiplication of DLLs everywhere in the system, with many apps embedding their own version of the DLL really is a security nightmare. And it's far from being rare.

There will be far more likely a security problem in the application itself.

Well, if an application has a security problem, that is only one occurrence of an issue. If a popular library that ends up being included in hundreds of apps, you have hundreds of packages to upgrade, and that may be simply doomed to be impossible to fix (contacting everyone, making sure they upgrade, etc. is not an easy task).

It really doesn't matter that much. Many developers write their software, test it and release it. They don't test it again when a new version of library appears (it costs them money). If the developer has more applications to maintain and the user base isn't big enough (many small but great application fall in this category) and compatibility problem appears, it could stay unfixed for long time, even forever. I'm talking from my own experiences - not making things up.

Which is why such piuparts tests should be automated before reaching the app store. Easy to implement, and the problem is fixed forever. Don't tell me that developers will not want to comply, they do already comply to so many stupid rules from Apple, I don't see why they would refuse a QA rule (which make sense) from Canonical.

Re:Good

[hobarrera]

The entire dependency tree is way more than 10MB for plenty of applications, and several gigs sure are expensive on the devices Ubuntu is targeting for this packaging system.

Also, duplicating libraries means you need to duplicate them in memory as well. This isn't noticable when running ONE application, but is noticable when running 10 applications.

I'd love to see java-based apps too (upward 100MB each package). Or python-based ones (~30MB?)

Re:Good

[hobarrera]

Some of us prefer fast (and low-power) ultrabooks (SSD), instead of ridiculous amounts of storage that we'll never fill up (HDD).

Re:Good

[Anonymous Coward]

That's already happened. There is no shortage of stupid users/administrators regardless of platform. Ars Technica has been running sorries about it for some time. Although nobody knows how the servers were initially compromised, most likely cause is stupid users.

Re:Good

[BrokenHalo]

As a matter of interest, one cross-platform app is in fact Skype, which (at least last time I looked) was built with Qt for the Linux implementation. Does anyone know if this is the case for the OS X or Windows binaries?

Re:Good

[Anonymous Coward]

Agreed. This really is not a not a new concept - more commonly known as application virtualization.

Re:Good

[Anonymous Coward]

Indeed... this sentence:

The new package format has promised highlights of having no dependencies between applications

...tells me there's gonna be a whole shitload of bloat, duplicate binaries, and a performance hit from Hell.

I could be wrong, but...

I'm not sure how you could be right, unless you do computing on computers from the 90's, in which case you probably have a hard time running Ubuntu anyway.

Re:Good

[bigbango]

The disk I/O latency can at least for HDDs be reduced if each application statically compiles in its libraries. I think Plan 9 actually does this, see http://harmful.cat-v.org/software/dynamic-linking/. There is a comparison of the file sizes of some command line tools there, but it would be interesting to know the binary size difference between statically and dynamically linked binaries for modern GUI apps that are using libraries like GTK or QT.

apt

[kthreadd]

Sounds like a complement to dpkg, not a replacement

Re:apt

[Anonymous Coward]

Sounds like a complement to dpkg, not a replacement

Oh, I hope so. I like Ubuntu - even Unity - but I won't tolerate them going all Apple on me.

Because if in the future I am stuck with either Canonical's depositories (half of my software is from other sources) or compiling everything from source - all those dependencies and everything - bye buy Ubuntu.

Re:apt

[phantomfive]

Designing the capability to bundle libraries with an application install is a good idea, the problem is.....

Ubuntu is building their own system for doing it, instead of using APT, which gets them 90% of the way there. Most likely, it will be poorly done, which is the common fate of those who are too lazy to understand existing systems.

Re:apt

[Anonymous Coward]

Yeah, Colin Watson knows nothing about apt. Maybe he wouldn't be so lazy if he would start maintaining some packages in debian.

Re:apt

[Anonymous Coward]

You do know who Colin Watson is, right? You are saying that he doesn't understand apt, because he is too lazy?

Re:apt

[Anonymous Coward]

Never mind, I cancel that comment. I thought about this a bit more and figured that it is possibly a good idea after all.

Re:apt

[exomondo]

Ubuntu is building their own system for doing it, instead of using APT, which gets them 90% of the way there. Most likely, it will be poorly done, which is the common fate of those who are too lazy to understand existing systems.

So you're saying Colin Watson is too lazy to understand existing systems? You've never actually looked at commits for APT have you.

Re:apt

[Anonymous Coward]

Only completely clueless moron would claim that Colin Watson is too lazy to understand APT. That goes doubly for the moderators who gave this drivel +5 Insightful.

Re:apt

[Anonymous Coward]

Sarcasm - now available in "whoosh".

Re:apt

[yahwotqa]

Just an off-topic question - how did you manage to misspell one half of "bye bye"? That's quite an accomplishment.

Re:apt

[Anonymous Coward]

Yes, seems to be.

Why not extend APT? Why rewrite it?

Is he the knight who says NIH?

Re:apt

[GPLHost-Thomas]

Probably we have to link to his QA page: http://qa.debian.org/developer.php?login=cjwatson

Re:apt

[Anonymous Coward]

which part is sarcasm?

Re:apt

[exomondo]

Why not extend APT? Why rewrite it?

I don't have the answer for that, but it's clearly not because they are too lazy to understand it.

Re:apt

[Anonymous Coward]

Designing the capability to bundle libraries with an application install is a good idea

it's already done, it's called *dependencies* -- if something is packaged by a distribution, it sure as well better have all the dependencies for that package in its repositories....

for other 3rd party shit i can see this potentially being of benefit to some, but from a distribution and its repository standpoint, worthless... but then using static libraries would work too, no?

Bloat

[paulej72]

If everything has no dependencies, then all of the dependencies must be included in the install. I wounder how many copies of each low level program would be on a given machine.

Re:Bloat

[fph il quozientatore]

If everything has no dependencies, then all of the dependencies must be included in the install. I wounder how many copies of each low level program would be on a given machine.

And, especially, good luck installing a security update on *all* your copies of a core library.

Re:Bloat

[Anonymous Coward]

Quite frankly, disk space is cheap. If this eats another 10 gigabytes of hard drive space over the traditional approach, I personally wouldn't even notice. If it made things even 50% less likely to break because of dependency problems I would be all for it.

Re:Bloat

[iggymanz]

there are plenty of applications that must use the common config & libraries & program file of other applications, can't have separate copies or versions to have a useful coherent system.

Re:Bloat

[Anonymous Coward]

If it made things even 50% less likely to break because of dependency problems I would be all for it.

What if it makes things more likely to break because package A and package B are using incompatible versions of a library? What if you get compromised because a package uses an old version of a library with a zero-day exploit? Even though you already updated the same library for other applications.

Re:Bloat

[Anonymous Coward]

I'm sure you'll also appreciate your computer using an additional 10GB for all of the now duplicate shared objects that need to get loaded into RAM as well...

Re:Bloat

[Anonymous Coward]

If everything has no dependencies, then all of the dependencies must be included in the install. I wounder how many copies of each low level program would be on a given machine.

And, especially, good luck installing a security update on *all* your copies of a core library.

Isn't the main purpose of the packaging/installation system to track all libraries and executables, no matter how many copies you have?

Re:Bloat

[interval1066]

Quite frankly, disk space is cheap. If this eats another 10 gigabytes of hard drive space over the traditional approach, I personally wouldn't even notice.

Might as well use Windows with that philosophy. The big difference with Linux is its efficiency. Get rid of that, might as well get rid of linux.

Re:Bloat

[jedidiah]

With n+1 copies of something you have n+1 entities that need to update their shared components. Most of them might not bother. If they don't bother, then you don't have anything to update.

Re:Bloat

[Anonymous Coward]

Especially when the security update breaks the API because there's no other way to fix it...

Re:Bloat

[Anonymous Coward]

What about all the waste and mistakes being caused by duplication of efforts and storage?
Not managing dependency problems means capitulation on OS management.
Now, this might be good for the intended use, for simple management of applications, but essentially you give up on all the benefits of managing your libraries and applications in the first place. If everyone thinks like that, the whole value proposition of dealing with an OS diminishes exponentially.

Seems kinda silly to spend 20+ years developing OSes and then just give up on it and go back to the "simple" solutions, which history shows does not work very well at all for many various reasons. Anyways, good luck with that. I'm glad I don't have to share the pain.

Re:Bloat

[Kjella]

Might as well use Windows with that philosophy. The big difference with Linux is its efficiency. Get rid of that, might as well get rid of linux.

Fast, cheap, good - pick two? >:-) If you have a modern system, no OS should take a significant amount of resources on its own. Don't waste just to waste but as long as developer time is a limited resource, I'd rather have more features, higher quality and better performance than lower resource usage. The hardware is there to be used, that's what it's bought for. Hell, I regularly run an application that likes to chew through it's whole 32 bit memory space (4GB) and I let it because I still have 12 to spare and there's no direct replacement and it mostly works. What you care about is simply nothing that I care about at all, but then so I took your advice on my machine in favor of Windows 7. If Microsoft continues down their path I might have to migrate to Linux again, but if so I'd like a few other things than efficiency. Otherwise it might be a Mac, but I'd rather not.

Re:Bloat

[bussdriver]

Already lost. With VMs being so widespread and popular, the OS has already lost one of its main purposes: To run software by providing the HAL and the common needs of software.

The OS should keep your old apps safely running forever. Going to a VM because of a broken dependency system or changing APIs (again related to dependency) or for SECURITY just illustrates that the OS has failed in doing it's job.

Linux (and others) have a bias to recompiling source for all the changes that go on -fine- be that way, but the packages should be able to compile against the new kernel (and basic libraries) without modifications. Sure, that means some THINKING and design as far as how to manage all the overhead of backward compatibility. It only seems insurmountable because nobody addresses it, they run away from the problem and push it onto everybody else to work around

Root level stuff can be different - but some user app should be able to run for decades unpatched, insecure, infected but still doing it's job for the user and not harming the rest of the system.

Re:Bloat

[king neckbeard]

Except you don't have dependency problems unless you are doing crazy shit that someone who couldn't figure them out would even know how to do in the first place. If you are smart enough to break it, you are smart enough to fix it.

Re:Bloat

[interval1066]

, I'd rather have more features, higher quality and better performance than lower resource usage.

Well, that's you. Fortunately Linux serves the embedded crowd as well where resource efficiency is highly prized. Score another for Linux.

Re:Bloat

[colinrichardday]

Quite frankly, disk space is cheap.

Not on a 64GB tablet.

Re:Bloat

[Anonymous Coward]

Thus your software will be old, bug ridden and filled to the brim with exploitable and time-tested security holes!
Neat.

Re:Bloat

[Tyler Eaves]

Seriously? Look at how bloated the average "modern" base install is. Look how many background daemons there are. Efficiency went out the window along time ago. The linux of Slackware, or even Gentoo, has largely ceased to be. It has become what it once reviled.

Re:Bloat

[Tyler Eaves]

Like installing software from a 3rd party repo?

Re:Bloat

[Anonymous Coward]

What if you get compromised because a package uses an old version of a library with a zero-day exploit? Even though you already updated the same library for other applications.

Conversely what if all your applications are compromised because one application wasn't compatible with a newer version of the library thus the dependencies caused the update to fail?

Re: Bloat

[TheEffigy]

Efficiency? If that what you think the big difference is, you might as well be using Windows.

Re:Bloat

[Anonymous Coward]

Well, that's you. Fortunately Linux serves the embedded crowd as well where resource efficiency is highly prized. Score another for Linux.

Man, how does the embedded crowd deal with all the bloat of X and Unity and such?

Oh wait, they don't install Ubuntu? Really?

You mean that just because a particular tool (like X, or static packages) is bad in one environment doesn't mean that if you bring it to another, you might as well get rid of Linux?

Re:Bloat

[EvanED]

The big difference with Linux is its efficiency.

For me, the differences are things like (1) better window managers, (2) better native shells (though I really like Powershell), (3) openness, and (4) a couple Linux-only apps. That's why I use Linux some of the time. Efficiency comes in... well, pretty far down the list.

Re:Bloat

[Anonymous Coward]

If everything has no dependencies, then all of the dependencies must be included in the install. I wounder how many copies of each low level program would be on a given machine.

Not an issue, OS X has been doing this rather well for years.

Re:Bloat

[ChrisMaple]

Disk space isn't necessarily the problem. If there's a change in a fundamental library, everything may have to be replaced, resulting in a substantial internet burden.

Re:Bloat

[ArsonSmith]

I know, my cluster base CentOS 6.3 is nearly 800Megs. What happened to the days when I could boot/root two floppies and have a full Unix OS.

Re:Bloat

[interval1066]

Yeah, not too sure how Ubuntu entered into the mix. Not by me. So, burn on, straw man.

Re:Bloat

[interval1066]

Again, not if you're needing an embedded system.

Re:Bloat

[Anonymous Coward]

Probably because the article is about Ubuntu, so it was implied.

Re:Bloat

[EvanED]

Take your pick of either of the following responses; I'm feeling a bit sarcastic at the moment.
----
Oh, I didn't realize that Linux was better than Windows on embedded systems.

[After all, from what you said before, one might as well use Windows if you're on a system where resource usage isn't at the top of the list.]
---
Ah yes. I forgot. Everyone is forced to use the same distribution and same software. That's really too bad... a solution which was more inefficient in terms of resource use but had some properties which would make desktop use nicer would have been nice. But alas.

Re:Bloat

[Burz]

Nope... real desktops don't work like that: http://news.slashdot.org/comments.pl?sid=3730307&cid=43672237

Re:Bloat

[smash]

Probably less of a problem than installing a shared library update which borks a (or multiple) mission critical app. Repeatedly.

Install application patch. Yes it is more bandwidth. Yes it is more disk. Compatibility issues much less frequent.

Re:Bloat

[smash]

Having lived with this approach on OS X for 3 years now, I am all for it. Install/uninstall for the vast majority of stuff is very basic drag/drop. Maybe clean up some saved preference plist files if you care about not having the configuration come back if you ever reinstall the app. I have not noticed any massive shortage of disk space. Most of an application's code is not shared, anyhow.

Re:Bloat

[smash]

You install the individual application updates. Without needing to worry about any one of them breaking other dependencies.

Re:Bloat

[smash]

So, why does Linux now need 256 MB of RAM pretty much as a minimum, to give a similar desktop experience to Windows XP which used to run in 2002 on 32 MB?

Re:Bloat

[smash]

RAM and DISK became far, far cheaper than the time spent dealing with dependency bullshit incurred when you try to do something but can't because the feature is not included in the base OS.

Re:Bloat

[smash]

Cheap is relative. That tablet has about 120 times the storage capacity of my first Linux PC.

Re:Bloat

[smash]

As opposed to the status quo, where if a fundamental library is replaced, it may cause breakage in every dependent app, resulting in a substantial burden.

Mac OS has been using application bundles since forever, and seems to manage just fine.

Re:Bloat

[jones_supa]

This. The cold fact is that Linux is no more the king in efficiency on the desktop.

Re: Bloat

[Anonymous Coward]

That's a misnomer. Xp didn't run on 32 when it came out, it crawled. It wasn't effective until at least 96. Never mind that by 2008 an OEMand up to date xp install basically required 512mb to be usable. That's about compatible to Ubuntu today I think.

Then you've got things like bitmaps and resolution differences. Those are where most of the bloat comed from today.

Re:Bloat

[timbo234]

How about comparing like-with-like instead of new software with software from 10 years ago:
Ubuntu 12.04 (released 2012): 384MB minimum
Windows 7 (released 2009): 1GB minimum for 32-bit, 2GB for 64-bit
Windows 8 (released 2012): 1GB minimum for 32-bit, 2GB for 64-bit

Plus the minimum requirement for XP was 64MB, with 128MB recommended (http://support.microsoft.com/kb/314865), not 32MB.

https://wiki.ubuntu.com/PrecisePangolin/ReleaseNotes/UbuntuDesktop#System_Requirements
http://windows.microsoft.com/en-us/windows-8/system-requirements
http://windows.microsoft.com/en-us/windows7/products/system-requirements

Re: Bloat

[smash]

Funny. I had XP running on 32MB when it came out. It wasn't blisteringly fast, but it was enough to burn CDs and stuff. It performed better with 32 MB than Windows 95 did with 4 MB which was the official requirement on release.

Re:Bloat

[smash]

Ubuntu does not have the same feature set as Windows 7. I was comparing a modern Linux distribution to Windows XP because the feature set is comparable. Release date doesn't really matter a shit, it's what you can actually DO with the operating system that is relevant.

Re:Bloat

[timbo234]

" I was comparing a modern Linux distribution to Windows XP because the feature set is comparable"

It's a nonsensical comparison. Ubuntu with Unity is more comparable to Windows 8, in that it's an attempt to merge the desktop and tablet interfaces - whether it's a real success or not remains to be seen but there's nothing even close to it in XP. Kubuntu provides the more traditional Windows 7-style desktop, with all the new features including 3D effects etc.and still needs a minimum of only 384MB RAM. I'm wondering what these critical features missing from Ubuntu are that only make it comparable to XP?

Re:Bloat

[semi-extrinsic]

The problem is that application developers then have to care about security updates. Which they don't. To wit: Maple's Linux version contains it's own copy of Java, which is 1.6.0 v. 18 on my computer, from a three-month-old Maple install. That's a mind-boggling 30 updates (or 4 years) ago!

Re:Bloat

[MrNiceguy_KS]

If you're working on embedded systems, you're not going to be using Ubuntu.

Re:Bloat

[elashish14]

Well, space still comes at a premium if you want to get a cheap and fast SSD....

Re:Bloat

[Thud457]

a 64GB tablet.

sigh. third millennium problems...


And just to bring this back OT and pile, FUCK THAT SHIT, I AM OUTTA HERE!.
I've been too lazy to get off my butt and pick a different distro, but this is just stupid lame NIH bullshit that just indicates that Canonical just isn't capable of understanding how things work and why they need to work the way they do.

Re:Bloat

[smash]

UI fluff maybe. I'm not talking about UI fluff.

Re:Bloat

[Anonymous Coward]

Please go away forever. I do not like you.

Re:Bloat

[Anonymous Coward]

Ubuntu does not have the same feature set as Windows 7.
True, Ubuntu has a much more comprehensive set of drivers for older hardware. And a whole load of important stuff you'd have to pay for or at least install separately on Win7.

Re:Bloat

[colinrichardday]

Still no excuse for wasting 15% of it.

Re:Bloat

[kermidge]

Wait, whut? (may be replying in wrong place but:)

Does not Ubuntu provide a core install specifically for embedded use?

Re:Bloat

[Anonymous Coward]

I've already read about 40Gb memory the size of a penny, and that was a few years ago. The more appropriate statement would have been "Quite frankly, disk space WILL be cheap."
If you're concern is space, though, you could always look for something that throws out all of the bells and whistles. Granted, the interface would look at sorry as Puppy linux. XD

Re:Bloat

[Burz]

Unfortunately, what uses less space often runs slower (not faster). The performance of Firefox and LibreOffice comes to mind, as they tend to be slower on Linux. And who wants to seriously use a decade-old desktop PC.... egads! I think I'll just find some way to hook up a monitor to my phone instead.

The Linux Desktop 'efficiency' also breaks down on another level: The one where users get inducted into a culture of always worrying about which DE and major version a prospective app uses. Real PC users would not worry about it and would probably carry on with libraries from 2 or 3 DEs loaded (I know this from experience, and no... I do not harrange them into devoting themselves and their app choices to one set of UI libraries). People are understandably turned-off by that kind of circus.

Re:Bloat

[timbo234]

The point is not that you'd want to run it on a decade old PC but that it uses less system resources, leaving more for applications you want to run. The Firefox slowness was a recognised problem to do with not optimising the build for Linux (Mozilla developer's blog entry http://glandium.org/blog/?p=1975). The "Libreoffice is slow" thing sounds anecdotal and a quick google shows just as many Windows users complaining about it.

Users don't need to worry about which DE a program uses, programs which use another DE's toolkit work seamlessly in whatever DE you happen to be using. It's been this way for many, many years so I can't imagine people are being turned off Linux by it.

Re:Bloat

[bigbango]

If each self contained application declared what libaries it contains, the OS could have some sort of security auditing agent that identifies exploits on the system. Kinda like portaudit in FreeBSD.

Why stop there?

[Anonymous Coward]

They should do it all on their own. No more leaching off Debian.

troll bait headline

[Anonymous Coward]

A better headline:

Ubuntu Phone apps will use a different package format than debian/dpkg/apt

I guess that's not really as exciting though

Re:troll bait headline

[MrEricSir]

Ubuntu Phone apps

Let's be clear: Canonical's vision doesn't involve "phone apps." They want the same apps running on your phone and on your desktop.

Re:troll bait headline

[Anonymous Coward]

Ubuntu Phone apps

Let's be clear: Canonical's vision doesn't involve "phone apps." They want the same apps running on your phone and on your desktop.

Ah, yes, the Microsoft theory! Man, that must be good, given how rich Microsoft is! Say, how is that strategy working for them?

Re:troll bait headline

[Anonymous Coward]

Obligatory comment: your traditional desktop is still there in Win8. Don't be afraid of the light.

Re:troll bait headline

[styrotech]

Doesn't really matter what the headline is.

Slashdotters will only see the word Ubuntu or Canonical, and then jump to their own conclusions anyway or rant about something unrelated like Unity or how Ubuntu should give up now because Mint is easily the most popular distro on the planet etc etc.

For example: what percentage of replies below didn't even skim the summary and assumed that Ubuntu will be ditching dpkg and apt for this new tool?

Re:troll bait headline

[Anonymous Coward]

Obligatory snarkiness:

'Sure, I dumped a load of manure on your front door, but your back door is still perfectly accessible. What are you complaining about?'

Re:troll bait headline

[ArsonSmith]

Obligatory: http://xkcd.com/927/

Re:troll bait headline

[Dracos]

I use Mint. I hope this gives them a good reason to at least consider weaning Mint off of Ubuntu packages and repositories. At some point there will be no reason for Mint to maintain the layer between Debian and itself.

I'm still running Lisa (which is now unsupported) and I burned a Nadia disc a few weeks ago, but I'm just going to hold off until Olivia is out at the end of this month.

Re:troll bait headline

[siride]

I can only read that as some sort of innuendo.

Re:troll bait headline

[siride]

Why is xkcd always obligatory? Can't people just post it because they think it might be relevant or funny? Is it actually required?

Re:troll bait headline

[Anonymous Coward]

You must be new here...

Re:troll bait headline

[Anonymous Coward]

That makes sense as phones, tablets and etc approach the laptop/desktop sphere. Consumers don't know what they want, they just are sold on what can be used.

Re:troll bait headline

[rsborg]

Ubuntu Phone apps

Let's be clear: Canonical's vision doesn't involve "phone apps." They want the same apps running on your phone and on your desktop.

Have they by chance been hiring Microsoft employees of late?

And what's with this OS unification frenzy that ignores how touch and pointers behave differently. I even hate it in OSX Lion with the "natural" scroll (though OSX is much less tablet-zombified than Win8). Scroll on a touchscreen is "natural" direction as your fingers track the object 1:1 in real time (hopefully). Scroll on a perpendicular surface separated from the screen (trackpad), and sensitivity could be greater than 1:1 - it's NOT natural to join the directions (it's somewhat workable for the laptop trackpad as you see your fingers and the screen in the same frame, but a magic trackpad just feels weird - I always "reverse" the scroll setting).

Re:troll bait headline

[ais523]

Unlike the Windows 8 version, the Canonical version appears to be to use the same codebase for the tablet and desktop programs, but to have a different interface for each. (It's entirely possible to put multiple interfaces in one codebase or even one binary; NetHack has been doing it for years.)

Re:troll bait headline

[gbjbaanb]

TBH you don't even need to do that - you have the same UI mechanisms for both, only on the phone you run your programs in full-screen, maximised style and on the desktop you run them in overlapped, windowed style.

Changing the buttons so they are bigger on the phone might be something you want to do, but then we also already have different pixel ratio screens to resize windows/fonts/etc so the same system could be used there too.

What the answer is not however, is to put the phone UI on the desktop and say "job done".

Re:troll bait headline

[Anonymous Coward]

Which is why they shall run on neither.

GoboLinux?

[Skinkie]

Wasn't this exactly what GoboLinux embraced?

Re:GoboLinux?

[oodaloop]

No, it was his Uncle Travelling Matt.

Re:GoboLinux?

[Anonymous Coward]

Gobo unfortunately died long time ago :( Still the best directory structure, instead of all those TLAs in "modern" Unices...

The good old days

[thomasdz]

Remember the good old days when everything was just a single -r-xr-xr-x executable in /bin or /usr/bin

sigh, the good old days

Re:The good old days

[phantomfive]

Talk about simplicity. Here is an example 'Makefile' from Unix 6. Compare it to today's auto-tools:

chdir lib
cc -c -O *.c
ar r /lib/liby.a *.o
rm *.o
chdir ../source
cc -s -O y?.c
cmp a.out /usr/bin/yacc
cp a.out /usr/bin/yacc
rm a.out *.o

Re:The good old days

[Anonymous Coward]

You didn't build emacs back in the bad old days, did you?

Re:The good old days

[oodaloop]

Oh, I'm terribly sorry. I didn't realize I was standing on your lawn. I'll remove myself forthwith.

Re:The good old days

[iguana]

*waves cane* Good! Begone you whippersnapper!

Re:The good old days

[MavEtJu]

Call me old-fashioned, but I prefer a proper Makefile which only compiles the files required and which separates between the build and install phase.

Re:The good old days

[phantomfive]

A lot of times that's actually slower, try it out.

Re:The good old days

[phantomfive]

btw that's not old-fashioned, that's newfangled. You and your newfangled Makefiles, get off my lawn!!

Re:The good old days

[Anonymous Coward]

Call me skeptical, but chdir() is a UNIX system call, not a command line program. The command line program is called cd. And why the hell are you byte-comparing a.out with /usr/bin/yacc (which supposedly doesn't even exist yet)?

Re:The good old days

[FooBarWidget]

I can make my Makefile just as simple by targeting Linux + gcc.

Want to make it work on Clang? Oh my Makefile needs to be bigger.
Want to make it work on BSD? Oh my Makefile needs to be bigger.
Want to make it work on Solaris? Oh my Makefile needs to be bigger.
Want to make it work on Windows? Oh my Makefile needs to be huge.

Autotools exist for a reason.

Re:The good old days

[jgrahn]

I can make my Makefile just as simple by targeting Linux + gcc.
Want to make it work on Clang? Oh my Makefile needs to be bigger.
Want to make it work on BSD? Oh my Makefile needs to be bigger.
Want to make it work on Solaris? Oh my Makefile needs to be bigger.
Want to make it work on Windows? Oh my Makefile needs to be huge.

Autotools exist for a reason.

Yes, but it's a reason which often is not valid. I bet I can cover any modern Unix which has gcc and Gnu make with one simple Makefile. (Using the native toolchains, especially the native make, would be significantly harder.) Windows is quite a different thing, and few Unix programmers care about it. There's no decent make there by default anyway.

Clang ... isn't it just another set of $(CC), $(CFLAGS) and $(CPPFLAGS)? Although I admit I'd want a separate "./configure --use-clang" step for that rather than "make USE_CLANG=yes clean all".

Re:The good old days

[FooBarWidget]

I'd like to see you try.

Oh yeah, BSD doesn't have GNU make installed by default. Good luck.

Re:The good old days

[Guy Harris]

Call me skeptical, but chdir() is a UNIX system call, not a command line program. The command line program is called cd.

(Actually, it's a shell builtin, not a program; it has to be, as a child process can't change the parent process's current working directory.)

It's called "chdir" in V6 UNIX, which is what that script was from. See the SH(I) man page in section 1 of the V6 manual.

And why the hell are you byte-comparing a.out with /usr/bin/yacc (which supposedly doesn't even exist yet)?

Beats me. Why don't you ask this guy?

More Flexibility?

[organgtool]

each package would install to its own directory

Would it allow users to install multiple versions of the same application from packages? One of my gripes with Linux is that it's not easy to test new or beta versions of software since there is no easy way to install from packages alongside the existing (stable) version. Yes, I know that I could build the app from source, but that can be quite a hassle sometimes.

Re:More Flexibility?

[girlintraining]

Would it allow users to install multiple versions of the same application from packages? One of my gripes with Linux is that it's not easy to test new or beta versions of software since there is no easy way to install from packages alongside the existing (stable) version. Yes, I know that I could build the app from source, but that can be quite a hassle sometimes.

That's because Linux suffers from a similar problem that Windows 95/98, and XP to a lesser extent did: DLL hell. The average linux installation has thousands of libraries. And they're all referenced and indexed using a half dozen different methods from files in /etc to compile-time kernel flags, etc.

Microsoft solved this (partially) using a centralized registry and integrated it into the operating system. They've tried to add integrity-checking and what-not so that critical DLLs can be reverted in place... a primitive version-control system you can access by running "sfc /scannow" at the command prompt.

Linux doesn't even have that much. It's a crap shoot as to which library version your executable will load. That's why adding 'beta' versions to the mix isn't easy: You could blow up your entire installation, so usually, beta releases are 'static' linked. I don't know why the kernel devs haven't addressed this problem.

Re:More Flexibility?

[Anonymous Coward]

https://nixos.org/nix/

Re:More Flexibility?

[X0563511]

Sure, if you call 'ldconfig' "a half dozen different methods"

Re:More Flexibility?

[Anonymous Coward]

Microsoft solved this (partially) using a centralized registry and integrated it into the operating system. They've tried to add integrity-checking and what-not so that critical DLLs can be reverted in place... a primitive version-control system you can access by running "sfc /scannow" at the command prompt....Linux doesn't even have that much

Thank God, that's definitely NOT the right solution.

Re:More Flexibility?

[interval1066]

Microsoft solved this (partially) using a centralized registry...

Um, the MS registry is a huge pain in the butt for developers and M$ knows it, but they can't get rid of it becuase its too ingrained. Getting rid of the registry was a huge selling point for Windows 8, as it was for Vista... and so on. I dare you to ask me why... if you don't realize its a huge honey pot for virii and hackers you have no business even asking. Linux DOES INDEED have a system for library control, its called pkg_config and it works very well. Its not my problem if developers are too lazy to use it. 90% of linux apps I've ever envountered use it, so don't come whining to me there's no soluton this lib hell of which you speak. I do quite well with Linux, thank you.

Re:More Flexibility?

[jedidiah]

> That's because Linux suffers from a similar problem that Windows 95/98, and XP to a lesser extent did: DLL hell.

"DLL hell" has squat to do with it. The package manager is going to want to replace one version of an app with another. That is the only real problem here. If you ignore the package manager, you can install what you want.

Linux has had versioned shared libraries for ever.

The registry is just crap and you're a moron for even bringing it up in this context.

Re:More Flexibility?

[julian67]

There is no such word as virii either in English or Latin. The plural of virus is viruses.

http://en.wikipedia.org/wiki/Plural_of_virus#Treating_v.C4.ABrus_as_2nd_declension_masculine

Re:More Flexibility?

[girlintraining]

Sure, if you call 'ldconfig' "a half dozen different methods"

Does ldconfig allow for different versions of the same library to be requested by the application? Does ldconfig warn you when a dependancy isn't met? Does it allow per-application flags to override global settings?

Nope.

Re:More Flexibility?

[Jaime2]

Microsoft created registration-free COM and .Net assemblies over ten years ago. Both improve on the old registry-based library locating technologies. Picking on Microsoft for this is like picking on Ford for building the Edsel.

Re:More Flexibility?

[girlintraining]

Um, the MS registry is a huge pain in the butt for developers and M$ knows it, but they can't get rid of it becuase its too ingrained.

Hi. Developer here. No, no it is not. Pain in the ass is thunking, handlers that silently disconnect from message pumps, calls to win32 that are "unmanaged" and so often lead to memory leaks even when you diligently try to do garbage collection, undocumented exceptions that are thrown by system calls that even the debugger blanches at, and endless layers of class and interfaces nine levels deep, many of which only document the public methods and tell you nothing else. The registry though? The registry is stupid easy. If you think that's a pain in the ass, you fail as a programmer. Turn in your badge.

Getting rid of the registry was a huge selling point for Windows 8,

So was the 'Metro' interface. And I don't see many people around here talking about how great Windows 8 is going to be -- everyone says it's going to be a three coiled turd. And this is what you use to advance your argument?

I dare you to ask me why... if you don't realize its a huge honey pot for virii and hackers you have no business even asking.

There's no such thing as 'virii' and I don't think you know what a honey pot is. But perhaps you mean it's a rich repository of system and application settings that could be exploited by malicious people? Yes, that is correct. But then, scanning down the C: for a list of filenames can do that too. The registry has a rich set of access controls; Your lack of familiarity with other security concepts suggests you probably didn't know that.

Linux DOES INDEED have a system for library control, its called pkg_config and it works very well.

A tool used to assist in compiling is not a "library control" tool dude. It's main job is to tell whether a library is installed or not, what version it is, and where it is located. It doesn't do much else. It most certainly does not have any management functions.

Its not my problem if developers are too lazy to use it.

*facepalm* Who wrote the applications you're using right now? Are you sure their "lazyness" isn't your problem?

90% of linux apps I've ever envountered use it, so don't come whining to me there's no soluton this lib hell of which you speak.

That whooshing sound is the point flying over your head. 100% of windows applications have to go through the kernel to load dlls, and so it presents a standardized interface for doing so. Linux does not have this. Whether it's 90% of linux apps, or 99%, the lack of a standard means you, the developer, have to guess, pray, or assume, things about the environment. You can't rely on it.

I do quite well with Linux, thank you.

That's nice. I'm a neo-pagan who dances around poles naked, and it works quite well for me. But I'm not going to suggest it's for everyone, or that there aren't occasional problems in going "sky clad" in a public place. The police, for example, aren't as understanding as one might hope.

Re:More Flexibility?

[Anonymous Coward]

+5 doesn't know what the fuck he's talking about? surely someone with mod points understands soname versioning, ldd, and ldconfig

Re:More Flexibility?

[girlintraining]

The registry is just crap and you're a moron for even bringing it up in this context.

You're just angry that I'm pointing out that linux lacks a central repository for application and kernel settings and you have to dig through /etc 's mass of files to do the same thing. Linux is still rocking the equivalent of ".ini" files, and yeah -- it is primitive. And I'm not a moron for bringing it up, you're a moron for not seeing that sometimes, your religion of choice, could benefit from looking outside of itself and seeing that other developers have done something better.

"DLL hell" has squat to do with it. The package manager is going to want to replace one version of an app with another. That is the only real problem here.

You haven't done software deployment, have you? There's a lot more to it than "replacing one version of an app with another". Applications have dependancies. These dependancies need to be validated, otherwise your copy-paste of a new application could result in a massive shit storm. Especially when you do it 140,000 times at a go.

If you ignore the package manager, you can install what you want.

Umm, no. If an application has been dynamically-linked to a given library, and you upgrade that library and one of the changes is the behavior of a function that application relies on, you can get all kinds of problems from buffer overflows to math errors and all other manner of fail because the application expects one thing and the library delivers something else.

This is the crux of "dll hell"; Multiple versions of a library. And not all of them are even developed by the same group. You can do dll injection, so that when you make a call to one dll, it's intercepted and replaced with something else. A great many exploits work on this functionality. A uniform interface for loading shared libraries, checking versioning and capabilities, etc., would resolve most of these problems and that's what Microsoft has been trying to move towards for years. Linux, meanwhile, has done nothing to address the issue, because malware authors have largely ignored Linux. But god help us all if the "day of the linux desktop" arrives, because we will be well and truly f*cked because of this design oversight.

Linux has had versioned shared libraries for ever.

That's nice. But I was talking about library management.

Re:More Flexibility?

[jedidiah]

> Does ldconfig allow for different versions of the same library to be requested by the application?

Yes.

> Does ldconfig warn you when a dependancy isn't met?

Better than that. You as a user can see what libraries are loaded from where and which ones are missing precisely.

The "superior alternative" is just a black box.

Re:More Flexibility?

[characterZer0]

You're just angry that I'm pointing out that linux lacks a central repository for application and kernel settings and you have to dig through /etc 's mass of files to do the same thing. Linux is still rocking the equivalent of ".ini" files, and yeah -- it is primitive. And I'm not a moron for bringing it up, you're a moron for not seeing that sometimes, your religion of choice, could benefit from looking outside of itself and seeing that other developers have done something better.

Text files for configuration are great. I can version control them, copy them from one system to another, see meaningful diffs between them, and invidual applications can choose formats that are sensible for them.

Why on earth would I want to cram everything into a central repository?

Re:More Flexibility?

[girlintraining]

Does ldconfig allow for different versions of the same library to be requested by the application?

Yes.

Can you please point out which setting in the man page allows you to set this, oh great wizard of Linux? Because I think you're just being a contrarian right now, and haven't actually read the damn page.

Better than that. You as a user can see what libraries are loaded from where and which ones are missing precisely.

Again, read the man page. You can specify which directories it uses to build its cache. That's it. There's no "precision" in that; And if you think I'm going to grep a few thousand lines of output to figure out which library it matched first, you've clearly spent too much time as a user and not enough time as a system administrator. I want something that just works... not having to screw around with a dozen /etc/ config files and another half dozen commands to suss out what went wrong everytime I upgrade a library or application.

The "superior alternative" is just a black box.

It's a black box that happens to meet the business needs of most organizations I have worked for. Linux has not. So, at least as far as usability is concerned, it is a superior alternative. MacOS is even superior from an administration perspective. Linux is good for servers, and that's it. You can build a linux system and then let it happily chortle away for years, even decades -- as long as you don't change anything. Keeping hundreds of linux boxes up to date and patched is a fucking nightmare.

Re:More Flexibility?

[girlintraining]

Why on earth would I want to cram everything into a central repository?

This is a question that's been asked and answered a great many times, if you care to google it. I won't bother going into all of the benefits over centralization... but the biggest one is concurrently running applications: A change in the registry means the applications that access that key get the new value in real time. A file doesn't necessarily do that; Especially if it's been locked for writing.

Re:More Flexibility?

[jedidiah]

I can't address your apparent problems with the man pages. However, I have encountered numerous applications have have managed to specify particular minor library versions.

> And if you think I'm going to grep a few thousand lines of output

You are a completely ignorant moron not really worth responding to. You are a very incompetent troll.

> It's a black box that happens to meet the business needs of most organizations I have worked for.

In other words you're unemployed and living in your mother's basement. Your weak attempts at bluster impresses NO ONE here.

You have no real clue abut Linux or corporate computing.

 

Re:More Flexibility?

[jedidiah]

> I want something that just works

As far as "just works" goes. Nothing that MacOS or WinDOS has can touch a Linux package manager.

That's why Apple copied this feature in their appliances.

Re:More Flexibility?

[girlintraining]

As far as "just works" goes. Nothing that MacOS or WinDOS has can touch a Linux package manager.

SCCM: I push a button. 140,000 machines get updated with the next security patch. I get a nice report showing any failures, and pass this on to my remediation team to follow up on.

Linux: I push a button. Then I push a few more buttons. Then I puzzle over /var/log/debug ... then I recompile the kernel. Then I try deploying the kernel to a few other workstations. Then I find out that some of the modules that I thought weren't needed, were. I recompile the kernel again. Now I deploy the kernel and updated application. About half of the boxes stop booting up. I spend the next few hours paging data centers to reboot them and what special lines to enter into the "boot:" prompt to get it working again. Finally, I get the kernel and application deployed. The application crashes because it expected libc6 instead of libc5. At the end of all of this, I write a custom script to generate a report for me telling me which workstations got installed, which didn't, and if so, how they failed. I write it in Perl, because... Perl. A week later, the application is patched and the phone has stopped ringing from angry users. I open up my inbox... It's another request for a patch. I open my desk drawer, take out the gun, and shoot myself in the head.

Re:More Flexibility?

[girlintraining]

You are a completely ignorant moron not really worth responding to. You are a very incompetent troll.

Yet I make way more money than you could even dream of doing network administration for a Fortune 100 business with over 150,000 workstations. Every night, I push out a half-dozen new applications, patches, and OS installs. Yes, I must be a troll... because I disagreed with your religious persuasions and am making an argument based on facts widely supported by market research and years of professional experience... whereas you're busy emoting on religious furvor.

In other words you're unemployed and living in your mother's basement. Your weak attempts at bluster impresses NO ONE here.

I think you're referring to yourself here, buddy. I'm going out this weekend to buy a new car...

You have no real clue abut Linux or corporate computing.

I know what technologies are in use at over a dozen Fortune 100 companies, and I'm familiar with them. And you know what -- none of them are looking for a boat load of linux administrators. There are reasons for this, whether you want to believe them or not.

Re:More Flexibility?

[Anonymous Coward]

What is WinDOS? Is this 1994?

Re:More Flexibility?

[Follis]

That's not an unmitigated good however, especially if you want to make edits but not commit them until you're done. Unix gets it mostly right in that I can send a NOHUP to tell the other process to reload. What would be nice is if there's a deamon running that would allow the admin to register processes and config files and that would watch the config files and auto-nohup if the admin so desires. Then again, that's probably already been built. Doesn't seem to difficult to write, but I haven't seriously looked into it.

Re:More Flexibility?

[girlintraining]

That's not an unmitigated good however, especially if you want to make edits but not commit them until you're done. Unix gets it mostly right in that I can send a NOHUP to tell the other process to reload.

Look, all I'm saying is that as far as ease of use, Linux fails here. I'm not saying linux can't perform well, or that it doesn't get the job done, etc., etc. What I am saying is that it's way of organizing configuration options is about thirty years old. Newer things have come along since, with clear advantages. Do they have disadvantages of their own? Of course.

But linux would benefit enormously from advancing to at least a central repository for application and operating system settings. If it's feeling particularly daring, it could even look at what Microsoft has done with .net assemblies and COM architecture. But, you know, baby steps...

Re:More Flexibility?

[Anonymous Coward]

Your ignorance of Linux is showing. Please refrain from commenting about things you do not understand.

Can you please point out which setting in the man page allows you to set this, oh great wizard of Linux? Because I think you're just being a contrarian right now, and haven't actually read the damn page.

You won't find that in the ldconfig man page because it's provided by the filesystem. This is a small snippet from the contents of my /usr/lib:

libboost_python-2.7-1_49.so
libboost_python-2.7-1_49.so.1.49.0
libboost_python-2.7-mt-1_49.so
libboost_python-2.7-mt-1_49.so.1.49.0
libboost_python-2.7-mt.so
libboost_python-2.7.so
libboost_python-3.2-1_49.so
libboost_python-3.2-1_49.so.1.49.0
libboost_python-3.2-mt-1_49.so
libboost_python-3.2-mt-1_49.so.1.49.0

Do you see what is happening there? Have you ever actually looked inside /lib or /usr/lib of a *nix system? Did you grasp what you saw? One application may need /usr/lib/libboost_python-2.7.so while another needs /usr/lib/libboost_python-3.2-1_49.so. Both get what they need.

In Linux the library's version is part of its filename. There is no "dll hell". DLL Hell in Windows was caused by a dll with a given filename being replaced by a different version with the *same filename* in the *same location*. I don't think you really understand the DLL Hell situation.

There's no man page for knowing what you're talking about.

Re:More Flexibility?

[Anonymous Coward]

/etc is the registry, and it is no more or less centralized than the Windows registry (which consists of multiple files).

The difference is that /etc is implemented using two of the most mature and well understood pieces of the system: a file system directory hierarchy and text files.

The windows registry, in contrast, is implemented using a limited and clunky database, which is difficult to manage and drives even experienced users to frustration.

And speaking of "rich access control". /etc has extremely robust access control via the filesystem. Access control that is well tested, well documented and well understood.

Re:More Flexibility?

[alcourt]

Query: ldd
Control: see the various environment variables that specify which lib dirs are used in what order for that environment you just created. (LD_LIBRARY_...)

Applications can specify the exact version number of a library (.so.1 vs .so.2).

Note, none of this is Linux specific. That family of operating systems is far from perfect in shared library handling, but I won't pretend that it doesn't inherit at least some tools that have at least some flexibility from older Unix tools.

Re:More Flexibility?

[alcourt]

Because you want AIX?

Re:More Flexibility?

[girlintraining]

Oooh, your a pagan... is that the sign that I'm supposed to take you seriously? Shillin' for Microsoft... they're recruiting from you freaks now eh?

And yet they mod me as the troll in this discussion...

Re:More Flexibility?

[Electricity Likes Me]

Also isn't this an app-problem? There's no specific reason any Windows app will actually re-read a changed registry key. It's easy enough to stick an inotify on your config files (and tons of daemons do exactly this).

Re:More Flexibility?

[Idimmu Xul]

You're just angry that I'm pointing out that linux lacks a central repository for application and kernel settings and you have to dig through /etc 's mass of files to do the same thing. Linux is still rocking the equivalent of ".ini" files, and yeah -- it is primitive.

I hope this is the greatest troll comment ever, because this is the last thing Linux needs. /etc is so mind numbingly simple and can be traversed with vim, grep and find so easily that turning it in to a shit fest of a binary repository, e.g. window's registry or even gconf's xml would be horrific

not having a repository like that is a feature as opposed to an over architected flaw

Re: More Flexibility?

[Anonymous Coward]

You are confusing Windows with .net, and the usability of the registry APIs with the usability of the system with the registry. In other words, you don't really know what you are talking about... I guess you need more training??

Re:More Flexibility?

[EvanED]

The difference is that /etc is implemented using two of the most mature and well understood pieces of the system: a file system directory hierarchy and text files.

You're simplifying.

You can't just say "text files", because I can't write "Hey Apache, I want you to put password protection on the stuff in /var/html/secret" in a file and have it work. Instead, Linux config files take many different formats, from INI-style to XML to shell scripts to custom formats like the X11 config.

I can very easily turn around the argument as follows:

"The difference is that /etc is implemented using a bunch of inconsistent formats. The Windows registry, in contrast, is implemented using a consistent, reasonably simple, typed key-value hierarchical database."

And speaking of "rich access control". /etc has extremely robust access control via the filesystem. Access control that is well tested, well documented and well understood.

The equivalent of registry-style access control would be more like separate ACLs for each line of a file. To do that, oh, you have to write a special program like crontab which runs with setuid (I guess that's what it does?) to edit the file but takes instructions from something else.

Useful? No clue, I don't do enterprise stuff. But from a pure objective level, the Windows registry offers a significantly more expressive set of security settings.

Re:More Flexibility?

[Anonymous Coward]

Admit it. C'mon now. JUST ADMIT IT!! You're fat.

Re:More Flexibility?

[jedidiah]

> doing network administration for a Fortune 100 business with over 150,000 workstations. Every night, I push out a half-dozen new applications, patches, and OS installs.

You need to troll better. I'm not calling you a troll because you disagreed with me. I am calling you a troll because you are a very bad liar.

Some of us have actually worked in environments like that.

It's like you're bringing a knife to an NRA convention.

Re:More Flexibility?

[jedidiah]

> then I recompile the kernel.

You might as well rename yourself to troll-in-training for that one.

It's like you aren't even trying.

Re:More Flexibility?

[jedidiah]

It's not 1994. It's 1984. It's always 1984 because you can't quite get away from the really bad design decisions that you once institutionalized. Even if you try to get away from it, it will tend to continue to linger and bite you in the arse.

Re:More Flexibility?

[Anonymous Coward]

and its easy to do a callback when a branch of the registry changes as well.

Re:More Flexibility?

[Anonymous Coward]

A _network administrator_ for a Fortune 100 that pushes out applications?

Color me skeptical.

Re:More Flexibility?

[Anonymous Coward]

huh. I work for a Fortune 5 company... and we can't hire enough Linux peeps.

Same for the Fortune 10 company before that. Weird.

Re:More Flexibility?

[El_Oscuro]

It seems like every time I make a change to something in the Windows Registry, I have to reboot. On Linux, I usually just have to restart the app or service that uses it.

Re:More Flexibility?

[ArsonSmith]

You have absolutely no idea what you're talking about. That doesn't even make sense as FUD. Were you just making stuff up as you went along?

Re:More Flexibility?

[Anonymous Coward]

Oooh, your a pagan

They are certainly not recruiting illiterates.
-Grammar Nazi

Re:More Flexibility?

[siride]

That may have been true for Windows 95/98, but NT was never based on DOS or really had anything to do with it.

Re:More Flexibility?

[Anonymous Coward]

Win32 API calls that require extremely specific inputs you can only find out by visiting The New Old Thing and reading a very matter-of-fact blog post are my favorite.

Re:More Flexibility?

[girlintraining]

Some of us have actually worked in environments like that.

You know, as much as I'd love to zip-thud and reveal my realworld identity and confirm that not only am I telling the truth, but I can provide specific examples, I am bound by an NDA and company policy that prohibits me from disclosing who I work for on social media.

I stand by what I said; The wide variety of linux distributions, software versions, differing packaging applications, etc., makes patch management and software deployment a nightmare. Every place that I have worked at where linux was used, has experienced major logistical headaches. Part of this is due to a lack of labor resources that are adequately trained in Linux, but a lot of it is that there aren't any enterprise-grade tools to make it easy. Most companies that support a lot of linux systems have rolled their own deployment infrastructure and have tried to standardize on one specific distribution to limit the amount of testing and validation needed.

Professionally, I can't recommend linux for anything other than servers and embedded solutions where the systems will run for years without being overhauled and that the only security patches to be applied will be for public-facing services.

That's just the reality of the industry. I have no attachment to Microsoft products; I've used MacOS, Linux, Windows... along with a variety of other now-defunct platforms like OS/2 Warp, BeOS, even CP/M. I'm "agnostic" about operating systems. My job as an IT professional is to facilitate the business process using the tools and resources given to me.

Re:More Flexibility?

[Anonymous Coward]

"100% of windows applications have to go through the kernel to load dlls,"

And going 'have to go through the kernel' for something that virtually every program needs to do is a good thing why?

Do you even realize how screwed up the DLL format itself is? Reference symbols by index number to a jump table, really? oh wait, there is a hack solution for that that adds some more indirect references. Oh and more hacks involving file timestamps and checksums? and the declspec and 'lib' file bandaid? If you don't know what I'm talking about then you don't know DLL's. DLL hell is DLL hell, not shared library hell.

"and so it presents a standardized interface for doing so. Linux does not have this. "

Bzzt. Wrong again. On linux shared libraries are either loaded automatically through the elf format, or demand-loaded through a standard api call with all the flexibility a developer would want, no hacks all clean.

Re:More Flexibility?

[girlintraining]

Your ignorance of Linux is showing. Please refrain from commenting about things you do not understand.

Blame the idiot that said 'ldconfig' does that, you arrogant bastard, not me.

Re:More Flexibility?

[Anonymous Coward]

You're just angry that I'm pointing out that linux lacks a central repository for application and kernel settings and you have to dig through /etc 's mass of files to do the same thing. Linux is still rocking the equivalent of ".ini" files, and yeah -- it is primitive. And I'm not a moron for bringing it up, you're a moron for not seeing that sometimes, your religion of choice, could benefit from looking outside of itself and seeing that other developers have done something better.

Text files for configuration are great. I can version control them, copy them from one system to another, see meaningful diffs between them, and invidual applications can choose formats that are sensible for them.

Why on earth would I want to cram everything into a central repository?

I followed you right up until the part I bolded, THAT is not a feature. The zoo of configuration syntax are a plague on Unix systems.

Look at the history of sudoers vulnerabilities, see how many are parser related.
http://web.nvd.nist.gov/view/vuln/search-results?query=sudoers&search_type=all&cves=on

Yup, version control, difference visualization, importing, exporting are all important features. But keeping the data in one spot or many has nothing to do with those.

Know what else is important to configuration management? Idempotency.
I don't mean the "if not grep KEYWORD sudoers then sed insert some shit" kind where you hope to be lucky.

Re:More Flexibility?

[jedidiah]

NT doesn't have to be based on DOS to suffer from the same kind of bad design decisions and single user mentality that plagued it's predecessors. Windows is fundementally a legacy support product. Cruft and bad habits linger.

Re:More Flexibility?

[starfishsystems]

Moreover, the "centralized" Registry isn't centralized at all. It's specific to each individual PC. It doesn't scale at all. You can't use it to manage a network of systems even in the simple ways we were doing in Unix at the time Microsoft introduced its Registry concept, much less in the contemporary sense necessary for Cloud configuration.

Re:More Flexibility?

[Anonymous Coward]

/etc is the registry, and it is no more or less centralized than the Windows registry (which consists of multiple files).

The difference is that /etc is implemented using two of the most mature and well understood pieces of the system: a file system directory hierarchy and text files.

The windows registry, in contrast, is implemented using a limited and clunky database, which is difficult to manage and drives even experienced users to frustration.

And speaking of "rich access control". /etc has extremely robust access control via the filesystem. Access control that is well tested, well documented and well understood.

Thank you for pointing out the similarities, now let me point out the big honking difference: /etc/* is in a hundred different syntaxes and damn near impossible to do fine grained configuration management in. You have to overwrite whole files usually because there is no idempotent way of asserting a specific granular setting.

For example, you can't just "set the first NTP server" in ntpd.conf. You have to create a template and generate it, or manage a whole copy, throwing away the original contents either way. I'm sorry, but sed search & replacing your way to victory just doesn't scale.

You can keep your distributed configs if they were a consistent syntax like plists on OS X. Then management from vi AND Puppet would be WAAAAY easier. If we can predict where config data is, it doesn't really matter if it's spread across many files, one big one, a database, or a bunch of databases. Idempotency, idempotency, idempotency.

IDEMPOTENCY!!!!!!

Re:More Flexibility?

[ohnocitizen]

Oh, that delicious linux user condescension.

There's no man page for knowing what you're talking about.

Actually that's what man pages are for - they provide application specific knowledge. Though I usually prefer to just google about for answers. If I'm feeling really masochistic I might post a technical question on slashdot, and read responses from ACs.

Re:More Flexibility?

[smash]

Should do. There's no reason I can't install multiple copies of an OS X application by just dragging and dropping copies to different folders.

Re:More Flexibility?

[Anonymous Coward]

You ever get the feeling you're doing it wrong? It turns out that I manage 30, 000 Linux boxes and I don't do anything that you just described. I don't think that would change much if it were 140,000 machines.

Re:More Flexibility?

[smash]

Uhh... typical mac installer. Fuck package mangers.... want to move the app to a different disk? Drag/drop. No dependency bullshit to deal with. Can run it from the network if i really wanted to.

Re:More Flexibility?

[Hypotensive]

pkgconfig is a GNOME library control mechanism, not a Linux one. The fact that 90% of the programs you use use it says more about you than it does about developers.

Re:More Flexibility?

[Anonymous Coward]

You're obviously unable to refute the point or come up with a viable counter-argument.

You then make the claim that GP is a 'troll', to which you respond, meaning you either want to deflect from your inability to come up with a rational counter-argument by resorting to name-calling, or you genuinely believe that GP is a troll yet are too weak-minded to stop yourself from giving a troll exactly what he/she wants.

The suggestion that the GP has 'no clue' doesn't bode well for your post either, I don't know who is right and who is wrong (if it is indeed black and white like that) but I'm inclined to think less of your post as it is just full of name-calling and hyperbole. GP's post may not be full of facts, but it is at least anecdotal evidence which should be pretty easy to refute if you do indeed know what you're talking about.

Also obviously given that you continued to post even after the 'troll' tirade and also this:

You are a completely ignorant moron not really worth responding to.

It doesn't seem you can even keep your own thoughts and actions consistent.

Re:More Flexibility?

[Anonymous Coward]

Nothing that MacOS or WinDOS has can touch a Linux package manager.

There's really nothing more pathetic than a rabid religious nerd that is frothing so hard at the mouth over computer operating systems that he refuses to even spell them correctly or use their correct moniker, seriously dude get a life and stop getting so hard up over this shit.

Re:More Flexibility?

[Electricity Likes Me]

With the point being, that it's not a problem with either approach since it depends on an app developer thinking "I should monitor my configuration for changes".

Re:More Flexibility?

[mvdwege]

Stop digging yourself deeper by showing you don't understand at all.

ldconfig tells your system where to look for libraries. Libraries on *nix systems are versioned, and can be installed side-by-side. ldconfig doesn't need to differentiate by version, the applications do that.

Granted, if an application requests a library without a version, it will get the latest one, which might break things. But no OS can protect against programmers making decisions like that, and that is something that is easily patched.

But dismissing the entire system of library versioning based on that is showing ignorance. Allow yourself to be educated, instead of trolling with 20-year old FUD.

Re:More Flexibility?

[mvdwege]

Linux: I roll out my updates into my Puppet repository. They get rolled out automatically on all subscribed systems, with failures mailed to me.

Really, if you are going to spread FUD, please update your knowledge, you are at least 30 years out of date.

Re:More Flexibility?

[jgrahn]

The registry is just crap and you're a moron for even bringing it up in this context.

You're just angry that I'm pointing out that linux lacks a central repository for application and kernel settings and you have to dig through /etc 's mass of files to do the same thing.

But /etc *is* the central repository for application and kernel settings you're talking about.

(Except the user-specific settings. It's unfortunate that ~/.??* doesn't cover all such settings and nothing *but* such settings. In retrospect it should have been ~/etc/ or something.)

Re:More Flexibility?

[Anonymous Coward]

Different versions: install both libfoo.so.1 and libfoo.so.2, programs can then either link against libfoo.so.1 (specific version) or libfoo.so (latest/any version).

The linker itself (ld.so or ld-linux.so - http://linux.die.net/man/8/ld-linux) tells you it can't load the executable if a dependancy isn't met. ldconfig just sets up a cache file for the linker so it doesn't have to search for libraries on disk every time you run a program. If you need to track it down by hand, "ldd" will list each object's dependencies.

The linker itself obeys LD_* environment variables in preference to the system defaults. Environment variables are per-process, so if you really need to override a global linker default to load your executable, just put a shell wrapper around it, e.g. LD_LIBRARY_PATH=/my/path/lib /my/path/bin/myexecutable

Re:More Flexibility?

[serviscope_minor]

Who are you and what have you done with girlintraining?

The dynamic loader on Linux is very flexible. There are actually several different systems of varying granularity availble.

The coarsest is using LD_LIBRARY_PATH to allow one program to use a different .so.

The next is versioning with libblah.so.?, which allows different .sos to be made available depending on how the program was compiled. This requires a little bit of care on the part of the library author to actually bother to increment the version numbers.

The next, more complex is symbol versioning within a .so. This allows a single .so to have multiple different versions within it, so a single.so can actually serve multiple different versions. This is really good for system libraries and allows a great deal of backwards compatibility without bloating the number of libraries, and while allowing the maximum amount of code sharing. It requires the most discipline, so is generally only done by the dedicated libc and libstdc++ people. It's particularly important for system libraries, since it allows libraries which depend on "different" versions of glibc or libstdc++ to be linked together without trouble.

This is why a modern libstdc++.so.6 can happily serve g++ compiled binaries from just after the last ABI change to now without trouble.

Keeping hundreds of linux boxes up to date and patched is a fucking nightmare.

What? With the popular, sane distros, you can install some version with some reasonable support term (DeadRat, CentOS, Ubuntu LTS, Suse) and just tell it to auto-update the packages at 3 AM. You can even point it at a local package mirror if you want to save on external bandwidth.

In fact one can easily create a PXE installer which will install a customised package list and set up that configuration for you. Once you've done that, you buy a new machine, mess with the BIOS just enough to PXE boot it, choose the version you want and hit go. 1 hour later, you'll have a working, freshly installed system which will keep itself up to date with security patches until the distro drops off support.

If you want to rely on 3rd party programs which sit in /opt, it is very easy to download the program, untar it and chuck the files into a dkpg or RPM file, and then just add that package to the list. In fact people like LibreOffice only make APTs and RPMs available making it a minor faff to install on a less popular distro.

Again, once you do that, it will automatically roll out to all machines. Of course there's a bit more interaction, but then it is up to you whether you want to upgrade to a new major version of LibreOffice or whatever. And this way, the users won't get exposed to those program's nasty auto-updater scripts hassling them for new versions or whatever.

Honestly, if you're having trouble keeping Linux boxes up to date, then you are doing something wrong.

Re:More Flexibility?

[Anonymous Coward]

It sounds like you either need to learn more Linux and get out of your comfort zone, or you need to start paying enterprise Linux vendors in the same way you're already paying Microsoft.

If you're running your own Linux installations, they run unattended-upgrades and upgrade to whatever the latest signed packages are, every day. No human intervention needed.

When you set up Linux on hundreds of machines, you set it up to use your own local package repository so they don't all need access to the internet. This is easy. You can then put your own signed packages in this repository. Each machine will update automatically because you already told them to. A report of what's installed where is just "for host in `cat hosts.txt`; do ssh myadminuser@$host dpkg -l mypackagename; done", or something fancier if you prefer it.

As you're a diligent sysadmin, you don't push out new packages without testing them first. So some of your linux machines are set to the "unstable" or "testing" branch of the package repository, and you first put your package there and see what happens. If it's all fine, you copy the package to the stable branch and then every other machine picks it up automatically.

Alternatively, if this sounds like too much hard work, pay RedHat and they do all this for you, just like Microsoft do all this for you because you pay them.

Re:More Flexibility?

[serviscope_minor]

There is no such word as virii either in English

And what, precisely, defines a word as "in English". If it's (a) in common use and (b) widely understood is it not in the language?

There are already many words with weird forms and odd back formations based on old misunderstandings so that's hardly a reason to exclude one particular example.

Re:More Flexibility?

[gbjbaanb]

calls to win32 that are "unmanaged" and so often lead to memory leaks even when you diligently try to do garbage collection

there's your problem - trying to use the native, OS from a managed sandbox environment. The dev div at MS really wanted to write everything themselves and ignore the actual platform. Trouble is, they did a piss poor job of it (read Chris Brumme's blog posts for examples, and he was the guy who write it!). If they had co-operated with the Windows division, they might have done something good, but no.. ego got in the way.

So, keep using your managed environment and good luck to you - but the problem is the detached environment layer you're using.

Re:More Flexibility?

[WaroDaBeast]

Compare what is comparable.

But before I the actual argument, here is a fact: even if we all agreed on "virus" being a second declension, masculine Latin word, it'd still be "viri" in the plural. Now, that kind of discredits people who think we should use "virii", doesn't it?

On the one hand, you've got a bunch of illiterate people. On the other hand, you have people who have studied languages (not just their own native language) for several years. It isn't far-fetched to think that the latter group, possessing not only practical but also theoretical linguistics skills, would be better-trained to abide by the rules.

Besides, if you throw the whole globalization thing into the mix, it's obvious that adhering to a defined set of rules benefits us. Language is a communication tool. If we stray off defined standards too much, we're hindering communication. Back when people were illiterate, communication was slow, so it was okay not to be so efficient. The same cannot be said in today's globalized world.

We didn't start talking about viruses until very recently — moreso when it comes to computer viruses.

Quite interestingly, this makes me think about the very topic of this article: what if every and each Linux distribution out there decided that the standard procedures as a whole are too weird? That things aren't systematic enough? What if, as a result, they all decided to make their own package format?


tl;dr While it is unreasonable, nowadays, to expect people to try and correct the whole of their language's vocab (which is in part very old), expecting said people to correct recent, misunderstood words isn't unreasonable.


P.S.: I don't think descriptive grammar (i.e. common use) is good enough. If you decide to solely go down that road, you'll end up with something even harder to conceive than English as it is now. I think a mix between prescriptive and descriptive is the best, as it is the best of both worlds: the theoretical aspect and its pragmatical counterpart.

Re:More Flexibility?

[gbjbaanb]

Why on earth would I want to cram everything into a central repository?

because its then much easier to find what you're looking for, compared to having configs scattered all over the place. (eg the mysql config being 'somewhere else' that I can never remember)

However, there is no reason why that central repository cannot be a directory called /etc with every config as a file! Simple, effective and all the benefits of a centralised repo.

Re:More Flexibility?

[Ash-Fox]

Note: I am not the grandparent.

I stand by what I said; The wide variety of linux distributions, software versions, differing packaging applications, etc., makes patch management and software deployment a nightmare.

I suspect you don't know how to do it properly based off that comment, since you don't even come up with any real examples or even bother naming a technology.

but a lot of it is that there aren't any enterprise-grade tools to make it easy.

I guess these relatively easy deployment tools I use on SuSE and Redhat for Enterprise level setups are just figments of my imagination. The funny thing is that I've been using these tools for years, back when Windows had 'Systems Management Server' as standard, so these aren't even a new development.

if you consider Windows' System Center Configuration Manager to be 'enterprise-grade' for software management, the package managers you get for free out of the box from major Linux distros tend to actually surpass it (I personally prefer some of the better all-in-one solutions that Novell provides that offer a level of fine grained management that is much harder to maintain and scale in Windows).

Re:More Flexibility?

[Ash-Fox]

Note: I am not the grandparent.

You can't just say "text files", because I can't write "Hey Apache, I want you to put password protection on the stuff in /var/html/secret" in a file and have it work.

Please explain to me how to get IIS8 to put password protection on the stuff in C:\inetpub\wwwroot\html\secret using only the Windows registry. :)

You can't just say "text files", because I can't write "Hey Apache, I want you to put password protection on the stuff in /var/html/secret" in a file and have it work.

To be honest, if you're in IT and someone tells you there is a "text file" configuration which results in you concluding that, there are bigger problems than that.

Re:More Flexibility?

[julian67]

Don't be one of the doofi. Go back to your boxen.

Re:More Flexibility?

[serviscope_minor]

But before I the actual argument, here is a fact: even if we all agreed on "virus" being a second declension

Who cares? The language we are talking about is English not Latin. If you confuse the two, then you end up claiming nonsensical things like a split infinitive is somehow bad, but not then extending that to the split nominitive.

Besides, if you throw the whole globalization thing into the mix, it's obvious that adhering to a defined set of rules benefits us.

What defined set of rules? English does not have any agency claiming to be the definitive controlling authority. The rules, such as they are are descriptive, not prescriptive and are compiled by many separate organisations. They do not always agree.

English is already full of all sorts of weird and wonderful pluralisations, reflecting its background of agglomerating words from two different primary languages, the grammar from one, but some rules randomly from another and then adopting a whole bunch of random words from other languages, and commonly applying a mis-matched set of rules. There's already more than one greek/latin/english mangling already widely accepted.

Actually, I do agree with your points on the whole. If people don't agree on language, then life becomes a mess. On the other hand language is what people speak to each other regardless of what anyone says.

But I can't find myself getting worked up about virii versus viruses, since applying some rules to an inappropriate word isn't exactly rare already. It also doesn't introduce any ambiguity.

Re:More Flexibility?

[Anonymous Coward]

Sometimes newer is not better.

Most people with an interest in the matter agree that the Linux conf files are, for the most part, less of a pain than the Windows registry.

I guess they're wrong though, eh?

Us cranky old *nix grannies need to get with the times are adopt a nice, opaque, inscrutable centralised registry. No better thing than a centralized registry to keep those settings safe, eh?

Re:More Flexibility?

[Anonymous Coward]

Not really true as there are very good (third-party) packagemanagers for both windows and osx. But these systems are primarilly used to distribute open source software, and the average windows/osx user really could not care less.

Re:More Flexibility?

[Anonymous Coward]

Nerds shall plurai words however they like!

Re:More Flexibility?

[siride]

You're not really making any arguments based on facts here, just railing out the same tired bullshit that Linux fanbois are so fond of. You clearly don't know anything about Windows NT's design, so it'd be best if you just stopped commenting.

Re:More Flexibility?

[Anonymous Coward]

Whatever. I'm going to use it irregardless.

Re:More Flexibility?

[julian67]

Surely that should be pluralizate?

In nerd land what is the plural of sheep?

venii, vidii, vicii, virii.

Re:More Flexibility?

[julian67]

I'm not sure I believe you but the proof is in the pudding.

Re:More Flexibility?

[X0563511]

It sounds like you've only tried to do Linux the hard way, without tools like Puppet or Chef to help you out.

Sure, it's a nightmare if you try to do everything yourself the hard way - but why would you do that?

Re:More Flexibility?

[Anonymous Coward]

I doubt any of my peers I have ever heard use Virii or Lexii has been under the illusion that it is anything but an indulgence of silliness. If the person were of a much different background than my own, or said something like "Virus? Virii?,..." then there may be cause to get all uppity about such matters.

I would completely accept the formal Latin tutorial if it is itself a joke. At which point this complaint is to the humorless mods that made this informative.

Re:More Flexibility?

[julian67]

I feel duty bound to point out your inappropriate use of capitalisation.

Re:More Flexibility?

[Anonymous Coward]

You need to troll better.

i disagree. if he/she is indeed a troll he/she has you by the balls! dude look at all the times you threw out the "troll" call and then continued to respond. calling somebody a troll is just proof that you can't refute their argument, in doing so you are replying and giving the troll exactly what they want, which a person genuinely believes they are being trolled obviously would not do.

Re:More Flexibility?

[Anonymous Coward]

You might as well rename yourself to troll-in-training for that one.

i reckon troll-pro is more appropriate given how well it's working against you!

It's like you aren't even trying.

wow! i'd hate to see what happens to you when somebody actually tries to troll you then :P

Re:More Flexibility?

[Guy Harris]

100% of windows applications have to go through the kernel to load dlls

As do 100% of Linux applications, *BSD applications, Solaris applications, HP-UX applications, AIX applications, OS X applications, etc., because accessing files such as shared library files on those OSes involves the kernel.

However, at least as I read the Windows Internals books, the actual loading of dlls other than ntdll.dll is done in user mode by LdrInitializeThunk.

On most current UN*Xes, the process of launching an executable image, except for 100% statically-linked images, involves the execution of the run-time linker, with the executable image itself handed to the run-time linker as a parameter in some fashion (e.g., being opened as a file, with a file descriptor for it being available to the run-time linker); the run-time linker, running in user mode, loads the shared libraries. (See the PT_INTERP program header element in ELF or the LC_LOAD_DYLINKER load command in Mach-O; those specify the image file to use as the run-time linker.)

and so it presents a standardized interface for doing so. Linux does not have this.

It might be easier to use a different mechanism for loading dynamically-linked libraries on Linux (or other UN*Xes) than on Windows, but it still takes work.

Are the Linux apps that don't use the standard Linux mechanism (ld.so) 100% statically-linked images, or what?

Re:More Flexibility?

[Guy Harris]

I'm face palming now 'cause omg-config most certainly part of the installation procedure for apps. .pc files?

pkg-config is part of the installation process for libfoobar-devel packages. It's not part of the installation process for libfoobar packages; you may need the .pc files for a library if you're developing code that uses it, but you don't need them if you're running prebuilt binaries that use it.

Re:More Flexibility?

[Anonymous Coward]

Um, the MS registry is a huge pain in the butt for developers and M$ knows it, but they can't get rid of it becuase its too ingrained.

I really don't know how Linux developers have gained this misapprehension, except perhaps by projecting their own disdain for the registry onto Windows programmers. I've been writing software for Windows since 3.x (3.0 if you include the usual array of college work), and I've never known any decent Windows developers who despise the registry. It's just another part of working within the system, and you're not forced to use it for most applications, not even COM registration since WinXP. Anyone who doesn't want to use the registry for desktop applications could store settings in XML files, flat name-value text files, or whatever - even INI files still work on modern versions of Windows. You need to use it for services, control panel applets, and a few other things, but most Windows developers aren't writing those. Installation developers need to use the registry, but modern tools like InstallShield, despite their pitfalls and annoyances, handle most of that for you unless you really need something unusual.

Getting rid of the registry was a huge selling point for Windows 8, as it was for Vista... and so on.

I don't recall seeing this in any of the advertisements for these operating systems, nor in any of the product announcements, and I doubt it would be anything more than a marginal selling point to most Windows developers (except maybe registration-free COM). The API is a bit clumsy, but also quite simple; we just don't find it to be that annoying.

- T

Re:More Flexibility?

[Anonymous Coward]

Text files for configuration are great. I can version control them, copy them from one system to another, see meaningful diffs between them...

You can do these things with .reg files if you're willing to jump through a couple of fairly simple hoops. It's not as trivially done as it is for config files, but the trade-off you get is a centrally managed settings repository with built-in ACLs and a handful of basic types beyond just strings.

...and invidual applications can choose formats that are sensible for them.

That's potentially a misfeature. The registry has basic types built-in, so the need for parsing is minimal, thus so is the opportunity for a custom parsing implementation to introduce problems. The ugliest thing I can encounter in the registry is a binary blob, and those are nearly all tucked away in places where I shouldn't be mucking around anyway.

- T

Re:More Flexibility?

[Anonymous Coward]

You can't just say "text files", because I can't write "Hey Apache, I want you to put password protection on the stuff in /var/html/secret" in a file and have it work.

Please explain to me how to get IIS8 to put password protection on the stuff in C:\inetpub\wwwroot\html\secret using only the Windows registry. :)

It's not clear to me if you're just joking here; in case you're serious: I think you might have missed the broader context of this sub-thread, so going back to the GGP and reading from there might clear it up. I think what EvanED was getting at is that although Linux filesystem permissions, while time-tested and well-understood, can be used to protect configuration text files, the granularity is at the file level. For the Windows registry, the granularity of protection from ACLs is at the registry key level. I think EvanED's example was meant to illustrate the fact that protecting just a few lines of a config file cannot be achieved using only the traditional filesystem security; you'd have to split the configuration file, or go some other route.

I wrote this to try to clarify things, but it sounds a bit snarky upon rereading it. I don't mean it to be, but I'm too lazy to rewrite it.

- T

Re:More Flexibility?

[Burz]

This is overstating the advantage of text files. They are *immature* in Unix/Linux in the sense that there are many different formats; The way Windows used .ini files was better.

Case in point: X11 for many years had no standard interface for changing and saving its own config settings. Instead, whatever trampy settings dialog that 'distro-Z' slapped together had to interpret and re-write Xfree/xorg's config file. Problem was the format was fairly complex and it was obvious that few coders were confident in its interpretation. This led not only to frequent Oopses and being dumped to a CLI or worse, but also to a stark dearth of options in the config UIs... any number of different utilities could be mucking around with the config file so the uncertainty led to an ultraconservative paucity of options for users. (This led to many power users and techies to changing Xorg.conf by hand to get certain features to work, and this would often make the control panel app go spastic.)

Having a registry makes *some* of the above problems go away to some extent. The Windows registry is a database with a very regular interface and virtually no guessing about formatting.

OTOH, Mac OS X is close to having the best of both worlds with its plist files. You can treat them in a Unix-y way, yet the formatting and even the possible types of relationships between elements is very predictable because it uses an XML-based format. Only a relatively small amount of config stuff is still using dispararte formats in /etc. The upshot is that I can change areas of OS X that I don't feel expert in with greater confidence than in Linux, because at least I'm on solid footing with the file format and so there is substantially less worrying in the back of my mind about the possilbility that I misunderstood or botched something.

Re:More Flexibility?

[Anonymous Coward]

There are reasons for this, whether you want to believe them or not.

And they are called the UNIX wars.

Re:More Flexibility?

[Anonymous Coward]

Good grief. Is it a hobby of yours to actively demonstrate that you're not getting it?

There's no man page for the particular thing the earlier poster was talking about.

Just as there's no man page for how to cook an Apache process in shower gel. Some topics simply are not, and should not be, covered by man pages.

Re:More Flexibility?

[haploc]

Keeping hundreds of linux boxes up to date and patched is a fucking nightmare.

For that we have automation tools like Puppet, Chef, CfEngine, Ansible, Satellite/Spacewalk or any other orchestration system.
Even some basic scripting can get your pretty far already..
Check them out, maybe.

Re:More Flexibility?

[Ash-Fox]

I think EvanED's example was meant to illustrate the fact that protecting just a few lines of a config file cannot be achieved using only the traditional filesystem security; you'd have to split the configuration file, or go some other route.

Indeed, but the point is invalid when Windows applications and services don't exclusively rely on the registry for storing their settings. Especially when the example given doesn't even work on Windows. To put it another way, it doesn't really matter what the theory is if it isn't done in practice. It's even worse to note that Microsoft that sets the 'standard' on how applications should be created in Windows doesn't even do it.

Re:More Flexibility?

[Hognoxious]

You clearly don't know anything about Windows NT's design

I'm surprised to hear it had one.

Re:More Flexibility?

[Hognoxious]

Who cares? The language we are talking about is English not Latin.

In English we don't form plurals by changing -us to -i either.

Shall I drop a new shovel down to you?

Re:More Flexibility?

[drinkypoo]

And yet they mod me as the troll in this discussion...

I've seen good evidence that you are a troll more than once. On the other hand, your statements clearly make you threatening because some people believe that anyone who would self-identify in this fashion is too dumb to operate a computer.

Re:More Flexibility?

[siride]

Yes, it did. It was developed as a completely separate product from Windows starting in the late 80s. They hired people from DEC and worked with IBM. It was a serious project. Take some time to look into the architecture and you might learn some things.

Re:More Flexibility?

[drinkypoo]

Actually, I think the objection is valid. The Windows registry has per-key permissions. You can't set a permission on a line in a file on Unix. You can break a config file up into multiple parts to which different users have permissions, but then you're just making /etc even more fragmentary. This is essentially already the case, with the proliferation of .conf files accompanied by .d directories full of still more config files in the typical Linux /etc.

I don't think that the Windows Registry (this specific implementation of the idea) actually offers sufficient value to be worth using Windows over Linux. What I think is that the idea has merit. On a Unix system, you could preserve the existing type of functionality through a virtual filesystem, so that you could manipulate the registry as if it were a collection of directories and files. On low-memory systems (perhaps embedded) with simpler registries, the registry could actually be a collection of directories and files. Or if you have sufficiently advanced filesystems which can efficiently handle that sort of load, you could do the same on more advanced systems. The down side is that any complex activity requires some sort of tool, but these tools do not need to be very complex.

In summary, a registry isn't a bad idea, nor does the Windows registry offer no advantages, even if the Windows registry does indeed suck.

Re:More Flexibility?

[WaroDaBeast]

What defined set of rules? English does not have any agency claiming to be the definitive controlling authority. The rules, such as they are are descriptive, not prescriptive and are compiled by many separate organisations. They do not always agree.

Well, that's what science is about, isn't it? It's always something like theory A, which seems to be right at first. Then someone comes up with theory B, that invalidates theory. After that, yet another guy finds out that his theory, B+, only partially invalidates B, and validates some of the points that theory A made in the beginning, but only in a different referential. And the quest for the best model goes on... Well, I'm sure you got the point already: it's an ongoing process, and we will never come up with something perfect.

I think we do need a scientific approach to understand what should and shouldn't be linguistically speaking. That's why I was talking about a set of rules in my previous post. Of course, we have to alleviate big agencies à la French academy — they come up with real shitty stuff at times.

But anyway, you already agree on needing rules while not interfering usage too much, so I don't need to go on.

My main gripe with "virii" is that it's a bad example. Supporting that word means adding complexity to the language. This is a definite case of good cause (simplifying/modernizing language), wrong argument (example is actually an exception).


P.S.: I think people who whine about split infinitives don't know that English is a Germanic language. That or they're delusional, infatuated elitists.

Re:More Flexibility?

[Hognoxious]

You can't just say "text files", because I can't write "Hey Apache, I want you to put password protection on the stuff in /var/html/secret" in a file and have it work.

Would you forward the memo?

The one about text files having to be in English. Seems I never got it.

Re:More Flexibility?

[NotBorg]

LD is documented over several man pages. The 'environment' section of http://linux.die.net/man/8/ld-linux might contain the information you so desperately want to not exist.

Want a --->real world <--- example? UT2004 ships with its own libstdc++.so.5, openal.so, libSDL-1.2.so.0 binaries. It's self contained within it's own directory tree. It doesn't drop files in any binaries into any system system directory. It's worked just fine despite the fact that I've changed distributions gone through many many system upgrades, and etc. over the years. I just copied the ut2004 directory from one system to another and ran it. Worked fine many years ago, still works fine today (completely unmodified) despite the "drastic" changes in distributions I've gone through.

If you look at the ut2004 launcher script that comes with it you'll see the following lines:

LD_LIBRARY_PATH=.:${UT2004_DATA_PATH}:${LD_LIBRARY_PATH} export LD_LIBRARY_PATH

Check the current dir, check some UT2004 dir, then check whatever the distribution has set up. It's been in the "just works" category for a long time now.

They could have packaged it in .deb, .rpm, .pkg.tar.xz, or what ever package manager you fancy and still be self contained without the need for a new package format.

And even with system libraries we don't have nearly the "dll hell" that we've seen on Windows. The msvcrt.dll vs msvcrt.dll hardly exists on Linux. Unlike Windows where the ABI changes between msvcrt.dll and msvcrt.dll when the ABI changes on Linux so does the file name. It's some.so.1 vs some.so.2. Failing that you can do the same thing application developers on Windows do: ship with your own library version.

Linux is good for servers, and that's it.

We have a new hairyfeet, I see. I'm sorry, you're wrong, and there's nothing anyone can do to help you.

Re:More Flexibility?

[doom]

Nope: you don't understand DLL hell at all. The real problem Windows had was there was no way for an app to know it was going to have the right version of a library without actually shipping a copy of it with itself. So every time you installed an app, you could potentially change versions of any of your DLLs. What versions you ended up with were path dependent: if you installed apps in one order, everything might work, if you did it in a different order, half of your stuff might be broken.

Library version management is handled pretty well by dpkg/apt and (as far as I know) it's competitors, like yum.

There is still a problem with linux in that it can be difficult to install multiple versions of the same thing and switch between them, and that's actually a pretty common need. In the Debian world the work around has been for major versions to leak into the package names, so, for example, you can install postgres8 and postgres9 and run them on the same system fairly eaisly. Of course, this doesn't help so much if you'd like to compare version 8.5 and 8.6...

another broken feature

[Anonymous Coward]

Ubuntu is dead.

Augment audio support which worked with Pulse which doesn't work.
Replace X which worked with Wayland/Whatever, which has fewer features and doesn't work as well.
Replace gnome with Unity which runs slower and lets you do less and is unusable on many setups.
Now, replacing a package manager which is common, well-supported, and works with one which will be none of those things.

Explain to me why anyone uses Ubuntu any more..... Oh yeah - it's because of marketing and ignorance and nerd-wannabees. In-the-know nerds have abandoned it years ago for OS's which actually make life easier - something which Ubuntu was intended to do, but not fails miserably at.

Stop re-building the wheel, please!

Re:another broken feature

[NGRhodes]

Please re-read the original post, they are not replacing dpkg/apt.

Re:another broken feature

[Anonymous Coward]

Which is actually even worse, because it has to exist alongside dpkg/apt. Still re-building the wheel and adding useless bloat, no matter how you look at it.

Re:another broken feature

[Patch86]

Replace X which worked with Wayland/Whatever, which has fewer features and doesn't work as well.
Replace gnome with Unity which runs slower and lets you do less and is unusable on many setups.
Now, replacing a package manager which is common, well-supported, and works with one which will be none of those things.

No comment on the Pulse Audio saga, but as for the other three-
- Everyone, on all major distros, is replacing X. Most of them are replacing it with Wayland. Ubuntu have announced that they will be replacing it with something else (called "Mir"). The controversy was around Wayland supporters being cross that Ubuntu wasn't joining their party; if you don't like the concept of replacing X with Wayland (as your post implies) then you should be no more cross with Ubuntu than with all the rest.
- Unity is not slower than Gnome 3. Unity was forked from Gnome 3 due to the terrible unpopularity of that platform; although Unity is up for a lot of criticism, there aren't many people arguing they should have stuck with Gnome. The most popular opinion seems to be that they should have ditched Gnome (as they did) with either a Gnome 2 fork (al a MATE) or that they should have forked Gnome 3 but made different design choices than they did with Unity (al a Cinnamon, which looks at first glance like a KDE 3 clone).
- They aren't replacing dpkg, they're adding a new second package management scheme. As per the details, it looks like this is mostly intended as a way of distributing Ubuntu Touch (phone & tablet) programmes in a less process-intensive way than APT does, for performance reasons (remember that Ubuntu Phones are going to be targeting the budget-smartphone sector). I don't have an opinion at this point as to whether that's sensible, but I can't see anything fundamentally wrong with the concept.

Basically, don't be hysterical. Each of their moves had sound logic behind them, even if the results aren't great (I don't hate Unity, but I'd hardly hold it up as a shining example of brilliance either). If you're using Mint instead of Ubuntu, you're still using an OS that ditched Gnome, uses Pulse Audio, and intends to migrate to Wayland. Hardly makes the case for switching compelling for "in-the-know-nerds". Most of the people who switched to Mint will have done so either because they prefer MATE/Cinnamon to Unity, or over the privacy shenanigans. The rest will have just been the usual nerd hipsters who insist on always using the next great "fringe" product.

Would make sense if...

[Anonymous Coward]

They are planning statically linked applications. Of course they might want to build their own DLL hell in which case they are on the right track using shared libraries...

duplicated programs & libraries & configs

[iggymanz]

many packages use the programs, configs, libraries of other packages, to say nothing of application frameworks spread across multiple packages (like say openvas client, server, manager, libraries) to address cases where a server might have some local and some remote parts, or all be on one machine. this idea would make a mess of things

but... WHY?

[girlintraining]

Why do we need yet another packaging standard? Isn't the whole point of open source to take good ideas and merge them together? So why then, do we see divergence like this so much more than convergence? Sigh. I suspect the reasons for this are political rather than technical; The main failing of open source as a community is that while the source is open, the politics are messy and it results in dozens of incompatible "open" standards, protocols, etc. We bitch and moan about closed source protocols and having to reverse-engineer everything, which is a massive waste of effort because we're duplicating previous work... and then we're busy doing it to ourselves. :(

Re:but... WHY?

[Picass0]

>> "Isn't the whole point of open source to take good ideas and merge them together?"

No, it's not. Open source is so you or anyone else may use the code as a starting point for your own changes, to learn from, study, improve, etc...

Re:but... WHY?

[amorsen]

We need it because while current packaging systems are great for central control, they are bad for actually letting users contribute.

a) You cannot submit a bug to a developer, get a fixed beta release, and install that in the packaging system (unless you know how to handle spec files)
b) You cannot do parallel installations of newer (or older) versions for testing unless the package is built specifically for that
c) It is difficult to make distribution-independent packages, so users become dependent on the distribution for all software
d) Almost all packages require root, the packaging system cannot track software installed by users themselves

On the other hand, switching to a Mac-style packaging system has at least these problems:

1) Security updates to common code are unlikely to actually get applied to all packages
2) Some libraries will not be shared, costing extra memory and cache footprint
3) Centralized control over what software is installed suddenly becomes difficult
4) Without dependencies you need to define the minimal environment that software can depend on. LSB tried to do that and failed.

Re:but... WHY?

[hawguy]

Isn't the whole point of open source to take good ideas and merge them together?

What gave you that idea? There are many Linux window managers, Word Processors, Image Editors, etc. That diversity is both a strength and a weakness.

Re:but... WHY?

[Anonymous Coward]

Because that is the way many improvements are made: by trying something new. By basically trying to reinvent the wheel.
As long as canonical does not enforce usage of the new system (because new = better), I'm fine with all of this: let them try out something.
And then when it's released, we can judge if it is indeed something useful and/or better...or not... not harm done in trying.

Re:but... WHY?

[EvanED]

We need it because while current packaging systems are great for central control, they are bad for actually letting users contribute.

One more:
e) Most current packaging systems don't let you pick an installation directory. (Many programs have directories set in stone when you compile them.)

This is one that has affected me, because in the environment I work in, we have standard stuff installed locally but a lot of more esoteric software as well as more current versions of software installed to network drives. (For instance, we run RHEL6 which comes packaged with Python 2.6, but I almost always use Python 2.7 off of the network. Or we have Clementine available for use only over the network.) But the way existing package managers work means that we can't really use them, which means that if I want to make something new available over the network, I have to go and chase down its dependencies myself and then compile everything.

3) Centralized control over what software is installed suddenly becomes difficult

I would argue that point for the most part. From some vantage point, it's already difficult to have centralized control over what's installed. After all, I can still do what I described above to install software, without the support of the package manager. It's just a pain. Or even if you switch to a better package manager that allows users to have control over what gets installed, you can still block that as an administrator by setting noexec on the drives.

Re:but... WHY?

[exomondo]

Isn't the whole point of open source to take good ideas and merge them together?

Because not all 'good ideas' are universally and objectively 'good' and those that are not necessarily compatible with eachother.

Re:but... WHY?

[Anonymous Coward]

Your IT guys suck.

There are easy ways to make both rpm and dpkg packages that report resolved dependencies, even for libraries on network mounted drives, you can even update the loader configuration to include the library paths of 'esoteric' packages that you may have. In fact, a lot of that can even be done with environment variables (e.g. fully user switchable through the environment-modules package) without any filesystem changes.

Re:but... WHY?

[EvanED]

Pointers to documentation? Does it require root?

Re:but... WHY?

[Anonymous Coward]

a) You cannot submit a bug to a developer, get a fixed beta release, and install that in the packaging system (unless you know how to handle spec files)

Yes we can. It's called "checkinstall" and it's friggin awesome. Works on >90% of all programs, excluding ones that do really odd installer stuff. Set your version from "3.94" to "3.94b" in the nice checkinstall menu and your package manager will prefer to keep your custom-rolled package until the official package update to "3.95." Sweet, huh?

b) You cannot do parallel installations of newer (or older) versions for testing unless the package is built specifically for that

If you want to do this kind of stuff, learn to ./configure ; ./make ; checkinstall. You can configure seperate data directories and things in the ./configure stage.

d) Almost all packages require root, the packaging system cannot track software installed by users themselves

I don't know what you're on about in the first half of d), but checkinstall handles the second half.

Re:but... WHY?

[Burz]

c) ...is the clincher. MS and Apple both established the expectation that independantly-distributed software can be easily bought off-the-shelf or downloaded, and then easily installed. Its not a personal computing OS unless it meets this defacto standard.

2) ...is overstated in this thread. Authors try to use the OS libraries when possible, keeping third-party libraries to a minimum.

3) ...also overstated here, I think. In the case of MacOS, its often up to the user if they want an app managed by Sparkle or the App Store.

4) ...this is a GOOD thing. As for LSB, they didn't even have an SDK until about a year ago. The Linux Foundation did not promote LSB as a 'brand' that developers should target, and never gained mindshare as a result. Defining a rich minimum environment fosters feature stability that allows developers to function without feeling its just a short matter of time before the rug gets pulled out from underneath them.

IIRC, both the Linux Foundation (in its usual timid way) and Canonical tried to get the desktop distros to standardize on library versions. But many would not do it. What Canonical is doing now is different: They're saying "we define the user and authoring experience for Ubuntu". If other distros come along that are "Ubuntu compatible", they would have less freedom than merely being an LSB compatible distro... but that if often a good thing from the user's point of view.

Re:but... WHY?

[Anonymous Coward]

It sounds no better or worse that zero install it's even cross platform and already available in the repos: http://0install.net/
Why is Canonical not consider embrasing that instead? Am I missing something?

johwi

So, staticly compiled?

[magic maverick]

I'm guessing that they are going to statically compile everything. Otherwise they couldn't get rid of dependencies. Which is bad generally for various reasons, except in specific cases.

Also, isn't there a variant of Linux that already does this? They also used symlinks to make a more sensible (and modern) file system, and other things. GoboLinux, I just found it. Actually, I'm not sure how similar they are...

(Also, the first link is not needed, please don't include such rubbish.)

let's see...

[Anonymous Coward]

I dont think this is so bad. One cause of Windows' (tm) success is for sure that developers and users dont have to think about broken library dependencies after an update. For commercial (proprietary) software such packaging system could finally start the year of the linux desktop (y).

Re:let's see...

[armanox]

Except commercial software has been able to do this for years. I've used quite a few static linked applications, that usually are packaged as .bin or .run (some have even been .rpm).

Re:let's see...

[X0563511]

You can blame that on c:\windows\winsxs and the 15gb it wastes in the process.

(go have a look - it's normally hidden)

Re:let's see...

[Mike Frett]

That 15GB is yours, Side by Side is designed to grow, substantially more than that. And older versions of files are NOT removed after you have removed the Application. Mine use to be anywhere from 30-40GB before I left and moved to Xubuntu. Your own Tamagotchi with a copy of Windows, feed it and watch it grow.

Anyway, I don't remember what it was called, but there was talk years ago about a Mac Style Package on Linux; but it was struck down by the community.

Re:let's see...

[Anonymous Coward]

Tell that to my bro. Ugh, everything Microsoft does is great, except for the poison that comes with the hidden services in the OS that you can't disable, the DRM, the backdoors and remote controls..

Also known as application bundles.

[sidragon.net]

http://en.wikipedia.org/wiki/Application_bundle

Once again, racing as fast as we can towards where the puck was 20 years ago.

Re:Also known as application bundles.

[Anonymous Coward]

Everything goes in cycles....

Re:Also known as application bundles.

[jedidiah]

You also don't need Canonical leading you by the nose with this option. Basic Unixisms will let you create a NeXT style "package" just fine. A number of apps are already distributed this way.

Because Apt-get is soooooo inferior.

[JeremyMorgan]

I think it's just a case of "because different" and "not developed here". I don't see how they could make any significant improvements over apt, but it doesn't surprise me from this group of hipsters.

Stop pissing in the pool Ubuntu.

Re:Because Apt-get is soooooo inferior.

[EvanED]

I don't want to get into whether you could use DPKG packages for what they want to do; that's beyond my scope of knowledge. However, what I can tell you is that for some tasks, apt-get just flat out doesn't work.

In particular, if you want to install programs to something other than /usr (for instance, you want to install to a network drive, or without root), then the mainstream package managers just flat out don't work.

Re:Because Apt-get is soooooo inferior.

[fuzzyfuzzyfungus]

I think it's just a case of "because different" and "not developed here". I don't see how they could make any significant improvements over apt, but it doesn't surprise me from this group of hipsters.

Stop pissing in the pool Ubuntu.

It does seem a trifle odd because, to the best of my knowledge, there isn't anything preventing existing tools from working normally with .deb packages that just happen to include everything, and have no defined dependencies. There might be some modest changes needed to allow you to process packages that don't do anything requiring root privileges without being asked for them; but that hardly seems like enough to justify an entire new tool.

Re:Because Apt-get is soooooo inferior.

[Electricity Likes Me]

I think it's just a case of "because different" and "not developed here". I don't see how they could make any significant improvements over apt, but it doesn't surprise me from this group of hipsters.

Stop pissing in the pool Ubuntu.

It does seem a trifle odd because, to the best of my knowledge, there isn't anything preventing existing tools from working normally with .deb packages that just happen to include everything, and have no defined dependencies. There might be some modest changes needed to allow you to process packages that don't do anything requiring root privileges without being asked for them; but that hardly seems like enough to justify an entire new tool.

Isn't there a D-Bus interface specifically for doing "root-less" installations of new packages - i.e. you say "install this!" and it can check if you're allowed to, then do it?

Re:Because Apt-get is soooooo inferior.

[fuzzyfuzzyfungus]

I know that Fedora was experimenting with some policykit setting where(by default, configurable in other ways) unprivileged users were delegated the authority to install any package already available from the approved repositories(which did require root access to muck with). There was some controversy about whether this was a good default setting or not.

I don't know the details of what apt can and can't do; but given the existence and considerable utility of sudo(which is precisely a tool for allowing a user to perform controlled impersonations of other user accounts in administrator-defined contexts) I would strongly suspect that it is either already possible to allow apt to perform certain approved operations on behalf of a non-root user, or that is a feature that could be added without substantial upheaval(especially for the use case that involves an OSX-like 'copy this special folder into a directory I have write privileges for' install operation, rather than a system-wide change, though system-wide cases would be doable as well).

Re:Because Apt-get is soooooo inferior.

[exomondo]

I don't see how they could make any significant improvements over apt, but it doesn't surprise me from this group of hipsters.

Right because Colin Watson never made any improvements to apt.

Stop pissing in the pool Ubuntu.

What is with this attitude of 'you're not allowed to create different things and disrupt the status quo'? Who cares if the build it?

Re:Because Apt-get is soooooo inferior.

[EvanED]

(especially for the use case that involves an OSX-like 'copy this special folder into a directory I have write privileges for' install operation, rather than a system-wide change, though system-wide cases would be doable as well)

Note that there's a big difference between these two cases. (The two cases are (1) allowing the administrator to delegate system-wide installation rights to a user and (2) users can unilaterally install programs to /home/me.) At least if you want to take the second case to it's "natural" conclusion.

In the case where the system-wide installation is being done, that's just a simple privilege delegation problem, and you're right it should be easy to solve.

However, in the second case, things become a lot dicier. Different users will have different stuff installed, so you need to split up the database of installed packages. Currently you can only have one version of a package installed at once with most package managers, and if you update it then the old one is replaced; with change (2), it becomes natural to allow multiple versions installed to separate directories, so now the package manager needs to be able to deal with that. If your packages aren't self-contained, then they need to know the path of their dependencies; since that path now can be anything, your package manager needs a way to instruct the packages that it's installing what those paths are.

Re:Because Apt-get is soooooo inferior.

[Anonymous Coward]

I think you need to review the apt/dpkg system a little more. Apt is not responsible for installing a package. Rather, it is responsible for resolving dependencies and downloading secondary packages to satisfy those dependencies.

Apt relies on dpkg to do the actual package installation; apt has no say where package files will be installed, and it is not supposed to.
The dpkg package specifies where the files are to be installed.
You can absolutely install programs in other directories than /usr, using the dpkg package system.
Dpkg can also call pre/post installation scripts which will intelligently handle any installation variables that you need. If you can handle a situation in a script, then dpkg will work for you.

If you want to use dpkg to install programs to a network drive, you can certainly do so. The filesystem makes no distinction between a network mounted directory and a local directory. It's all one big tree. You could use a preinstall script to check on and connect a network mount, if you like. That would work fine.

You will need to be root to install the dpkg package. Write access to the package database is only allowed as root. You could probably set up group or acl permissions, but that's an ability that is not supported by any dpkg distribution that I know of.

Re:Because Apt-get is soooooo inferior.

[EvanED]

You can absolutely install programs in other directories than /usr, using the dpkg package system.

Yes and no. dpkg is sort of up to it, but the ecosystem needs a lot of support to make it work.

For instance, let's say that we have a library and a program, and Program depends on Library. (For the moment, these are separate packages.) The user installs Library to a different location. How is Program going to find it? The conventional strategy would be to compile Program with Library's path, and it gets added to the rpath field inside Program's actual executable. A modification of this conventional strategy which would work with a more directory-based package manager would be to use patchelf or something to rewrite the executable's rpath entry to include Library's actual install directory. But where's it going to get that information? I guess you could have the post-install script look up the installation directory from the dpkg database, but again, it's inelegant and would have to be done independently for every package, as opposed to having direct support in the package manager. And as I describe below, I suspect that wouldn't work.

The dpkg package specifies where the files are to be installed.
You can absolutely install programs in other directories than /usr, using the dpkg package system.

Like I said, I'm not very familiar with the dpkg-level of things. My understanding of your statements are that the package maintainer can choose the directory, but the only control over installation directory from the user's side that I see is --instdir.

And if this understanding is correct, --instdir is insufficient: dpkg will chroot to that directory to do the installation and run the configure scripts, but what if a dependency is installed outside of that root? The way that current packages are set up, I can't install both Program and Library to different directories.

If you want to use dpkg to install programs to a network drive, you can certainly do so. The filesystem makes no distinction between a network mounted directory and a local directory. It's all one big tree.

Oh, I was under no illusion that it would treat it differently; I was just mentioning the network drive situation to explain my use case a little bit more.

You will need to be root to install the dpkg package. Write access to the package database is only allowed as root.

Another place where dpkg falls short of my ideal package manager. Why is there a single centralized database when different users may have different software installed?

Re:Because Apt-get is soooooo inferior.

[Anonymous Coward]

"In particular, if you want to install programs to something other than /usr"

dpkg has an option '--root' for exactly that.

You learn something every day, eh?

Re:Because Apt-get is soooooo inferior.

[EvanED]

dpkg has an option '--root' for exactly that.

And as I discuss a little bit in a reply to your sibling, from the manpage it sounds like it wouldn't work.

The --root doc says "Changing root changes instdir to dir and admindir to dir/var/lib/dpkg", and the --instdir doc says that option causes it to chroot to that directory to run the installation scripts. (Also the fact that it chroots means it needs root.) But that's no good if packages aren't completely self-contained. If I want to install a program into /opt/program and a library it uses into /opt/library, there's no directory to give the program such that it will install correctly and still be able to see the library.

I suppose that it might work if you do make a self-contained package, but it's still not an out-of-the-box solution.

Re:Because Apt-get is soooooo inferior.

[Anonymous Coward]

For instance, let's say that we have a library and a program, and Program depends on Library. (For the moment, these are separate packages.) The user installs Library to a different location.

The dpkg package is quite able to install binaries to, say, the /opt directory. This contradicts your original statement of saying that mainstream package managers can't install to something other than /usr.

For your example, though, you are talking about user installed packages. I'll concede that regular dpkg packages are unable to be installed as user.

It should be possible to create a user-installable package system with the dpkg format, but you'd need to create your own installer. Shouldn't be too hard. The dpkg command can extract all files in the package, and your installer can then arrange them as necessary in the user directory. User installed libraries can be referred to by setting the LD_LIBRARY_PATH env. Saves having to bother with buggering the binary rpath, as you initially suggested.

Why is there a single centralized database when different users may have different software installed?

I guess nobody thought it a useful feature when the package systems were being designed. From my experience, though, the dpkg system is extensible enough to include this as a feature, if the Debian developers thought it was necessary. Alas, I'm guessing that most Debian users wouldn't need the feature, and it's unlikely that the developers will create it.

To be fair, what you're asking for doesn't exist in any system that I know of. It would open up new and interesting issues of conflicting packages installed by different users, properly resolving dependencies between user installed and system installed libraries and programs, and probably many other problems that won't be apparent until someone tries to create the system in the first place.

Re:Because Apt-get is soooooo inferior.

[Ash Vince]

I don't see how they could make any significant improvements over apt,

Apt is fine for the OS, they even said so. What they want to come up with is something completely different I think. This is not a replacement for apt, it is to complement apt. It actually sounds like this is really designed as a competitor to the APK file you use under android for distributing applications.

However great apt is, it is utterly useless from the point of selling commercial software as there is the possibility of software not installing due to dependency issues. This is not an option with commercial software as the (stupid) end use will blame the software he just bought for not installing, not the fact that his machine is not able to download a dependency package because it is not available upstream. As many have pointed out this wastes disk space, but who cares as it is cheap now.

It sounds like their grand idea is to come up with an additional application wrapper format that will always install everything for a particular application in a single directory also making uninstalling much easier.

Re:Because Apt-get is soooooo inferior.

[Anonymous Coward]

However, what I can tell you is that for some tasks, apt-get just flat out doesn't work.

In particular, if you want to install programs to something other than /usr (for instance, you want to install to a network drive, or without root), then the mainstream package managers just flat out don't work.

I'm sure it's a pain and very troublesome for you.

But have you considered to use apt-get --download-only and then use dpkg --instdir.

I mean download the packages and then install with specifying the install directory?

Re:Because Apt-get is soooooo inferior.

[EvanED]

have you considered to use apt-get --download-only and then use dpkg --instdir.

I mean download the packages and then install with specifying the install directory?

Aside from the fact that we're on an RPM-based distribution, dpkg requires root and it doesn't allow a program and dependent library to be installed to two different instrdirs, as when running the installation scripts it chroots to the instdir. So if I put the library in /net/library, and try to install the program with --instdir=/net/program, then my reading of the man page says that it won't be able to see /net/library.

So no, it wouldn't work.

Goodbye Ubuntu

[FuzzNugget]

Hello Debian

Re:Goodbye Ubuntu

[SeanBlader]

Going to have to agree with FuzzNugget here. Seems like a good time to finally bite the bullet and move myself upstream.

I think this is for "apps" not applications

[jandrese]

I don't think we're going to see a completely separate install of Gnome for every single Gnome app on your system. I think this is intended for standalone apps like you see on phones and tablets.

Re:I think this is for "apps" not applications

[MoxFulder]

What does "standalone" even mean? The Wikipedia app on my Android phone uses some HTML5-to-app Javascript framework, the mobile banking apps use some other HTML5-to-app framework(s), the Wifi network debugger app uses some Busybox tools and would probably have been a lot simpler to write if it could rely on standard Linux wireless-tools, etc.

When I look on the Android market and I see 20 apps that do roughly the same thing, but 18 of them do it badly, and they all duplicate the basic functionality of a standard open-source utility... I weep with despair. :-p

Re:I think this is for "apps" not applications

[pinkushun]

You are correct. The existing system will stay intact.

This is not aimed at changing packages that are already part of the
Ubuntu archive; for the most part our existing system works well for
those, and they tend to have non-trivial dependency structures. We'll
continue to use dpkg and apt for building the Ubuntu operating system,
syncing with Debian, and so on. There's no point developing a packaging
system for apps and making it have the full panoply of features needed
for the Ubuntu archive: it'd just be second-system-effect on top of our
current packaging system. So the scope of what I've been considering is
purely leaf apps built on a fixed "base system", which in the case of
the initial target of the Ubuntu phone/tablet work would be the run-time
part of the Ubuntu SDK.

NIH sydrome but already been done

[OrangeTide]

it seems like they suffer from Not Invented Here but at the same time, I seem to recall that Puppy Linux already installs self-contained package bundles into individual directories. Not unlike OSX/NeXT app bundles.

Re:NIH sydrome but already been done

[X0563511]

Puppy is a specialist distribution (like Damn Small Linux). What Puppy does may not work well for a more general purpose distro.

We need another standard..?

[kagaku]

Obligatory: http://xkcd.com/927/

Re:We need another standard..?

[johnsnails]

Beaten 2 it

Re:We need another standard..?

[mvdwege]

Too bad I'm out of mod points.

Been done many times

[laffer1]

This reminds me of PBI from PC-BSD. Others have pointed out the similarities with Apple / NeXT as well.

For simple applications, it makes sense to do this. However, imagine creating a package for something large like firefox, libreoffice or kde? WIth the mass number of dependencies... it's a nightmare. Do I really need hundreds of copies of a PNG library on my system? What about zlib? gtk+ ?

Re:Been done many times

[aztracker1]

I really wanted to like PC-BSD.. and would have loved it for my primary system, but I need windows and linux at the very least in VM form, and there weren't good solutions when I tried for that. I see that there now seems to be a VirtualBox PBI so may give it another try.

Re:Been done many times

[Anonymous Coward]

I do not think, this will be used for apps in distro.

In my opinion it will be very useful for third-party, binary only, applications, things like Matlab, proprietary RDBMSes, now a days they do the same, they just skip package system in favor of proprietary installers.

Re:Been done many times

[laffer1]

Well even before there was a PBI, one could use the FreeBSD ports collection on PC-BSD to install VirtualBox.

but is apt/dpkg perfect?

[OrangeTide]

Arch's pacman is has some significant improvements over apt/dpkg, especially when it comes to creating new packages. And gentoo portage/emerge has lots of useful features that don't exist in dpkg/apt either.

Debian is solid and has an excellent package system. But it isn't the pinnacle of achievement. We can take package management further still, I am certain.

Shoot it again!

[Chris Mattern]

The bugger ain't dead yet!

Why not concentrate

[thrill12]

on having good stable API's of core libraries that are backwards compatible up to an extent, rather than continuously fighting dependency hell when it comes to updating packages ?
This proposal seems basically like "we statically link every binary", and we all know that is not wanted because of disk usage and more importantly: memory usage. Especially in constrained embedded systems statically that could be a concern if you start having a lot of running applications.

A crippled version of APT

[gringer]

From the email:

The proof of concept I wrote also isn't entirely new code. It's tiny due to using .deb as a container format (minus maintainer scripts, full dependencies, etc.), so I get to save effort by using dpkg to unpack things, which leaves us room to selectively use more of its features in future if we want to.

So they start off with what they think they need, then become more like APT as they need to add more features.

So the scope of what I've been considering is purely leaf apps built on a fixed "base system", which in the case of the initial target of the Ubuntu phone/tablet work would be the run-time part of the Ubuntu SDK.

In other words, this is something to be used in addition to APT (i.e. post-install), rather than instead of APT.

* no dependencies between apps; single implicit dependency on the base
      system by way of a Click-Base-System field

Just like Debian has an implicit dependency on the base system (except for base packages, which have more complicated rules). In other words, this system will only accept a single dependency, the Click-Base-System. I'm not quite sure why this is different from only accepting applications that only depend on Click-Base-System.

And note that the "each package will install to its own directory" bit is on the to-do list:

Obvious items I still need to work on:

• produce a strawman hooks implementation with some real worked examples
• integrate (or demonstrate how to integrate) the container isolation properties worked on elsewhere
• Click-Base-System field is skeletally simple right now, and may need to be expanded to at least leave open the possibility of multiple flavours of base system (see also GNOME's profiles idea)
• adjust unpack handling to avoid problems with project renames and name clashes, and to unpack each version into its own directory and flip symlinks to allow for multi-user independence
• integrate into the Ubuntu SDK, as well as providing examples of how it can be integrated into other build systems too

Bad idea.

[Eravnrekaree]

puttting each program in its own directory is an absurdly bad idea. Then you would end up with a massive PATH variable and also does not follow the time honored Unix tradition which needs to be respected. For allowing multiple versions of the same program I would prefer to see some other solution, one possibility might involve putting symlinks in /usr/bin to program files into another directory where different versions of the program can be stored. the different versions of the program could be accessed in the seperate directory holding multiple versions and the symlink from /usr/bin would point to the default version.

Re:Bad idea.

[EvanED]

Then you would end up with a massive PATH variable...

First: that's only one solution. For example, I have (issues file system query) probably three or four thousand different packages available to me right now, all installed into their own directory. (This counts multiple versions separately. As a disclamer, some of those packages are very very old and won't even run on this system as the library dependencies aren't present or they are only built for another architecture, and most of the others are obsolete and there's little reason to use them. Point being: I have access to tons of packages.) My $PATH has 21 entries, including some redundancies.

The first step to reconciling these facts is basically what you suggest later in your post: that there are multiple directories with symlinks. For instance, ~/bin is in my $PATH, and it has a few dozen symlinks to some of those packages.) But doing this or what you said ("one possibility might involve putting symlinks in /usr/bin to program files into another directory where different versions of the program can be stored") still requires a package manager which can install to a different location, which is not really supported by the Apt toolchain.

Second: just because you have a package available doesn't mean you need it in your $PATH. I have a ton of different GCC versions available, and I use three or four with some regularity. (I use even more of them infrequently.) But I don't necessarily need, say, GCC 4.5 in my $PATH. If I want 4.5 explicitly, I can always run /path/to/gcc-4.5/bin/gcc.

Third: you have to remember who Ubuntu is aimed at. It's aimed at casual users. Casual users don't even care about $PATH in the first place, because they don't start things from the command line. They just hit the windows key or whatever they do to bring up the launcher, choose what program they want to run, and click it. ...and also does not follow the time honored Unix tradition which needs to be respected.

They need to be respected, even if it has significant problems in some environments and fatal problems in others (e.g. mine)?

Re:Bad idea.

[EvanED]

Crap, shoulda previewed. Sorry for the formatting. Fixed version:

Then you would end up with a massive PATH variable...

First: that's only one solution. For example, I have (issues file system query) probably three or four thousand different packages available to me right now, all installed into their own directory. (This counts multiple versions separately. As a disclamer, some of those packages are very very old and won't even run on this system as the library dependencies aren't present or they are only built for another architecture, and most of the others are obsolete and there's little reason to use them. Point being: I have access to tons of packages.) My $PATH has 21 entries, including some redundancies.

The first step to reconciling these facts is basically what you suggest later in your post: that there are multiple directories with symlinks. For instance, ~/bin is in my $PATH, and it has a few dozen symlinks to some of those packages.) But doing this or what you said ("one possibility might involve putting symlinks in /usr/bin to program files into another directory where different versions of the program can be stored") still requires a package manager which can install to a different location, which is not really supported by the Apt toolchain.

Second: just because you have a package available doesn't mean you need it in your $PATH. I have a ton of different GCC versions available, and I use three or four with some regularity. (I use even more of them infrequently.) But I don't necessarily need, say, GCC 4.5 in my $PATH. If I want 4.5 explicitly, I can always run /path/to/gcc-4.5/bin/gcc.

Third: you have to remember who Ubuntu is aimed at. It's aimed at casual users. Casual users don't even care about $PATH in the first place, because they don't start things from the command line. They just hit the windows key or whatever they do to bring up the launcher, choose what program they want to run, and click it.

...and also does not follow the time honored Unix tradition which needs to be respected.

They need to be respected, even if it has significant problems in some environments and fatal problems in others (e.g. mine)?

Unix had a ton of really great ideas. But many of them have run their course. You can't progress if you say you can't change stuff.

Re:Bad idea.

[bussdriver]

The OS already lost. With VMs being so widespread and popular, the OS has already lost one of its main purposes: To run software by providing the HAL and the common needs of software.

The OS should keep your old apps safely running forever. Going to a VM because of a broken dependency system or changing APIs (again related to dependency) or for SECURITY just illustrates that the OS has failed in doing it's job.

I don't care what is done about it but I am sick of the mess everybody has. The only benefit linux/BSD has is that you are made to feel stupid for not enjoying all the complexity involved (which of course is so bad that everybody uses almost as complex tools to manage it all.)

Me, I think the future is one of complex VM hypervisors where it almost feels like that is the OS and the client OS are just frameworks apps use like the window managers are today. It is not the future I want... but it is coming. Apple did it 1st I believe with their OS 9 (being closed, they could and did kill it.) There are apps from the 90s that I could still find useful today... especially the ones I paid for...

In a world of software patents nearing the edge of insanity, we can't pretend everything has to be and can always be open source and that ALL users are capable of supporting the code.

Re:Bad idea.

[Anonymous Coward]

Dude, you just described the current use for /opt.

Re:Bad idea.

[starfishsystems]

puttting each program in its own directory is an absurdly bad idea. Then you would end up with a massive PATH variable and also does not follow the time honored Unix tradition which needs to be respected.

In about 1996 when we were supporting a heterogenous network of several hundred Unix systems which had to support a combination of both BSD (everything flattened under /usr/local ) and System V (apps contained within their own subdirs of /opt) conventions, we found that an effective solution was to install the actual apps in System V style but then symlink into them so as to produce a BSD style directory tree which could be on the users' default PATH.

Organizing around System V style was critical to making this successful, because we had to expose multiple versions of each app on multiple platforms. Because each app version was distinctively located under /opt (or its equivalent network mount point) a user could always ensure that a specific app of a specific version took precedence over the default if necessary. It also meant that we could easily roll out new versions for people to test, that we could advance or revert the default version of an app simply by changing a symlink, and that we could maintain older versions indefinitely without holding back progress.

The same architecture allowed us to automatically cache local repositories of apps in addition to the canonical ones maintained on the fileservers. Our institution supported multiple research groups which in some cases maintained their own fileservers and software licenses and in other cases shared in the funding and operation of common resources. The same architecture also allowed us to cleanly arrange for both users and client systems (workstations and compute farms) to have not only the correct range of access to the entire superset of apps across the fileservers but the correct precedence in which they would be found.

Putting each program in its own directory turns out, in practice, to be a very sensible idea as soon as requirements extend beyond a single isolated workstation and a handful of apps.

The NHL is better then the 2 shit baseball teams i

[Joe_Dragon]

The NHL is better then the 2 shit baseball teams in my home town.

AppV for Linux?

[Anonymous Coward]

This sounds like Microsoft's AppV. At least by my feeble understanding of AppV and what little I read in the summary. All dynamic libraries are packaged with the application and delivered as a unit. OS's and underlying hypervisors can use memory de-duplication to reduce the bloat that this might otherwise cause.

Why?

[robmv]

I am not well versed in the dpkg format, but RPM has Relocatable Packages, not many people use it, but if you want to do something like Ubuntu wants on an RPM based distribution without creating another format, You hack rpm commands so it can check a per user packages database using relocatable packages, no need of a new format

this is as far from UNIX philosophy as you can get

[pm_rat_poison]

so every time I install something which is bundled with (say) java, I'll get java every time? How many copies of java with inconsistent and possibly incompatible behaviour does a person need?
example, say I have an app which comes bundled with "helper-program" version 1.0, which keeps its config files in ~/.helperprogram/config
and then I have another app which comes bundled with "helper-program" version 1.1 which keeps its config files in ~/.helperprogram/config
wtf??? am I missing something here?

More Redundancy Department output

[Anonymous Coward]

So now they are going to reinvent, rename, and claim full credit for Android Package files (.apk), the same way they reinvented, repackaged, and claimed credit for Debian?

Re:I never got "packaging systems"

[X0563511]

No, it's not just an executable. Go look in c:\windows\system32 and c:\windows\winsxs (and in c:\Program Files\Common Files) and you'll find more DLLs than you can shake a stick at.

Cutting Edge Debian

[tuppe666]

Hello Debian

Except Ubuntu users want cutting edge Debian, not tried and tested Debian...and unfortunately using Debian is not going to make it more cutting edge.

...Now if Debian decided to produce a (stable) cutting edge Desktop version (perhaps working with an existing Distribution team). To complete there ultra stable, you have me sold.

Re:Cutting Edge Debian

[Anonymous Coward]

The distribution you're looking for is called Linux Mint, Debian edition.

ubuntu has jumped the shark.

[Anonymous Coward]

The majority of Ubuntu software comes from Debian. What are they thinking?

Re:I never got "packaging systems"

[Anonymous Coward]

Yeah sure, but the *installer* is just an executable. That's what I'm talking about. All you need are APIs that tell you what dynamic libraries are installed, what versions they are, and what (if any) applications are currently using them. The installer doesn't need to be in a "packaging format", it's just executable code, that's what I'm talking about. APIs that tell you what the installer needs to know ought to have been settled a long, long time ago. Then you could make the installer anything you want. On Windows that's EXE, but there's nothing to stop it from being a batch file, Perl script, Pythoh, whatever, and it gets along fine with all the other installations as long as it makes the correct API calls.

Re:I never got "packaging systems"

[fuzzyfuzzyfungus]

IMHO, this is something Windows gets right. It's a fucking executable dammit. Yeah, it calls some APIs that are needed for installing. Installation library, sure; but "packaging system"??? Package format? Sooner or later you'd think that Linux people would just wake up and realize it's an executable.

You'd better go tell Microsoft about that, they've apparently been running headlong away from 'getting it right' since 1999... While it doesn't have the concept of 'repositories' in the same sense that Linux package managers generally do, the Windows Installer Service and the .msi, .msp, and .mst files that it works with are easily as or more complex as anything on the Linux side(and that's in addition to the distinct Windows Update mechanism, which interacts either with Microsoft, with a WSUS server, or with .msu files, exactly what circumstances require this rather than WIS are not 100% clear to me).

Yes, Windows doesn't forbid much simpler mechanisms like the nullsoft installer or 'just click foo.exe'; but neither does linux. Plenty of non-packaged software comes as an 'install.sh' or just an executable binary you copy somewhere.

It wasn't clear in your comment...

[OrangeTide]

So are you saying that Ubuntu should or should not follow in Puppy's footsteps?

stupid Why break something that is fixed?

[Anonymous Coward]

Why break something that is fixed?
Absurd..

Re:I never got "packaging systems"

[cas2000]

actually, it's something that Windows gets dead-wrong, because executable installer apps (setup.exe and the like) are just plain fucking stupid.

they're an unfortunate necessity because windows doesn't have, and never has had a decent package management system. and is unlikely to ever get one because the windows software market is primarily commercial and proprietary.

when you have 10 (or 100 or 500) packages to upgrade on a single system (and then multiply that by 100 or 1000 systems), executing hundreds of installer packages one after another is the worst possible way to do it.

i've never understood why Windows (or Apple) users tolerate that shit. it's a tedious chore that's ripe for automation - exactly the kind of thing that computers are good at doing and users are bad at doing (due to boredom, fatigue, loss of attention, ignorance, or stupidity)

which is precisely why linux distros (and other *nixes) don't do it that way. they have packaging systems because systems are consistent, predictable, and easily automated.

windows users and windows developers often have just the wrong way of looking at things, the wrong mental model of how things work and how they should work.

I ran across a program for Windows recently called Ninite. It's a multi-app installer and updater. it sounds like a good idea and is. it's a big improvement over the usual click-and-execute for each individual program.

except the way it works is weird and clumsy:

you go to their website and select which apps you want to install (from a bunch of internet-available apps, including free software and proprietary freeware like adobe flash), and then it builds you an installer app that you download and run, and it installs and/or upgrades the apps you selected off their website.

WTF?

nice starting idea, but the implementation is idiotic. Why not just have one Ninite app that fetches a list of available apps and installer URLs and whatever custom installer scripts ninite needs for them) and allow the user to select which apps whenever they run it?

i.e. instead of a moronic implementation, actually make a smart and useful implementation that copies good ideas from linux distro installers like apt-get and yum, and re-purposes them for the Windows environment.

(oh, and adobe are sending cease-and-desist letters and threatening to sue if the ninite developer doesn't remove the ability to install & update downloadable adobe products like flash, so his good ideas and good intentions are fucked by the corporate vermin mindset that dominates the windows software market)

another thing windows devs don't get is shared libraries (DLLs in windows terminology). Why does every single app have to install their own copy of the MS C++ libraries? or .net? or nvidia physx? and numerous other common library packages? these things are supposed to be shared resources provided and kept up-to-date by the operating system, not bundled with every app that uses them.

Look into Debian's CUT project

[neiras]

Except Ubuntu users want cutting edge Debian, not tried and tested Debian...and unfortunately using Debian is not going to make it more cutting edge.

...Now if Debian decided to produce a (stable) cutting edge Desktop version (perhaps working with an existing Distribution team). To complete there ultra stable, you have me sold.

You asked for it, Debian delivers. The Debian CUT Project aims to publish usable snapshots of Debian Testing on a monthly basis. They're pretty new but picking up steam.

Re:Look into Debian's CUT project

[Anonymous Coward]

But you get no security updates with these, so it's useless for anyone but devs.

Re:Look into Debian's CUT project

[Anonymous Coward]

Plus they halted releasing new snapshots back in Aug 2012 until Wheezy was released. So if you were using the last snapshot you've gone almost a year without any updates. It's not even useful for developers.

Re:Look into Debian's CUT project

[Anonymous Coward]

Except Ubuntu users want cutting edge Debian, not tried and tested Debian...and unfortunately using Debian is not going to make it more cutting edge.

...Now if Debian decided to produce a (stable) cutting edge Desktop version (perhaps working with an existing Distribution team). To complete there ultra stable, you have me sold.

You asked for it, Debian delivers. The Debian CUT Project aims to publish usable snapshots of Debian Testing on a monthly basis. They're pretty new but picking up steam.

Don't forget Linux Mint Debian (the version based on Debian instead of Ubuntu, just as the name implies), my understanding is that they take big portions of test and deliver them in chunks, so you have a slightly more stable update cycle but still get the frequent updates.

Mark Montana...

[Anonymous Coward]

http://i.imgur.com/BcS4XJm.png

Which solves an important problem with Linux...

[Anonymous Coward]

...too few package formats.

Yeah

[Anonymous Coward]

Because we all know that the one thing Linux is missing is yet ANOTHER packaging system.

666

[Anonymous Coward]

666 Ubuntu Sucks Dix.

grep: command not found

[Mister Liberty]

curtain.

Re:grep: command not found

[Anonymous Coward]

Anyone on this site who is stumped by grep missing need leave. Now.

Re:grep: command not found

[Anonymous Coward]

If only there was some sort of package management system that could be used for installing such software.

Re:grep: command not found

[Anonymous Coward]

But I can't get it to run in cmd.exe!? Is it a VBA script?

Re:grep: command not found

[candeoastrum]

Anyone on this site who is stumped by grep missing need leave. Now.

What's grep?

Re:I never got "packaging systems"

[jedidiah]

Windows just assumes that you have free run of the system. The installer runs amok and does whatever it likes with your system. This is hardly anything to emulate or brag about.

There is no API. There's just the single user DOS mentality.

Say what you will about Canonical...

[foreverdisillusioned]

I've definitely not been a fan of their track record these past few years, but they do occasionally hit on some really good ideas (if somehow managing to screw up their implementations: Upstart was a good in principle, and so was making a verical launcher/taskbar instead of making our widescreens even shorter.) This is another one. Well, sort of. Maybe not 'no dependencies' but at least 'no dependency conflicts, ever.' It's two thousand thirteen, why are we still tolerating this shit? There's absolutely no reason why the package manager can't chroot/symlink the little fuckers and make them see what they need to see so they can coexist with any other package. If the package manager is informed enough to recognize a conflict, it's also smart enough to resolve it without the user doing anything beyond confirming the installation of the extra required dependencies, and yet for some reason none of the current crop of package mangers do this.

I'd rather have a bad solution from Ubuntu inspiring people to do it the right way (see: Mir lighting a fire under GNOME's ass to help out with Wayland) than have no solution at all.

Re:Say what you will about Canonical...

[Anonymous Coward]

and so was making a verical launcher/taskbar instead of making our widescreens even shorter.

So something you could do back in Windows 95?

Re:Say what you will about Canonical...

[foreverdisillusioned]

Neither windows 95 nor any other widely deployed desktop (to my knowledge) made this the default. And even today it often breaks stuff. Latest version of XFCE apparently removed the ability to rotate some panel widgets.

Re:I never got "packaging systems"

[EvanED]

another thing windows devs don't get is shared libraries (DLLs in windows terminology). Why does every single app have to install their own copy of the MS C++ libraries? or .net? or nvidia physx? and numerous other common library packages? these things are supposed to be shared resources provided and kept up-to-date by the operating system, not bundled with every app that uses them.

They are... sort of. Take the MSVC runtime. That's not maintained or installed necessarily by the OS for (some good, some mediocre) reasons which I'll explain in a second, but I'm 95% sure that it's shared between programs in the sense that when you see an program installer that spawns off the MSVC runtime installer, the latter will either be (1) installing a new version of the MSVC runtime or (2) discovering that it's already present and doing nothing. The runtime installs to a shared location. (Look at msvc*.dll in windows\system32.) So the runtime installer has to be bundled with individual programs for the upcoming reasons, but it's not wasting disk space by installing duplicate copies (subject to the caveat below) or wasting memory by loading the same thing from different hard drive locations at different time.

So why does it do this? Well, a couple reasons, I think. (I'm speculating here, but I consider them educated guesses.) First is the mediocre reason: there's no package manager. This leads to the "well, you have to ship the runtime installer with each program."

Second is the pretty-good reason: compatibility and correctness. You can definitely have multiple major versions (e.g. the runtime associated with VS2008 and 2010) installed simultaneously, and I think you might be able to have multiple patch versions of the same library installed simultaneously. I think the former is true in Linux too (libfoo.so.1.0.0 vs libfoo.so.2.0.0, though I thought those only show up for -devel packages... hmmm, not sure), but the latter isn't so much. It may well be that Program A installs version 1.0.0 and Program B installs version 1.0.1239, where on Linux the latter would likely be packaged to upgrade the former. (This is the caveat to my "no wasted space" claim above.)

Why is that good? Well, why did the library change? Bug fix? Well, MS usually will bend over backwards to maintain compatibility, which has often meant bug-for-bug compatibility with old programs, at least as a shim. If you take the Linux approach, then programs which rely on the old behavior of the buggy code will break. This is sometimes good (e.g. bad security-related fixes), but is often not. Or it doesn't have to be a bug fix, it could just be some behavior change within the specification. By keeping multiple versions around, the Windows approach keeps the individual programs happier.

How you weight these various advantages and disadvantages is up to you. I'm not really trying to argue that the Windows approach is better, just explain why it is as it is and give a fair description of what goes on.

Re:I never got "packaging systems"

[gl4ss]

Yeah sure, but the *installer* is just an executable. That's what I'm talking about. All you need are APIs that tell you what dynamic libraries are installed, what versions they are, and what (if any) applications are currently using them. The installer doesn't need to be in a "packaging format", it's just executable code, that's what I'm talking about. APIs that tell you what the installer needs to know ought to have been settled a long, long time ago. Then you could make the installer anything you want. On Windows that's EXE, but there's nothing to stop it from being a batch file, Perl script, Pythoh, whatever, and it gets along fine with all the other installations as long as it makes the correct API calls.

but they don't want root access to be necessary, to be able to install dll's system or even user wide. some mobile apps do away with this by installing everything as a different user, so that at least in theory installing one application can't fuck up another application - or even mess with it on purpose.
the reasoning is really that they wouldn't be able to audit or trust the packages which would be installed, at all. the easy way out is that everything provides everything it needs - minus the base system of course - this mindset is something that's also geared HEAVILY for commercial software which is what they're hoping for(commercial sw doesn't tend to work in the way that two different commercial ui programs would use the same shared library on a system unless the shared library happens to be system included.. companies just don't get along like that on purpose).

what the dpkg etc do is provide information about which dynamic libraries(dependencies) are there and what versions..

Nope..

[Junta]

*If* everyone picked exactly the same lib version, yes.

In practice, people aren't going to standardize on the same library version.

Bonus problem: Now each app provider is responsible for addressing a hypothetical libcrytpo vulnerability rather than the distro patching it in one place.

Re:Nope..

[Burz]

But they *do* standardize on library versions most of the time... when they are using system-supplied libraries. A desktop OS should be rich enough that even the most involved applications should only need a smattering of third-party libraries.

IMO, this sort of thing is not a significant source of bloat.

Canonical have realized that an OS needs its own packaging system if it is to thrive. App authors need a break from specifying in detail what each piece of system funtionality should look like, and also from fielding inquiries from umpteen different distro maintainers (when you were only interested in having the app work on one or two distros in the first place). Simple-to-moderately complex apps should be able to work just fine by specifying nothing more than the OS version as a dependency.

Bonus problem: Now each app provider is responsible for addressing a hypothetical libcrytpo vulnerability rather than the distro patching it in one place.

When you commit to really learning and writing well for a desktop OS, you don't go looking looking for third-party crypto packages first. The OS should have great crypto tools built-in. OTOH, if your app needs a ton of unusual functionality then chances are its either going to be run in an unusual environment with hardware specs to match... or it will be very prized with boutique-level appeal and people won't mind an extra 50-100MB of used space.

These conversations (which cycle endlessly on FOSS fan sites like this without any seeming ability to learn from history) are a reason why I totally gave up on desktop Linux around 2008. The assumptions that hackers kept insisting on making in their promotion of the category were mostly inappropriate/delusional... as if typical users *wanted* to learn about different libraries and toolkits as the most visible feature in an app's description... as if a company could practically undertake a tech support effort where most of the users were *likely* to describe an interface that was not readily familiar to trained staff... as if people (in school or otherwise) who start wading into app programming want to discover that the program they wrote only has a 1-in-50 chance of running unmodified on their colleages' Linux systems (Oops! looks like they don't work like they are the same OS). ...And they really *aren't* the same OS. Not according to groundrules and user expectations that were hammered out for the personal computer market by Apple and Microsoft.

So at first glance it seems like Ubuntu is going in the right direction with this. As much as I hate the Unity interface, this packaging scheme and other developments restore some hope. Ubuntu is outgrowing the "Linux distro" genre and growing up. Even if the package format is technically just a slight variation of dpkg/apt, the expectations that go along with it can make a world of difference.

Re:Nope..

[Anonymous Coward]

*If* everyone picked exactly the same lib version, yes.

In practice, people aren't going to standardize on the same library version.

Bonus problem: Now each app provider is responsible for addressing a hypothetical libcrytpo vulnerability rather than the distro patching it in one place.

But you just said distro.. as in first party. Why are people confusing inter-app dependencies with core-OS dependencies??? If the OS ships with a library, use it, if you can't, then it !_IS_! your responsibility to patch that library with your app.

Re:Nope..

[Anonymous Coward]

But they *do* standardize on library versions most of the time... when they are using system-supplied libraries. A desktop OS should be rich enough that even the most involved applications should only need a smattering of third-party libraries.

This has proven itself to be massively incorrect assumption. Declaring libraries that are only used by a small number of applications as "system libraries" just makes it massively more difficult to do OS upgrades. This is a very real maintenance burden on Linux distributors which everyone has always accepted 'just because' the packaging system forced them to.

A better packaging system would mean the entire world doesn't need to be recompiled for every new OS release. Most older packages could "just work". Plus, a much smaller "system" would means the OS could be iterated more quickly and (more importantly) QA testing would be much more efficient. My guess is this what Ubuntu is going for.

Re:Nope..

[Burz]

A typical desktop distro is an example of a system that is very 'fat' in terms of available components, but poor in terms of what can be considered integral to the system. There is gobs of duplicated functionality, and the packaging system treats all these pieces pretty equally and a lot of it can get in the way when you have independantly installed apps. So I think the difficulty for upgrading that you speak of is more acute in desktop distros than it is for, say, OS X.

Ubuntu is starting to limit the role of the managed repository: It will continue to be used for the core OS, but apps will increasingly use the new format which primarily specifies the OS version as a dependency to be checked. If the app needs more than what the OS offers, then they are free to include the extra libraries in their own tree. This makes a lot of sense and I hope it catches on with app developers.

Re:Nope..

[Burz]

But they *do* standardize on library versions most of the time... when they are using system-supplied libraries. A desktop OS should be rich enough that even the most involved applications should only need a smattering of third-party libraries.

IMO, this sort of thing is not a significant source of bloat.

Canonical have realized that an OS needs its own packaging system if it is to thrive. App authors need a break from specifying in detail what each piece of system funtionality should look like, and also from fielding inquiries from umpteen different distro maintainers (when you were only interested in having the app work on one or two distros in the first place). Simple-to-moderately complex apps should be able to work just fine by specifying nothing more than the OS version as a dependency.

Bonus problem: Now each app provider is responsible for addressing a hypothetical libcrytpo vulnerability rather than the distro patching it in one place.

When you commit to really learning and writing well for a desktop OS, you don't go looking looking for third-party crypto packages first. The OS should have great crypto tools built-in. OTOH, if your app needs a ton of unusual functionality then chances are its either going to be run in an unusual environment with hardware specs to match... or it will be very prized with boutique-level appeal and people won't mind an extra 50-100MB of used space.

These conversations (which cycle endlessly on FOSS fan sites like this without any seeming ability to learn from history) are a reason why I totally gave up on desktop Linux around 2008. The assumptions that hackers kept insisting on making in their promotion of the category were mostly inappropriate/delusional... as if typical users *wanted* to learn about different libraries and toolkits as the most visible feature in an app's description... as if a company could practically undertake a tech support effort where most of the users were *likely* to describe an interface that was not readily familiar to trained staff... as if people (in school or otherwise) who start wading into app programming want to discover that the program they wrote only has a 1-in-50 chance of running unmodified on their colleages' Linux systems (Oops! looks like they don't work like they are the same OS). ...And they really *aren't* the same OS. Not according to groundrules and user expectations that were hammered out for the personal computer market by Apple and Microsoft.

So at first glance it seems like Ubuntu is going in the right direction with this. As much as I hate the Unity interface, this packaging scheme and other developments restore some hope. Ubuntu is outgrowing the "Linux distro" genre and growing up. Even if the package format is technically just a slight variation of dpkg/apt, the expectations that go along with it can make a world of difference.

./

Re:Nope..

[BrokenHalo]

Declaring libraries that are only used by a small number of applications as "system libraries" just makes it massively more difficult to do OS upgrades.

Well, that's probably true for most distros, but I heard that Ubuntu is adopting a rolling-release model for future upgrades. Now, if they do that right (which I suspect they won't, because the whole thing seems to be an afterthought) then upgrading should just be a one-liner.

A fair example of a (usually) successful rolling-release platform is Arch Linux, where on the whole, pacman does a good job of keeping all packages up to date. A downside of this is that occasionally things will break (which is candidly admitted on the Arch wiki). I won't go into why I dumped Arch here, since that's another story, but the point I am making is that if Ubuntu somehow manages to pull a rabbit out of the hat and implement what's good about rolling releases but without the speed-bumps, then good luck to them

Re:Nope..

[K. S. Kyosuke]

*If* everyone picked exactly the same lib version, yes.

Well, it they won't, you'll simply have multiple versions of the same library, but you would never have identical files on the disk.

Bonus problem: Now each app provider is responsible for addressing a hypothetical libcrytpo vulnerability rather than the distro patching it in one place.

If all the "identical libs" were hardlinks to a single file, you'd just patch a single file...

Re:Nope..

[GPLHost-Thomas]

This makes a lot of sense and I hope it catches on with app developers.

No, it doesn't make sense to have N versions of the same library. This is pure crap, only driven by the commercial interest of having an app store where people make money. My n900 works pretty well with .deb files and real dependencies, there's absolutely no technical reasons why a phone would be different from any other kind of operating system.

Now, the words from Shuttleworth are even more lies if they implement this shit. It will not be like the desktop OS. And definitively, I don't want such crap.

Re:Nope..

[Burz]

Um, yes it does make sense... because if the system architects are doing a decent job, then N is bound to be a low, manageable quantity. Don't burden the OS distrubutor with trying to manage its relationships and compatibility within a repository because it is 3rd party and doesn't belong under their supervision.

This is pure crap, only driven by the commercial interest of having an app store where people make money.

I understand your skepticism, but this makes it far easier for both app store managers AND developers who want to do an end-run around Canonical by offering direct downloads. Its the independant developers and users who win... and if the app developers want to make a buck who are Canonical to stop them?

Re:Nope..

[GPLHost-Thomas]

I understand your skepticism, but this makes it far easier for both app store managers AND developers who want to do an end-run around Canonical by offering direct downloads. Its the independant developers and users who win... and if the app developers want to make a buck who are Canonical to stop them?

Sure, that's easier for the developers and Canonical. No doubt for that. Though that doesn't mean that this is better for the end user. My opinion is that it makes it a very inferior system, with duplication of libraries and security problems, with potentially very bad safety consequences.

Re:Nope..

[nbritton]

*If* everyone picked exactly the same lib version, yes.

In practice, people aren't going to standardize on the same library version.

We have library standardization, it's called Red Hat Enterprise Linux and Ubuntu LTS. The trouble is that by the time we standardize, the kernel and libraries are already antiquated. Linux is the largest software development project in the world and a very fast moving target. It may end up being better to let the application owners manage this, it works well for Mac OS X. I think if it makes it easier for normal people to install an application it's a huge win for usability. I don't see any reason why you can't implement both static bundling and shared libraries in parallel on a system; perhaps just have core library services like libcrytpo shared, much like the core services available in Mac OS X.

packaging isn't that hard...

[cas2000]

i can't see why i'd want to install an app by a developer who wasn't competent to do something that's actually quite easy.

the only purpose for this is to cater to ignorance and incompetence.

User installed programs

[Agent ME]

Will this finally allow non-admin users to install packaged programs into their own user home folders? I hate how there's been no easy way for users to install packaged programs into their own home folders without privileges.

Re:User installed programs

[starfishsystems]

What? That's always been possible, ever since Unix version 7.

Oh wait, not in Debian/Ubuntu, because deb packages don't properly support relocation.

Re:User installed programs

[Anonymous Coward]

GOOD. A user should not need to install anything into their home directory.

If a user needs something then the admin should install it. Allowing a user to install anything, regardless of location, is overstepping the admins' authority.

If you are expecting that a user should be able to install anything, or worse allowing them to do this, that means you are not doing your job as a system adminstrator.

I hope you are keeping detailed logs on your user's activites. You are going to need it when your boss fires you over that "KiddyPornDownloaderWithFBINotifierPlugin_Installer.exe" lawsuit.

Re:User installed programs

[Anonymous Coward]

You can manually unpack them then play around with LD_LIBRARY_PATH, etc and hope.

Re:this is as far from UNIX philosophy as you can

[alcourt]

That every time you update appFoo that needs you to go to Java 1.6.0.49.1, appBar will break because it only works with 1.6.0.49.0.

Dear ubuntu..

[kallisti5]

Stop forking. No, seriously... stop.

Scripts...

[BenJeremy]

So I won't have to write special scripts every time I install a new daemon app?

Seriously, I do not live in the Linux ecosystem, so it's a pain in the ass when I have to install anything on the few Linux boxes I have here in my house, looking up the obscure commands to figure out how to get everything running - and failing to get some daemons running, without so much as a single log line to tell me why it failed.

Sorry... just venting. Compared to Linux, Windows installations are light years ahead. That's just a simple fact.

Re:Scripts...

[iggymanz]

because the registry is so superior to text files that are easily read and changed? or configuring the windows firewall easier than iptables? enterprise windows software installation is a nightmare, I've found. And I've admined a dozen other OS, windows is the very worst.

Re:Scripts...

[burning-toast]

I have no idea what you are actually attempting to do on Linux but I get the feeling you are "holding it wrong". What daemons are you attempting to install which requires you writing scripts? And why in the world would you have to install daemons on any sort of recurring basis with just a couple of machines on a home LAN? When you use the package managers for Linux systems that should be taken care of for you almost in the entirety, "out of the box" per-se.

I haven't had an experience anywhere remotely similar to what you are claiming except for when I've gone off the farm and have attempted to custom compile applications downloaded off the web or from a proprietary vendor (i.e. very rarely). But I knew what I was getting into and which automated management facilities wouldn't be available to me when I did. That I occasionally had any problems doing manual compilation was not unexpected and help was frequently just a simple google away.

I've been maintaining multiple (dozens of) networks of Windows, RedHat/CentOS, and Debian/(K|U)buntu servers and desktops for years now (plus tinkering with other derivatives). They are all pretty good about "easy" and "just works" installations... with the expectation that you are using their respective package managers, repositories, toolsets, methodologies, and ecosystems (or at least packaging formats) to install software.

RPM/Yum and Dpkg/Apt really do take care of most of the work and neither are obscure by definition of the fact that they manage the entire distribution (and repositories) by default. Your equivalent problem in Windows would be a failure of you to understand (or use) Windows Update and instead attempt to install all of the Windows updates including registry hacks... by hand... without using an .msi file or the like and then pondering why Windows is so convoluted when you fail to get a working machine out of the ordeal. Nobody works that way.

Besides that, most Linux application developers will release into one of these two formats anyways (deb or rpm), so I fail to see how you could possibly be stuck writing scripts "every time" you "install a new daemon app" unless you are using something like DSL (Damn Small Linux) where package managers are not necessarily present. And if that is the case you are using the wrong distro for your skill level.

I've also had the opposite experience re: log files on Linux. Text and log files are cheap and plentiful when the command line is a useful part of your operating system. Normally I get such verbose logging from a failure that it actually takes a little bit of investigative work to find the original point of failure instead of all of the effects. On the other hand I rarely get log lines (only error codes when I'm lucky) from many Windows applications when they fail however...

Not to be too harsh but your "simple fact" is not reflective of the reality on the ground. Your perspective is "off" and I think you have failed to grasp some basic computing and usage concepts instead.

- Toast

Re:Scripts...

[BenJeremy]

SABNZBD is a great example of what I'm talkign about.

On Windows, it's... "click the installer" and it's pretty much done.

On Kubuntu Linux, I had to locate a solid tutorial, about 7 pages long, on installing it and getting it running correctly.

I have nothing against text files as config files, but geez... how about standardizing the damn things? ...and Where the f*ck are my logs? No, they don't get put in the same subfolders every time, and I NEED those logs a lot more in Linux than in Windows.

I'm running a LAMP server and I have Kubuntu running as a media server. Every time I plug in a new USB drive, I have to go through a bunch of extraneous steps just to permanently mount and share the drive on SAMBA - there just isn't a simple way to do it. I have to get the UUID of the drive, and edit FSTAB and the samba config files. Why does it have to be that painful?

I have init.d scripts that work fine on a couple of my python daemons, but not on a couple of other daemons (which manually start fine).

So I'm "holding it wrong?" - sorry, the OS should NOT have me so involved. I'm a software developer, my bread and butter is on Microsoft-based enterprise apps, but my background includes years working in embedded systems. Hell, I've written my own multi-tasking operating systems and built up entire IO libraries for devices that were custom built.

I'm wrong for wanting to drop an installer on my Linux box and have it install without issues. I should WANT to have to fire up the editor-de-jour for whatever flavor of Linux I'm using (let's not forget to fire it up with sudo!!), and sift through a bunch of options, hopefully all of them are documented, to configure it? Again, why? What's the point of having a GUI if not to make life easier for users? Why bother with VNC?

Do you think my parents would use a shell-based OS? Hell no. What I always get form Linux fanatics is the condescending "use the shell" answer, which is complete bullsh*t. Editing text config files isn't much different from using a shell either... Would it kill Linux developers to provide a GUI control panel? Would it kill them to provide a one-click install? ...and why don't they? Oh yeah... because who knows what desktop or distribution they will be installed in.... yes, it's all called Linux, but it's like everybody who gets upset takes theri ball and goes home... then branches off another distribution.

Sorry... venting again.

The point is, it shouldn't be so hard for people who are not autistic savants who dwell on TTY terminals, tapping away on monochrome 80x25 text displays, convinced of their superiority. I don't live and breathe Linux, so don't tell me I'm doing it wrong.

For the record, I've never had to do any "registry hacks" to install any damn Windows apps - not in 20 years of using Windows. Either there is an installer that works fine, or it's a portable app that can be dumped into a folder and run. I've written plenty of apps that can launch, and configure themselves for running as a service, or setting up as a startup app. I've also written a lot of software pretty "close to the metal" - apps running on over 400,000 PCs right now, where security and robustness is important. They work. They don't require any hacks. The user doesn't even get involved in the install process.

Re:Scripts...

[Anonymous Coward]

Summary: I know very little about Linux, and so I'm whingeing about how it's not like Windows and how the advanced stuff which I don't understand is difficult. I'm bringing in irrelevant stuff about my parents and the command line even though nothing they are likely to do would require the CLI.

As for this:
I don't live and breathe Linux, so don't tell me I'm doing it wrong.

It just leaves you speechless.

"I know nothing so don't even *dare* try to educate me".

It's on a par with me going into Windows and saying "where is the package manager, how do I update everything with one click, don't tell me windows doesn't work like that, I don't want to hear it"
"where are my config files, don't tell me about the registry, I don't want to know"

You really are pathetic. You want Linux to *be* windows? Just *use Windows* FFS.

Re:Scripts...

[burning-toast]

JCFP maintains an Ubuntu package which is stored in an unofficial repository1.

Attention: As of Ubuntu 10.04 Lucid, SABnzbd is part of the standard Ubuntu repository "multiverse". Installing SABnzbd is easy:

        Start the Software Center and search "sabnzbd" (or "sabnzbdplus"). Then click Install.
        Or, from the command line with "multiverse" enabled, type "sudo apt-get install sabnzbdplus".

If you use this method, you can skip the first parts and jump to "How To Start"

vent away i guess... just be aware that the difficulty you have in configuring it is the fault of the app developer... not a lack of OS facilities to make it brain dead easy

-Toast

Re:Scripts...

[Anonymous Coward]

If you want a GUI for every setting of every program on your Linux box, then you'll have to write the ones that don't exist. Writing settings GUIs is boring, painful and full of validation rubbish (because users like you will complain if the GUI lets you dump crap into the config). So people don't bother. Imagine how complex your Apache config GUI would be. How many options does it have, and would you rather the Apache devs spent their time debugging that maze than developing Apache for your LAMP setup? What about the host file? Does that need a GUI too? Also, many of these programs are installed on a server under a log somewhere in Timbuktu and you only have a console interface, so why would you want to bother loading up a GUI, X-forwarding/VNCing it, getting to the tab and flicking the combobox for "a" to "b"? Much easier to open vi (or nano if vi is too hard) and change "setting=a" to "setting=b".

Besides many many tools do have GUI confgurators: for example pysdm for fstab, and gnome-network-admin for hosts (not tried, don't need) Look in your Preferences menu for a large set which are installed by default. And you do have one-click install for and deb or rpm!

About time!

[Anonymous Coward]

I'm really happy to see Canonical taking the lead on this one. The main stream Linux distros have been putting off having a self-contained package bundle for far too long. PC-BSD has this technology, OS X has it, Android has it, Windows has it. Ever so often someone in the Linux world implements this sort of thing, but it never gains wide support because it's not backed by one of the big distros. Having Ubuntu move forward with a proper dependency-less package format and the tools to work with it will be wonderful. It looks like they are currently using dpkg as a backend for the new format which means it should be easy to port this new package manager to any other Debian-based distribution.

reinventing the wheel? Doesn't epkg do this alread

[Anonymous Coward]

reinventing the wheel? Doesn't epkg do this already?

I've worked placed that used epkg across all UNIX platforms to re-package packages. It is a little old-school - these days something like ansible or rex or salt would be a better choice. Anything but the 1000x too complex puppet.

remember rox?

[mental666]

Remember Rox Desktop? http://en.wikipedia.org/wiki/ROX_Desktop Very similar to how mac os works. Lay down a base system with the common libraries in a central location. Apps are just custom folders with a very specific directory structure. It's not horrible, as an end user it's kind of nice. It will lead to security whack-a-mole issues when common but non-core libs have issues, but nothing's perfect.

yeah and in MSDOS.....

[decora]

each program came with its own video card drivers, it's own printer drivers, it's own windowing system, it's own mouse reading code, and sometimes it's own memory management code.

Re:yeah and in MSDOS.....

[Anonymous Coward]

Yeah, it was awesome having to cold-boot just to switch to another application when one completely hosed up. I don't miss those days for that, but at least the reboot was faster than any "modern" OS!

what files?

[decora]

as Junta stated above, "In practice, people aren't going to standardize on the same library version."

how can you reference count libwhargharbl-0.2.4.1.2 when your app comes bundled with 0.2.4.1.3

OMG I hope not

[CrypticSpawn]

Will they also forgo the shared libraries, and have everything statically linked? Sounds familiar? If they go this route, one downside to this is it takes up too much memory. Which is why apple switched from static libraries and started using shared libraries.

Releveant XKCD

[Anonymous Coward]

http://xkcd.com/927/

Re:Releveant XKCD

[Anonymous Coward]

Learn to make a link.

The problem with open source ...

[Anonymous Coward]

... constantly reinventing the same wheel over and over for no reason.

Instead of spending resources making the current wheels better, faster and stronger, there is a tendency of just wasting resources on reinventing it just because the old one is not cool to work on anymore.

Welcome to Mac!

[cdwiegand]

So... catching up with Mac OSX? Sounds just like the .app "bundles" (really just zips as far as I can tell)

Beginning of the end

[Anonymous Coward]

Manage source not versions of binaries and crutches to help you walk uphill. If compiling from source is not working for core features of the OS there is a bigger problem at hand. Canonical cannot squeeze blood from a stone in this regard- if they want their own package manager they need to put it in a paid-for enterprise version. Its amazing to me that after all these years open source has turned into a way for companies to claim that they are improving things by rebranding them. If you want developers to cater to you then pay them don't jury-rig their work and call it an OS.

Re:I never got "packaging systems"

[Guy Harris]

Second is the pretty-good reason: compatibility and correctness. You can definitely have multiple major versions (e.g. the runtime associated with VS2008 and 2010) installed simultaneously, and I think you might be able to have multiple patch versions of the same library installed simultaneously. I think the former is true in Linux too (libfoo.so.1.0.0 vs libfoo.so.2.0.0,

Well, you're not likely to have multiple versions of the C runtime installed, because, in most if not all UN*Xes, the C runtime is part of the equivalent of kernel32.dll (libc.so, libSystem.dylib, or whatever it's called).

But, yes, you can have multiple "major" versions of libraries present. The SVR4 shared library mechanism, upon which the Linux and *BSD shared library mechanism are based, and the SunOS 4.x shared library mechanism upon which the SVR4 mechanism is based, gives libraries "major" version numbers, which change when the library ABI changes in a binary-incompatible fashion, and "minor" version numbers, which change when the library ABI changes in a way that preserves binary compatibility with older library versions but might add features (routines, flags to routines, etc.) that, if used, won't work with those older versions.

However, if your application uses libfoo version 2, but it's linked with a library that uses libfoo version 1, that's a problem. (Replace "a library" with "libpcap", and replace "libfoo" with "libnl", and you have one of the problems that makes me want to have libpcap on Linux talk directly to netlink sockets without the "help" of libnl, but I digress....)

but the latter isn't so much. It may well be that Program A installs version 1.0.0 and Program B installs version 1.0.1239, where on Linux the latter would likely be packaged to upgrade the former.

If libfoo is done correctly, any program linked with version 1.0.0 should Just Work with version 1.0.1239, and Program B should only upgrade to 1.0.1239 if there's a bug in 1.0.0 through 1.0.1238 that breaks Program B so it requires 1.0.1239 or later, and Program A should just require 1.x.x and not install 1.0.0 if 1.0.1239 is installed.

If you take the Linux approach, then programs which rely on the old behavior of the buggy code will break. This is sometimes good (e.g. bad security-related fixes), but is often not. Or it doesn't have to be a bug fix, it could just be some behavior change within the specification. By keeping multiple versions around, the Windows approach keeps the individual programs happier.

How you weight these various advantages and disadvantages is up to you. I'm not really trying to argue that the Windows approach is better, just explain why it is as it is and give a fair description of what goes on.

Yes, that's the question of the extent to which the real "specification" upon which clients depend on is the official specification or the full behavior of the implementation, and the extent to which you're willing to tell developers of code that doesn't fit the former specification but fits the latter specification to go pound sand if you "break" their code. Sometimes you end up not telling them to go pound sand, e.g. the "7090 compatibility mode" in the IBM 7094 (in which mode the index number field in instructions is interpreted not as an index register number but as a bitmask with bits corresponding to 3 of the index registers, with all the index registers specified by the bitmask being ORed together to generate the index) or the hacks in various OS X libraries in which the library detects that program XXX is using the library and falls back on the old buggy behavior (I think Raymond Chen's "The Old New Thing" has examples of similar hacks on Windows).

Maybe it's not as bad as it sounds.

[doragasu]

It can be a good idea if it is used as a complementary system, used ONLY for a few selected packages, like for example non free ones. Non free packages have the problem that sometimes they become a real pain to get working, when the libraries they depend on get outdated, and are not available in the repositories of the distro you are using. As Ubuntu continues moving away from the free software ecosystem, I think this is hardly a surprising move.

Is it really necessary?

[Anonymous Coward]

While all they actually need is just .zip files with .info file and .dpkg files, .dpkg being the application itself and all non-standard libraries. Dead simple stuff.

Re:I never got "packaging systems"

[cas2000]

Why is it SO hard for people who use linux to understand that there are multiple runtime libraries because [...]

it's not that we don't understand how and why windows DLLs are fucked up, it's just that since we're used to a versioned shared library system that actually works, we see the windows DLL mess as being fundamentally broken.

you don't even seem to understand what's being discussed here - after the second sentence, you digress into an irrelevant rant about kernel versions.

and, BTW, since linux can run even ancient a.out format binaries from the 1990s on modern kernels, the problem you are describing is actually a problem of shoddy practices by proprietary software companies.

Re:

[kurkosdr]

As an Average Joe who has been tortured by X.org issues and dependecy hell problems more than a few times, I can only welcome Canonical's decision to pursue Mir and this new package system. Sooner or later, there will be a schism between "linux for the Average Joes" (Android, and maybe Ubuntu) and "linux for hackers" (Debian, Arch etc). "and, BTW, since linux can run even ancient a.out format binaries from the 1990s on modern kernels" Unless they have a GUI, because you know, X.org...

perfect example of why linux fails it

[Anonymous Coward]

So once again we see Liunx developers reinventing a perfectly good wheel instead of writing some quality software that might make people actually want to use Linux on the desktop.

Next week they'll rewrite the desktop (again), the GUI engine (again), the filesystems (again), the mail client (again) but still there will be NO DECENT APPLICATIONS.

No wonder desktop Linux will never take off.

Re:I never got "packaging systems"

[kurkosdr]

"Windows just assumes that you have free run of the system. The installer runs amok and does whatever it likes with your system. This is hardly anything to emulate or brag about." It's mostly a disease of Windows developers, stuck to them since the DOS and pre-MSI ages. "I 'll just make a script or executable that copies this and this there and changes those settings". Blame DOS and early Windows for not having install APIs. Just wait 'till those developers transfer their mentality to Linux. I remember Flash requiring you to run some script to install it on Ubuntu.

Hold

[msk]

apt-mark hold Ubuntu

Re:Hold

[Anonymous Coward]

# apt-get purge msk-insipid-comments

Meh

[BrokenHalo]

I've got a better idea. Or rather, Pat Volkerding does. Never mind dependency checking, just let the user sort them out for himself. Slackware's package system is beautiful: a simple *.tgz or .txz file, with a note saying "and BTW, you'll need foo and bar as well". No need for separate directories full of statically linked packages, and it just works.

Of course, I have to admit that Debian packages work too, but if that nice Mr Shuttleworth thinks otherwise, then (sadly) there's another reason not to use Ubuntu.

While I can admire Shuttleworth's passion, he isn't doing anyone any favours by pursuing this "Not Invented Here" ideology. Everyone would benefit if he would just act like a part of the community, instead of trying to railroad it.

Re:Meh

[crutchy]

pursuing this "Not Invented Here" ideology. Everyone would benefit if he would just act like a part of the community, instead of trying to railroad it

i think he's actually pursuing the ecosystem ideology... trying to trap developers and users in a similar fashion to microsoft and apple. not surprising really. canonical must turn a profit to survive. they don't have clout in the datacenter like redhat and their user base is full of ex-windows freeloaders.

if shuttleworth was really an ideological inventor before businessman, it wouldn't really make much sense to piggyback off another operating system. he might be gradually trying to develop a new OS, but he'll probably do it as a businessman, implementing small pieces and building his ecosystem by stealth. eventually ubuntu users will be as trapped with ubuntu as isheep are enslaved by their ithings.

Re:I never got "packaging systems"

[nine-times]

nice starting idea, but the implementation is idiotic. Why not just have one Ninite app that fetches a list of available apps and installer URLs and whatever custom installer scripts ninite needs for them) and allow the user to select which apps whenever they run it?

Well the idea is that if you need to deploy the same package on a bunch of different computers, you grab that one install package, and then run it anywhere, and it will apply a consistent set of installs/updates. The website is really just a way to generate the configuration. They could have had the same setup/configuration in a local application instead of the Ninite website, but I'm not sure that really helps you much.

Second, you can hold onto that installer and re-run it at any time, and it should update all of your existing installs. Third, they have "Ninite Pro" which lets you script out what to install better, and offers more management options.

Not that it isn't a little backwards. I think both Apple and Microsoft should create package managers that would let you simply add repositories, so that their "software update" and "windows update" would be able to fetch updates from other vendors without needing to be in some kind of walled garden.

Bodhi Linux does it.

[cute_orc]

Bodhi Linux has one click software installation binaries. Irony is that it is based on Ubuntu.

Re:I never got "packaging systems"

[EvanED]

If libfoo is done correctly, any program linked with version 1.0.0 should Just Work with version 1.0.1239

Here's the problem: the Linux ecosystem has a much more liberal interpretation of "Just Work" than MS does. MS's approach I think is quite a bit closer to "any change is a potentially-breaking change" which is why they keep around a lot of minor updates which on Linux would just replace the old file. It gets to this point:

Yes, that's the question of the extent to which the real "specification" upon which clients depend on is the official specification or the full behavior of the implementation, and the extent to which you're willing to tell developers of code that doesn't fit the former specification but fits the latter specification to go pound sand if you "break" their code

I don't actually know why the situation seems to be a lot different on the two systems. Maybe Linux changes really do break software fairly frequently, and it's just rarely-used software that few care about and the Linux people are fully prepared to say "oh well, deal with it" in situations where MS would maintain compatibility. Maybe the fact that most Linux software has source available means that the problem is reduced a bit, because a recompile will sometimes fix the problem. Maybe the design of Unix better encourages people to write software which depends only on the documented specification instead of implementation details. I really have no clue.

Re:linux is for screaming lunatics apparently

[kermidge]

Excuse me, but "Bill Gates = cured Polio [sic]"

No mention of Salk or Sabin? (I remember getting the Salk vaccine in grade school back late Fifties, can't right now recall the exact year, what grade I was in, or where, but it was a 'Big Deal'. Friend of mine from first and second grade got polio halfway through second, developed worst form, later died from something else while living in an iron lung.)

Anyway, tell me, just how did Bill cure polio? (I'll give you a clue: there is no cure, only vaccines used for immunization.)

Now, I don't get out much, but this is the first time I've seen an OS castigated by an ad hominem attack. Congrats.

this has already been done, properly...

[ciscon]

this is essentially what (http://nixos.org/) or (http://www.gobolinux.org/) do, though the former has much grander goals.

Very mixed feelings

[Anonymous Coward]

So, will each and every package load *all* their shared libraries, or will the packaging system look to see what libraries are on the system, rather than read the d/b for package names?

              mark

Re:I never got "packaging systems"

[Guy Harris]

Why is it SO hard for people who use linux to understand that there are multiple runtime libraries because windows has been around so long there are multiple versions of the shell environment. To ensure that the program runs correctly on the target machine the runtime is included. This in turn relates to the kernel which linux does not handle gracefully at all. I don't know how many times I've wanted to install an app on linux but it is dependent on features from a specific kernel. Windows does this to some degree but by shippping a runtime its possible to translate the instructions of the application in question to an older or newer kernel.

"Dependent on features from a specific kernel" as in "doesn't work with 2.6.22, works with 2.6.23, doesn't work with 2.6.24", or "dependent on features from a specific kernel" as in "doesn't work with 2.6.22, works with 2.6.23 and later"?

The former either means they introduced a feature in 2.6.23 and yanked it in 2.6.24 or that it's dependent on implementation details from a specific kernel. The first of those might be done less in Windows, but that's a question of whether the OS's developers treat "preserving compatibility" as being more important than "not leaving cruft around". The second of those can show up in applications for any OS if the developer isn't careful.

The latter means "gee, they introduced a new feature in 2.6.23, which my program uses"; that happens in Windows, too - try unconditionally using an API or an API feature introduced in Windows Vista and then see whether your program runs on XP. One trick to handle that, at least in the case of a routine being introduced in a newer version of Windows, is to do a LoadLibrary() on the library containing the API and GetProcAddress() to try to get the address of that routine; if it fails, disable the feature requiring that routine or work around its absence in the code. That same trick can be done on UN*Xes, including Linux; replace LoadLibrary() with dlopen() and GetProcAddress() with dlsym().

"Windows does this to some degree but by shippping a runtime its possible to translate the instructions of the application in question to an older or newer kernel." sounds more like changing the system call interface to the kernel and changing the routines that use it to match. That's not restricted to Windows; one goal of the SVR4 shared library mechanism (which is what Linux's shared library mechanism is based on) was to allow that to be done transparently to compiled applications, by having applications dynamically linked with system libraries, so that an application binary gets the appropriate version of the library for the kernel version. OS X's shared library mechanism works the same, and Apple doesn't even support statically linking with its libraries.

Re:I never got "packaging systems"

[Anonymous Coward]

Your knowledge of Windows installation technology is way out of date. WFP was introduced in Windows 2000, FFS, and current versions have stronger protections for system libraries, files, and even registry settings. MSI and MSP installation databases are the most common approach now, though sometimes there is an EXE wrapper around the actual MSI or MSP. Installers cannot simply stomp all over everything anymore.

- T

Re:I never got "packaging systems"

[cas2000]

Well the idea is that if you need to deploy the same package on a bunch of different computers, you grab that one install package, and then run it anywhere, and it will apply a consistent set of installs/updates.

that's easily done with a configuration file that lists the "packages" to install. Copy the main Ninite app and the config file to all machines.

to me, this is the natural and obvious way of doing it. i've been doing it this way for years - e.g. get dpkg to give me a list of installed packages on one machine, copy the list to another machine and import it.

and, being a simple text file, the list is easily generated and/or modified with standard text-processing tools like a text editor, or sed or

this is, IMO, the biggest blindness of Windows users and devs - they don't see data as something malleable and re-usable. The windows model is based around particular apps that "own" data. the *nix model is around data that can be manipulated by multiple apps or tools. The former works well for vendors, who want lock-in. The latter works better for users, who need to own their own data.

This is why Windows software vendors like Adobe are moving towards software rental, rather than software purchase. Once you have significant amounts of data locked into their proprietary software, you have no choice but to keep on paying your rent/subscription-fee if you want to keep accessing your data. It's why MS changes their data formats with every new release - to break compatibility with alternative software (forcing upgrades is only a secondary benefit), and it's why Microsoft has done everything they can to sabotage open formats like ODF with pseudo-open formats like OOXML & DOCX

Second, you can hold onto that installer and re-run it at any time, and it should update all of your existing installs

again, config file.

I guess I underestimated the effect of the windows mindset - i should have mentioned it explicitly. I didn't because i assumed it was obvious that an installer app should keep a record of what programs (and versions) are installed.

when you run it again, you have the option of just updating what's already installed, or you can examine and change the list of software-to-be-installed.

Re:I never got "packaging systems"

[cas2000]

the linux (and unix) attitude is that depending on undocumented behaviour is brain-damaged. if you do it and it bites you on the arse sometime in the future, then you've learnt a valuable lesson on why you shouldn't do that. fix it, recompile, and don't do it again.

this can cause a small amount of short-term pain (not as much as a windows user might expect because very few linux/unix developers don't understand this lesson) but it results in better quality software and less legacy bugs being kept alive for a decade or more.

chocolatey.org

[Anonymous Coward]

"I ran across a program for Windows recently called Ninite. It's a multi-app installer and updater. it sounds like a good idea and is. it's a big improvement over the usual click-and-execute for each individual program."

It's [Ninite] also closed source!

Chocolatey NuGet claims to be "a Machine Package Manager, somewhat like apt-get, but built with Windows in mind"

It's here: http://chocolatey.org/

Tried it I have not.

Re:I never got "packaging systems"

[nine-times]

that's easily done with a configuration file that lists the "packages" to install... I guess I underestimated the effect of the windows mindset

No, you misunderstand the nature of the problem that is being solved. You're a managing windows and want to push out a standard set of packages to environments where you don't necessarily have complete control. Given the option of telling a user to download and install a package manager and write an appropriate config file vs. download an .EXE and run it, I'd choose the latter.

Now obviously I would prefer a package manager with a standard packaging format, but you can't blame Ninite for servicing a need. For the environment that they're operating in, they provide something meaningfully close to the functionality of a package manager for a series of disparate apps that aren't packaged in standard ways. I don't think the "pro" version will accept a config file per se, but there are various options in the command line, so you can still script it and have it select which applications you want to install/update.

It's not perfect, but trying to get Adobe to adhere to the same package standard as Oracle is a fool's errand.

Portable

[slash.jit]

Oh... I am going to miss the good old days of portable software which I just had to extract and run

What applications?

[Burz]

I just tried out the "Linux Desktop's" premiere SIPphone app, Ekiga. It wants you to sign up for their ekiga.net service, but per their instructions I skipped that step to use my existing SIP service. Now there is no way to add a non-Ekiga service... none! zip! The Accounts dialog shows an empty list and every single button is greyed-out.

Oh yeah, on initial startup, it asked me to choose from a list of 6 audio devices 3 times (for audo ringing, input and output). When I type a number into it, the thing opens up a call status window that says "Call completed" instead of "please setup a SIP service first". Lovely.

The alternative that the Ubuntu repo lists is LinPhone, which got 2.5 stars to Ekiga's 3. It looks like an app from 1992 and not sure I want to try it.

As for Firefox, the Linux version is in rough shape. The way it handles UI element focus is wacked-out (sorry, it is not just "different" than OS X and Windows). I don't appreciate having links clicked-on when I click on a window in the tiled window manager listing. I don't like having it 'remember' HALF of the windows in my session. I don't like file dialogs that are blank window frames if an IFRAME containing a video happens to be showing at the moment.

The "Linux Desktop" ecosystem is broken and never worked. It insists on stamping the server-room mindset onto the desktop. So what you get is a situation where even server admins prefer Windows and OS X for their desktop tasks. In a nutshell this is why "Linux Desktop" failed and Android succeeded.

Users don't need to worry about which DE a program uses, programs which use another DE's toolkit work seamlessly

I'm aware of Project Portland and its successors and whatnot. Yes the apps seem to work, except when they don't, and in doing so they negate the resource advantage you clamined.

Re:What applications?

[timbo234]

I wasn't talking about 'Project Portland' (I honestly had never even heard of it). I was referring to the simple fact that you can seamlessly and without problems run a KDE application in Unity or GNOME, and vice-versa run a GNOME (or more correctly GTK) application in KDE. The same goes for the minor DE's, e.g. running KDE apps in XFCE.

You said "users get inducted into a culture of always worrying about which DE and major version a prospective app uses", but this is a problem that doesn't even exist, hasn't for many years and certainly doesn't need some new project on the horizon to solve it.

Re:What applications?

[Burz]

Project Portlant was a Linux Foundation effort to provide a standard interface for DE-level integration features like status bar icons, etc. It goes back to around 2007 and isn't new.

You said "users get inducted into a culture of always worrying about which DE and major version a prospective app uses", but this is a problem that doesn't even exist, hasn't for many years and certainly doesn't need some new project on the horizon to solve it.

Well then stop quoting unrealistically low memory figures for single-toolkit & DE usage scenarios.

Re:What applications?

[timbo234]

If that was the point you were trying to make why didn't you actually write it, instead of going on with a load of nonsense about users having to worry about which DE toolkit an application was built with?

It's not even a very good one point - given the vast difference between Linux and Windows' *minimum* memory usage there's plenty of room for an Ubuntu box to load the toolkit from another DE without even using up the minimum memory usage for a Windows 7 or 8 box. Not to mention that different Windows applications use multiple different GUI toolkits, so your average Windows box in use will need even more memory to work.

If you want a real world example: I'm running 64-bit Kubuntu 12.04 with bells and whistles like desktop effects turned on. The computer's been up for nearly 2 days, in which time I've run applications using both KDE/QT, GNOME/GTK and Mono .NET GUI toolkits. I have Firefox running currently and memory usage is only 1GB, that's half the *minimum* requirement for 64-bit WIndows 7 or 8.

Re:What applications?

[Burz]

If that was the point you were trying to make why didn't you actually write it, instead of going on with a load of nonsense about users having to worry about which DE toolkit an application was built with?

Why do a preponderance of apps found within most repositories feel the need to describe themselves, first and foremost, in terms of which toolkit or DE they are based on? 'OMG! I found a Gnome3 checkbook manager!'

It isn't nonsense; Its a description of a social malady. FOSS desktop systems have no shortage of them. Unlike the moblile space, their primary movers are wedded to the greybeard hacker/sysadmin concept of what an OS should be: A server with a layer of foamy GUI fluff on top that can be disposed of or ignored or replaced at a moments notice.

I say, lets replace them; make them irrelevant. If Android completely mopped up all the (residual) Desktop Linux market share tomorrow (even from Ubuntu), I wouldn't shed a tear.

It's not even a very good one point - given the vast difference between Linux and Windows' *minimum* memory usage there's plenty of room for an Ubuntu box to load the toolkit from another DE without even using up the minimum memory usage for a Windows 7 or 8 box. Not to mention that different Windows applications use multiple different GUI toolkits, so your average Windows box in use will need even more memory to work.

If you want a real world example: I'm running 64-bit Kubuntu 12.04 with bells and whistles like desktop effects turned on. The computer's been up for nearly 2 days, in which time I've run applications using both KDE/QT, GNOME/GTK and Mono .NET GUI toolkits. I have Firefox running currently and memory usage is only 1GB, that's half the *minimum* requirement for 64-bit WIndows 7 or 8.

Mono, LOL.

OTOH, my 2012 model ThinkPad i5 running Ubuntu 13.04 uses 12% CPU to play a low-bandwidth voice MP3 while the notorious Gnome System Monitor shows up as 15%. Memory use is 2GB + 500MB swap for 20 very simple web pages in Firefox plus Rythmbox plus GSM plus CLI; I am using the defalt vanilla Ubuntu apps and preferences. Its on-par with OS X for RAM use, and very inefficient compared to the CPU usage on my Macbook despite the Macbook being a 2007 model that's less than half as fast in raw power.

That's not to mention all the hardware integrations it got wrong (of course, its mainly sound and visual-- but who really needs those when you got an ethernet port?!!).

sigh.

[Anonymous Coward]

Ubuntu has just passed a very important milestone: The Jumping of the Shark.

Re:linux is for screaming lunatics apparently

[Anonymous Coward]

*cough* John Mcafee

appropriate LD_LIBRARY_PATH will do it as on today

[zaxebo1]

as on today with existing mechanisms, this can be somewhat achieved by putting all dependencies in a folder and putting a appropriate LD_LIBRARY_PATH . Isn't it?

Re:appropriate LD_LIBRARY_PATH will do it as on to

[Anonymous Coward]

You are right ,bro .
  I am sure they will just put a fancy wrapper GUI/commandline to dump and remove the package directory ; but in back they will use the same LD_LIBRARY_PATH, as you mentioned.