*background noise: chirp chirp chirp (crickets)*

..sorry but humor is good at times like this

I didnt earn the adjective PITA for no reason now did I?

The initramfs needed would be fairly large. One would have to be created, rebuilt when updates occurred to any specific individual file used, and loading something that large would take considerable time.

Doing that creates another complexity and more for a system administrator.

The point is to do less work with better tools, not more work. Adding complexity means more work, more problems to squash if they bug up, and more to maintain in the end when updates occur.

I think busybox is generally sufficient for the non-udev non-systemd non-RAID non-LVM non-LUKS portions of the initrd, with specific utilities from the five or so exceptions being the only ones that need special attention. My initrd containing various kernel modules plus udev and LUKS+LVM support is only 11MB uncompressed. systemd would add a bit to that (since it would replace busybox's init; I'm not sure if dbus is required in the initrd or if it is not needed until switching to the main system) but I don't think it would be too bad. As long as this procedure is standardized via a script (like mkinitrd) then it wouldn't be too much worse than it is now. That being said I still side with a legitimate non-initrd separate /usr setup for those who want it.

Yes, but it has nothing to do with systemd. It is clearly written on the freedesktop page that systemd work very well with a separate usr partition. It is only the messenger.

It is not casual that basic verbs (i.e. to be) are
irregular in all languages. You can dismiss some
incoherence in the first steps but not once a dialect
has became a consolidated language. It would be nor
coherent neither useful to create today a new verb and
not use the termination "ed" in the past form.

In the beginnings of anything it not exists a context
to be coherent with :-). Ask yourself why the syntax
of commands like find are different from the rest.

If someone here consider this comment off-topic then
"coherently" will consider off-topic the link that
Patrick Volkerding included in the thread "systemd and
Slackware's" future:

http://www.linuxquestions.org/questi...ml#post4727533

The link is this:

http://theody.net/elements.html

Those that trolled me in this thread (included some
moderator) should read it carefully.

The whole idea behind all my posts in this thread
points in one direction. My conviction that the
only possible prophylaxis respect issues like
systemd is trying to show, educate, teach new users in
what the article linked by Patrick says.

If you understand the above you'll see that my aim
politely explaining (between other examples*) the
reason behind using hard wrapped lines in text edition
is a better move in that direction than "spoon
feeding" new (and not so new) users with WYSIWYG
interfaces (even if the use of hard wrapped lines in
this forum could be questionable in some cases, but
it's not the point).

The effort that Ser Olmy is putting explaining his
point of view about file systems goes in the same
direction.

(*) Other examples behind systemd issue:

Will I be forced to stop using the Bourne [Again] Shell?
Will I be forced to stop editing text files to manage my system?
Will I be forced to stop using shell script init files?
Will I be forced to use a parallel, dubiously stable, boot sequence?
Will I lose the flexibility that Unix historical distinctive "all is a file" feature gives me at time to use my file system?
May I start to consider obsolete the way I use my system?
And a long etcetera.

There is a good reason to do that?
Is that reason coherent with what has been done till now?

Can you expand on this? As far as I know, almost all initramfs solutions from other distros ensure that /usr is mounted already - it's not really something new or specific to systemd.

(For reference, here are a couple of distros that do it already):
[1] Arch Linux: https://projects.archlinux.org/mkini...tree/hooks/usr
[2] Dracut [fedora, RH, possibly openSUSE in the future]: http://git.kernel.org/?p=boot/dracut...fa5162;hb=HEAD

The 'decrease in speed' isn't anything quantifiable, and the technical strengths and simplification of the hierarchy seem to outweigh them. Personally, I dislike having about 6 or 8 different locations that executable binaries can live.

@
e
l
o
i
:

i
n
s
i
s
t
i
n
g

o
n

h
a
r
d

w
o
r
d
s
-
w
r
a
p
p
i
n
g

o
n
l
y

s
h
o
w
s

h
o
w

m
u
c
h

y
o
u

c
a
r
e

f
o
r

o
t
h
e
r
s
'

r
e
a
d
i
n
g

c
o
m
f
o
r
t
.

5 members found this post helpful.

All of fifteen minutes before deriding a lack of response? PITA indeed! (sorry but humor is good at times like this)


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).

