![](https://seccdn.libravatar.org/avatar/aea1d8248292e6482742234c5cb514de.jpg?s=120&d=mm&r=g)
You are not reading what I am saying in whole. You are taking sections and rallying against them, but if you read the whole thing, you find you are disagreeing with something I don't believe. Anton Aylward wrote:
Linda Walsh said the following on 02/06/2013 01:48 AM:
Anton Aylward wrote:
And no, I don't think the the changes we've seen are "ill-thought-out changes that serve no purpose".
Yet when asked for reasons WHY -- NO ONE can come up with an answer. If you have one, let's hear it.
Perhaps if you can deal with specifics rather than generalizations, and perhaps if you want me to do your googling for you...
But I suspect this is RELIGION. I'm not a <strike>doctor</strike> True Believer, I'm an engineer. "It Works for me" and works well.
I'm a scientist graduated from an engineering background. Works for me isn't always enough -- I want to know how it works as well -- I test, I benchmark, I research.
---- Insult? Saying something an idea is ill-thought out is hardly an insult. I can't say an idea is 'bad' without it being an "insult"? If I don't agree, I'm insulting? Um... excuse me!
There are people who devoted a great deal of time effort, though and experimentation to matters such as systemd. Saying it was 'ill-thought out" is saying that they had inferior though processes. I would see that as insulting.
Ill thought out doesn't mean 'ill thought processes', it means they didn't use their abilities and didn't do "due-diligence". Usually it means insufficient (not inferior) consideration was given as they took someone else's word for it -- that's the *usually* definition in my experience. In this case, since the root of this idea stems from the much reviled Microsoft (the designer admits to the the config files being almost an exact carry over from the many ".ini" files of Win98/XP (Win7 is more XML based or other higher-level language based -- not to mention registry). Case in point -- has been the move away from a central local for config files in /etc/sysconfig, and a proliferation of config files spread out in per-package locations. This was already shown to be a bad idea by MS for system management -- but it is a phase they went through 10 years ago. Seems like we are getting their 10-20 year old ideas...
There's a lot of things that are well thought out but constrained in the implementation because of other constraints such as economics and ability to manufacture. Automotive engineering has a lot of the former (we could build really great cars but they would cost 100 times as much) and aeronautics the latter - we often simply don't have materials to do the job. But this is software. neither of those apply. If you can think it through you can build it and we do and we have.
Or if you can take current ideas on the subject rather than using 10-20 year old ideas that were rejected for their problems, you can leap-frog ahead. Do you think MS and Apple use each other's 10 year old ideas? They readily pay attention to state-of-the-art.
---- lilo can already boot from lvm, but that's neither here nor there... You could have had your cake and I could have had mine too -- BOTH could have their way -- and neither HAD to step on the other's toes to get to where you want to go.
Ah, religion at work again. That you CAN doesn't mean you should or have to. That you choose to ...
Religion? That's an irrational holding to a belief that something is a certain way. You claimed, irrationally, that the new system gets away from a limited size boot and allows you to boot from LVM. I boot from a RAID5 with XFS -- someting grub hasn't supported directly from disk and still doesn't AFAIK. Whether the earth is flat or round isn't religion (well some people believed it was), but, really, it isn't. But I said, that wasn't important -- since you could have your way of doing things and I could have my way -- BOTH could have our way AT the same time with a better solution.
You seem to be asking for two things. The first is that we are not to be given choices.
---- You misread what I wrote.
The second is that the result of that lack of choice is to stick with the old way of doing things.
You misread what I wrote. I'm saying both could have been provided with less work than has been done to date.
My point here is that I have choices and I choose to exercise them; the whole point of Linux and FOSS is that there is no 'state religion' as with Microsoft.
Where do you think these ideas of a "Service Manager" that manages all states of boot and boots from hidden or encrypted partitions comes from? This is Paladium in different socks -- something roundly rejected as bad for consumers -- turning them into passive "users", and removing their capacity to be producers/creaters.
The choice to destroy the past, is the part that was ill thought out.
As you point out by insisting on LILO, the past is not destroyed. I still have all the openSuse installation CDs back to 7.something. I may have earlier ones in a box somewhere...
---- I am not insisting on Lilo. I am pointing out it solves some of the problems you had without the many changes that are ongoing. The fact that you have historical archives that are both incompatible and can't be easily integrated or work with modern software is moot. You may still have 5.25" floppies or "Dec-tape" for storage. Try using that with any modern machine.
Now how can you claim that is not, at least, "ill thought out" -- and that's giving the benefit of the doubt of malice, but writing this -- I don't see any other point other than malice to do it that way.
You are picking on 'just one thing'. The integration of "/" and "/usr" was driven by many other ENGINEERING factors. Prime among them was systemd. As Felix says
Which was later shown to not need such. My latest system (which will work until the next upgrade), boots just fine with systemd (except for it's video corruption) with /usr NOT mounted. The engineering factors were, after further *thought*, were found not to be necessary -- and that's a prime example of the initial decision "ill thought out" -- there was a jump & leap before the engineering factors were examined by Suse experts -- who I suspect are a bit more circumspect (or have been) than fedora engineers (though RedHat has a few high powered employees, so am not "dissing" them or those who work in fedora).
# why have you not installed # sysvinit-init to dispense with it if you think systemd is your problem?
I had it installed. Twice I've been "upgraded" to systemd. I've installed packages from 12.2 and factory -- and the trend is toward making these decisions for the user and not using their previous defaults. Example: On my boot disk, I see: (not a complete listing)... Oct 29 2011 disk.b Oct 29 2011 first.b ---- Dec 10 01:04 initrd -> initrd-3.1.10-1.16-desktop Dec 10 01:04 initrd-3.1.10-1.16-desktop Dec 10 01:04 initrd-3.1.9-1.4-vanilla Dec 10 01:04 initrd-3.2.0-Isht-Van Dec 10 01:05 initrd-3.2.21-Ish-Van Dec 10 01:05 initrd-3.2.21-Isht-Van Dec 10 01:05 initrd-3.2.29-Isht-Van Dec 10 01:05 initrd-3.2.5-pk-IshImqXen2 Dec 10 01:06 initrd-3.3.6-Ish+xen Dec 10 01:06 initrd-3.3.6-Ish-Van Dec 10 01:06 initrd-3.4.4-Ish-Vanilla Dec 10 01:06 initrd-3.5.4-Isht-Van Dec 10 01:07 initrd-3.6.0-1-desktop Dec 10 01:07 initrd-3.6.0-Isht-Van Dec 10 01:07 initrd-3.6.2-Isht-Van Dec 10 01:07 initrd-3.6.3-Isht-Van Dec 10 01:08 initrd-3.6.6-Isht-Van Dec 10 01:08 initrd-3.6.7-Isht-Van Dec 10 01:08 initrd-3.6.8-Isht-Van Dec 10 01:00 initrd-vanilla -> initrd-3.1.9-1.4-vanilla --- May 23 2011 inside.bmp May 23 2011 tuxlogo.bmp --- Jun 27 2012 vmlinux-3.1.10-1.16-desktop.gz Jan 27 2012 vmlinux-3.1.9-1.4-vanilla.gz Oct 11 03:27 vmlinux-3.6.0-1-desktop.gz Dec 4 01:20 vmlinuz -> vmlinuz-3.1.10-1.16-desktop Jun 27 2012 vmlinuz-3.1.10-1.16-desktop Jan 27 2012 vmlinuz-3.1.9-1.4-vanilla Sep 23 08:08 vmlinuz-3.2.0-Isht-Van Jun 30 2012 vmlinuz-3.2.21-Ish-Van Sep 1 01:29 vmlinuz-3.2.21-Isht-Van Sep 18 05:41 vmlinuz-3.2.29-Isht-Van Aug 22 22:13 vmlinuz-3.2.5-pk-IshImqXen2 May 31 2012 vmlinuz-3.3.6-Ish+xen Aug 7 2012 vmlinuz-3.3.6-Ish-Van Jun 28 2012 vmlinuz-3.4.4-Ish-Vanilla Oct 4 15:23 vmlinuz-3.5.4-Isht-Van Oct 11 03:13 vmlinuz-3.6.0-1-desktop Oct 4 19:47 vmlinuz-3.6.0-Isht-Van Oct 15 04:27 vmlinuz-3.6.2-Isht-Van Nov 6 17:28 vmlinuz-3.6.3-Isht-Van Nov 19 16:42 vmlinuz-3.6.6-Isht-Van Nov 21 17:09 vmlinuz-3.6.7-Isht-Van Dec 2 03:35 vmlinuz-3.6.8-Isht-Van --- Feb 2 22:16 vmlinuz-3.7.1-Isht-Van Feb 5 22:16 vmlinuz-3.7.6-Isht-Van Dec 10 01:00 vmlinuz-vanilla -> vmlinuz-3.1.9-1.4-vanilla --- Notice, some package I installed on Dec 10, built unusable initrd disks for ALL of my then existing kernels. The ones built since then don't have them. My lilo.conf -- which was unalterered, has lines like: ---------------- image = /boot/vmlinuz-3.7.6-Isht-Van label = 376-Isht-Van append = "root=/dev/sdc1 showopts console=ttyS0,115200n8 console=tty0 elevator=cfq pcie_aspm=force pcie_ports=native reboot=bios" root = /dev/sdc1 ... image = /boot/vmlinuz-3.6.8-Isht-Van label = 368-Isht-Van append = "root=/dev/sdc1 showopts console=ttyS0,115200n8 console=tty0 elevator=cfq pcie_aspm=force pcie_ports=native" root = /dev/sdc1 image = /boot/vmlinuz-3.6.7-Isht-Van label = 367-Isht-Van append = "root=/dev/sdc1 showopts console=ttyS0,115200n8 console=tty0 elevator=cfq pcie_aspm=force pcie_ports=native" root = /dev/sdc1 --- Notice NONE of them specify an initrd to use on boot. There is no way those initrd's could have been used, but the default was to create initrd's for all my kernels.
I already asked -- and NO ONE ANSWER, does /usr/bin also include /usr/SHARE?...
Don't be silly! /usr/share is under /usr not /usr/bin!
---- That wasn't being silly, the initial plan called for /bin, /sbin and the lib directories -- not share.
So far, the answer has been YES!...the "SHARE" partition has to be on the root partition too..
You can say that all you want and it doesn't make it so.
----- It's ALREADY the case: (from my boot log): done Starting udevd: done Loading drivers, configuring devices: <notice -- Feb 7 07:20:18.879116000> service boot.sysctl done udevd[187]: SYSFS{}= will be removed in a future udev version, please use ATTR{}= to match the event device, or A TTRS{}= to match a parent device, in /etc/udev/rules.d/50-euvccam.rules:1 ....(many others delete).... udevd[187]: SYSFS{}= will be removed in a future udev version, please use ATTR{}= to match the event device, or A TTRS{}= to match a parent device, in /etc/udev/rules.d/50-euvccam.rules:7 udevd[187]: BUS= will be removed in a future udev version, please use SUBSYSTEM= to match the event device, or SU BSYSTEMS= to match a parent device, in /etc/udev/rules.d/98-usbprog.rules:7 .....(list of USB probs deleted).... udevd[187]: SYSFS{}= will be removed in a future udev version, please use ATTR{}= to match the event device, or ATTRS{}= to match a parent device, in /etc/udev/rules.d/98-usbprog.rules:16 udevd[187]: SYSFS{}= will be removed in a future udev version, please use ATTR{}= to match the event device, or ATTRS{}= to match a parent device, in /etc/udev/rules.d/98-usbprog.rules:19 udevd[398]: failed to execute '/usr/share/virtualbox/VBoxCreateUSBNode.sh' '/usr/share/virtualbox/VBoxCreateUSBNode.sh 189 768 09': No such file or directory udevd[399]: failed to execute '/usr/share/virtualbox/VBoxCreateUSBNode.sh' '/usr/share/virtualbox/VBoxCreateUSBNode.sh 189 256 09': No such file or directory ...(many failures from not having /usr/share mounted deleted)... udevd[492]: failed to execute '/usr/share/virtualbox/VBoxCreateUSBNode.sh' '/usr/share/virtualbox/VBoxCreateUSBNode.sh 189 3 00': No such file or directory udevd[493]: failed to execute '/usr/share/virtualbox/VBoxCreateUSBNode.sh' '/usr/share/virtualbox/VBoxCreateUSBNode.sh 189 2 00': No such file or directory
I've told you before and I'll tell you again. I'm running an LVM system where I created a new LV that had "/" and "/usr" copied into it, the /etc/fstab edited to accommodate that an that only, and a new entry in /boot/grub2/grub.cfg to boot using that. The fstab has entries for
/usr/share, /usr/share/icons, /usr/lib/perl, /usr/lib/ruby
I also have partitions for /home/anton, /home/anton/Documents, /home/anton/Music, /home/anton/Video so I can mount them on any machine on the LAN :-) Oh, and I have no problems with such 'roving shares'.
I go for mostly higher level directories: / /usr /var /tmp->/var/rtmp, /var/cache/squid /boot /home /Share /home.diff /Media /backups /backups/Media --- My exports look completely different: Audio (/Share/Audio) backup (/backup/<hostname>) backups_by_user (/backup/<username>) Documents (/home/[<domain|host>/]<user>/Documents) home (/home # limited access) homes (/home/<domain|Host>/<User> <user> (same as homes) Media (/Media) Music (/Share/Music) Pictures (/home/<User>/Documents/Pictures) servhome (/home/<User>) #unix home dir Share (/Share) usr_share (/usr/share) usr_share_doc (/usr/share/doc) Root (/) # visible/accessible to 'Domain Admins' only Several of the above are "cross-linked" -- like Documents. The server exports Documents based on the user's Domain/host (if they aren't logged in on a domain login), and their username, yet they get the same directory based on their name.
Please stop spreading the nonsense that this s not possible, that /usr/share has to be on the root partition.
It's not nonsense -- it's from the system boot log.
I *like* the fast and parallelized boot of systemd ---- It is SLOWER, it just seems faster because it flashes the screen more...it's a Microsoft design policy -- which is where systemd's design has come from.
Considering the large number of people that have done comparative timing studies and that systemd has tools to let you see where the boot process is spending its time so you can do something about that, I'm not sure where you get the idea that a parallelized boot system is slower than the old serialised sysv-init.
I didn't say that. The system that came before systemd used a parallel make type structure. Parallel make is VERY fast. Before recent 12.1 changes, my system came up in as little as 23 seconds (to initial login & ability to serve files/web pages...etc). Now it's usually ~ 90 seconds, though minimally about 50-60, not counting the 2-3 hour sessions to get it to come up at all that happen about every other boot. I think the normal time just before I started installing 12.1 was about 33 seconds. No way 60-90 is faster, let alone the 2-3 hour repair times...which nearly always require a separate rescue disk because systemd's startup processes are designed not to be hand startable.
I'm not going to comment on your "Microsoft" observation other than to say that it seems like religion. At one time IBM was spoken of in the same anathematic tones by users of DEC/UNIX.
I've been told on this list, if I want MS Windows, then go to MS. I'm less MS-hostile than most -- if they have a good technology, I look at it and like it.
# You really think systemd has anything to do with framebuffer trouble when # you're using a video card so old
--- 3 years old? It came on the server board.
it has a dedicated section in the # framebuffer HOWTO? [1] **If** you are using 12.1 (and 12.2? 12.3?), why have you not installed # sysvinit-init to dispense with it if you think systemd is your problem?
I have -- twice. It's been upgraded on me -- twice.
If you are blaming systemd for the fact that you are using "a crap video card".
It's designed to be a server. Not a desktop. My desktop has an Nvidia 690 SLI card with 3GB memory -- that wouldn't be supported on linux in any meaningful way either!
then its clear that you are striking out irrationally because you don't understand the role of systemd.
It's clear you don't understand separation of roles and systems. I use the server as a back-end for my desktop. I want the server to do it's thing, and my Windows desktop can do it's thing. After many years I came to this solution -- and Win7 cinched it because Win7 isn't reliable with backups and files. So all my data is on the server. It does everything Windows isn't so good at -- firewall, routing, Mail server, IMAP(dovecot), fast disks, backups, DNS, web proxy, disk space (~30T on the non-root partitions, about half of which is used for backups) w/max speeds ~ 1TB/RW Win7 does the things linux isn't easy to use *or* is not good at -- multimedia (my 2nd screen is my Samsung LCD TV on the wall where I watch videos). My primary screen where I do linux devel and win-desktop app usage (photoshop, a [very] few games) is a 2560x1600 Dell. I can watch videos and do devel at the same time -- the win machine powers both fetching content from the server over what is currently a 300-400MB/s ethernet link (20Gb dedicated for my workstation, 1Gb for rest of house). What part of my HW is 'crap' and exactly where am I "stuck" in the past? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org