Thomas Bächler wrote:
RedShift schrieb:
/proc and /sys are already hardcoded. About your system being broken
without these filesystems mounted:
- SSH (both server and client) won't work without devpts mounted
- None of the virtual X terminal things will work without devpts mounted
It doesn't prevent the system from booting and having a working
virtual console. So people can fix it if they decided to mess with the
default entries in fstab.
That's correct.
You guys just don't get it. This is about _principle_.
YOUR principle.
Yes, and guess where I got them from. Arch, 3 years ago.
And its not because there already are some filesystems hardcoded, that
the rest should be.
I'm not talking about "the rest", I'm talking about things that are
mandatory for basic system operation.
It is not mandatory for basic system operation. With basic system operation I
mean getting a virtual console working and that's it. You know, the thing the
users aren't supposed to be afraid of? Having some working xterm's or whatever
in X is not basic system operation.
In fact, these should be moved from hardcoding to fstab. But that will
probably never happen.
You're right, it won't, because it is impossible. If you would care to
even read rc.sysinit, you would know why.
Yes, there are things that need to be hardcoded because there is no way around
them. I have no problem with those. /dev/pts doesn't fall in this exception.
Wether these are "virtual" or "real" filesystems, it doesn't matter:
the fs in fstab stands for FileSystem, period. If something needs to
be mounted, it should go there.
Says you?
Yes. It's logical.
This is exactly as what happened with the lo moving to rc.sysinit,
hiding stuff so the newbies won't remove it because they think they
don't need it. And the fact is, if you remove lo from the system, you
can *still* boot your system and most stuff works without lo. So they
can still fix lo if they removed it.
This is not about hiding things, it is about keeping it simple. What is
simple about having to configure something that everybody needs, always
needs it and will break everything if it is configured differently? It
is unnecessary to even be able to configure it. So simplicity tells me
to hardcode it.
I'm sick and tired of complaining about issues like these, that
shouldn't be discussed in the first place. Do you think I like
complaining?
Then don't complain, I'm sick of it. These changes do not decrease your
flexibility, nor do they break anything.
Believe me, I am all against changes that remove control from the user.
But this is about things a user doesn't have to control, doesn't even
want to control. What I want is a system that is flexible on the one
hand, robust and unbreakable on the other hand. The 'lo' change (as well
as the devpts change) is about increasing robustness without removing
any flexibility. I cannot see how this is not a good thing.
*everything* should be in the user's control. That includes things that can
shoot him in his own foot. You don't know if there are out there that want to
control lo or devpts. Now they'll have to apply a patch every time the
initscripts get upgraded.
Since when do we assume the user is stupid? All that's been
accomplished here is create a big mess.
This is rule number one of development, always assume the user is
stupid. The result of that is, that I have less emails with complaints
to answer, less forum posts to unbreak user's systems, one less
bugreport to close. It essentially means that I have more time doing
things that actually benefit the Arch community.
Yah, that's kind of like exactly the opposite of what Arch stands (stood?) for.