Sure, it is. Just an option that almost all distributions use, since it allows for a fully modular kernel, and setting up the early OS. Also, who did 'supposed to be' come from? :-)

Not really, they get copied over. And if you're doing a full distribution update, you'll be rebuilding the initramfs anyway. And if it's a critical updating involving the early boot process, usually package managers will do a quick rebuild for you. And on slackware + the -current branch, surely we're all reading the changelog where this will be mentioned.

Nope, most are copied directly from the root partition, or busybox is used to perform the actions. Try a 'tree' on your /boot/initrd-tree/ for example.

I am not completely sure if this is true regarding 16mb of ram, but c'mon, it's 2012. Even my computer from 9 years ago had 1gb of memory. And for anything smaller form-factor, does a separate /usr even make sense? Especially without using an initramfs.

See "3" above, but an initrd is pretty commonly used in install media to provide modularity in hardware detection.

Sure, but since this is a systemd thread, I'll comment that systemd can even exist in the initramfs these days, to make the handoff pretty transparent :-) Dracut is doing this for fedora (even though I think this is a bit bloaty personally), but each distribution can handle the handover pretty seemlessly these days.

1 members found this post helpful.

...this is just getting too ridiculous.

Your complaints are eating a cake and complaining about the fudge you smear on your face when you take away the false statements you just claimed.
There are ofcorse costs to change.
If I am a PITA then you must be Mr. CommonSense - the Sense.

So you prefer a Rotten Apple because you dont want fudge on your face from eating cake?

I am giving up. I find it unjustifiable to inject common sense into people that fight against it. Yes it is unlogical for me to pursue to help people think Logically if they are so against Logic.. all they want is to argue to be right and spread FUD. What do I gain except waste time...

Common sense tells me to let things go and ignore 100 threads calling me out afterwards and focus more on learning Scheme. Bye.

I would like to ask abrouwers and elvis4526 exactly what is required to try systemd in Slackware?
The link that abrouwers posted earlier in this thread is dead for me and I think elvis4526 was involved in this. http://www.mail-archive.com/systemd-.../msg06172.html

Following this thread has left me with the feeling that systemd is something that I would like to trial for my personal interest and investigation. This is FOSS after all.

Praise "Bob"! My prayers have been answered!

2 members found this post helpful.

Use of a good analogy is a skill requiring great effort or talent to master. If you cannot provide a consistent analogy then do not use one. Right now your analogy makes little sense and doesn't seem to describe saulgoode's post at all, which had valid points.
I don't think abrouwers's post had anything to do with you at all, and was directed at refuting saulgoode's points. Again, there were valid points made here. This is not a cut and dry issue and valid points have been made on both sides (this is what is known as a discussion) so your poor attitude is both unwarranted and unwanted.

1 members found this post helpful.

Actually, I have a git repo, with -almost- everything you need to run systemd. I tried to make a clear readme that explains how to do it. The only problem is that you need to recompile a lot of standard slackware package on a install with systemd so it get linked to it instead of the old udev (yes, systemd replace udev too). Besides this, I tried it on my system, and it work pretty well besides the fact that you need to almost recompilate a lot of packages in a clean environnement with systemd so you want experience random breakage.
Here's my github repo: https://github.com/elvis4526/slackware-systemd
Oh, and forget the part when it speak about binary packages, I tought I could build prebuilt packages but everyone on #slackware told me that nobody would trust my packages, so forget about it.
So, for everyone that want to test systemd for the latest slackware stable release, if you encounter any problems with my procedure and my slackbuilds, or if you have any suggestions about how making things work better, tell me as soon as possible.

3 members found this post helpful.