[opensuse] Separate /usr?
For many years I've been running successive versions of openSUSE with a /usr partition separate from the root partition /. But I see that the Fedora manuals insist that the practice of separating these two filesystems can lead to dire results. I note, too, that there was a problem with this in the early drops oS 12.2 Is there a problem here, or a potential problem, in openSUSE? Or can I continue to separate these two filesystems with confidence? -- Robin K Wellington "Harbour City" New Zealand -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Thursday, August 09, 2012 23:54:47 Robin Klitscher wrote:
For many years I've been running successive versions of openSUSE with a /usr partition separate from the root partition /. But I see that the Fedora manuals insist that the practice of separating these two filesystems can lead to dire results. I note, too, that there was a problem with this in the early drops oS 12.2
Is there a problem here, or a potential problem, in openSUSE? Or can I continue to separate these two filesystems with confidence?
WE have put measures into place so that you can continue to use /usr as a separate partition. On the other hand, going forward I suggest to not setup a separate /usr anymore, there's no benefit in it. Andreas -- Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn,Jennifer Guild,Felix Imendörffer,HRB16746 (AG Nürnberg) GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 09/08/12 23:59, Andreas Jaeger wrote:
On Thursday, August 09, 2012 23:54:47 Robin Klitscher wrote:
For many years I've been running successive versions of openSUSE with a /usr partition separate from the root partition /. But I see that the Fedora manuals insist that the practice of separating these two filesystems can lead to dire results. I note, too, that there was a problem with this in the early drops oS 12.2
Is there a problem here, or a potential problem, in openSUSE? Or can I continue to separate these two filesystems with confidence?
WE have put measures into place so that you can continue to use /usr as a separate partition.
On the other hand, going forward I suggest to not setup a separate /usr anymore, there's no benefit in it.
Andreas
Thank you. That's all I needed to know. -- Robin K Wellington "Harbour City" New Zealand -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Andreas Jaeger said the following on 08/09/2012 07:59 AM:
On the other hand, going forward I suggest to not setup a separate /usr anymore, there's no benefit in it.
Backups? More to the point, management of backups. Oh, right, you've got some Sony DAT tape thing that can take half a terabyte and a budget for an endless supply of tapes ... Unlike many of us ... -- Doubt is not a pleasant condition, but certainty is absurd. -- Voltaire -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Thursday, August 09, 2012 08:38:14 Anton Aylward wrote:
Andreas Jaeger said the following on 08/09/2012 07:59 AM:
On the other hand, going forward I suggest to not setup a separate /usr anymore, there's no benefit in it.
Backups? More to the point, management of backups.
Oh, right, you've got some Sony DAT tape thing that can take half a terabyte and a budget for an endless supply of tapes ...
Unlike many of us ...
I don't understand how a separate /usr helps with backups. Could you elaborate, please? Andreas -- Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn,Jennifer Guild,Felix Imendörffer,HRB16746 (AG Nürnberg) GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Andreas Jaeger said the following on 08/09/2012 08:42 AM:
On Thursday, August 09, 2012 08:38:14 Anton Aylward wrote:
Andreas Jaeger said the following on 08/09/2012 07:59 AM:
On the other hand, going forward I suggest to not setup a separate /usr anymore, there's no benefit in it.
Backups? More to the point, management of backups.
Oh, right, you've got some Sony DAT tape thing that can take half a terabyte and a budget for an endless supply of tapes ...
Unlike many of us ...
I don't understand how a separate /usr helps with backups. Could you elaborate, please?
Ah, you're thinking in terms of backup by tree, by file walking. And copying live files. Perhaps while they are open. Or and index and data pair getting copied 'out of sync'. Risky. Think about it. As I keep saying, I use LVM, so my idea of a backup is a snapshot of a 'partition'. More atomic. I try to get my partitions to be around 5G so that I can copy the snapshots to DVD. Why? Because most machines these days, laptops included, come with DVD burners. Not everyone is in a corporate setting. Not everyone can afford corporate style backup facilities. DVDs are easy. Snapshots & burn is easy to automate for a home user, a SMB. The result is a DVD that has a mountable file system, so retrieving files is easy. Arguments I don't want to get into: * Will DVDs outlive/outlast tape? * Are DVDs more robust than tape? * Will solar flares .. Oh never mind. -- Few problems cannot be solved by proper application of high explosives. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Anton Aylward wrote:
Andreas Jaeger said the following on 08/09/2012 08:42 AM:
On Thursday, August 09, 2012 08:38:14 Anton Aylward wrote:
Andreas Jaeger said the following on 08/09/2012 07:59 AM:
On the other hand, going forward I suggest to not setup a separate /usr anymore, there's no benefit in it. Backups? More to the point, management of backups.
Oh, right, you've got some Sony DAT tape thing that can take half a terabyte and a budget for an endless supply of tapes ...
Unlike many of us ... I don't understand how a separate /usr helps with backups. Could you elaborate, please?
Ah, you're thinking in terms of backup by tree, by file walking. And copying live files. Perhaps while they are open. Or and index and data pair getting copied 'out of sync'. Risky. Think about it.
As I keep saying, I use LVM, so my idea of a backup is a snapshot of a 'partition'. More atomic.
The two ideas are orthogonal. You can snapshot the LVM and then backup selected files just as you would with live files.
I try to get my partitions to be around 5G so that I can copy the snapshots to DVD.
But again, you just need to select 5 GB of files, not complete partitions.
The result is a DVD that has a mountable file system, so retrieving files is easy.
And so is a DVD produced in the way I describe. You're (presumably) going to be mounting the backup filesystem at some place such as /mnt/backup, not in the original position (e.g. /usr) if you want to recover some or all files. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Dave Howorth said the following on 08/09/2012 09:12 AM:
Anton Aylward wrote:
The two ideas are orthogonal. You can snapshot the LVM and then backup selected files just as you would with live files.
Yes but why? It seems very fiddle-fiddle. Look: many people forget about backups. We know its one of the "sore points" in administration, even in serious corporate settings. Yes, I've seem first tier banks and other major corporate entities screw up their backups and their backup/restore for various reasons. So why add aggravation? Forget the fiddle-fiddle: AUTOMATE! And to automate you want to have set procedures that are SIMPLE and RELIABLE and can't go wrong. Of course you may like fiddle-fiddle, you make like showing of your geek street cred with such virtuoso. YMMV.
I try to get my partitions to be around 5G so that I can copy the snapshots to DVD.
But again, you just need to select 5 GB of files, not complete partitions.
Fiddle-fiddle. Sorry, I'll take SIMPLIFY. Doing the partition I'm sure I've not missed anything :-) No "oops" in the patterns .... -- I would rather try to persuade a man to go along, because once I have persuaded him he will stick. If I scare him, he will stay just as long as he is scared, and then he is gone. Dwight D. Eisenhower -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Thursday 09 August 2012, Andreas Jaeger wrote:
On Thursday, August 09, 2012 08:38:14 Anton Aylward wrote:
Andreas Jaeger said the following on 08/09/2012 07:59 AM:
On the other hand, going forward I suggest to not setup a separate /usr anymore, there's no benefit in it.
Backups? More to the point, management of backups.
Oh, right, you've got some Sony DAT tape thing that can take half a terabyte and a budget for an endless supply of tapes ...
Unlike many of us ...
I don't understand how a separate /usr helps with backups. Could you elaborate, please?
If one prefers to backup whole file systems rather than dealing with directory trees and complicated/dangerous in/exclude rules then it might help to keep it small by separating /usr. Another point would be if you share /usr read-only across many machines then you have to backup only one /usr. cu, Rudi -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Ruediger Meier said the following on 08/09/2012 09:08 AM:
If one prefers to backup whole file systems rather than dealing with directory trees and complicated/dangerous in/exclude rules then it might help to keep it small by separating /usr. Another point would be if you share /usr read-only across many machines then you have to backup only one /usr.
We can take this a bit further. There's a lot under /usr that is protected. If you are using thin clients, LXE boot, and just about everything lives on the server, or perhaps the Windows/SAMBA equivalent (Hi Lynn) then its even possible that the NFS source isn't all on the same machine! We can clearly identify thing like /usr/share which seem to have been designed to be shared in this way. Logically at least even non-think machines can share that resource. There may be development libraries which it is easier to keep updated at a single point: /usr/lib/ruby, or if you are obsessive many of the library directories under /usr/lib. There may also be shared resources like corporate cryptographic keys. There are many good reasons to partition your data. Its why I'm very dubious about BtrFS. -- The price of liberty is eternal vigilance. --Thomas Jefferson -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Anton Aylward wrote:
We can clearly identify thing like /usr/share which seem to have been designed to be shared in this way. Logically at least even non-think machines can share that resource.
Not sure what a 'non-think' machine is, but certainly machines with different hardware architectures can share those directories.
There may be development libraries which it is easier to keep updated at a single point: /usr/lib/ruby, or if you are obsessive many of the library directories under /usr/lib.
IMHO, it is better to keep local copies of libraries, mainly for performance reasons. In the case of development libraries there are likely to be different versions in dev, test & production and careful and comprehensive version management should be in place.
There may also be shared resources like corporate cryptographic keys.
And you want to trust those to NFS :) You're avvin a larf, aincha? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Dave Howorth said the following on 08/09/2012 09:55 AM:
Anton Aylward wrote:
We can clearly identify thing like /usr/share which seem to have been designed to be shared in this way. Logically at least even non-think machines can share that resource.
Not sure what a 'non-think' machine is, but certainly machines with different hardware architectures can share those directories.
sorry: typo - "non-THIN". You recall I had been discussing 'thin clients'
There may be development libraries which it is easier to keep updated at a single point: /usr/lib/ruby, or if you are obsessive many of the library directories under /usr/lib.
IMHO, it is better to keep local copies of libraries, mainly for performance reasons. In the case of development libraries there are likely to be different versions in dev, test & production and careful and comprehensive version management should be in place.
YMMV. When I'm deal with large institutional clients I address the problems differently from SMBs and one man shops. Not everyone had a dedicated IT department, a dedicated ITIL trained staff, a dedicated InfoSec department and trained staff, and so forth. As I keep saying Context is Everything
There may also be shared resources like corporate cryptographic keys.
And you want to trust those to NFS :) You're avvin a larf, aincha?
Oh most certainly. At home. On my server. So when I take my laptop or smartphone or pad away the key stays at home. And no it can't be accessed by wifi and no it can't be accessed by NFS other than from a known machine (MAC) after mounting the crypto partition with 34 character passphrase that is not recorded anywhere. Go on, laugh. -- All articles that coruscate with resplendence are not truly auriferous. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Thu, 2012-08-09 at 14:55 +0100, Dave Howorth wrote:
Anton Aylward wrote:
We can clearly identify thing like /usr/share which seem to have been designed to be shared in this way. Logically at least even non-think machines can share that resource. Not sure what a 'non-think' machine is, but certainly machines with different hardware architectures can share those directories.
He means non-thin.
There may be development libraries which it is easier to keep updated at a single point: /usr/lib/ruby, or if you are obsessive many of the library directories under /usr/lib. IMHO, it is better to keep local copies of libraries, mainly for performance reasons. In the case of development libraries there are likely to be different versions in dev, test & production and careful and comprehensive version management should be in place.
+1, this shared /usr parts thing is ancient thinking. It never had anything to do with anything other than disks-are-expensive. They aren't anymore. Even when I managed thin clients I rolled an NFS root for each client. *MUCH* easier to manage. Then updates can be rolled out rather than slam-dunked [fun - break everyone at once!]. And the filesystem for thin clients these days will easily fit on a flash drive - local, faster, and less network dependent. Update schemes and package management is *FAR* superior to even 10 years ago and light years more advanced than what was available back in the disks-are-expensive days. Let the package management work, let volume management or sub-volume [butter style] management work for use. These are all around superior techniques.
There may also be shared resources like corporate cryptographic keys. And you want to trust those to NFS :) You're avvin a larf, aincha?
+1
Anton Aylward wrote:
Andreas Jaeger said the following on 08/09/2012 07:59 AM:
On the other hand, going forward I suggest to not setup a separate /usr anymore, there's no benefit in it.
Backups? More to the point, management of backups.
Oh, right, you've got some Sony DAT tape thing that can take half a terabyte and a budget for an endless supply of tapes ...
Unlike many of us ...
Just use dirvish or one of the many other backup programs that will back up arbitrary parts of your file tree. In the case of dirvish, you can use any pattern that rsync understands to choose files, and use as many patterns as you want. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Dave Howorth said the following on 08/09/2012 08:43 AM:
Just use dirvish or one of the many other backup programs that will back up arbitrary parts of your file tree. In the case of dirvish, you can use any pattern that rsync understands to choose files, and use as many patterns as you want.
The operative thing here is 'FILE TREE". What if you have a high performance database (e,g, MySQL) that uses a raw partition? Or some other application. What if you're backing up an encrypted partition in its raw form? (Rather than a set of individually encrypted files or a file that is going to be mounted with losetup.) And "back up onto what?" Oh, right, a DVD. But then you have to build the ISO image of the tree you've copied/built using RSYNC. Or tape? Well OK, some people like having lots of programs to fiddle with, scripts, config files, GUIs. I don't. So bite me. -- Life's a bitch. Then you die. Then you get re-incarnated and it starts all over again only worse. And it doesn't matter if you don't believe in reincarnation, Life's still a bitch. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Thu, 2012-08-09 at 09:11 -0400, Anton Aylward wrote:
Dave Howorth said the following on 08/09/2012 08:43 AM:
Just use dirvish or one of the many other backup programs that will back up arbitrary parts of your file tree. In the case of dirvish, you can use any pattern that rsync understands to choose files, and use as many patterns as you want. The operative thing here is 'FILE TREE". What if you have a high performance database (e,g, MySQL) that uses a raw partition? Or some other application. What if you're backing up an encrypted partition in its raw form? (Rather than a set of individually encrypted files or a file that is going to be mounted with losetup.) And "back up onto what?"
Sorry, I miss whatever this has to do with /usr being a separate partition or not? Certainly raw partitions have no bearing on that.
Anton Aylward wrote:
Andreas Jaeger said the following on 08/09/2012 07:59 AM:
On the other hand, going forward I suggest to not setup a separate /usr anymore, there's no benefit in it. Backups? More to the point, management of backups.
Oh, right, you've got some Sony DAT tape thing that can take half a terabyte and a budget for an endless supply of tapes ...
Unlike many of us ...
Is there really any need to back up /usr, unless you want a full "bare metal" restore? Of course, there's no reason why you can't back up individual subdirectories if needed. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
James Knott said the following on 08/09/2012 09:49 AM:
Anton Aylward wrote:
Andreas Jaeger said the following on 08/09/2012 07:59 AM:
On the other hand, going forward I suggest to not setup a separate /usr anymore, there's no benefit in it. Backups? More to the point, management of backups.
Oh, right, you've got some Sony DAT tape thing that can take half a terabyte and a budget for an endless supply of tapes ...
Unlike many of us ...
Is there really any need to back up /usr, unless you want a full "bare metal" restore? Of course, there's no reason why you can't back up individual subdirectories if needed.
I've met many managers/sysadmins who *DO* want to do full 'bare metal' restores, usually in the belief that its fast and has a lower impact on operations. They were all proven wrong because the normal business processes required other backup/restore strategies such as of a project or project specific database (which happened to be on a raw partition). As it happens I do a lot of work in scripting languages, Ruby, Perl, and update the libraries under /usr/lib. For me its worth having mountable partitions for those so I can 'wipe' the basic /usr and hence /usr/lib but retail my enhancements. -- IOException: Jovian moons misaligned. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Thu, 2012-08-09 at 09:49 -0400, James Knott wrote:
Andreas Jaeger said the following on 08/09/2012 07:59 AM:
On the other hand, going forward I suggest to not setup a separate /usr anymore, there's no benefit in it. Backups? More to the point, management of backups. Oh, right, you've got some Sony DAT tape thing that can take half a terabyte and a budget for an endless supply of tapes ... Unlike many of us ... Is there really any need to back up /usr, unless you want a full "bare
Anton Aylward wrote: metal" restore? Of course, there's no reason why you can't back up individual subdirectories if needed.
Not really. And if your / is on LVM you can snapshot it, and backup the snapshot. Or if you are using butter you can do it's equivalent of the same thing. But /usr being a separate partition or not really doesn't have any bearing on that. Unless, possibly, somebody is actually still using dump / restore? In which case, ugh, just stop doing that.
On Thu, 2012-08-09 at 13:59 +0200, Andreas Jaeger wrote:
On Thursday, August 09, 2012 23:54:47 Robin Klitscher wrote:
For many years I've been running successive versions of openSUSE with a /usr partition separate from the root partition /. But I see that the Fedora manuals insist that the practice of separating these two filesystems can lead to dire results. I note, too, that there was a problem with this in the early drops oS 12.2 Is there a problem here, or a potential problem, in openSUSE? Or can I continue to separate these two filesystems with confidence? WE have put measures into place so that you can continue to use /usr as a separate partition. On the other hand, going forward I suggest to not setup a separate /usr anymore, there's no benefit in it.
+1 I make a separate /boot, sometimes a separate /tmp, often a separate /var/spool and /var/lib [depending on the purpose of the box]. /srv and /home are always separate. I don't see any upside to a separate /usr [or /lib|/lib64 or /sbin or /var] - that really is just part-of-the-operating-system | base-install.
Am 10.08.2012 15:13, schrieb Adam Tauno Williams:
On Thu, 2012-08-09 at 13:59 +0200, Andreas Jaeger wrote:
On Thursday, August 09, 2012 23:54:47 Robin Klitscher wrote:
For many years I've been running successive versions of openSUSE with a /usr partition separate from the root partition /. But I see that the Fedora manuals insist that the practice of separating these two filesystems can lead to dire results. I note, too, that there was a problem with this in the early drops oS 12.2 Is there a problem here, or a potential problem, in openSUSE? Or can I continue to separate these two filesystems with confidence? WE have put measures into place so that you can continue to use /usr as a separate partition. On the other hand, going forward I suggest to not setup a separate /usr anymore, there's no benefit in it.
+1
I make a separate /boot, sometimes a separate /tmp, often a separate /var/spool and /var/lib [depending on the purpose of the box]. /srv and /home are always separate.
I don't see any upside to a separate /usr [or /lib|/lib64 or /sbin or /var] - that really is just part-of-the-operating-system | base-install.
From history (yes, I know, old thinking) /usr was separated because you could mount it read-only and no-one was able to do nasty things in this file system. In those days, UNIX boxes were normally run as terminal servers with lots of users trying to murder the box and ruin the life of
the admin (see http://bofh.ntk.net/BOFH/ for examples). There was no idea to separate /bin, /sbin, /lib, or /etc (at least not by thinking people), because those dirs contained only software that was needed for booting. /bin and /sbin do and did not contain static files only, but the corresponding libraries were in /lib, on the same filesystem - in contrast to executables in /usr/bin and /usr/sbin, that had their libraries in /usr/lib. To gain performance, /usr and /usr/lib often resided on different hard disks. Of course, all temporary stuff (/var, /tmp, /var/tmp, ...) was separated too. Regards Werner -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On the other hand, going forward I suggest to not setup a separate /usr anymore, there's no benefit in it.
So I tried it. I have a 11.4 system and grub. Please don't ask me to upgrade to 12.1 or grub2. And yes I have Fedora-16 system with grub2 and ... that boots into the LVM partition, so I know it can be done that way. But there is a lot on the Web of a Million Lies about systems being converted to boot into LVM'd root using grub. Well, regular readers know that I'm and advocate of LVM. So what I did was create a LVM partition "NewRoot" large enough to hold / and /usr. Its an ext3. (I'd really like a resiserFS so I don't have to worry about how many inodes ...) and using rsync copied / and /usr there. As in using the "lHK" flags. I then did the fiddly bit as descried in the relevant section here http://www.linuxweblog.com/convert-root-filesytem-lvm-over-raid sections 6, 7 and 8 The reboot give me a panic, but without enough information as to why. I do have concerns that /dev/root is /dev/sda2 but I'm not sure if the boot process should redefine that. Any thoughts from people who know more about boot and what initrd is about and what the mkinitrd does? -- If a better system is thine, impart it; if not, make use of mine. - Horace -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Anton Aylward wrote:
I then did the fiddly bit as descried in the relevant section here http://www.linuxweblog.com/convert-root-filesytem-lvm-over-raid sections 6, 7 and 8
The reboot give me a panic, but without enough information as to why.
Unable to mount root device?
I do have concerns that /dev/root is /dev/sda2 but I'm not sure if the boot process should redefine that.
Any thoughts from people who know more about boot and what initrd is about and what the mkinitrd does?
The initrd contains an initramfs which essentially contains the bits you need to get the root filesystem mounted. mkinitrd creates the initrd. The initrd itself is just a cpio archive. -- Per Jessen, Zürich (26.0°C) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Per Jessen said the following on 08/14/2012 01:07 PM:
Anton Aylward wrote:
I then did the fiddly bit as descried in the relevant section here http://www.linuxweblog.com/convert-root-filesytem-lvm-over-raid sections 6, 7 and 8
The reboot give me a panic, but without enough information as to why.
Unable to mount root device?
Yes, I wondered about that. The first iteration I saw that message and thought about it. The baseline system has root on /dev/sda1 since that was how it was installed # ls -l /dev/root brw------- 1 root root 8, 1 Aug 14 06:59 /dev/root # ls -l /dev/sda2 brw-rw---- 1 root disk 8, 1 Aug 14 06:59 /dev/sda1 But the root is on the LVM The reason I asked about initrd was not about how it was made up. the cpio/compress, (I knew about that and had peeked) but whether it would dynamically redefine /deb/boot since the entry in fstab and in the grub.lst was /deb/mapper/vgmain-NewRoot # cd /mnt/disk # ls -l dev/root brw------- 1 root root 8, 1 Aug 12 11:53 deb/root ]# ls -l dev/vgmain/NewRoot lrwxrwxrwx 1 root root 7 Aug 12 11:57 dev/vgmain/NewRoot -> ../dm-8 # ls -l dev/dm-8 brw-rw---- 1 root disk 252, 8 Aug 12 11:57 dev/dm-8 So I removed dev/root and used mknod to create one that was "252,8" The message about not being able to mount root went away but the panic - with no explanation - was still there. I conclude that the system in the initrd does NOT redefine root according to the 'command line' of grub.lst but there is still more going on. -- There are two rules for success in life: Rule 1: Don't tell people everything you know. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Hello, On Tue, 14 Aug 2012, Anton Aylward wrote:
Per Jessen said the following on 08/14/2012 01:07 PM:
Anton Aylward wrote:
I then did the fiddly bit as descried in the relevant section here http://www.linuxweblog.com/convert-root-filesytem-lvm-over-raid sections 6, 7 and 8
The reboot give me a panic, but without enough information as to why.
Unable to mount root device? [..] But the root is on the LVM The reason I asked about initrd was not about how it was made up. the cpio/compress, (I knew about that and had peeked) but whether it would dynamically redefine /deb/boot since the entry in fstab and in the grub.lst was /deb/mapper/vgmain-NewRoot [..] I conclude that the system in the initrd does NOT redefine root according to the 'command line' of grub.lst but there is still more going on.
As Per already told you: you need the LVM/DM stuff in your initrd! So, add whatever dm-* modules you need for your stuff to the variable INITRD_MODULES="..." in /etc/sysconfig/kernel and run mkinitrd. Only then can / be mounted from the initrd as the new root and consequently switched to it. -dnh -- Boy, you can find /everything/ on CPAN now. Modules for moving countries? Cool. Probably redrawing borders based on some sort of array of points, I'm guessing. -- C. Rovers -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 09/08/12 21:54, Robin Klitscher wrote:
For many years I've been running successive versions of openSUSE with a /usr partition separate from the root partition /. But I see that the Fedora manuals insist that the practice of separating these two filesystems can lead to dire results. I note, too, that there was a problem with this in the early drops oS 12.2
Is there a problem here, or a potential problem, in openSUSE? Or can I continue to separate these two filesystems with confidence?
I am not that there is any useful mileage to be gained from having a separate /usr partition but there is usefullness in creating a separate partition called, say, /data to contain some of the directories/folders normally kept in your /home directory. Doing this you can install/re-install your oS by formatting your partitions except for /swap and /data without first haivng to backup your /home directory (or rather the important files in it). I'll clarify this. My second HDD has only one partition, formatted in ext4, and it is mounted as /data. Here I created a directory called /Symed and moved into it my Download, Pictures, Video, /.mozilla and /.thunderbird directories and others which contain data I don't want to lose if the main system HDD goes down. In my /home directory I created symlinks to all the folders I moved into /data/Symed/ (eg, /data/Symed/.mozilla). Doing this also makes it possible for other distro installations to access /data/Symed/ folders - Thunderbird installed on, say, openSUSE 12.1 can be access by openSUSE 12.2 and later by 12.3 when I install that. You get the picture :-) . BC -- Using openSUSE 12.2 x86_64 KDE 4.8.4 & kernel 3.5.0-2 on a system with- AMD FX 8-core 3.6/4.2GHz processor 16GB PC14900/1866MHz Quad Channel Corsair "Vengeance" RAM Gigabyte AMD3+ m/board; Gigabyte nVidia GTX550Ti 1GB DDR5 GPU -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Basil Chupin said the following on 08/09/2012 08:26 AM:
I am not that there is any useful mileage to be gained from having a separate /usr partition but there is usefullness in creating a separate partition called, say, /data to contain some of the directories/folders normally kept in your /home directory. Doing this you can install/re-install your oS by formatting your partitions except for /swap and /data without first haivng to backup your /home directory (or rather the important files in it).
Indeed, and you can symlink (or mount -B) from ~/MyDocuments, ~/MyDownloads, ~/MyMedia, ~/MyMail and so on. Actually I have separate partitions for all those :-) Regular readers will recall that I use LVM so creating more as those containers fill up (~/MyMedia/Music, ~/MyMedia/Photos, ...) is not a problem. Search the archives for the benefits of using LVM with RAID.
Doing this also makes it possible for other distro installations to access /data/Symed/ folders - Thunderbird installed on, say, openSUSE 12.1 can be access by openSUSE 12.2 and later by 12.3 when I install that. You get the picture :-) .
Or, as I do, put it on the file server and use NFS ... No really; my file server is a craqqed out old Dell but I can do the 'thin client' thing ... -- "I am always ready to learn, although I do not always like being taught". -- Winston Churchill -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Basil Chupin wrote:
I am not that there is any useful mileage to be gained from having a separate /usr partition but there is usefullness in creating a separate partition called, say, /data to contain some of the directories/folders normally kept in your /home directory.
Why not just have a separate /home? On my main computer, /home is on it's own drive mounted in a slide out tray. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 09/08/12 23:46, James Knott wrote:
Basil Chupin wrote:
I am not that there is any useful mileage to be gained from having a separate /usr partition but there is usefullness in creating a separate partition called, say, /data to contain some of the directories/folders normally kept in your /home directory.
Why not just have a separate /home? On my main computer, /home is on it's own drive mounted in a slide out tray.
This implies that you will be re-using /home for the next, new, installation of the distribution and, therefore, all the settings sitting in /home will be used. I am of the opinion that a new installation should always be a CLEAN installation without any baggage from the old version of the OS. For this reason I have only those directories which I know will not affect the new, clean, installation such as .mozilla, .thunderbird, Download, Documents, and so on - that it, these are directories containing my data, and I can safely wipe the whole of /home without suffering any damage :-) . BC -- Using openSUSE 12.2 x86_64 KDE 4.8.4 & kernel 3.5.0-2 on a system with- AMD FX 8-core 3.6/4.2GHz processor 16GB PC14900/1866MHz Quad Channel Corsair "Vengeance" RAM Gigabyte AMD3+ m/board; Gigabyte nVidia GTX550Ti 1GB DDR5 GPU -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
I am not that there is any useful mileage to be gained from having a separate /usr partition but there is usefullness in creating a separate partition called, say, /data to contain some of the directories/folders normally kept in your /home directory. Doing this you can install/re-install your oS by formatting your partitions except for /swap and /data without first haivng to backup your /home directory (or rather the important files in it). +1
My second HDD has only one partition, formatted in ext4, and it is mounted as /data. Here I created a directory called /Symed and moved into it my Download, Pictures, Video, /.mozilla and /.thunderbird directories and others which contain data I don't want to lose if the main system HDD goes down.
In my /home directory I created symlinks to all the folders I moved into /data/Symed/ (eg, /data/Symed/.mozilla).
Doing this also makes it possible for other distro installations to access /data/Symed/ folders - Thunderbird installed on, say, openSUSE 12.1 can be access by openSUSE 12.2 and later by 12.3 when I install that. You get the picture .
I'd just like to add that bind mounts can sometimes be quite useful. For example, I typically like to have separate /local, /build, /home and /pub filesystems. On my laptop, with a relatively small disk, I don't want to create hard partitions, so I have a single /data filesystem, with /data/{local,build,home,pub} directories under it, and then in my /etc/fstab: /data/local /local none bind 0 0 /data/home /home none bind 0 0 /data/pub /pub none bind 0 0 /data/build /build none bind 0 0 Just my $0.02 worth. -Nick -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
I think it's at least safe to say that it's no one's place to try to tell anyone else, let alone everyone else, something as sweeping as "there is no use for separate /usr". Asking why someone does it is the wrong question. They do. And they have their reasons. And the OS needs to support it. Or else become less useful and useful to less. -- bkw -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 08/09/2012 05:36 PM, Brian K. White wrote:
I think it's at least safe to say that it's no one's place to try to tell anyone else, let alone everyone else, something as sweeping as "there is no use for separate /usr".
Asking why someone does it is the wrong question. They do. And they have their reasons. And the OS needs to support it. Or else become less useful and useful to less.
;) It's interesting that in this thread - if I didn't miss anything - many people told why having separate partitions are useful. I agree with that. I just don't remember seeing a use case why a separate /usr is beneficial. Yes, people do it - and openSUSE continues to support it - but the only reasons I'm aware of are historical like [1]. So, what is the reason to create a separate /usr with openSUSE 12.2? Please educate me ;) Andreas Footnote: [1] http://lists.busybox.net/pipermail/busybox/2010-December/074114.html -- Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn,Jennifer Guild,Felix Imendörffer,HRB16746 (AG Nürnberg) GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2012-08-09 21:02, Andreas Jaeger wrote:
;)
It's interesting that in this thread - if I didn't miss anything - many people told why having separate partitions are useful. I agree with that. I just don't remember seeing a use case why a separate /usr is beneficial.
No? Go fetch those paper books you included with SuSE Professional not that long ago. A separate /usr was recommended there. Yes, people do it - and openSUSE continues to support it - but the only
reasons I'm aware of are historical like [1].
So, what is the reason to create a separate /usr with openSUSE 12.2? Please educate me ;)
Spreading the system over several hard disks, speeding filesystem access. - -- Cheers / Saludos, Carlos E. R. (from 12.1 "Asparagus" GM (bombadillo)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlAkCqgACgkQU92UU+smfQUgSACdHY71vH32tweLnPylV0Mue3l+ 3ccAnilFHQ3EzW/WsEuStD0DrKiZoCLR =GxOz -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Carlos E. R. said the following on 08/09/2012 03:08 PM:
On 2012-08-09 21:02, Andreas Jaeger wrote:
So, what is the reason to create a separate /usr with openSUSE 12.2? Please educate me ;)
Spreading the system over several hard disks, speeding filesystem access.
And don't forget that FSCK is O(2) of the size of the FS or worse. - -- "The wide world is all about you: you can fence yourselves in, but you cannot for ever fence it out." -- JRR Tolkien, -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iOgEAQECAAYFAlAkE9wACgkQGa6akpZ3YCl+UQZfYmfnAyA05Dkd4bQ6Fa/hRCI9 eojveVAhyk35w6JHVPqXBJY4qkgjFyHYIQNN9VaZZ21HAPleB4T7zwutXy5P4FOJ coQ01J3KWPpyKyzzZoBDi0w8F1H59LaXWKwzaQG1XvM8z+R4iXQbSqzwPauKkCer ifK1d81lgppLSfTk+vc6fNnkSMJPKiZdMMH9FRwgr4sFsMIB4funoT4LHtcAAoeA 7CJXTDDo2d1mzjAYkbmioANI9QdsdmJ3ZT1Q0ReSpRUjF7orvWtfOR4y =Txe5 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Thu, 2012-08-09 at 15:47 -0400, Anton Aylward wrote:
Carlos E. R. said the following on 08/09/2012 03:08 PM:
On 2012-08-09 21:02, Andreas Jaeger wrote:
So, what is the reason to create a separate /usr with openSUSE 12.2? Please educate me ;) Spreading the system over several hard disks, speeding filesystem access. And don't forget that FSCK is O(2) of the size of the FS or worse.
Very true, but still, checking a 5, 10, or 30GB partition is fast. I routinely fsck 500+GB partitions mounted via iSCSI from a SAN [not the fastest transport on the planet] and they complete in not that long. Doing an fsck on a local hard drive on a reasonably modern desktop or laptop is not much of an obstacle to larger filesystems.
On 08/09/2012 09:08 PM, Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2012-08-09 21:02, Andreas Jaeger wrote:
;)
It's interesting that in this thread - if I didn't miss anything - many people told why having separate partitions are useful. I agree with that. I just don't remember seeing a use case why a separate /usr is beneficial.
No?
Go fetch those paper books you included with SuSE Professional not that long ago. A separate /usr was recommended there.
historical ;) - see below ;)
Yes, people do it - and openSUSE continues to support it - but the only
reasons I'm aware of are historical like [1].
So, what is the reason to create a separate /usr with openSUSE 12.2? Please educate me ;)
Spreading the system over several hard disks, speeding filesystem access.
/usr is so tiny compared to the size of disks that I do not see that as an advantage *today*, Andreas -- Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn,Jennifer Guild,Felix Imendörffer,HRB16746 (AG Nürnberg) GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Andreas Jaeger said the following on 08/09/2012 03:51 PM:
Spreading the system over several hard disks, speeding filesystem access.
/usr is so tiny compared to the size of disks that I do not see that as an advantage *today*,
That entirely depends on your architecture. Don't forget that Linux is used on everything from machine the size of the Strawberry Pi to big data centres, from home PCs that are dual boot with Windows to all manner of corporate machines. -- The best victory is when the opponent surrenders of its own accord before there are any actual hostilities...It is best to win without fighting. Sun-tzu, The Art of War. Planning a Siege -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2012-08-09 21:51, Andreas Jaeger wrote:
On 08/09/2012 09:08 PM, Carlos E. R. wrote:
I just don't remember seeing a use case why a separate /usr is beneficial.
No?
Go fetch those paper books you included with SuSE Professional not that long ago. A separate /usr was recommended there.
historical ;) - see below ;)
But then don't say "I don't remember". It is the history of your own company...
/usr is so tiny compared to the size of disks that I do not see that as an advantage *today*,
Tiny? Where are you looking at? bombadillo:/lib/systemd/system # df -h /other/main/usr /other/main/usr/src /other/main/usr/local Filesystem Size Used Avail Use% Mounted on /dev/sdb8 21G 13G 7.1G 65% /other/main/usr /dev/sdc6 10G 8.7G 1.4G 87% /other/main/usr/src /dev/sdc7 13G 3.2G 8.9G 27% /other/main/usr/local - -- Cheers / Saludos, Carlos E. R. (from 12.1 "Asparagus" GM (bombadillo)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlAkG78ACgkQU92UU+smfQXLtgCeLeEkp5XknccB4yx1IfYDteeb elUAn0qbXmQ+xm1vjMbUMMl/ynmq4szo =wrAl -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Carlos E. R. wrote:
On 2012-08-09 21:51, Andreas Jaeger wrote:
/usr is so tiny compared to the size of disks that I do not see that as an advantage *today*,
Tiny? Where are you looking at?
"tiny compared to the size of the disks". As I think Anton pointed out, it depends - however, for desktops and servers Andreas is certainly right, /usr is not a large amount of data when seen relative to the size of the disks. -- Per Jessen, Zürich (16.5°C) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Thursday 09 Aug 2012 22:21:19 Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2012-08-09 21:51, Andreas Jaeger wrote:
On 08/09/2012 09:08 PM, Carlos E. R. wrote:
I just don't remember seeing a use case why a separate /usr is beneficial.
No?
Go fetch those paper books you included with SuSE Professional not that long ago. A separate /usr was recommended there.
historical ;) - see below ;)
But then don't say "I don't remember". It is the history of your own company...
/usr is so tiny compared to the size of disks that I do not see that as an advantage *today*, Tiny? Where are you looking at?
bombadillo:/lib/systemd/system # df -h /other/main/usr /other/main/usr/src /other/main/usr/local Filesystem Size Used Avail Use% Mounted on /dev/sdb8 21G 13G 7.1G 65% /other/main/usr /dev/sdc6 10G 8.7G 1.4G 87% /other/main/usr/src /dev/sdc7 13G 3.2G 8.9G 27% /other/main/usr/local
Historically they are on separate partitions/disks was because when they developed Unix, they ran out of space on the small disks and just added more disks. It was to get around a size limitation on the machine they used to develop unix. (or something along those lines) All the other reasons for the separate partitions was just spin to justify it and unfortunately they didnt change it when the disks got bigger. Fedora is now being sensible about the directory structures.. i personally on have 3, swap, root and home.
- -- Cheers / Saludos,
Carlos E. R. (from 12.1 "Asparagus" GM (bombadillo)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAlAkG78ACgkQU92UU+smfQXLtgCeLeEkp5XknccB4yx1IfYDteeb elUAn0qbXmQ+xm1vjMbUMMl/ynmq4szo =wrAl -----END PGP SIGNATURE-----
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Andreas Jaeger wrote:
It's interesting that in this thread - if I didn't miss anything - many people told why having separate partitions are useful. I agree with that. I just don't remember seeing a use case why a separate /usr is beneficial.
Carlos E. R. wrote:
I just don't remember seeing a use case why a separate /usr is beneficial. No?
Go fetch those paper books you included with SuSE Professional not that long ago. A separate /usr was recommended there. historical ;) - see below ;)
But then don't say "I don't remember". It is the history of your own company...
Carlos, please don't make spurious attacks by quoting out of context. Andreas clearly limited his point to *comments in this thread*. You owe him an apology. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2012-08-10 11:25, Dave Howorth wrote:
Andreas Jaeger wrote:
It's interesting that in this thread - if I didn't miss anything - many people told why having separate partitions are useful. I agree with that. I just don't remember seeing a use case why a separate /usr is beneficial.
Carlos E. R. wrote:
I just don't remember seeing a use case why a separate /usr is beneficial. No?
Go fetch those paper books you included with SuSE Professional not that long ago. A separate /usr was recommended there. historical ;) - see below ;)
But then don't say "I don't remember". It is the history of your own company...
Carlos, please don't make spurious attacks by quoting out of context. Andreas clearly limited his point to *comments in this thread*. You owe him an apology.
Attacks? I'm not aware of having attacked anybody. You will have to justify that or make an apology to me :-| - -- Cheers / Saludos, Carlos E. R. (from 12.1 "Asparagus" GM (bombadillo)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlAlD7YACgkQU92UU+smfQWgagCfbit8kgu6P5vewIvhLLe4+oG3 SjQAoISyuWtrO6PndsBKZhJaVYUvI/c8 =/k/N -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
09.08.2012 22:21, Carlos E. R.:
bombadillo:/lib/systemd/system # df -h /other/main/usr /other/main/usr/src /other/main/usr/local Filesystem Size Used Avail Use% Mounted on /dev/sdb8 21G 13G 7.1G 65% /other/main/usr /dev/sdc6 10G 8.7G 1.4G 87% /other/main/usr/src /dev/sdc7 13G 3.2G 8.9G 27% /other/main/usr/local
/usr/local does not count - the things you put in /usr/local you can put in /opt as well :-) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Andreas Jaeger wrote:
On 08/09/2012 05:36 PM, Brian K. White wrote:
I think it's at least safe to say that it's no one's place to try to tell anyone else, let alone everyone else, something as sweeping as "there is no use for separate /usr".
Asking why someone does it is the wrong question. They do. And they have their reasons. And the OS needs to support it. Or else become less useful and useful to less.
;)
It's interesting that in this thread - if I didn't miss anything - many people told why having separate partitions are useful. I agree with that. I just don't remember seeing a use case why a separate /usr is beneficial. Yes, people do it - and openSUSE continues to support it - but the only reasons I'm aware of are historical like [1].
So, what is the reason to create a separate /usr with openSUSE 12.2?
Having a read-only /usr is useful for NFS-mounting to thin clients. We have a cluster that runs like that - not exactly thin, but sharing /usr makes managing everything much easier. Probably not a reason for creating a separate /usr, but it would be nice to have the support for it. -- Per Jessen, Zürich (16.2°C) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Thu, 2012-08-09 at 21:02 +0200, Andreas Jaeger wrote:
I think it's at least safe to say that it's no one's place to try to tell anyone else, let alone everyone else, something as sweeping as "there is no use for separate /usr". Asking why someone does it is the wrong question. They do. And they have their reasons. And the OS needs to support it. Or else become less useful and useful to less. It's interesting that in this thread - if I didn't miss anything - many
On 08/09/2012 05:36 PM, Brian K. White wrote: people told why having separate partitions are useful. I agree with that. I just don't remember seeing a use case why a separate /usr is beneficial. Yes, people do it - and openSUSE continues to support it - but the only reasons I'm aware of are historical like [1]. So, what is the reason to create a separate /usr with openSUSE 12.2? Please educate me ;)
IMNSHO, there are none / zero reasons for a dedicated /usr partition. And the world is frowning on the practice. Modern systems, especially desktops, are complicated and require a variety of services to spin up at boot [you have wireless security, possibly VPNs, possibly cryptography, hot-plug support for USB and other busses, bluetooth, HID, etc...] and get the machine to a "normal" state. So having this nicely organized in the root volume [ /sbin, /etc, /sbin, /bin, /lib ] is just a nicer way to do it. I'm sure they exist but *I* have never seen a thin client that mount's the *server's* /usr; so I don't really believe that is relevant either [and I'd consider it very odd, and just a bad idea]. Last I saw that type of mounting was far back in the day when not-thin "workstations" mounted points of the server to their own hierarchy to save precious disk space. It meant central updates broke things, network outages broke workstations, and that performance was hobbled - pretty much everyone stopped doing that once disks got cheap enough.
On Fri, 10 Aug 2012 23:26:28 Adam Tauno Williams wrote:
IMNSHO, there are none / zero reasons for a dedicated /usr partition.
Except that it is part of the Filesystem Hierarchy Specificaton for Unix-like operating systems, with a exception proposed for Linux. Read the draft spec linked to elsewhere in this thread. If you disagree with the spec, file a bug against the spec.
And the world is frowning on the practice. Modern systems, especially desktops, are complicated and require a variety of services to spin up at boot [you have wireless security, possibly VPNs, possibly cryptography, hot-plug support for USB and other busses, bluetooth, HID, etc...] and get the machine to a "normal" state. So having this nicely organized in the root volume [ /sbin, /etc, /sbin, /bin, /lib ] is just a nicer way to do it.
See above. [,,,] -- ========================================================================== Rodney Baker VK5ZTV rodney.baker@iinet.net.au ========================================================================== -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Historically a separate /usr filesystem, be it partition or (more typically) a separate disk, was because / held the system and /usr held everything else. No kernel, no system libraries, nothing required for startup or shutdown. It was economical and practical, given the capacities of disks at the time and it made backing up and expansion of storage easier. /usr also held user directories, hence the name "usr". You could run the system without /usr with no trouble. Some noncritical files and commands might be missing and users wouldn't have access to their home directories but the system was usable at pretty much every runlevel. Since the long-standing policy of keeping everything system and everything needed for startup on / has been tossed out and system files essential to startup are buried somewhere, anywhere, in /usr it must be mounted early during startup or be on the root filesystem otherwise the system fails to start up even in runlevel 1 and basically becomes a whiny brick. Startup depends on /usr being there. So having a separate /usr filesystem is no longer safe. Even if a system set up so it can start up without /usr, there is always the invetiable clueless someone who comes along and puts something system-critical in /usr, breaking the startup process. /usr can no longer be a separate partition by dint of ignorance or whatever supposedly reasonable motive moved people to disregard policy. To change it back would be too much effort that few are willing to undertake and fewer still are willing to agree with. The best that can be done now is to ensure that no one starts putting system critical files in /home, /tmp, /media, or other new and weird places. Enjoy your tangential arguing everyone... -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
j debert said the following on 08/09/2012 03:32 PM:
Historically [...]
Since the long-standing policy of keeping everything system and everything needed for startup on / has been tossed out and system files essential to startup are buried somewhere, anywhere, in /usr it must be mounted early during startup or be on the root filesystem otherwise the system fails to start up even in runlevel 1 and basically becomes a whiny brick.
That was a design decision not a necessity.
Startup depends on /usr being there.
That was a design decision not a necessity. There is no reason the systemd stuff in /usr/ *HAS* to be there. Historically, /boot didn't exist. Historically many of the config files that are now in /etc weren't. There is no reason other than design decision to make stuff needed by the startup (or shutdown for that matter) in /usr.
/usr can no longer be a separate partition by dint of ignorance or whatever supposedly reasonable motive moved people to disregard policy. To change it back would be too much effort that few are willing to undertake and fewer still are willing to agree with.
True, but we've done great changes to the hierarchy in the past.
The best that can be done now is to ensure that no one starts putting system critical files in /home, /tmp, /media, or other new and weird places.
To a generation that grew up with all the config files in /etc having some in /usr is /weird/. "Those ignorant of history are doomed to repeat it" -- Call 226682779489712859637199678587902423107 for a good prime! -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 08/09/12 15:55, Anton Aylward pecked at the keyboard and wrote:
j debert said the following on 08/09/2012 03:32 PM:
Historically [...]
Since the long-standing policy of keeping everything system and everything needed for startup on / has been tossed out and system files essential to startup are buried somewhere, anywhere, in /usr it must be mounted early during startup or be on the root filesystem otherwise the system fails to start up even in runlevel 1 and basically becomes a whiny brick.
That was a design decision not a necessity.
25 years ago disks were expensive, small and slow so it made sense to have separate disks/partitions for ever expanding filesystems. And raid was not very prevalent then if at all and LVM was not available. SunOS even provided a chart for estimating how much space to allocate to certain filesystems. It took experience to figure out what sizes to use which is why the software vendor was called in to help with partitioning (at least where I worked before I was trained to be the IT person).
Startup depends on /usr being there.
That was a design decision not a necessity.
There is no reason the systemd stuff in /usr/ *HAS* to be there. Historically, /boot didn't exist. Historically many of the config files that are now in /etc weren't.
There is no reason other than design decision to make stuff needed by the startup (or shutdown for that matter) in /usr.
/usr can no longer be a separate partition by dint of ignorance or whatever supposedly reasonable motive moved people to disregard policy. To change it back would be too much effort that few are willing to undertake and fewer still are willing to agree with.
True, but we've done great changes to the hierarchy in the past.
The best that can be done now is to ensure that no one starts putting system critical files in /home, /tmp, /media, or other new and weird places.
To a generation that grew up with all the config files in /etc having some in /usr is /weird/.
"Those ignorant of history are doomed to repeat it"
There will always be people that do things in a different manner, that does not make them wrong for what they do, only different. -- Ken Schneider SuSe since Version 5.2, June 1998 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2012/08/09 15:55 (GMT-0400) Anton Aylward composed:
To a generation that grew up with all the config files in /etc having some in /usr is /weird/.
Inane is what I call it. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 08/09/2012 12:55 PM, Anton Aylward wrote:
j debert said the following on 08/09/2012 03:32 PM:
Startup depends on /usr being there.
That was a design decision not a necessity.
Whatever it was, it is now a de facto necessity.
There is no reason the systemd stuff in /usr/ *HAS* to be there. Historically, /boot didn't exist.
Someday perhaps /boot can go away too.
Historically many of the config files that are now in /etc weren't.
/etc originally didn't have system config files. It was where miscellaneous binaries and data lived. System configs were more likely to be found in /, /lib, and /var. Those few that weren't hard coded, that is. It didn't take long for config files to start popping up everywhere and anywhere so the decision -- design decision -- was made to drop all the system config files in /etc, move all misc binaries and data to /usr, /var, and /opt.
There is no reason other than design decision to make stuff needed by the startup (or shutdown for that matter) in /usr.
Of course there's no reason. But it happened. Fait accompli.
/usr can no longer be a separate partition by dint of ignorance or whatever supposedly reasonable motive moved people to disregard policy. To change it back would be too much effort that few are willing to undertake and fewer still are willing to agree with.
True, but we've done great changes to the hierarchy in the past.
Do you recall how much fighting there was over it?
The best that can be done now is to ensure that no one starts putting system critical files in /home, /tmp, /media, or other new and weird places.
To a generation that grew up with all the config files in /etc having some in /usr is /weird/.
/usr/etc: Where non-system configs can have a home. Unfortunately many developers disagree and prefer /lib/application/.config or some windows registry or something equally weird. Personally, I'd rather they were all in one place and not have to go on safari to find them. jd -- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 08/09/2012 10:02 PM, lynn wrote:
On 09/08/12 21:32, j debert wrote: /usr also held user directories, hence the name
"usr".
usr = Unix System Resources, it says here. . .
That may be correct. At least "officially". I vaguely recall hearing that definition of "usr". But system resources weren't kept in /usr originally. I've heard from old fogie Unix engineers and sysadmins that /usr was called that because that's where all the users lived. I recall it being mentioned in an ATT Unix booklet as well. It also seems that three letter directory names were rather popular at the time. Unix minimalism, I guess. jd -- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
j debert, 10.08.2012 18:28:
On 08/09/2012 10:02 PM, lynn wrote:
On 09/08/12 21:32, j debert wrote: /usr also held user directories, hence the name
"usr".
usr = Unix System Resources, it says here. . .
That may be correct. At least "officially". I vaguely recall hearing that definition of "usr". But system resources weren't kept in /usr originally.
I've heard from old fogie Unix engineers and sysadmins that /usr was called that because that's where all the users lived. I recall it being mentioned in an ATT Unix booklet as well. It also seems that three letter directory names were rather popular at the time. Unix minimalism, I guess.
Aye. There was no such thing as "/home". Home was place to go and live there, not a directory :-) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 8/13/2012 4:18 PM, Werner Flamme wrote:
j debert, 10.08.2012 18:28:
On 08/09/2012 10:02 PM, lynn wrote:
On 09/08/12 21:32, j debert wrote: /usr also held user directories, hence the name
"usr".
usr = Unix System Resources, it says here. . .
That may be correct. At least "officially". I vaguely recall hearing that definition of "usr". But system resources weren't kept in /usr originally.
I've heard from old fogie Unix engineers and sysadmins that /usr was called that because that's where all the users lived. I recall it being mentioned in an ATT Unix booklet as well. It also seems that three letter directory names were rather popular at the time. Unix minimalism, I guess.
Aye. There was no such thing as "/home". Home was place to go and live there, not a directory :-)
sco open server put home directories in /usr up until 5.0.5 or 5.0.6 but that was always a terrible terrible mess. I never tried to create a user named "lib" on a sco box but I wouldn't be surprised if the system allowed it and made exactly the mess you are now imagining. I think there was a system user named "bin" that was not login enabled and had no home directory defined so that one skates by on technicalities. ;) 5.0.6 or 5.0.7 finally shipped with a new default of /u, still not /home. Hardly any better since /u was a common place for countless 3rd party commercial apps to put their stuff. But at least by then there was a simple variable to edit in /etc/default/somethingorother and you could put /home instead of /u and all subsequent users would get created in /home. It's one of the few instances where I'll agree the historical way was not the result of greater wisdom and worth perpetuating. -- bkw -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Brian K. White said the following on 08/14/2012 03:49 AM:
sco open server put home directories in /usr up until 5.0.5 or 5.0.6 but that was always a terrible terrible mess. I never tried to create a user named "lib" on a sco box but I wouldn't be surprised if the system allowed it and made exactly the mess you are now imagining. I think there was a system user named "bin" that was not login enabled and had no home directory defined so that one skates by on technicalities. ;)
And there are many other entries in /etc/passwd ... Go look. Years ago there was a paper at a USENIX or some conference titled "Life without root". It showed how many subsystems could be administered without the need for root. The paper used UUCP and mail as an example. At the time this was dramatic but now its the way we do it. We see it subtly today in other ways, there are files and devices owned by, for example, lp. Logically we could have assigned sub administrators with relevant logins. Delegation and all that. Logically all those binaries and libraries could be managed and updated by someone with less than root power. Call such an entity "bin". Change ownership of /bin /usr/bin and the files beneath. I've seen it done. A few hiccups with setuid-root programs ... How much like Big Iron and the way Big Iron gets administered do you want to be? Traditionally Big Iron had few processes that were closely monitored and tuned because process creation and inter process communications in the traditional model; heck even the DEC VAX-VMS that grew up after UNIX and had Bill Joy battling with Dave Cutler over performance issues between VMS and VAX-UNIX had lots of static processes because process creation was expensive. Part of what was revolutionary about UNIX was that process creation was cheap-cheap-cheap, and so the shell could create short lived, transient programs that did something simple (and hence weren't complex and hence could be easily debugged and proved correct) and combined with pipes by the shell. This was revolutionary. But there was no way that such ephemeral, evanescent entities could be tuned the way mainframe programs were, no way that principles of resource management and optimization and all those other techniques could - or needed - to be applies. But, it seems, we're giving up on that. Many of our models are getting to be more like the traditional mainframe as versions of UNIX/Linux move in to take over work that was once done by mainframes. So perhaps we will see delegated authority making use of non root IDs to do what used to be done by root. "Life without root". -- Leadership is understanding people and involving them to help you do a job. That takes all of the good characteristics, like integrity, dedication of purpose, selflessness, knowledge, skill, implacability, as well as determination not to accept failure. ~ Admiral Arleigh A. Burke -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Tue, 14 Aug 2012 21:25:27 Anton Aylward wrote:
[...] So perhaps we will see delegated authority making use of non root IDs to do what used to be done by root. "Life without root".
So the sysadmin will become a eunuch? Sorry, couldn't resist... -- ========================================================================== Rodney Baker VK5ZTV rodney.baker@iinet.net.au ========================================================================== -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 08/14/2012 04:55 AM, Anton Aylward wrote:
Brian K. White said the following on 08/14/2012 03:49 AM:
sco open server put home directories in /usr up until 5.0.5 or 5.0.6 but that was always a terrible terrible mess. I never tried to create a user named "lib" on a sco box but I wouldn't be surprised if the system allowed it and made exactly the mess you are now imagining. I think there was a system user named "bin" that was not login enabled and had no home directory defined so that one skates by on technicalities. ;)
And there are many other entries in /etc/passwd ... Go look.
Early on it wasn't such a problem, as user access and activity was restricted and *nix was seen as more of a lab curiousity than a production system. That started changing in the 1980's and accelerated when Linux 0.99 was released.
Years ago there was a paper at a USENIX or some conference titled "Life without root". It showed how many subsystems could be administered without the need for root. The paper used UUCP and mail as an example. At the time this was dramatic but now its the way we do it. We see it subtly today in other ways, there are files and devices owned by, for example, lp.
It works great when implemented intelligently. Otherwise it was a disaster.
How much like Big Iron and the way Big Iron gets administered do you want to be?
Traditionally Big Iron had few processes that were closely monitored and tuned because process creation and inter process communications in the traditional model; heck even the DEC VAX-VMS that grew up after UNIX and had Bill Joy battling with Dave Cutler over performance issues between VMS and VAX-UNIX had lots of static processes because process creation was expensive. Part of what was revolutionary about UNIX was that process creation was cheap-cheap-cheap, and so the shell could create short lived, transient programs that did something simple (and hence weren't complex and hence could be easily debugged and proved correct) and combined with pipes by the shell. This was revolutionary. But there was no way that such ephemeral, evanescent entities could be tuned the way mainframe programs were, no way that principles of resource management and optimization and all those other techniques could - or needed - to be applies.
Tangential trivia: Unix and the ephemeral nature of Unix processes turned out to be ideal (with some tweaking) for managing telephone switches and their transient connections.
But, it seems, we're giving up on that. Many of our models are getting to be more like the traditional mainframe as versions of UNIX/Linux move in to take over work that was once done by mainframes.
I would have said more like Windows and it's monolithic do-everything-under-the-sun style of coding and constant reinventing of the wheel rather than using what is already there and piping between tools. Like, why reinvent sed in python? Just build a script and call sed. Simple, right? There are many existing tools that are not being used because... Why??? Baffling. And what's starting to happen: The tools are disappearing, deprecated because people prefer to reinvent the wheel, do things the hard way, so no one uses them and when you need them, *they're not there anymore!* I intended to recycle my old Yggdrasil and Slackware distro CD's but I think I'd better keep them if just for the tools they have that are beginning to disappear from current Linux distros. Been so long since I've even /seen/ a running mainframe or mini I had forgotten about the mainframe styles. IIRC reinventing the wheel in mainframes was the norm, perhaps even the gold standard, even outside of the classroom. DOS and Windows programmers started out in that environment so it's no wonder Windows has been such a load of mess. Unfortunately, that mentality is displacing KISS and it's flexibility.
So perhaps we will see delegated authority making use of non root IDs to do what used to be done by root. "Life without root".
Sounds like Android. And that's fine but root isn't going away. I hope. Still need someone with godly powers to sort out messes created by the lesser-privileged. Windows: "Work harder, not smarter!" *nix/Linux: "Work smarter, not harder!" (aka "G***amn lazy programmers!") jd -- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Hello, On Tue, 14 Aug 2012, j debert wrote:
I would have said more like Windows and it's monolithic do-everything-under-the-sun style of coding and constant reinventing of the wheel rather than using what is already there and piping between tools. Like, why reinvent sed in python? Just build a script and call sed. Simple, right? There are many existing tools that are not being used because... Why??? Baffling. And what's starting to happen: The tools are disappearing, deprecated because people prefer to reinvent the wheel, do things the hard way, so no one uses them and when you need them, *they're not there anymore!*
Such as? Anyway: I like the *nix style. I use ed if applicable, sed, awk, perl, grep, agrep, sgrep, pcregrep, cut, sort, cat, tac, head, tail, find, xargs, ... Oh, I think afio is gone from the distro. -dnh PS: yeah, I often write about how you can replace external commands with bashisms or one perl-script, but it's always the matter of what to use for what purpose. You should see some of my "one-liners" in bash ... But in scripts, esp. in loops therin, I try to avoid external programs from the "unix toolbox" and switch to using perl rather soonish, mostly depending on how often I think I'll be using the script and for what. ;) I e.g. have a short indexing script (using several finds, that has 11 pipes in it, a bunch of subshells, awk, sed, grep, sort, ...) and as that script indexes a couple of TB currently producing 17MB in ~200k lines, disk-io from find dominates runtime by several orders and thus I don't care about inefficiencies in that script ;) Another case is the texmf scripts (mktex* etc.). Well, they are portable. $ file /usr/share/texmf/bin/noarch/* | \ sed '/link/d; s/.*: *//' | sort | uniq -c 3 C shell script, ASCII text 31 POSIX shell script, ASCII text 1 POSIX shell script, ASCII text, with CR, LF line terminators 2 POSIX shell script, ISO-8859 text 1 a texlua script, ASCII text But some stuff I'd like to replace by a perl-script, esp. when some script calls others repeatedly in a loop (those as functions in the perl-script - whoopdie doo ;) -- GETOPT(3) BUGS This manpage is confusing. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 08/14/2012 07:30 PM, David Haller wrote:
Hello,
On Tue, 14 Aug 2012, j debert wrote:
I would have said more like Windows and it's monolithic do-everything-under-the-sun style of coding and constant reinventing of the wheel rather than using what is already there and piping between tools. Like, why reinvent sed in python? Just build a script and call sed. Simple, right? There are many existing tools that are not being used because... Why??? Baffling. And what's starting to happen: The tools are disappearing, deprecated because people prefer to reinvent the wheel, do things the hard way, so no one uses them and when you need them, *they're not there anymore!*
Such as? Anyway: I like the *nix style. I use ed if applicable, sed, awk, perl, grep, agrep, sgrep, pcregrep, cut, sort, cat, tac, head, tail, find, xargs, ...
Oh, I think afio is gone from the distro.
There I was, writing the above and trying to remember what it was that was missing... Sorry, I can't recall anymore, other than dc and bc, both of which came back in a much later major rev. And both libtool and autoconf disappeared for a while as well. I do remember how annoying it was to upgrade and then find my scripts didn't work anymore and being dogged by very unhappy bosses wanting to know where their reports were. I eventually managed to use the source to replace them. There has been talk of removing "legacy" tools because they have been around since prehistoric times and are well, just old, y'know. jd -- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Hello, On Thu, 16 Aug 2012, j debert wrote:
On 08/14/2012 07:30 PM, David Haller wrote:
On Tue, 14 Aug 2012, j debert wrote:
happen: The tools are disappearing, deprecated because people prefer to reinvent the wheel, do things the hard way, so no one uses them and when you need them, *they're not there anymore!*
Such as?
There I was, writing the above and trying to remember what it was that was missing... Sorry, I can't recall anymore, other than dc and bc, both of which came back in a much later major rev. And both libtool and autoconf disappeared for a while as well.
'dc' may have been missing a while, but bc, autotools and libtool were always there. And if I miss something, I try to add it to OBS ;) -dnh -- Farscape is an epic science-fiction story told in grand cinematic fashion. What is it really? It's a really long, hot slog in leather out at Homebush [Studios]. -- Ben Browder, The Making of The Peacekeeper Wars -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 08/16/2012 01:19 PM, David Haller wrote:
'dc' may have been missing a while, but bc, autotools and libtool were always there. And if I miss something, I try to add it to OBS ;)
They certainly were missing. I don't know the circumstances. Could not build much from source for a while because they were. Happened to find a version of bc that did not require autoconf. jd -- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 8/17/2012 9:13 AM, j debert wrote:
On 08/16/2012 01:19 PM, David Haller wrote:
'dc' may have been missing a while, but bc, autotools and libtool were always there. And if I miss something, I try to add it to OBS ;)
They certainly were missing. I don't know the circumstances. Could not build much from source for a while because they were.
Happened to find a version of bc that did not require autoconf.
jd
They could only have been missing from your box, which can happen any number of ways, but they were always a part of the base distribution install media, available to be installed on demand. -- bkw -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 08/17/2012 01:07 PM, Brian K. White wrote:
On 8/17/2012 9:13 AM, j debert wrote:
On 08/16/2012 01:19 PM, David Haller wrote:
'dc' may have been missing a while, but bc, autotools and libtool were always there. And if I miss something, I try to add it to OBS ;)
They certainly were missing. I don't know the circumstances. Could not build much from source for a while because they were.
Happened to find a version of bc that did not require autoconf.
jd
They could only have been missing from your box, which can happen any number of ways, but they were always a part of the base distribution install media, available to be installed on demand.
They weren't on the media and they weren't found in any repos. I thought that point was self-evident but obviously I was wrong. Why would anyone think I wouldn't even bother to look for them? This was a while before OBS, BTW. jd -- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 8/17/2012 5:39 PM, j debert wrote:
On 08/17/2012 01:07 PM, Brian K. White wrote:
On 8/17/2012 9:13 AM, j debert wrote:
On 08/16/2012 01:19 PM, David Haller wrote:
'dc' may have been missing a while, but bc, autotools and libtool were always there. And if I miss something, I try to add it to OBS ;)
They certainly were missing. I don't know the circumstances. Could not build much from source for a while because they were.
Happened to find a version of bc that did not require autoconf.
jd
They could only have been missing from your box, which can happen any number of ways, but they were always a part of the base distribution install media, available to be installed on demand.
They weren't on the media and they weren't found in any repos. I thought that point was self-evident but obviously I was wrong. Why would anyone think I wouldn't even bother to look for them? This was a while before OBS, BTW.
jd
I have original install media and/or repo mirrors from current back to 9.0 I predict that if I look I will find them in all of those. Do you mean older than that? Not that 9.0 is all that old, but I just do not believe that autoconf and libtool were not part of the standard distro anytime after those tools were commonly used. That was well before 9.0 so there are versions I can't check right now that might actually be missing them as you say. -- bkw -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Thu, 9 Aug 2012 21:24:47 Robin Klitscher wrote:
For many years I've been running successive versions of openSUSE with a /usr partition separate from the root partition /. But I see that the Fedora manuals insist that the practice of separating these two filesystems can lead to dire results. I note, too, that there was a problem with this in the early drops oS 12.2
Is there a problem here, or a potential problem, in openSUSE? Or can I continue to separate these two filesystems with confidence?
A general reply to all in this thread; the Filesystem Hierarchy Standard is currently being revised - the draft of v3.0 has been released by The Linux Foundation and can be found here: http://www.linuxfoundation.org/collaborate/workgroups/lsb/fhs-30-draft-1 The base spec has not changed the purpose of /usr within the overall scheme for Unix-like operating systems, however there is an os-specific annex (section 6) for Linux which removes the separate /usr. This seems contradictory to the main body of the spec, which states that the system must be able to boot without /usr mounted, and the annex that states that nothing in the annex should contradict the main spec. There is a mailing list dedicated to discussing the FHS and also instructions on filing bugs. The mailing list is at: https://lists.linux-foundation.org/mailman/listinfo/fhs-discuss Can I suggest that anyone who cares enough to argue about it here join that list and contribute to the development of the final spec? If there are specific use-cases that justify continued support for a separate /usr partition (Anton - btw, I'm with you on this one) then the case for that should be made in the appropriate forums while the spec is still in beta (so that there is opportunity to have it fixed). The FHS is complementary to the LSB which (afaik) openSuSE purports to be more or less compliant with (but I'm open to be corrected if that is wrong). Therefore, openSuSE should also be compliant with the LHS. -- ========================================================================== Rodney Baker VK5ZTV rodney.baker@iinet.net.au ========================================================================== -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 10/08/12 16:11, Rodney Baker wrote:
A general reply to all in this thread; the Filesystem Hierarchy Standard is currently being revised - the draft of v3.0 has been released by The Linux Foundation and can be found here:
<snip>
Can I suggest that anyone who cares enough to argue about it here join that list and contribute to the development of the final spec? If there are specific use-cases that justify continued support for a separate /usr partition (Anton - btw, I'm with you on this one) then the case for that should be made in the appropriate forums while the spec is still in beta (so that there is opportunity to have it fixed).
Thank you. That is very enlightening. Even as an ignorant tyro in these matters I do wonder, though, why it should be necessary to argue for continued support for a separate /usr partition when Section 3.1 of the draft already makes the case so cogently and convincingly? Or perhaps a better question is why has Fedora chosen a path, and why is openSUSE about to follow suit, that apparently abandons what seems to me to be the great good sense set out in the draft FHS in this aspect at least? -- Robin K Wellington "Harbour City" New Zealand -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 08/10/2012 07:07 AM, Robin Klitscher wrote:
On 10/08/12 16:11, Rodney Baker wrote:
A general reply to all in this thread; the Filesystem Hierarchy Standard is currently being revised - the draft of v3.0 has been released by The Linux Foundation and can be found here:
<snip>
Can I suggest that anyone who cares enough to argue about it here join that list and contribute to the development of the final spec? If there are specific use-cases that justify continued support for a separate /usr partition (Anton - btw, I'm with you on this one) then the case for that should be made in the appropriate forums while the spec is still in beta (so that there is opportunity to have it fixed).
Thank you. That is very enlightening.
Even as an ignorant tyro in these matters I do wonder, though, why it should be necessary to argue for continued support for a separate /usr partition when Section 3.1 of the draft already makes the case so cogently and convincingly?
Or perhaps a better question is why has Fedora chosen a path, and why is openSUSE about to follow suit, that apparently abandons what seems to me to be the great good sense set out in the draft FHS in this aspect at least?
Robin, openSUSE will continue to support a /usr. So, there should not be a problem... Robin, read my replies and those of others: This was an educational exercise. Enough of that from my side, I've got some answers ;) Cheers, Andreas -- Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn,Jennifer Guild,Felix Imendörffer,HRB16746 (AG Nürnberg) GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 10/08/12 19:58, Andreas Jaeger wrote:
On 08/10/2012 07:07 AM, Robin Klitscher wrote:
On 10/08/12 16:11, Rodney Baker wrote:
Robin, openSUSE will continue to support a /usr. So, there should not be a problem...
Robin, read my replies and those of others: This was an educational exercise. Enough of that from my side, I've got some answers ;)
Andreas, I assure you that I have read the replies - every one - and with great interest. And yes, it has been greatly educational. If I misinterpreted your earlier remark, I apologise. But in saying this: "On the other hand, going forward I suggest to not setup a separate /usr anymore, there's no benefit in it." you seemed at least to be signalling an uncertain future for /usr as a separate partition. And, having read the draft FHS mentioned by Rodney, I thought I could see reasons why the option of a /usr separate from / could have benefits despite what you had said. But perhaps I'd taken you too literally the first time around ..... All of which goes to show, I suppose, that there's no such thing as a single answer for all occasions! Regards, R -- Robin K Wellington "Harbour City" New Zealand -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 08/10/2012 10:27 AM, Robin Klitscher wrote:
On 10/08/12 19:58, Andreas Jaeger wrote:
On 08/10/2012 07:07 AM, Robin Klitscher wrote:
On 10/08/12 16:11, Rodney Baker wrote:
Robin, openSUSE will continue to support a /usr. So, there should not be a problem...
Robin, read my replies and those of others: This was an educational exercise. Enough of that from my side, I've got some answers ;)
Andreas, I assure you that I have read the replies - every one - and with great interest. And yes, it has been greatly educational.
If I misinterpreted your earlier remark, I apologise. But in saying this: "On the other hand, going forward I suggest to not setup a separate /usr anymore, there's no benefit in it." you seemed at least to be signalling an uncertain future for /usr as a separate partition. And, having read the draft FHS mentioned by Rodney, I thought I could see reasons why the option of a /usr separate from / could have benefits despite what you had said. But perhaps I'd taken you too literally the first time around .....
Even if we would forbid it for new systems, it would break one of openSUSE key successes: You can update a system from one version to the other. So, we do need to support existing systems with /usr as separate partition. But I woouldn't advocate it anymore.
All of which goes to show, I suppose, that there's no such thing as a single answer for all occasions!
Indeed ;) Andreas -- Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn,Jennifer Guild,Felix Imendörffer,HRB16746 (AG Nürnberg) GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2012-08-10 10:33, Andreas Jaeger wrote:
On 08/10/2012 10:27 AM, Robin Klitscher wrote:
Even if we would forbid it for new systems, it would break one of openSUSE key successes: You can update a system from one version to the other. So, we do need to support existing systems with /usr as separate partition. But I woouldn't advocate it anymore.
Thank you! :-) I appreciate that. Because that's indeed my case, my system is inherited from 6.2. I see a slight advantage in spreading the system over several hard disks (faster), but on new systems I don't usually bother to create a separate /usr.
All of which goes to show, I suppose, that there's no such thing as a single answer for all occasions!
Indeed ;)
Yep. - -- Cheers / Saludos, Carlos E. R. (from 12.1 "Asparagus" GM (bombadillo)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlAlEbIACgkQU92UU+smfQX7AQCbBYc8UzTeNwzXiXTAk41TI8tb Yu4AoIl/sF/QuQFk/q5N//WLURYaJfvv =FiMe -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 08/09/2012 11:11 PM, Rodney Baker wrote:
The FHS is complementary to the LSB which (afaik) openSuSE purports to be more or less compliant with (but I'm open to be corrected if that is wrong). Therefore, openSuSE should also be compliant with the LHS.
It is the "more or less" part that has led to the complete failure of FHS to accomplish the purposes for which it was envisioned. The FHS in its present form is an excellent standard which if complied with would provide for better cross distro portability of all opensource code and accomplish its intended purpose of providing a standard framework of file locations to be relied on by those developing software for Linux. The genesis of the project was to solve the issue years ago of "why do all the good games only run on ms..." However, instead of embracing FHS, the opensource community created libtool, automake, etc... Distros selectively implemented parts of FHS and chose in a non-consistent manner and made use of FHS <alternative> designation for reasons other than strictly providing cross-compile capabilities (e.g. /lib, /lib64, etc..) Now some distros do not even provide all the elements of FHS, instead choosing to only provide symlinks to e.g. /lib. The present FHS is a good standard. Things can always be improved, any dramatic changes would just further undercut the legitimacy of FHS as a Linux-wide standard by providing more reason for individual distros to 'depart' from a radically changed new standard. I agree with Rodney, if this is something that Linux wants to make work, then we should all provide comment on the proposed FHS changes to insure the end product is something that makes sense to implement, instead of just becoming another well intentioned idea at the end of a link ending in .pdf... -- David C. Rankin, J.D.,P.E. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 08/14/2012 07:37 AM, David C. Rankin wrote:
On 08/09/2012 11:11 PM, Rodney Baker wrote:
The FHS is complementary to the LSB which (afaik) openSuSE purports to be more or less compliant with (but I'm open to be corrected if that is wrong). Therefore, openSuSE should also be compliant with the LHS.
I agree with Rodney, if this is something that Linux wants to make work, then we should all provide comment on the proposed FHS changes to insure the end product is something that makes sense to implement, instead of just becoming another well intentioned idea at the end of a link ending in .pdf...
+5 The divergence form the standard, seemingly at whim, is frustrating. jd -- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 08/14/12 13:56, j debert pecked at the keyboard and wrote:
On 08/14/2012 07:37 AM, David C. Rankin wrote:
On 08/09/2012 11:11 PM, Rodney Baker wrote:
The FHS is complementary to the LSB which (afaik) openSuSE purports to be more or less compliant with (but I'm open to be corrected if that is wrong). Therefore, openSuSE should also be compliant with the LHS.
I agree with Rodney, if this is something that Linux wants to make work, then we should all provide comment on the proposed FHS changes to insure the end product is something that makes sense to implement, instead of just becoming another well intentioned idea at the end of a link ending in .pdf...
+5
The divergence from the standard, seemingly at whim, is frustrating.
jd
And also why linux will never become mainstream. Until all of the different flavors of linux get together and agree to a standard regarding something as simple a filesystem layout big business will never take it serious. -- Ken Schneider SuSe since Version 5.2, June 1998 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Tue, Aug 14, 2012 at 3:21 PM, Ken Schneider - openSUSE
On 08/14/12 13:56, j debert pecked at the keyboard and wrote:
On 08/14/2012 07:37 AM, David C. Rankin wrote:
On 08/09/2012 11:11 PM, Rodney Baker wrote:
The FHS is complementary to the LSB which (afaik) openSuSE purports to be more or less compliant with (but I'm open to be corrected if that is wrong). Therefore, openSuSE should also be compliant with the LHS.
I agree with Rodney, if this is something that Linux wants to make work, then we should all provide comment on the proposed FHS changes to insure the end product is something that makes sense to implement, instead of just becoming another well intentioned idea at the end of a link ending in .pdf...
+5
The divergence from the standard, seemingly at whim, is frustrating.
jd
And also why linux will never become mainstream. Until all of the different flavors of linux get together and agree to a standard regarding something as simple a filesystem layout big business will never take it serious.
Where is your big business perspective coming from? Because Linux is the only thing taken seriously these days. The new deployments of Solaris, AIX, and HP-UX are the exception, not the rule. My observations come from working as a Unix system administrator at a Fortune 100 telecom company. Also, the total lack of a filesystem standard didn't keep big business from from adopting the aforementioned dinosaurs in the first place. -- Chris -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 15/08/12 02:37, David C. Rankin wrote:
I agree with Rodney, if this is something that Linux wants to make work, then we should all provide comment on the proposed FHS changes to insure the end product is something that makes sense to implement, instead of just becoming another well intentioned idea at the end of a link ending in .pdf...
Even to a non-technical user like myself, from comments in this thread it's blindingly obvious that a published standard and the manner in which some distributions are implemented have parted company, or are about to. This is worrying, for how can it be good? If the standard is inappropriate, let it be amended accordingly. If it is irrelevant, or otherwise to be ignored, why put effort into maintaining it? Instead, let developers do what they fancy and to the devil with consistency, thus adding yet another layer of confusion to the existing anarchy that already limits the appeal of the Linux operating system as a serious contender in the field. Otherwise, if the standard is valid, let it be adhered to so the results are not only understood but consistent. And in that case, doesn't it make more sense to put effort into ensuring the standard is appropriate than simply to dismiss it as a sideshow? I don't know - I'm only asking ....... -- Robin K Wellington "Harbour City" New Zealand -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 8/14/2012 5:13 PM, Robin Klitscher wrote:
On 15/08/12 02:37, David C. Rankin wrote:
I agree with Rodney, if this is something that Linux wants to make work, then we should all provide comment on the proposed FHS changes to insure the end product is something that makes sense to implement, instead of just becoming another well intentioned idea at the end of a link ending in .pdf...
Even to a non-technical user like myself, from comments in this thread it's blindingly obvious that a published standard and the manner in which some distributions are implemented have parted company, or are about to. This is worrying, for how can it be good?
If the standard is inappropriate, let it be amended accordingly. If it is irrelevant, or otherwise to be ignored, why put effort into maintaining it? Instead, let developers do what they fancy and to the devil with consistency, thus adding yet another layer of confusion to the existing anarchy that already limits the appeal of the Linux operating system as a serious contender in the field.
Otherwise, if the standard is valid, let it be adhered to so the results are not only understood but consistent. And in that case, doesn't it make more sense to put effort into ensuring the standard is appropriate than simply to dismiss it as a sideshow?
I don't know - I'm only asking .......
Unfortunately, that "anarchy" is an indelible facet of one of the major values of unix and linux in the first place. The benefits of standardization are obvious, but it should also be obvious that no single standard can serve every need. Too much standardization about too many of the details only comes at the expense of flexibility and suitability for other jobs. That is why the standards *try* not to define too many details, but rather to define features, and leave it up to the system how to provide those features. They do of course define a lot of details, but they try not to wherever possible. They don't say a file will have exactly this name and be found in exactly this directory, they say a file that does this job will exist somewhere, and this rule can be used to determine where it is on the spot. For instance, they don't say a binary will be found in a certain directory, they say a variable named $PATH will be searched for binaries. And they don't say how $PATH will get filled. There is no universal file or set of files that sets $PATH. That's on purpose. You _want_ that. Unix is not a product, it's a tool box. You are _supposed_ to assemble the tools in your own ways because it's _supposed_ to be agnostic enough to be useful for anyone and anything without knowing ahead of time what those needs might be. You are _supposed_ to be able to make a race car or a dump truck or a bicycle out of it, or whatever you happen to need at the time that no one could have predicted before hand. Rather than try to think of everything and fail because that's impossible, they just provide intentionally open-ended tools, and so you are well served when 20 years later you discover that you need sail-roller-blades. It's like, instead of trying to assemble a list of all possible integer values you might need, instead you just have 10 tiny numbers from 0 to 9, and a simple rule to use those 10 digits to express any infinite and unpredictable value you might ever need to express forever. So it's a balance. Some standardization is helpful. Utter anarchy isn't useful because no admin or user can ever figure out anyone elses system, and no software can be shared between systems. But too much removes what is the _core_ value of unix in the first place. This is why systemd drives me crazy. Systemd basically says, here's 0,1,2,8. There is no 7. You don't need 7. If you think you need 7, it actually just means you're doing something wrong. I don't actually know what you're doing by the way, never the less, I know you don't need 7. It's perfectly ok to invent systemd and for some systems to use it. That is entirely within the free world of unix. But it's just not a good tool for managing a general purpose OS like Suse. It's good for highly specialized, limited, focused and managed black boxes like appliances, phones, tablets, maybe chromebooks. But until it becomes as flexible as the shell scripts it's replacing (which it could, they just refuse to), it's no good for a general purpose OS. It makes the OS more efficient for some things, more manageable, and less useful. -- bkw -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 15/08/12 12:18, Brian K. White wrote:
So it's a balance. Some standardization is helpful. Utter anarchy isn't useful because no admin or user can ever figure out anyone elses system, and no software can be shared between systems. But too much removes what is the _core_ value of unix in the first place.
Which, in a nutshell, is what I was trying to say in my own clumsy way. Balance is the watchword - balance between impenetrable chaos and stultifying order. Or, come to think of it, perhaps a better word is discipline. And in that context, as the man said, there's no such thing as a free lunch.... -- Robin K Wellington "Harbour City" New Zealand -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 08/14/2012 07:18 PM, Brian K. White wrote:
It's perfectly ok to invent systemd and for some systems to use it. That is entirely within the free world of unix. But it's just not a good tool for managing a general purpose OS like Suse. It's good for highly specialized, limited, focused and managed black boxes like appliances, phones, tablets, maybe chromebooks. But until it becomes as flexible as the shell scripts it's replacing (which it could, they just refuse to), it's no good for a general purpose OS. It makes the OS more efficient for some things, more manageable, and less useful.
Why do distributions seem to drink the same kool-aid? Some seem to just run to the punch bowl and fill their cup with the latest batch, while others linger talking to friends until they get thirsty. However, due to the fact that only one punch bowl is chilled -- all seem to eventually drink from it. Systemd is a great example. I have not run into a limitation that init-scripts cannot accommodate, but since it seem that handhelds are capable of booting it, we now have everyone in the room (Linux distros collectively) running to dump init-scripts and move to systemd, just because it looks like some new fancy-colored punch in the bowl. As with all new recipes, it's not quite done, and it needs a few more ingredient before it actually tastes as good as the old... But since it is new, let's just abandon our old favorite and rush to the new... I'm all for improved, more capable, more flexible, etc..., but sometimes is seems there is no compelling reason for a new flavor of punch. Systemd seems like the poster child of this craze... In all of the discussion about systemd, all anyone should care about is: (1) Does systemd provide *needed* additional capabilities that are not currently available; (2) What are they? (3) What are the disadvantages of the switch? (4) Do the advantages significantly outweigh the disadvantages, taking into consideration the time, talent and energy required to implement the change (for both the developers and end-users)? If it is justified -- do it. If it is just being pushed because it is somebody pet project, then seriously consider impacting all end-users before foisting the change on them. It just leaves Linux looking punch-drunk... -- David C. Rankin, J.D.,P.E. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 8/27/2012 11:22 AM, David C. Rankin wrote:
On 08/14/2012 07:18 PM, Brian K. White wrote:
It's perfectly ok to invent systemd and for some systems to use it. That is entirely within the free world of unix. But it's just not a good tool for managing a general purpose OS like Suse. It's good for highly specialized, limited, focused and managed black boxes like appliances, phones, tablets, maybe chromebooks. But until it becomes as flexible as the shell scripts it's replacing (which it could, they just refuse to), it's no good for a general purpose OS. It makes the OS more efficient for some things, more manageable, and less useful.
Why do distributions seem to drink the same kool-aid? Some seem to just run to the punch bowl and fill their cup with the latest batch, while others linger talking to friends until they get thirsty. However, due to the fact that only one punch bowl is chilled -- all seem to eventually drink from it.
I was just musing about that the other day while installing 12.1 and trying to fathom the seemingly every-other-year wholesale swapout of sound systems and their component parts. We've come from virtually no sound support back in the SuSE 5 days to having 3 or 4 systems all stepping all over each other to determine who or what is going to handle the sound. And the about faces are sudden, and imperfect, with lots of stuff failing to work, and just when you thing its coming together there is another zig-zag. Reminds me of small bird flocks which all turn at once on no apparent signal, except for the few that always seem to get trimmed off, and have to play catch-up. The co-pilot may not be on board yet, the cabin crew haven't got everyone in their seats, they are not finished fueling, we've got no clearance to taxi, two flat tires, and one of our engines wont spool up, but by god we are going to take off anyway. -- _____________________________________ ---This space for rent--- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Hello, On Mon, 27 Aug 2012, John Andersen wrote:
On 8/27/2012 11:22 AM, David C. Rankin wrote:
On 08/14/2012 07:18 PM, Brian K. White wrote:
It's perfectly ok to invent systemd and for some systems to use it. That is entirely within the free world of unix. But it's just not a good tool for managing a general purpose OS like Suse. [..] Why do distributions seem to drink the same kool-aid? Some seem to just run to the punch bowl and fill their cup with the latest batch, while others linger talking to friends until they get thirsty. However, due to the fact that only one punch bowl is chilled -- all seem to eventually drink from it.
ACK.
I was just musing about that the other day while installing 12.1 and trying to fathom the seemingly every-other-year wholesale swapout of sound systems and their component parts.
Just install sysvinit instead.
We've come from virtually no sound support back in the SuSE 5 days to
Well, 5.3 had OSS.
having 3 or 4 systems all stepping all over each other to determine who or what is going to handle the sound.
I use only ALSA. No pulse, no phonon, just their libs, but I do have quite a bit of gstreamer installed as some apps I use need those.
And the about faces are sudden, and imperfect, with lots of stuff failing to work, and just when you thing its coming together there is another zig-zag. Reminds me of small bird flocks which all turn at once on no apparent signal, except for the few that always seem to get trimmed off, and have to play catch-up.
The co-pilot may not be on board yet, the cabin crew haven't got everyone in their seats, they are not finished fueling, we've got no clearance to taxi, two flat tires, and one of our engines wont spool up, but by god we are going to take off anyway.
Nice analogy. -dnh -- Sufficiently advanced incompetence is indistinguishable from malice. -- dima -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
* David C. Rankin
If it is justified -- do it. If it is just being pushed because it is somebody pet project, then seriously consider impacting all end-users before foisting the change on them. It just leaves Linux looking punch-drunk...
-- David C. Rankin, J.D.,P.E.
Andy Rooney would be proud :^) -- (paka)Patrick Shanahan Plainfield, Indiana, USA HOG # US1244711 http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 http://en.opensuse.org openSUSE Community Member Registered Linux User #207535 @ http://linuxcounter.net -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Mon, Aug 27, 2012 at 2:22 PM, David C. Rankin
On 08/14/2012 07:18 PM, Brian K. White wrote:
It's perfectly ok to invent systemd and for some systems to use it. That is entirely within the free world of unix. But it's just not a good tool for managing a general purpose OS like Suse. It's good for highly specialized, limited, focused and managed black boxes like appliances, phones, tablets, maybe chromebooks. But until it becomes as flexible as the shell scripts it's replacing (which it could, they just refuse to), it's no good for a general purpose OS. It makes the OS more efficient for some things, more manageable, and less useful.
Why do distributions seem to drink the same kool-aid? Some seem to just run to the punch bowl and fill their cup with the latest batch, while others linger talking to friends until they get thirsty. However, due to the fact that only one punch bowl is chilled -- all seem to eventually drink from it.
Systemd is a great example. I have not run into a limitation that init-scripts cannot accommodate, but since it seem that handhelds are capable of booting it, we now have everyone in the room (Linux distros collectively) running to dump init-scripts and move to systemd, just because it looks like some new fancy-colored punch in the bowl.
As with all new recipes, it's not quite done, and it needs a few more ingredient before it actually tastes as good as the old... But since it is new, let's just abandon our old favorite and rush to the new...
I'm all for improved, more capable, more flexible, etc..., but sometimes is seems there is no compelling reason for a new flavor of punch. Systemd seems like the poster child of this craze...
In all of the discussion about systemd, all anyone should care about is:
(1) Does systemd provide *needed* additional capabilities that are not currently available;
(2) What are they?
(3) What are the disadvantages of the switch?
(4) Do the advantages significantly outweigh the disadvantages, taking into consideration the time, talent and energy required to implement the change (for both the developers and end-users)?
If it is justified -- do it. If it is just being pushed because it is somebody pet project, then seriously consider impacting all end-users before foisting the change on them. It just leaves Linux looking punch-drunk...
David, There were tons of emails pro/con the move to systemd on the factory mailing list about 15 months ago. I can't say I remember all the pros/cons, but go hit the factory archives if you want to see them. IIRC, the biggest issue was integration with newer messaging sub-systems like d-bus. Greg -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Mon, 2012-08-27 at 13:22 -0500, David C. Rankin wrote:
On 08/14/2012 07:18 PM, Brian K. White wrote:
It's perfectly ok to invent systemd and for some systems to use it. That is entirely within the free world of unix. But it's just not a good tool for managing a general purpose OS like Suse.
Yes, it is a great tool and a huge improvement.
Systemd is a great example. I have not run into a limitation that init-scripts cannot accommodate,
Which is?
but since it seem that handhelds are capable of booting
That hardly describes the motivation behind systemd.
we now have everyone in the room (Linux distros collectively) running to dump init-scripts and move to systemd,
Yes, thank goodness. Init scripts are a cruddy hack.
just because it looks like some new fancy-colored punch in the bowl.
No, because it solves numerous problems.
I'm all for improved, more capable, more flexible, etc..., but sometimes is seems there is no compelling reason for a new flavor of punch. Systemd seems like the poster child of this craze...
Nope, the reasons are numerous and have been frequently enumerated.
In all of the discussion about systemd, all anyone should care about is: (1) Does systemd provide *needed* additional capabilities that are not currently available; (2) What are they? (3) What are the disadvantages of the switch? (4) Do the advantages significantly outweigh the disadvantages, taking into consideration the time, talent and energy required to implement the change (for both the developers and end-users)?
And this has been discussed openly and frequently. http://en.wikipedia.org/wiki/Systemd https://lwn.net/Articles/389149/ "It is intended to provide a better framework for expressing services' dependencies, allow more work to be done concurrently at system startup, and to reduce shell overhead." It solves the nasty problem of forking daemons where a fork 'disappears' Your shell script *CAN NOT* solve that problem. Services can be activated on demand and *reliably* determine if another service the service depends on is running. Read http://freedesktop.org/wiki/Software/systemd/
If it is justified -- do it
It is justified.
Hello, On Wed, 15 Aug 2012, Robin Klitscher wrote:
Even to a non-technical user like myself, from comments in this thread it's blindingly obvious that a published standard and the manner in which some distributions are implemented have parted company, or are about to. This is worrying, for how can it be good?
Actually, to me it seems distributions are getting closer to each other, for part because adhering to the FHS, and also and to me partly much more annoyingly by adhering to freedesktop.org. There's tons of stuff from there I just can't stand and yet not avoid. *gah* -dnh -- Die Frau soll das Schmuckstück des Mannes sein. Tja! Manche Schmuckstücke können recht teuer sein. [WoKo in dag°] -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Hello, On Tue, 14 Aug 2012, David C. Rankin wrote:
However, instead of embracing FHS, the opensource community created libtool, automake, etc...
Whooopsie there, David, autotools and libtool are quite a bit older than the FHS! The FHS is for linux, autotools and libtool are for linux, basically all unices still out there (including Darwin), Win, and a bunch of othere OSes I've never heard of ;) And yes: I did once unpack the wget-tarball on winders with a cygwin bash (IIRC) and M$ compilers etc. ./configure, (n?)make and just put the wget.exe somewhere in %PATH%. -dnh -- A common mistake that people make, when trying to design something completely foolproof is to underestimate the ingenuity of complete fools. -- Douglas Adams - Mostly Harmless -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
participants (25)
-
Adam Tauno Williams -
Andreas Jaeger -
Anton Aylward -
Basil Chupin -
Brian K. White -
Carlos E. R. -
Christofer C. Bell -
Dave Howorth -
David C. Rankin -
David Haller -
Felix Miata -
Greg Freemyer -
ianseeks -
j debert -
James Knott -
John Andersen -
Ken Schneider - openSUSE -
lynn -
Nick LeRoy -
Patrick Shanahan -
Per Jessen -
Robin Klitscher -
Rodney Baker -
Ruediger Meier -
Werner Flamme