In 7 years of using Xen (since 2.07) and selling VPS, I've seen many things crash, but never the network stack of Xen, which I believe was the part that was the most easy to virtualize, and that has been reliable for years. Now, maybe with Qemu, but I don't use it (I use PV).
You do realize that with hard links, a file can be in multiple directories and stored on both disk once?
I do. And I also realize that they don't work over multiple partitions. Anyway, using hardlinks instead of SONAMEs isn't the correct solution. SONAME are working well, and we're fine with them, we don't need the hardlinks on top of that, so why bother changing something that works already very well? In what exactly, adding hardlinks, will help? Should we completely redesign shared libs, and remove SONAMEs then?
However, if two applications downloaded and installed through an App Center were compiled with different versions of libc, then yes, have two on the disk. How many are we realistically talking about, given that we're not talking about the stuff that comes pre-installed or anything in any.deb file? Several megabytes? In an extreme case maybe a gigabyte of disk space?
If someone wants to do what you are saying above, then he can simply do static linking. So I don't see your point.
Since apps would run in jails, you'd only want to upgrade the apps needing the functionality that's broken. For example, if my app does not have permission to use the network, you should not upgrade my copy of libc6 to fix a major network security bug. Again, we're talking about user apps, not the base shipped by Debian. How many packages are we likely talking about? 10 mabye?
You're just trying to find an example that matches your argument, but I don't think that works. What if we REALLY find a bug affecting them ALL?
Anyway, currently, you HAVE some vendors that are shipping statically apps. Try installing google earth on Linux, for example. It's one binary for all distro, and to be installed under ~/bin. But frankly, I don't like it... It's like that for only one reason: because we don't have the sources, and we can't rebuild.
I didn't want to get into this much detail, but you are right. Libc isn't a representative case. If I make a simple command line utility, it should by default link against an older libc to be compatible with as many distros as possible.
This is not the way things work. Do this: objdump/lib/libc.so.6 -p | grep SONAME. This tells the SONAME of the libc. If you do something and dynamically link it to libc, then it has to have the matching SONAME of the system one, otherwise at runtime, it wont be able to use the functionality of libc. There's nothing such backward compatibility here. Either you have a matching SONAME pair, either you don't. End of the story.
High level packages like Qt should be published by the developers in occasional stable releases not only in source form, but in binary, all the way down to libc. When building a Qt app, I should be able to specify that I link against an exact version of Qt, which of course could mean users have do to a major download if they don't have it already, or I could specify that it must be a version of Qt 4.x, where x >= 7. It should also indicate that it was built and tested with Qt 4.7 with the full SHA-256 hash code of the Qt library used, so if users have trouble running it with Qt 4.9, they can run it instead with the original 4.7.
Again, that's not the way it works. When you build a library, you give something like this to gcc: -Wl,-soname,libfoo.so.1.0
Then your library will have libfoo1.0 as soname. There's no such things such as >= libfoo1.0, it has to be AN EXACT MATCH. It has to, that's the way library works. If you think it shouldn't, feel free to contribute to the GNU compiler...:)
Then under Debian, there's dh_shlibdeps that will collect dependencies for each library you have built against. That's an automatic process, and you shouldn't care too much about it, but what you got to know is that it will, by default, and IIRC, do Depends: libbar1 (>= VERSION-INSTAL
Since it seems you didn't get it, let me explain again. Let's say you need to run service A, B and C. If you don't have virtualization, you'd run them all on the same server. Then if A, B and C are each running as their own user, you need to get an attack vector on let's say A, get root, then you can affect B and C. If you have virtualization isolating A, B and C, each on their VM, then you need to find an attack vector in A, get root, then find an exploit in the hypervisor if you want to reach B or C. That's one more step, hence the added security.
As for what Xen does, I think you are really missing a lot of parts in the PC architecture that needs to get virtualized (like APIC, MSI, console, serial, the paravirtualized drivers themselves, etc.).
As for the python code, it's slowly fading away, being replaced by Ocaml code (see xl replacing xm).
That said, my goal is to get GNU/Linux developers and the Debian devs in particular to wake up to the fact that we've built a cathedral when we need a bazaar. As you've likely read in the paper by that title
Of course I know the Cathedral and the Bazaar. I believe that Debian is a mix of both methods, since we release SID 4 times a day, and stable each 2 years based on that.
That was the bazaar, and it's where the heart and sole of GNU/Linux was created.
I'd say that's what Linux is doing now (but do you remember the Linux 2.5 development version?), I'm not so sure about GNU and the GNU tools.
The problem is that this binary repository is managed lovingly by devoted monks. Every brick is carefully examined by experts and nothing gets included unless it passes the high standards of the Debian monastery. The process of carefully examining every brick and excluding most has not changed since emacs.
Debian is adding about 500 new (source) package each month. I don't think anyone can even keep-up with this pace and know all what's available. In some ways, there's too many packages in already (especially since many aren't maintained by anyone, and that the QA team has to suffer the burden of it). If you want even more packages to get in, the issue isn't religion. Debian is a do-ocratie: do things, and you'll be right. Here, there's clearly not enough people working on mentoring / sponsoring uploads.
The magic happening in Android, and I hate to admit but iOS too, is they've gone back to the bazaar model where anyone can share any app they like.
And you know what? I'm SOOOOOOOOOO happy that this isn't the case in Debian!!! No, I don't want just any random sh*t to get in the archive. Thanks but no thanks.
However, anyone is enabled to share whatever crap they like as an app in the market. That freedom to share is missing in Debian.
You are free to share crap through a private repository, and advertize about it. But you don't have the freedom to upload anything into main. The first reason for that is at least that we have the need, for legal reasons, to check on the debian/copyright file. By the way, another way of sharing would be PPA, like it happens in Ubuntu. The advantage of PPAs is that you also get the advantage of having your package built on all arch (eg: you use the buildd things from Debian), which would be quite hard to reproduce at home.
Why should my popular fart app suffer because it has bugs that were sensitized by a new libsndfile shared library?
Simple: because we want libsndfile to be FIXED, once and for ALL of it's reverse dependency, and because we care about the distribution as a whole. Your example is pointing at flaws and errors, these should get fixed, that's it, and that's why we got a bug tracker.
If we just run them in their own jails, and never upgrade their shared libraries (except in sever security situations), that fart app should continue to run for decades.
You still don't get it, so I'll try again. So, according to you, if we have 2 applications, then it's ok to have 2 times the same library stored twice, and using twice the amount of RAM that they should. What if that's the case for let's say 1000 apps instead of 2? What if all apps where carrying their own version of libc6, which makes about 20 000 packages in Debian holding their own version of libc6? What if there was a security issue in libc6? Will we have to update ABSOLUTELY ALL the 20000 packages? I don't think that's remotely possible to work this way, unless you find 20 000 new Debian Developers to work this way. The memory usage would go up a lot too. Please don't tell that libc6 isn't a good example: you'll find some others, I'm sure. I could say gtk, qt, alsa, or whatever, there would be just less "users" but the point would be the exact same one. So, NO, what
I completely agree. And from what I have seen so far, the available virtualization systems are all actually less reliable than the same OS run on bare hardware (at least if the OS is Linux;-). That would also imply they are less secure.
Citation needed. Please care showing everyone grave security exploits in Xen (as much as I know, there's none that are very serious if you don't use PCI passthrough, just few hard to exploit DoS).
For that reason, I don't think you can regard virtualization that runs as root as much of a security/isolation gain. It may even represent a net loss, except that the attackers have to invest a bit more into research. But they may gain portable attacks as a benefit.
One thing you seem to fail to understand, is that to get this type of exploit, you'd need to 1/ get root (hard already) then 2/ get to the hypervisor level. So please explain to me how this is LESS safe, when you have 2 layers of exploits to find instead of just one.
Virtualization is just another layer of software to exploit
But it's a WAY smaller than the kernels you may run. On my laptop, Xen is a bit over 650KB, but the initrd image for my kernel is about 11MB. That is, 16 times smaller. I believe that Xen is more than 16 times safer than the kernel, since absolutely zero "root" exploits have been found (if you don't use PCI passthrough, which historically, has been quite worrisome).
Adding more software and bugs does not add security, especially since you're just doing the exact same thing the original OS was supposed to do.
The point is, Xen doesn't. It does only virtualization, not drivers, where most of the security exploits have been found.
So your argument becomes 'I'm better at it than you'
It's not that, I'm afraid. The Linux kernel is full of various useless, but yet exploitable, (often old) device and (often old) protocol drivers, written by various people from various vendors that maybe didn't care much but to do an (as fast as possible) quick and dirty work. Just look at exploits history, and you'll see what I'm talking about. The Xen hypervisor doesn't have to suffer from this at all: the set of contributors is much smaller, the code-base is smaller too.
But that's only one side of it and not the main one. Often, you'd get root on a server because one of the service that is running has flows. Not because of a kernel root exploits. In this case, having things isolated means you'd get root only on a server running a single service. For example, you wouldn't have root access to the MySQL database files if it was installed on another server. And that's the main point everyone is making about security: exploits have limited consequences, since not everything is running on the same server.
What you really need is shared libraries that never change, unless there's a major security flaw detected.
During the life of a particular distribution, you just want fix to bugs and security flows, yes, and that's what happens after a flavor of Debian or Ubuntu is frozen (and then released). But what you don't want to change is the ABI (Application Binary Interface). Even when there's a security flow, you don't want the ABI to change. When there's an ABI change and you have reverse dependency on a library, you got to get in touch with the release team, and make a transition in SID (packages depending on your library wont get migrated until everyone made the transition), and it takes a fair amount of work to have this to happen, but it's really necessary (note: most of the time, a simple binary only upload is enough, since just rebuilding solves the issue if the API didn't change).
When you install, you get hard links in your app's directory to all the exact versions of each shared library they depend on. Any application using the same shared library also has a hard link to it, so it's only on the disk once. With this scheme, while it takes more space, testing requirements drop a ton, you don't break when you upgrade, and you can have multiple versions of apps and libraries installed at the same time.
Not, libraries don't work with symlinks in Linux, but with the SONAME attached to it. Until the SONAME changes, you don't have ABI incompatibility. If this happens, then it's a bug, and you can file a report against the library package (eg: the SONAME must change if there's an ABI incompatibility). If the SONAME stays the same, but the minor version of the library increases, then you're only producing changes without ABI modification (most of the time: fixes or improvements, no new features). If the SONAME changes, then you can normally have multiple versions of the same library installed on the system.
For example, under debian (and by policy, so it's a MUST, if you see an example where it's not the case, please fill a bug report), if you have libfoo in version 3.4.5.2, the SONAME being libfoo3.4, then the corresponding debian package will HAVE to be: libfoo3.4_VERSION_arch.deb (not that the version of the package doesn't have to match the SONAME, but it's often the case, so here the version would be 3.4.5.2-1 for example, with "1" being left for Debian to increase).
Also, running apps in a jail is the way to go. Not that it eliminates threats, but it's a lot better than letting an app see the whole system.
That's another debate (and I agree with your point: jailing/chroot is useful), and it has nothing to do with library version coexistence, or SONAME, or even the fact you think (wrongly) that libraries should be duplicated.
The truth is even on phones space requirements are rapidly becoming a non-issue, and the ease of developing applications is more important than ever.
But again, doing what you wrote doesn't make it more easy for programers. It just makes it a complete nightmare to manage security issues (because if you duplicate libraries, then you got to update all of them, and risk to forget one, or loose track of which one got the fix or not). Also, duplicating libraries mean that you will store them multiple times in memory at runtime, which really, is a big issue (last time I checked, mobile phone are still stuck with not even 1GB of RAM, and even with more on a desktop computer, saving RAM is always good).
Just look at Android, with now over 300K apps, vs Debian with around 30K packages.
In Android, anyone can decide to put one more app in the store, without much checking of usefulness. In Debian, before you can upload a package, a Debian developer will ask what's your motivation to have the package in the archive. For example, if there's already a pack
No! That's bad for performance AND safety of the data. Doing few commands more (which by the way, are very easy to type, and you just need to write them ONCE down), when doing the recovery is nothing compared to the added safety. More over, for many things, you'll need special option, like noatime, which increases a lot read efficiency (for example, you can set that for your/usr, since you wont ever need this information).
By the way, there are only 2 devices that might need further grow:/home and/var. Even without online growing/shrinking, you can umount these without rebooting.
Even with LVM, you still have to find that extra space when you add it
Typically, you'd leave some free space on the volume group, just for that purpose. NO! The space isn't more wasted than using a big, unique, partition. Also, what will you do once your HDD gets full? Easy: add another HDD, add the new space to the volume group, then resize a partition (which will span on more than a single disk, thanks to LVM).
why not just allocate it all at once, shared between/,/bin/lib,/usr etc..
See above. It's a *very* bad newbie way to do things, and that's truth for both a server or a laptop. It's slower not to do it, less safe, and less convenient.
I always asked myself: when we buy a dead tree book, we can lend it to friends. What about e-books? Is there some kind of copyright/licensing that prevents it? Then could we make lending of a paper book forbidden (which I would feel weird about)?
Dumb. Do you have the idea of the size of a 180 minutes, 1080p movie, without compression? I'm not sure this would fit on any HDD you'd have... Anyway, even cutting this debate, trying to re-compress a FLAC is still a totally dumb idea.
The Gnu/Linux file organization is one of the main obstacles to FOSS development. If I want to publish an Android app, I write it this week, and it's in the Market next week. This is because my app will run in a jail where it can only find the files it really needs, in it's own application directory. If I want to provide an Android library (which I have), you just publish your code and people link to it statically. In Debian, you have to do a shared library, meaning you have to do extensive testing for any new release. It's total BS red tape, and it's killing Linux FOSS efforts. It's actually easier to develop FOSS for WIndows.
Actually, shared libraries are handled a way better in Linux than in Windows. In Windows, you can have many versions of the same library, and an app will choose the one it needs. That sux and completely kills the idea of having one, unique, shared library actually really shared between apps. Under Linux, we just need to rebuild, that's easy, and in non-FOSS, you're just stuck with what's available. This shared library system is even more important in embedded systems where space is scarce. Saying that people need to statically link to all libs is just plain stupidity!
Actually, perhaps increasing the diversity of directories might come in handy (like in/usr/i686/lib +/usr/x86-64/lib + whatever you might need, and with eventual optimizations, and with eventual debug).
Note that while large, single mount, flesystems are prevalent these days in the PC
I still consider that this is a newbie way of doing things. First, you should separate/tmp from others, because you don't want any stupid app to fill up your rootfs. Then/var should be separated because it optimizes access and you should take care that it never gets full.
If you have a laptop, then it makes sense to use encryption. In this case, then a separate/home makes a lot of sense (but there's no reason why you would encrypt/usr). Even without encryption, a separate/home also makes sense anyway.
Today most installations have the whole system (/ and/usr) on the same partition
NO! YOU maybe doing it, but not *most* people: you have no statistics to tell (and if you do, please share...).
I don't do that, because of many reasons, like having less access to the rootfs is safer, having my/usr on LVM so that I can resize it, etc. Also, remember that/usr could be mounted read only (if you wanted to), which is quite a nice feature that increases performances quite a lot. Try to do that with the rootfs, and come back to me (I really wish it was possible to mount it read only as well)!
Gosh, don't you know? The sbin dir is for superuser only binaries. The/bin and/sbin are there for vital binaries to be available at boot time, when there's no/usr available.
FYI, most distro have, or are currently moving/var/run to/run, because it's creating issues not to have/var/run at boot time.
Please explain to me how this isn't totally stupid to decide something and it's exact opposite on the exact same year (eg: recognizing that we need stuff at boot time on the rootfs).
Exactly what do you call "things where they should be"? What's your definition?
FYI, not putting something according to the FSHS is considered a bug in Debian (like putting a configuration file somewhere else than/etc, an arch dependent library somewhere else than/usr/lib, or even in/lib when it's not needed at boot time, etc.).
Yes, it's going to go away, but not for the reason you stated. It's going away, because we're moving to a multi-arch system, when libs of many arch can coexist (like armel and armhf, for example, not just x86 stuff).
As in... nowadays, we don't store movies and music compressed??? What performance and characteristics do you imagine doing by re-compressing a file that already has lossful compression?
Nope, because NONE of those apps will work with a touchscreen.
This must be a joke, just try a n900 and see by yourself. Having mobile phone apps and tablet apps available in Linux (Debian/Ubuntu) would also rox (because easy to get the sources, modify, etc.). And by the way, I wonder why you guys always associate "phone" with "virtual keyboard". It's been years I'm only having phones with REAL keyboard, and the worst hardware keyboard you'll find will be light-years ahead of any virtual keyboards, and when I think phone, I always think small hardware keyboard. I don't think I'll ever buy a phone where it's so difficult to type an email. It's already a pain with the size of my hardware keyboard that I often give-up...
Linux has ZERO apps that will work on a phone or tablet, they ALL need to be re-written.
You mean maybe adapted which roughly means arrange things for less space. That's really not a lot of work compared to a full rewrite.
There's tons of apps in Linux that I use every day on my phone. Like for a start on the shell: scp, ssh, xterm, mtr, joe (I don't like vim), host, nmap, and various other networking tools, mplayer. Then as GUI: openvpn, gpodder (to listen to podcasts in the car), vlc (all of them had very minor GUI rewrite).
Again, I'm not saying it's an approach for the majority, it might not even be good for YOU, but I DO like it, and I DO want such phone. You can say you wouldn't like it, but please don't say "zero apps" or "linux isn't adapted", because for some (like me), IT IS, and I really don't care the fuck about the 200000 apps with 99% of them being useless. The n900 repo is also bloated with so many crappy stupid apps, backgrounds, themes, etc. which are on the way to serious software/packages and its more a nuisance than anything else to ME (eg: I can understand it might fit others).
Ah? You don't care browsing the web (firefox, chromium, etc.), reading emails (many clients), watching videos (VLC, mplayer), listening to mp3, chatting with friends (pidgin, telepathy, irc, etc.), using SIP (many apps), transfering files (ftp, scp, etc.) with clients proven to be good? Plus all the shell tools exactly like in your workstation, that's quite a cool thing to have in your pocket. Maybe you also don't care reading attached PDF or word/openoffice document with a decent reader?
I mean, really, how are you going to use XEmacs on a tablet?
I don't expect to do the same things in a tablet that I do on my laptop. I also do expect the environment to be different, and adapted to the use in a tablet. I don't want a Debian gnome 2 desktop for example. Hildon desktop on the n900 is ok-ish on such device, but I'm sure it is possible to do better.
Yes. https://elektranox.org/n900/
The only problem with Debian on a phone is that you don't have much applications for the phone itself (eg: make phone calls, use sms, etc.), and the real work to be done is there.
Slashdot Mirror
In 7 years of using Xen (since 2.07) and selling VPS, I've seen many things crash, but never the network stack of Xen, which I believe was the part that was the most easy to virtualize, and that has been reliable for years. Now, maybe with Qemu, but I don't use it (I use PV).
You do realize that with hard links, a file can be in multiple directories and stored on both disk once?
I do. And I also realize that they don't work over multiple partitions. Anyway, using hardlinks instead of SONAMEs isn't the correct solution. SONAME are working well, and we're fine with them, we don't need the hardlinks on top of that, so why bother changing something that works already very well? In what exactly, adding hardlinks, will help? Should we completely redesign shared libs, and remove SONAMEs then?
However, if two applications downloaded and installed through an App Center were compiled with different versions of libc, then yes, have two on the disk. How many are we realistically talking about, given that we're not talking about the stuff that comes pre-installed or anything in any .deb file? Several megabytes? In an extreme case maybe a gigabyte of disk space?
If someone wants to do what you are saying above, then he can simply do static linking. So I don't see your point.
Since apps would run in jails, you'd only want to upgrade the apps needing the functionality that's broken. For example, if my app does not have permission to use the network, you should not upgrade my copy of libc6 to fix a major network security bug. Again, we're talking about user apps, not the base shipped by Debian. How many packages are we likely talking about? 10 mabye?
You're just trying to find an example that matches your argument, but I don't think that works. What if we REALLY find a bug affecting them ALL?
Anyway, currently, you HAVE some vendors that are shipping statically apps. Try installing google earth on Linux, for example. It's one binary for all distro, and to be installed under ~/bin. But frankly, I don't like it... It's like that for only one reason: because we don't have the sources, and we can't rebuild.
I didn't want to get into this much detail, but you are right. Libc isn't a representative case. If I make a simple command line utility, it should by default link against an older libc to be compatible with as many distros as possible.
This is not the way things work. Do this: objdump /lib/libc.so.6 -p | grep SONAME. This tells the SONAME of the libc. If you do something and dynamically link it to libc, then it has to have the matching SONAME of the system one, otherwise at runtime, it wont be able to use the functionality of libc. There's nothing such backward compatibility here. Either you have a matching SONAME pair, either you don't. End of the story.
High level packages like Qt should be published by the developers in occasional stable releases not only in source form, but in binary, all the way down to libc. When building a Qt app, I should be able to specify that I link against an exact version of Qt, which of course could mean users have do to a major download if they don't have it already, or I could specify that it must be a version of Qt 4.x, where x >= 7. It should also indicate that it was built and tested with Qt 4.7 with the full SHA-256 hash code of the Qt library used, so if users have trouble running it with Qt 4.9, they can run it instead with the original 4.7.
Again, that's not the way it works. When you build a library, you give something like this to gcc: -Wl,-soname,libfoo.so.1.0 :)
Then your library will have libfoo1.0 as soname. There's no such things such as >= libfoo1.0, it has to be AN EXACT MATCH. It has to, that's the way library works. If you think it shouldn't, feel free to contribute to the GNU compiler...
Then under Debian, there's dh_shlibdeps that will collect dependencies for each library you have built against. That's an automatic process, and you shouldn't care too much about it, but what you got to know is that it will, by default, and IIRC, do Depends: libbar1 (>= VERSION-INSTAL
Since it seems you didn't get it, let me explain again. Let's say you need to run service A, B and C. If you don't have virtualization, you'd run them all on the same server. Then if A, B and C are each running as their own user, you need to get an attack vector on let's say A, get root, then you can affect B and C. If you have virtualization isolating A, B and C, each on their VM, then you need to find an attack vector in A, get root, then find an exploit in the hypervisor if you want to reach B or C. That's one more step, hence the added security.
As for what Xen does, I think you are really missing a lot of parts in the PC architecture that needs to get virtualized (like APIC, MSI, console, serial, the paravirtualized drivers themselves, etc.).
As for the python code, it's slowly fading away, being replaced by Ocaml code (see xl replacing xm).
That said, my goal is to get GNU/Linux developers and the Debian devs in particular to wake up to the fact that we've built a cathedral when we need a bazaar. As you've likely read in the paper by that title
Of course I know the Cathedral and the Bazaar. I believe that Debian is a mix of both methods, since we release SID 4 times a day, and stable each 2 years based on that.
That was the bazaar, and it's where the heart and sole of GNU/Linux was created.
I'd say that's what Linux is doing now (but do you remember the Linux 2.5 development version?), I'm not so sure about GNU and the GNU tools.
The problem is that this binary repository is managed lovingly by devoted monks. Every brick is carefully examined by experts and nothing gets included unless it passes the high standards of the Debian monastery. The process of carefully examining every brick and excluding most has not changed since emacs.
Debian is adding about 500 new (source) package each month. I don't think anyone can even keep-up with this pace and know all what's available. In some ways, there's too many packages in already (especially since many aren't maintained by anyone, and that the QA team has to suffer the burden of it). If you want even more packages to get in, the issue isn't religion. Debian is a do-ocratie: do things, and you'll be right. Here, there's clearly not enough people working on mentoring / sponsoring uploads.
The magic happening in Android, and I hate to admit but iOS too, is they've gone back to the bazaar model where anyone can share any app they like.
And you know what? I'm SOOOOOOOOOO happy that this isn't the case in Debian!!! No, I don't want just any random sh*t to get in the archive. Thanks but no thanks.
However, anyone is enabled to share whatever crap they like as an app in the market. That freedom to share is missing in Debian.
You are free to share crap through a private repository, and advertize about it. But you don't have the freedom to upload anything into main. The first reason for that is at least that we have the need, for legal reasons, to check on the debian/copyright file. By the way, another way of sharing would be PPA, like it happens in Ubuntu. The advantage of PPAs is that you also get the advantage of having your package built on all arch (eg: you use the buildd things from Debian), which would be quite hard to reproduce at home.
Why should my popular fart app suffer because it has bugs that were sensitized by a new libsndfile shared library?
Simple: because we want libsndfile to be FIXED, once and for ALL of it's reverse dependency, and because we care about the distribution as a whole. Your example is pointing at flaws and errors, these should get fixed, that's it, and that's why we got a bug tracker.
If we just run them in their own jails, and never upgrade their shared libraries (except in sever security situations), that fart app should continue to run for decades.
You still don't get it, so I'll try again. So, according to you, if we have 2 applications, then it's ok to have 2 times the same library stored twice, and using twice the amount of RAM that they should. What if that's the case for let's say 1000 apps instead of 2? What if all apps where carrying their own version of libc6, which makes about 20 000 packages in Debian holding their own version of libc6? What if there was a security issue in libc6? Will we have to update ABSOLUTELY ALL the 20000 packages? I don't think that's remotely possible to work this way, unless you find 20 000 new Debian Developers to work this way. The memory usage would go up a lot too. Please don't tell that libc6 isn't a good example: you'll find some others, I'm sure. I could say gtk, qt, alsa, or whatever, there would be just less "users" but the point would be the exact same one. So, NO, what
I completely agree. And from what I have seen so far, the available virtualization systems are all actually less reliable than the same OS run on bare hardware (at least if the OS is Linux ;-). That would also imply they are less secure.
Citation needed. Please care showing everyone grave security exploits in Xen (as much as I know, there's none that are very serious if you don't use PCI passthrough, just few hard to exploit DoS).
For that reason, I don't think you can regard virtualization that runs as root as much of a security/isolation gain. It may even represent a net loss, except that the attackers have to invest a bit more into research. But they may gain portable attacks as a benefit.
One thing you seem to fail to understand, is that to get this type of exploit, you'd need to 1/ get root (hard already) then 2/ get to the hypervisor level. So please explain to me how this is LESS safe, when you have 2 layers of exploits to find instead of just one.
Virtualization is just another layer of software to exploit
But it's a WAY smaller than the kernels you may run. On my laptop, Xen is a bit over 650KB, but the initrd image for my kernel is about 11MB. That is, 16 times smaller. I believe that Xen is more than 16 times safer than the kernel, since absolutely zero "root" exploits have been found (if you don't use PCI passthrough, which historically, has been quite worrisome).
Adding more software and bugs does not add security, especially since you're just doing the exact same thing the original OS was supposed to do.
The point is, Xen doesn't. It does only virtualization, not drivers, where most of the security exploits have been found.
So your argument becomes 'I'm better at it than you'
It's not that, I'm afraid. The Linux kernel is full of various useless, but yet exploitable, (often old) device and (often old) protocol drivers, written by various people from various vendors that maybe didn't care much but to do an (as fast as possible) quick and dirty work. Just look at exploits history, and you'll see what I'm talking about. The Xen hypervisor doesn't have to suffer from this at all: the set of contributors is much smaller, the code-base is smaller too.
But that's only one side of it and not the main one. Often, you'd get root on a server because one of the service that is running has flows. Not because of a kernel root exploits. In this case, having things isolated means you'd get root only on a server running a single service. For example, you wouldn't have root access to the MySQL database files if it was installed on another server. And that's the main point everyone is making about security: exploits have limited consequences, since not everything is running on the same server.
What you really need is shared libraries that never change, unless there's a major security flaw detected.
During the life of a particular distribution, you just want fix to bugs and security flows, yes, and that's what happens after a flavor of Debian or Ubuntu is frozen (and then released). But what you don't want to change is the ABI (Application Binary Interface). Even when there's a security flow, you don't want the ABI to change. When there's an ABI change and you have reverse dependency on a library, you got to get in touch with the release team, and make a transition in SID (packages depending on your library wont get migrated until everyone made the transition), and it takes a fair amount of work to have this to happen, but it's really necessary (note: most of the time, a simple binary only upload is enough, since just rebuilding solves the issue if the API didn't change).
When you install, you get hard links in your app's directory to all the exact versions of each shared library they depend on. Any application using the same shared library also has a hard link to it, so it's only on the disk once. With this scheme, while it takes more space, testing requirements drop a ton, you don't break when you upgrade, and you can have multiple versions of apps and libraries installed at the same time.
Not, libraries don't work with symlinks in Linux, but with the SONAME attached to it. Until the SONAME changes, you don't have ABI incompatibility. If this happens, then it's a bug, and you can file a report against the library package (eg: the SONAME must change if there's an ABI incompatibility). If the SONAME stays the same, but the minor version of the library increases, then you're only producing changes without ABI modification (most of the time: fixes or improvements, no new features). If the SONAME changes, then you can normally have multiple versions of the same library installed on the system.
For example, under debian (and by policy, so it's a MUST, if you see an example where it's not the case, please fill a bug report), if you have libfoo in version 3.4.5.2, the SONAME being libfoo3.4, then the corresponding debian package will HAVE to be: libfoo3.4_VERSION_arch.deb (not that the version of the package doesn't have to match the SONAME, but it's often the case, so here the version would be 3.4.5.2-1 for example, with "1" being left for Debian to increase).
Also, running apps in a jail is the way to go. Not that it eliminates threats, but it's a lot better than letting an app see the whole system.
That's another debate (and I agree with your point: jailing/chroot is useful), and it has nothing to do with library version coexistence, or SONAME, or even the fact you think (wrongly) that libraries should be duplicated.
The truth is even on phones space requirements are rapidly becoming a non-issue, and the ease of developing applications is more important than ever.
But again, doing what you wrote doesn't make it more easy for programers. It just makes it a complete nightmare to manage security issues (because if you duplicate libraries, then you got to update all of them, and risk to forget one, or loose track of which one got the fix or not). Also, duplicating libraries mean that you will store them multiple times in memory at runtime, which really, is a big issue (last time I checked, mobile phone are still stuck with not even 1GB of RAM, and even with more on a desktop computer, saving RAM is always good).
Just look at Android, with now over 300K apps, vs Debian with around 30K packages.
In Android, anyone can decide to put one more app in the store, without much checking of usefulness. In Debian, before you can upload a package, a Debian developer will ask what's your motivation to have the package in the archive. For example, if there's already a pack
Just make your root filesystem 40GB and move on.
No! That's bad for performance AND safety of the data. Doing few commands more (which by the way, are very easy to type, and you just need to write them ONCE down), when doing the recovery is nothing compared to the added safety. More over, for many things, you'll need special option, like noatime, which increases a lot read efficiency (for example, you can set that for your /usr, since you wont ever need this information).
/home and /var. Even without online growing/shrinking, you can umount these without rebooting.
By the way, there are only 2 devices that might need further grow:
Even with LVM, you still have to find that extra space when you add it
Typically, you'd leave some free space on the volume group, just for that purpose. NO! The space isn't more wasted than using a big, unique, partition. Also, what will you do once your HDD gets full? Easy: add another HDD, add the new space to the volume group, then resize a partition (which will span on more than a single disk, thanks to LVM).
why not just allocate it all at once, shared between /, /bin /lib, /usr etc..
See above. It's a *very* bad newbie way to do things, and that's truth for both a server or a laptop. It's slower not to do it, less safe, and less convenient.
I always asked myself: when we buy a dead tree book, we can lend it to friends. What about e-books? Is there some kind of copyright/licensing that prevents it? Then could we make lending of a paper book forbidden (which I would feel weird about)?
Dumb. Do you have the idea of the size of a 180 minutes, 1080p movie, without compression? I'm not sure this would fit on any HDD you'd have... Anyway, even cutting this debate, trying to re-compress a FLAC is still a totally dumb idea.
The Gnu/Linux file organization is one of the main obstacles to FOSS development. If I want to publish an Android app, I write it this week, and it's in the Market next week. This is because my app will run in a jail where it can only find the files it really needs, in it's own application directory. If I want to provide an Android library (which I have), you just publish your code and people link to it statically. In Debian, you have to do a shared library, meaning you have to do extensive testing for any new release. It's total BS red tape, and it's killing Linux FOSS efforts. It's actually easier to develop FOSS for WIndows.
Actually, shared libraries are handled a way better in Linux than in Windows. In Windows, you can have many versions of the same library, and an app will choose the one it needs. That sux and completely kills the idea of having one, unique, shared library actually really shared between apps. Under Linux, we just need to rebuild, that's easy, and in non-FOSS, you're just stuck with what's available. This shared library system is even more important in embedded systems where space is scarce. Saying that people need to statically link to all libs is just plain stupidity!
Actually, perhaps increasing the diversity of directories might come in handy (like in /usr/i686/lib + /usr/x86-64/lib + whatever you might need, and with eventual optimizations, and with eventual debug).
Actually, what you want is multi-arch support.
With your solution, you either waste space, or risk making one of the partitons too small for future needs.
Ever heard about LVM? :)
Note that while large, single mount, flesystems are prevalent these days in the PC
I still consider that this is a newbie way of doing things. First, you should separate /tmp from others, because you don't want any stupid app to fill up your rootfs. Then /var should be separated because it optimizes access and you should take care that it never gets full.
/home makes a lot of sense (but there's no reason why you would encrypt /usr). Even without encryption, a separate /home also makes sense anyway.
If you have a laptop, then it makes sense to use encryption. In this case, then a separate
Today most installations have the whole system (/ and /usr) on the same partition
NO! YOU maybe doing it, but not *most* people: you have no statistics to tell (and if you do, please share...).
/usr on LVM so that I can resize it, etc. Also, remember that /usr could be mounted read only (if you wanted to), which is quite a nice feature that increases performances quite a lot. Try to do that with the rootfs, and come back to me (I really wish it was possible to mount it read only as well)!
I don't do that, because of many reasons, like having less access to the rootfs is safer, having my
Gosh, don't you know? The sbin dir is for superuser only binaries. The /bin and /sbin are there for vital binaries to be available at boot time, when there's no /usr available.
/var/run to /run, because it's creating issues not to have /var/run at boot time.
FYI, most distro have, or are currently moving
Please explain to me how this isn't totally stupid to decide something and it's exact opposite on the exact same year (eg: recognizing that we need stuff at boot time on the rootfs).
Exactly what do you call "things where they should be"? What's your definition?
/etc, an arch dependent library somewhere else than /usr/lib, or even in /lib when it's not needed at boot time, etc.).
FYI, not putting something according to the FSHS is considered a bug in Debian (like putting a configuration file somewhere else than
Yes, it's going to go away, but not for the reason you stated. It's going away, because we're moving to a multi-arch system, when libs of many arch can coexist (like armel and armhf, for example, not just x86 stuff).
No, the way to fix it is the multi-arch thing of Debian (SID), which we are all migrating (painfully) to.
As in... nowadays, we don't store movies and music compressed??? What performance and characteristics do you imagine doing by re-compressing a file that already has lossful compression?
Nope, because NONE of those apps will work with a touchscreen.
This must be a joke, just try a n900 and see by yourself. Having mobile phone apps and tablet apps available in Linux (Debian/Ubuntu) would also rox (because easy to get the sources, modify, etc.). And by the way, I wonder why you guys always associate "phone" with "virtual keyboard". It's been years I'm only having phones with REAL keyboard, and the worst hardware keyboard you'll find will be light-years ahead of any virtual keyboards, and when I think phone, I always think small hardware keyboard. I don't think I'll ever buy a phone where it's so difficult to type an email. It's already a pain with the size of my hardware keyboard that I often give-up ...
Linux has ZERO apps that will work on a phone or tablet, they ALL need to be re-written.
You mean maybe adapted which roughly means arrange things for less space. That's really not a lot of work compared to a full rewrite.
There's tons of apps in Linux that I use every day on my phone. Like for a start on the shell: scp, ssh, xterm, mtr, joe (I don't like vim), host, nmap, and various other networking tools, mplayer. Then as GUI: openvpn, gpodder (to listen to podcasts in the car), vlc (all of them had very minor GUI rewrite).
Again, I'm not saying it's an approach for the majority, it might not even be good for YOU, but I DO like it, and I DO want such phone. You can say you wouldn't like it, but please don't say "zero apps" or "linux isn't adapted", because for some (like me), IT IS, and I really don't care the fuck about the 200000 apps with 99% of them being useless. The n900 repo is also bloated with so many crappy stupid apps, backgrounds, themes, etc. which are on the way to serious software/packages and its more a nuisance than anything else to ME (eg: I can understand it might fit others).
Ah? You don't care browsing the web (firefox, chromium, etc.), reading emails (many clients), watching videos (VLC, mplayer), listening to mp3, chatting with friends (pidgin, telepathy, irc, etc.), using SIP (many apps), transfering files (ftp, scp, etc.) with clients proven to be good? Plus all the shell tools exactly like in your workstation, that's quite a cool thing to have in your pocket. Maybe you also don't care reading attached PDF or word/openoffice document with a decent reader?
I mean, really, how are you going to use XEmacs on a tablet?
I don't expect to do the same things in a tablet that I do on my laptop. I also do expect the environment to be different, and adapted to the use in a tablet. I don't want a Debian gnome 2 desktop for example. Hildon desktop on the n900 is ok-ish on such device, but I'm sure it is possible to do better.
If you think that Debian will entice regular people to a tablet
No, I don't think that way. I have *never* claimed that it would be a successful product. I just wrote I would love to have one.
Yes. https://elektranox.org/n900/
The only problem with Debian on a phone is that you don't have much applications for the phone itself (eg: make phone calls, use sms, etc.), and the real work to be done is there.