And you ould always compile the system with static /dev too I suppose, some packages will be broken/whine a lot but I think that a workaround could be doable since a number of people on the Gentoo forums have done it.

So anyone tried BeOS and its derivatives?

What about that Russian NT kernel clone?

Including mounting /usr over the network? Isn't systemd supposed to bring up the network?

Where a number of its own components are located
Kinda sounds like a chicken and egg problem.

Now repeat after me, systemvinit is best init, proven by time and many, many idiots trying to break it

Gentoo's also investing in mdev as well. You'll still need to know basic /dev mounting techniques for mdev but it works. There's also eudev.

As far as ReactOS, it's far from being ready for general usage. It's a viable project, but unless more people would contribute time and resources into the project's advancement, getting ReactOS off the ground is going to be a work-in-progress effort.

As far is sysvinit being the best. Actually it's not the best, it's just a good baseline. Sysvinit however doesn't offer much. This is why OpenRC was created. OpenRC greatly expanded sysvinit into its own separate init. Plus you can also add into sysvinit with rc-init like Slackware uses, adding in RunIt, s6, or perp to expand functionality.

This kind of problem is nothing that is new and was solved ages before with the invention of the initrd/initramfs.

Um, wasn't mudev the Busybox udev, and eudev the Gentoo udev fork?


Thanks for the info, it also looks like they are trying to start a commercial cloud desktop project based around ReactOS, I sure hope they succeed, I am a UNIX fanboy, but more decent opensource operating systems won't hurt anybody, especialy if they are compatible with Windows applications and drivers.
I hope they manage to upgrade their clean room reimplementation to server 2008 and Windows 7 and 8 too.
I am definitely going to check this project more thoroughly in the future.

Hey, I like OpenRC too, I was merely saying that sysvinit and the concept behind it were both well tested and resilient solutions that have worked just fine since the 70s.



Unless you want a custom kernel without initramfs that has been stripped down to the bare essentials of course.

By the way, does anybody still own the trademark on Bedrock/the Flintstones, I think that the copyright should have expired by now.
It might be fun to name my no frills minimalistic, traditionalist, rolling friendly and OpenRC only distro Flintstone Linux, or Bedrock Linux, with an ASCII art image of Dino or Fred

The Busybox alternative is called mdev.
And unless you use a monitor you won't get pictures on a screen. Of course you have to adapt your system to its technical facts.

As long as it has ssh running on it I am perfectly fine, also is there a particular reason why I can't compile my video drivers into the kernel, also is there anything special about the kernel's ability to load them after it mounts everything, I know that DRI is implemented inside of it, but does that mean that I need initramfs, and I could always use VESA, that would still give me enough to work with the console?
I will admit I am not very familiar with the Linux kernel's video architecture, nor have I ever been interested in it all that much, the most I've ever wanted from my hardware where graphics was the ability to watch 720p video, I neither care for effects nor for 3d.

I doubt most embedded Linux-es use udev and initramfs.

You totally missed my point. What I was saying is: To see pictures on your screen you actually have to connect the screen, in the same way you have to use initramfs/initrd when you want to network-mount a /usr-partition. Which is by the way, as already stated, not a new invention and used in Debian for a long time already with the standard kernels.

Ok, several things here,first of all why would any sane person use an /usr partition mounted over the network, it contains a lot of essential stuff.
Second, according to the specs at least all the essential stuff for a minimal system boot and recovery operations should be available in /sbin.
I do not know what you consider minimal, but the ability to mount all local file systems sure sounds like it to me.
Oh, and I do not recall saying anything about a /usr filesystem mounted over the network, although that should be doable too if the specs and good design practices were followed IMO.

In larger installations this can be a way to provide a large base of machines with the same programs installed, maintained at a single point.
Which specs? The FHS that nobody follows or the LSB that nobody cares about? Also, on many distributions nowadays /sbin and /bin are just symlibnks to /usr/sbin and /usr/bin.
Except in post #78, where you called it a chicken and egg problem.
It is, following the practice that is standrd for years in Debian, using an initramfs.

Yes and do remember who told us to take everything we knew about POSIX compliancy and discard it all. If someone is willing to discard POSIX, then FHS, LSB, and even the Unix philosophy are merely meaningless nuisances. A sound distribution of a UNIX or UNIX-like system must follow these guidelines or it can't be called any of those.

Then neither Slackware, Gentoo nor FreeBSD can call themselves UNIX-like. Have a look here, which OSes are fully POSIX compliant: http://en.wikipedia.org/wiki/Posix#F...OSIX-compliant. Also, please keep in mind that many distributions were not LSB or FHS compliant long before Poettering called for not aiming at POSIX compliance.

LOL, holy attempt at changing the subject batman, a nice way of weaselling out of actually responding to ReaperX7's post(eyeroll)
As to #78, if you actually read it carefully you will find that I was talking about systemd's inability to bring the network up because its components are not in /sbin or /bin, and that because of its overly complicated convoluted design it can't do everything it is supposed to, thus giving us a chicken and egg problem, since everything necessary for a minimal boot must be in /bin or /sbin as stated above.Repeating.Bolding.And Underlining for better visibility, I hope you ACTUALLY understand it now, LOL!.

As to your larger installations, I belie that maintaining everything from a single point, means single point of failure, laziness is a good thing at times, but there is such a thing as diminishing returns, there is also the minor issue of network faults and having your NFS/SAMBA/Whatever servers going down for maintenace.

If you think so. I see nothing wrong in showing him which OSes support POSIX fully when he asks that only those that do can call themselves UNIX-like, but to each his own.

Which is only a chicken and egg problem when /usr is hosted on the newtwork and even then easily solved with an initramfs. Talking about weaseling out.

1 members found this post helpful.