SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
@elvis4526: I was just looking through your repro and reading your README. Just a heads up, /etc/os-release is included in the upcoming Slackware 14, so you won't need to supply it in the future.
@elvis4526: I was just looking through your repro and reading your README. Just a heads up, /etc/os-release is included in the upcoming Slackware 14, so you won't need to supply it in the future.
Thanks for the info. Finally, I replaced the file that I made myself with the one from current, with the exception that I replaced the version numbers for 13.37.
The udev0 -> udev1 change is pretty challenging indeed. Anything linking against version 0 of udev will need recompiling (a bit more than the "x" series). Also, in the "x" series, I think only xorg-server, and a few of the drivers (-ati, -intel, -evdev, -nouveau ?) actually need rebuilding, not the entire stack.
I don't use a full slackware install myself, but also needed a few things like bluez, libatasmart, lvm, ... Arch linux has decent reverse-deps list that I guided myself through:
Also, about the instructions, it might be nice to use upgradepkg's replace feature, instead of first removing udev ? upgradepkg oldpackage%newpackage will replace stand-alone udev with the one included within systemd.
I don't have a problem with parallelizing boot, keeping more track of deamons started, cleaning everything up but I wish there wasn't this tendency to make things less modular (stick udev together with init, don't allow separate /usr, etc. ) Sure in some situations it won't much matter but why limit flexibility
The udev0 -> udev1 change is pretty challenging indeed. Anything linking against version 0 of udev will need recompiling (a bit more than the "x" series). Also, in the "x" series, I think only xorg-server, and a few of the drivers (-ati, -intel, -evdev, -nouveau ?) actually need rebuilding, not the entire stack.
I don't use a full slackware install myself, but also needed a few things like bluez, libatasmart, lvm, ... Arch linux has decent reverse-deps list that I guided myself through:
Also, about the instructions, it might be nice to use upgradepkg's replace feature, instead of first removing udev ? upgradepkg oldpackage%newpackage will replace stand-alone udev with the one included within systemd.
"Also, in the "x" series, I think only xorg-server, and a few of the drivers (-ati, -intel, -evdev, -nouveau ?) actually need rebuilding, not the entire stack."
Yes, I tought about that too. When I orginally wrote the README, I felt a bit lind when I learned that somes package should be recompiled. When I saw xorg freezing, I knew the problem was within the x series, so to catch everything, I just recompiled everything. But yeah, the arch reverse-dep list makes a lot of sense. For upgradepkg udev, I tought that it could break if we do it with upgradepkg. Besides udev being in systemd, the systemd packages contains a lot of new binary, etc...
BUT, if the part from from that say that upgradepkg just install the new package and remove the old file that aren't present in the new packages is true, yes, maybe it is a better solution.
Well, I'll have something interesting to do to night.
I don't have a problem with parallelizing boot, keeping more track of deamons started, cleaning everything up but I wish there wasn't this tendency to make things less modular (stick udev together with init, don't allow separate /usr, etc. ) Sure in some situations it won't much matter but why limit flexibility
Did you actually know that a systemd package is like 7-8 binary (maybe more), and you can delete those that you don't want ?
I don't see what isn't modular here.
This is extremely wrong to say that systemd does not allow seperate /usr partition too. You shoud REALLY read this: http://freedesktop.org/wiki/Software...-usr-is-broken
1) Initramfs is supposed to be optional
2) Initramfs results in duplicate versions of core system utilities
3) The utilities of the initramfs tree are built differently than the "runtime" versions (typically being statically linked, or linked to different libraries)
4) Initramfs increases the RAM needed by the system (while Linux can run on 16Mb, initramfs typically demands 64Mb for booting)
5) Initramfs duplicating /sbin utilities takes away space on the install media
6) Initramfs entails a (rather large) init script to be executed before handing over control to the system init.
While none of these are insurmountable, and in many situations are not particularly problematic, they are issues to be contended with (and some of us would rather not be forced into doing so).
Linux has always been a system that can cater to legacy hardware that not only still viable for usage but for resurrecting systems that Windows has forgotten about and no longer cares to support.
The fact I can load Slackware 13.37 on an old Toshiba V3100 series with a Celeron 500mhz and 256mb SDRAM using an Intel 82810 chipset, Voodoo 3 3000 PCI graphics, Intel Pro/100 Ethernet, and Aureal Vortex 8810 audio and still run the system fine and allow my niece a PC a learn on for her educational needs is what makes Linux a choice OS for me...
No fancy-shmancy hardware needed, the software is always supported to some extent, and if I do install the next version, everything is still supported and works. It takes a while longer to compile stuff from source when needed, but the system still chugs away.
Old systems often are neglected because people feel they can't use them. I've seen a start-up server farm in my area always having ads in the paper buying up old PCs so they can reformat them, put them in their clusters, and revive them for usage with Linux based operating systems so that they can offer stuff like server disk space and web and file hosting to customers while they budget in newer server equipment.
It's funny seeing old laptops being used as servers, but when you can get something up and running for cheap, it pays off.
Using bloated initramfs files, more system resource intensive daemons, and duplicating too much stuff that costs disk space... all that is going to push people away from Linux where they used Linux to get older hardware running again.
I don't have a problem with parallelizing boot, keeping more track of deamons started, cleaning everything up but I wish there wasn't this tendency to make things less modular (stick udev together with init, don't allow separate /usr, etc. ) Sure in some situations it won't much matter but why limit flexibility
I was in the same boat for awhile. Especially when things like the journal started showing up. But after stepping back a little bit, systemd is a rather neat idea as a core. It's responsible for bringing up the system, handling devices and services effectively and intelligently, and giving the user complete control and information about the whole thing. And it works really well, in practice.
And about the claim to being heavy, I'm not sure that's completely true - people in the embedded world have already started consuming systemd for it's benefits of quick boot and access time. But, systemd does require some new linux technology. Personally, I think using powerful features we have available makes sense, but again, the "linux only" point is mostly political by now.
And last, just to be clear, systemd would NOT require the user to use an initrd. It's just solution to people wanting to do a separate /usr and having some unique requirements. Systemd just prints the small notice that people should pay attention in this situation, and mounting in an initrd to solve the problem seems pretty valid, systemd or not.
I was in the same boat for awhile. Especially when things like the journal started showing up. But after stepping back a little bit, systemd is a rather neat idea as a core. It's responsible for bringing up the system, handling devices and services effectively and intelligently, and giving the user complete control and information about the whole thing. And it works really well, in practice.
And about the claim to being heavy, I'm not sure that's completely true - people in the embedded world have already started consuming systemd for it's benefits of quick boot and access time. But, systemd does require some new linux technology. Personally, I think using powerful features we have available makes sense, but again, the "linux only" point is mostly political by now.
And last, just to be clear, systemd would NOT require the user to use an initrd. It's just solution to people wanting to do a separate /usr and having some unique requirements. Systemd just prints the small notice that people should pay attention in this situation, and mounting in an initrd to solve the problem seems pretty valid, systemd or not.
Tell that to Allen Cox the guy that messed up the Kernel Code and then blamed it on KDE for its apps not working right... Now all he does is troll around Linus and Lennart for a living. I can stand up and say that systemd on my Fedora box has not given me any probs at all. As a matter of fact my biggest prob with Fedora is Gnome 3 and I think they will add a Mate desktop for Fedora 18 as alternative. Never tried Mate but Gnome 2 and KDE is my favorites (prefer Gnome 2). As far as systemd, it boots flawlessly of my use for the past few months. The biggest problem I had was that I had to manually shut off after a "halt" a few times due to hardware I was using it on. I had more problems on regular init then with systemd even though it loads a hell of a lot more crap on boot it still loads faster and works better for me. So when I read all this anti systemd posts from people who have never even tried it... I am like... Really?
PS: I wasnt gonna post until I read the comment about BrianL praying to Bob... I just wanted to prove that his God is a fake
Last edited by Mercury305; 08-27-2012 at 03:53 PM.
Over the years, cool theories have been developed to explain or justify the /bin-/usr/bin split. The real reasons may be more down to earth, as it is nicely explained by Rob Landley on his blog and this paper http://landley.net/writing/hackermon...ue022-pg33.pdf
So no, the /bin-/usr/bin split is not the result of 40 years of careful innovation
LOL I wasn't going to comment on the glorification of unix in this thread, but it is so funny how this paper confirms my long-held suspicions.
Btw, I don't hold those suspicions just on the / vs. /usr split, but on any standards that supposedly are the result of decades of "evolution" or "experience". Ususally there is some totally down-to-earth act of random at the birth of anything.
NB: the term "evolution" requires the mechanisms of replication (usually generation based), mutation and survival of the fittest. the term "experience" requires an authority making those experiences and re-designing the standard. Both of which don't really exist in a pluralistic population where each participating agent copies from the other.
Btw, there is the (now ancient) unix haters handbook that tries to take some more shine of the glorified operating system. Eric S Raymond blogged about it in as late as 2008, and gave it a little credit here and there (although on the whole he dismissed it):
LOL I wasn't going to comment on the glorification of unix in this thread, but it is so funny how this paper confirms my long-held suspicions.
Btw, I don't hold those suspicions just on the / vs. /usr split, but on any standards that supposedly are the result of decades of "evolution" or "experience". Ususally there is some totally down-to-earth act of random at the birth of anything.
NB: the term "evolution" requires the mechanisms of replication (usually generation based), mutation and survival of the fittest. the term "experience" requires an authority making those experiences and re-designing the standard. Both of which don't really exist in a pluralistic population where each participating agent copies from the other.
Btw, there is the (now ancient) unix haters handbook that tries to take some more shine of the glorified operating system. Eric S Raymond blogged about it in as late as 2008, and gave it a little credit here and there (although on the whole he dismissed it):
To see what Rob Pike thinks about "Unix Philosophy".
It is very interesting to observe the creators (masters) talk in their own words.
Its interesting how a cult can form around statements made 40 years ago... disregarding the fact that technology keeps it moving forward.
I guess this is how religion gets formed. Jee I wonder what Jesus really said that led to the KJV we have now.
Bob was wrong about the end of the world and now... more light is poured into this dark abyss of mindlessness by your most hated Mercury305.
...But honestly I still believe in Unix Philosophy. In a terminal it makes more sense to have tools for 1 purpose. Even if Rob himself denies it. That way I can pipe things. But I am doublethinking on this. In other words big programs can work too... why not? Isn't Linux itself a big program with many pieces? (since programs are executable files run with instructions.)
Last edited by Mercury305; 08-27-2012 at 04:15 PM.
The article says Linux in general doesn't work with /usr on a separate partition. The example they use to prove their case, is a udev rule that won't work if /usr is unavailable.
Newsflash: Stuff that relies on /usr won't work without /usr.
I would like to point out that "/usr on a separate partition and/or file system" != "not having /usr available at all". Also, "Linux" != "a system running udev".
This is just silly. If /usr lives on the / file system, it is obviously always available. If it's somewhere else, it has to be mounted first. Since udev may need to access stuff that's in /usr, how about mounting /usr before starting udev? Or you could, you know, move stuff that's needed early in the boot process to a location that's available at boot time. I fact, I believe there used to be a directory called /lib for things like that.
The article just tries to obfuscate the real problem, which is that udev is now integrated into systemd, so you can no longer delay starting udev.
Here's a short, very in-comprehensive list of software we are aware that currently they are not able to provide the full set of functionality when /usr is split off and not pre-mounted at boot: udev-pci-db/udev-usb-db and all rules depending on this (using the PCI/USB database in /usr/share), PulseAudio, NetworkManager, ModemManager, udisks, libatasmart, usb_modeswitch, gnome-color-manager, usbmuxd, ALSA, D-Bus, CUPS, Plymouth, LVM, hplip, multipath, Argyll, VMWare, the locale logic of most programs and a lot of other stuff.
Yeah... udev-pci-db/udev-usb-db , PulseAudio, NetworkManager, ModemManager, udisks, libatasmart - all coming out of the same (red) hat.
I call this self-fulfilling prophecy: first you write a lot of programs which kill established UNIX functionality, then demand that people start using it, "or else"... and then cry that Linux did not really support a separate /usr anyway so why bother supporting it. I call bullshit.
I call this self-fulfilling prophecy: first you write a lot of programs which kill established UNIX functionality, then demand that people start using it, "or else"... and then cry that Linux did not really support a separate /usr anyway so why bother supporting it. I call bullshit.
It looks a lot like a tactic known as "embrace, extend, extinguish".
And "systemd is just the messenger". Yes, it's the messenger saying "I'm sorry, you can't do that anymore. Because of me."
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.