RedShift schrieb:

Yes. It's not logical. fstab was made for mounting filesystems, why even consider moving it to rc.sysinit? It's not because it makes the system unusable without it, that it should be moved to rc.sysinit. Why the change anyway? What's the benefit? Now we're going to see "Heeey stuff's being mounted that's not in fstab? wtf?". This change is just plain irrational, fstab was _specifically made_ for mounting filesystems.

fstab was made for mounting real filesystems, not virtual ones. We already mount several virtual filesystems outside of fstab because we have to. This is just adding more logic: Mount stuff that is mandatory for the system to be functional in a hardcoded way instead of allowing people to break it.

If you're going to hardcode stuff like that you might as well throw away fstab.

NOW you're being irrational.

- Can anyone think of a case where pts should NOT be mounted. You don't want someone having to edit a script. - Will this break some scripts that might rely on grepping fstab? (For example, this could make a port from other Linux distros harder) On Mon, Apr 7, 2008 at 8:35 AM, Jan de Groot wrote:

On Mon, 2008-04-07 at 00:24 +0200, RedShift wrote:

...

Thomas Bächler wrote:

...

RedShift schrieb:

...

Thomas Bächler wrote:

...

I am hacking initscripts and can't quite decide on two issues:

1) I'd like to hardcode /dev/pts/ mounting in rc.sysinit.

What's wrong with putting that in fstab? What if I don't want to have that mounted? So instead of modified fstab I'd have to mess with rc.sysinit everytime the initscripts get upgraded? This is the same discussion as with moving lo to rc.sysinit instead of leaving it in rc.conf. Uterly pointless.

The point is, everyone needs it mounted. Your system will be completely useless without devpts (as it is without the lo interface).

However, I know your opinion on these issues. Are there any rational reasons not to hardcode devpts?

Yes. It's not logical. fstab was made for mounting filesystems, why even consider moving it to rc.sysinit? It's not because it makes the system unusable without it, that it should be moved to rc.sysinit. Why the change anyway? What's the benefit? Now we're going to see "Heeey stuff's being mounted that's not in fstab? wtf?". This change is just plain irrational, fstab was _specifically made_ for mounting filesystems. If you're going to hardcode stuff like that you might as well throw away fstab.

Glenn

/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

One sidenote though: I don't think users will break their system, the /dev/shm and /dev/pts mounts are in fstab during setup and I think most people don't remove them. I haven't seen bugs about "hey my system doesn't boot, but when I add these lines to /etc/fstab it works"

-- ---- www.cern.ch/ribalba / www.ribalba.de Email / Jabber: ribalba@gmail.com Phone (Work) : +41 22 7679376 Skype : ribalba Address : CERN / IT-FIO-FS / GENEVE 23/ SCHWEIZ

Jan de Groot wrote:

On Mon, 2008-04-07 at 00:24 +0200, RedShift wrote:

...

Thomas Bächler wrote:

...

RedShift schrieb:

...

...

I am hacking initscripts and can't quite decide on two issues:

1) I'd like to hardcode /dev/pts/ mounting in rc.sysinit. What's wrong with putting that in fstab? What if I don't want to have

Thomas Bächler wrote: that mounted? So instead of modified fstab I'd have to mess with rc.sysinit everytime the initscripts get upgraded? This is the same discussion as with moving lo to rc.sysinit instead of leaving it in rc.conf. Uterly pointless. The point is, everyone needs it mounted. Your system will be completely useless without devpts (as it is without the lo interface).

However, I know your opinion on these issues. Are there any rational reasons not to hardcode devpts?

Yes. It's not logical. fstab was made for mounting filesystems, why even consider moving it to rc.sysinit? It's not because it makes the system unusable without it, that it should be moved to rc.sysinit. Why the change anyway? What's the benefit? Now we're going to see "Heeey stuff's being mounted that's not in fstab? wtf?". This change is just plain irrational, fstab was _specifically made_ for mounting filesystems. If you're going to hardcode stuff like that you might as well throw away fstab.

Glenn

/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. You guys just don't get it. This is about _principle_. And its not because there already are some filesystems hardcoded, that the rest should be. In fact, these should be moved from hardcoding to fstab. But that will probably never happen. 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. 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. 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? Since when do we assume the user is stupid? All that's been accomplished here is create a big mess.

One sidenote though: I don't think users will break their system, the /dev/shm and /dev/pts mounts are in fstab during setup and I think most people don't remove them. I haven't seen bugs about "hey my system doesn't boot, but when I add these lines to /etc/fstab it works"

On Mon, 2008-04-07 at 11:12 +0200, RedShift wrote:

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? Since when do we assume the user is stupid? All that's been accomplished here is create a big mess.

I think these things shouldn't be discussed in public anymore. Your use of language makes me sick. This is the same for that thread aaron opened about the direction archlinux is going, some people personally attacked several devs.

On Monday 07 April 2008 11:28:42 Jan de Groot wrote:

I think these things shouldn't be discussed in public anymore. Exactly the wrong way. Face the critics or dig a hole and wait for it to be over.

On Monday 07 April 2008 11:39:32 Thomas Bächler wrote:

...

You guys just don't get it. This is about _principle_.

YOUR principle.

Wrong dude. Those are Juds prinicples. We just happen to agree and stand for it.

...

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.

thanks for the confirmation that you disagree with us on prinicples. -- best regards Arvid Ephraim Picciani

Nicely put and seconded Geoff. Geoff wrote:

On Mon, 07 Apr 2008 11:28:42 +0200 Jan de Groot wrote:

<snip>

...

I think these things shouldn't be discussed in public anymore.

Whatever may be the outcome of this particular debate, I do respectfully suggest that it would be a retrograde step to take discussion of these issues (even heated discussion), out of the public domain. Many of your users care about such issues. Even if we do not all have the technical competence to contribute to every argument, we learn from reading what the devs have to say. Sometimes harsh things are said in the heat of the moment, but surely every user/developer of open source projects understands how to make allowance for that.

Geoff

-- Kind Regards Russell ================== www.windsorcycles.com.au sales@windsorcycles.com.au ph. 02 4577 3209 bikes.no-ip.info Linux user #369094 ==================

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.

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.

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.

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?

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.

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.

RedShift schrieb:

...

...

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.

I doubt that narrow-mindedness is a principle that you got from Arch.

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.

Clearly, you can define basic system operation one way or the other. I count the possibility to allocate Pseudo TTYs as basic system operation. Now, seriously: Show me one system out there that doesn't have devpts mounted or lo up. Show me one user who doesn't those. Show me one machine where the presence of lo or devpts is bad for the system. Only one. You won't find it.

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.

That's right, it doesn't.

...

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.

It is in your control. I'm just doing what makes sense ... if you want to do things that don't make sense, feel free to fork your own initscripts, that's in your control.

...

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.

Not necessarily. Of course, at some point I have to assume that a user knows certain things and if the task becomes complicated, then I have to assume much knowledge. However, by keeping the assumption on a user's knowledge to a minimum, I avoid problems. Let's take the 'lo' example: If I assume a user has no idea what 'lo' is, I can still give him a working system by hardcoding the 'lo' interface to rc.sysinit. Then I look at the user under the assumption that he knows what 'lo' is: he still has a working system, his flexibility has not been reduced at all, he is as happy as before (in fact, he won't even notice). To go further: if he really wants to configure 'lo' differently (which he doesn't), he still can. There is in fact a valid reason why we should not hardcode devpts and I am thinking of dropping the thought, but none of you even cared to bring it up, instead you bitch about your weird principles, which you claim to be Arch's principles, insulting developers and being an ass on the way. I am following KISS and trying to make things simpler, while you want to keep things more complicated, because you think that's what Arch is about.

On Mon, 07 Apr 2008 13:58:22 +0200 RedShift wrote:

...

There is in fact a valid reason why we should not hardcode devpts and I am thinking of dropping the thought, but none of you even cared to bring it up, instead you bitch about your weird principles, which you claim to be Arch's principles, insulting developers and being an ass on the way. I am following KISS and trying to make things simpler, while you want to keep things more complicated, because you think that's what Arch is about.

Obviously we have a different view of what "Simple" actually means. There is no common ground anymore.

I think the argument has gotten lost. We shouldn't be debating whether these things should be loaded or not. The issue is -where- they are loaded. Either the standard location or some make believe script that isn't part of standard operation. Of course they should be loaded by default. Who wants to see Arch Linux become LFS+pacman? Nobody I think.

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Thomas Bächler wrote: [snip]

There is in fact a valid reason why we should not hardcode devpts and I am thinking of dropping the thought, but none of you even cared to bring it up, instead you bitch about your weird principles, which you claim to be Arch's principles, insulting developers and being an ass on the way. I am following KISS and trying to make things simpler, while you want to keep things more complicated, because you think that's what Arch is about.

This is not KISS. KISS means keep what you're doing simple. Doing things manually in initscripts instead of somewhere which was designed to hold information of that nature is not simple, it is complicated. If the KISS philosophy meant "make it simpler for the user", Ubuntu would be the best KISS distro out there at the moment and Arch would be aspiring to be like Ubuntu. Although there is nothing wrong with Ubuntu, I hope we can all agree that is not what we want Arch to be. Dave Moore -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkf6JEcACgkQOP+t1LlaoiFgcACgggtHN4UcXSOL/6/wnb6qwcgM 8uoAoLOyVl28te6fs/XAf24iuloaMWve =LrLl -----END PGP SIGNATURE-----

On Monday 07 April 2008 13:52:21 Thomas Bächler wrote:

If I assume a user has no idea what 'lo' is, I can still give him a working system by hardcoding the 'lo' interface to rc.sysinit.

Your assumptions are worse then i thought.

Then I look at the user under the assumption that he knows what 'lo' is: he still has a working system,

ubuntu is "working" too.

his flexibility has not been reduced at all, he is as happy as before (in fact, he won't even notice). To go further: if he really wants to configure 'lo' differently (which he doesn't), he still can.

weird. exactly the arguments ubuntu devs use.

I am following KISS and trying to make things simpler, while you want to keep things more complicated, because you think that's what Arch is about.

ubuntu-simple and arch-simple are different. ubuntu, ubuntu, ubuntu, ubuntu, ubuntu, ubuntu, ubuntu, ubuntu, just not archlinux. http://phraktured.net/arch-way.html http://phraktured.net/patching-patching-patching.html thanks aaron, you rock. -- best regards Arvid Ephraim Picciani

I believe the missing question is: what is the rationale beyond this decision of putting the /dev/pts out of fstab? Besides the aforementioned robustness (which at some point I tend to agree), what else would be the technically benefits? If for nothing else than "stopping the user to shoot his foot", I believe this should not be done, as I need to agree that it hurts Arch Way. Also as pointed before, it may create problems with chroot (if I understood correctly). Just my (user standpoint) 2 cents. -- Cheers, Rodrigo A computer is like air conditioning: it becomes useless when you open windows. ~Linus Torvalds

[many comments skipped] Could we please finally STOP insulting devs? There are _more civilized_ ways for discussion. -- Roman Kyrylych (Роман Кирилич)

Arvid Ephraim Picciani schrieb:

On Monday 07 April 2008 13:52:21 Thomas Bächler wrote:

...

If I assume a user has no idea what 'lo' is, I can still give him a working system by hardcoding the 'lo' interface to rc.sysinit.

Your assumptions are worse then i thought.

I just assume as few knowledge as I can, as long as maximum control and flexibility is assured. In this very special case, I can assume no knowledge at all without removing any flexibility from smarter users. There could be no better situation than this.

...

Then I look at the user under the assumption that he knows what 'lo' is: he still has a working system,

ubuntu is "working" too.

Actually, from what I hear from experienced Linux users, it's not. I never tried myself though.

...

his flexibility has not been reduced at all, he is as happy as before (in fact, he won't even notice). To go further: if he really wants to configure 'lo' differently (which he doesn't), he still can.

weird. exactly the arguments ubuntu devs use.

I am insulted by that comment and expect an apology.

...

I am following KISS and trying to make things simpler, while you want to keep things more complicated, because you think that's what Arch is about.

ubuntu-simple and arch-simple are different.

ubuntu, ubuntu, ubuntu, ubuntu, ubuntu, ubuntu, ubuntu, ubuntu, as soon as we make a change that makes life easier for them. In this case, I am being insulted for _thinking_ about adding one line to a

Arch implements many aspects of simple: - Simple to understand the underlying system (scripts, package management and so on) - Simple to modify the system (making packages is soooo easy in Arch) - Simple to use and configure Most people seem to forget that last point. If we can make the system simpler to use (and thus more robust and error-proof) without adding unnecessary complexity, then we have to do it. But instead of being happy about it, _some_ of our user base start screaming script, that would make the lives of many people easier (wow, one extra line, that certainly adds so much complexity, Arch is really becoming Ubuntu these days).

just not archlinux.

http://phraktured.net/arch-way.html

If you had actually read that document, you would understand my point completely. I quote: "'Simple' is defined from a technical standpoint, not a usability standpoint. It is better to be technically elegant with a higher learning curve, than to be easy to use, and technically crap." What you don't get is that if you have to make a decision between two equally technically elegant decisions, and one of them improves usability, you go for usability. What you and some other people here seem to think is that usability automatically implies technical non-elegance.

http://phraktured.net/patching-patching-patching.html

This is absolutely not related to this topic, so I won't comment on it here. I will say it one last time: Adding the _necesity_ to configure something that doesn't need to be configured is crap, from a technical and a usability point of view and thus defeats the Arch Way.

Arvid Ephraim Picciani schrieb:

...

I quote: "'Simple' is defined from a technical standpoint, not a usability standpoint. It is better to be technically elegant with a higher learning curve, than to be easy to use, and technically crap."

What you don't get is that if you have to make a decision between two equally technically elegant decisions, and one of them improves usability, you go for usability.

You twisted it. Mind the "not" in front of "a usability standpoint".

It says:

technical correctness > usability

not:

usability > higher learning curve

It only says not to sacrifice technical correctness for the sake of usability, nothing else.

But you know that argument failed, which is why you argue it beeing invalid:

...

I will say it one last time: Adding the _necesity_ to configure something that doesn't need to be configured is crap, from a technical and a usability point of view and thus defeats the Arch Way.

You implicitly add the statement "Usability is bad, we don't want our stuff to be usable, so don't even try" to the Arch way.

thanks again for admiting that you disrespect the arch way. Now black on white and not revokeable.

No, what we have now - black on white - is that you have no idea what the Arch way is about and simply twist it the way you want it. My original thought was "Let's remove one line from fstab and add one line to rc.sysinit, this will make the system more robust". It's a technically simple, non-complex change (which, as said, I dropped after further consideration). The thread you guys produced as a result is ridiculous. This is the my last post in this thread, I simply can't see this crap continue. I should never have even responded to RedShift's first posting, I'm sorry for that. In fact, I should never have responded or never respond to any posting by you and RedShift or you anytime in the past or the future.

Thomas Bächler wrote:

Arvid Ephraim Picciani schrieb:

...

On Monday 07 April 2008 13:52:21 Thomas Bächler wrote:

...

If I assume a user has no idea what 'lo' is, I can still give him a working system by hardcoding the 'lo' interface to rc.sysinit.

Your assumptions are worse then i thought.

I just assume as few knowledge as I can, as long as maximum control and flexibility is assured. In this very special case, I can assume no knowledge at all without removing any flexibility from smarter users. There could be no better situation than this.

...

...

Then I look at the user under the assumption that he knows what 'lo' is: he still has a working system,

ubuntu is "working" too.

Actually, from what I hear from experienced Linux users, it's not. I never tried myself though.

...

...

his flexibility has not been reduced at all, he is as happy as before (in fact, he won't even notice). To go further: if he really wants to configure 'lo' differently (which he doesn't), he still can.

weird. exactly the arguments ubuntu devs use.

I am insulted by that comment and expect an apology.

Insulted or not, it is 100% right what Arvid wrote.

...

...

I am following KISS and trying to make things simpler, while you want to keep things more complicated, because you think that's what Arch is about.

ubuntu-simple and arch-simple are different.

Arch implements many aspects of simple: - Simple to understand the underlying system (scripts, package management and so on) - Simple to modify the system (making packages is soooo easy in Arch) - Simple to use and configure

...

ubuntu, ubuntu, ubuntu, ubuntu, ubuntu, ubuntu, ubuntu, ubuntu, as soon as we make a change that makes life easier for them. In this case, I am being insulted for _thinking_ about adding one line to a

Most people seem to forget that last point. If we can make the system simpler to use (and thus more robust and error-proof) without adding unnecessary complexity, then we have to do it. But instead of being happy about it, _some_ of our user base start screaming script, that would make the lives of many people easier (wow, one extra line, that certainly adds so much complexity, Arch is really becoming Ubuntu these days).

...

just not archlinux.

http://phraktured.net/arch-way.html

If you had actually read that document, you would understand my point completely.

I quote: "'Simple' is defined from a technical standpoint, not a usability standpoint. It is better to be technically elegant with a higher learning curve, than to be easy to use, and technically crap."

What you don't get is that if you have to make a decision between two equally technically elegant decisions, and one of them improves usability, you go for usability. What you and some other people here seem to think is that usability automatically implies technical non-elegance.

There's nothing elegant about hardcoding stuff. Simple as in a technical standpoint, says that it should be mounted in fstab. Why? Because fstab is the place were filesystems that should be mounted on boot go. The damn thing is *made* for it. Take again for example lo, if I want to reconfigure it, everytime the initscripts get upgraded, I have to apply a patch I had to write myself to change lo to whatever I want. How exactly does this fit the "simple" scenario? Plus it adds unnecessary code to the initscripts, while we've already got a perfectly working network initialization scheme. And lo fits right in. It's the thought behind all of this that is being questioned here. Arvid is right. And it doesn't matter if the user Does or Does Not Want, it's about that he Can.

...

http://phraktured.net/patching-patching-patching.html

This is absolutely not related to this topic, so I won't comment on it here.

I will say it one last time: Adding the _necesity_ to configure something that doesn't need to be configured is crap, from a technical and a usability point of view and thus defeats the Arch Way.

On Montag, 7. April 2008 19:10 Thomas Bächler wrote:

I'm sick of being insulted and I'm sick of Arch or my work on Arch being compared to Ubuntu, because they're nothing alike.

+1 I don't think this, not now and not in the future. Thanks for your work and for your answers here. This is thread is non-constructive disrespect and everyone should decides if this is as desired. See you, Attila

On 4/8/08, David Moore wrote:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

Thomas Bächler wrote: [snip]

...

...

Simple as in a technical standpoint, says that it should be mounted in fstab. Why? Because fstab is the place were filesystems that should be mounted on boot go. The damn thing is *made* for it.

I already dropped the devpts idea, for different reasons than you may think, but I dropped it.

One of the reasons I stay subscribed to this list is so that I can learn more about my system. In that light, would you mind sharing with us why exactly you did drop the idea? I would really like to know.

thanks, Dave Moore [snip]

+1 BTW, Aaron, thanks for moderating this... :-P -- Cheers, Rodrigo A computer is like air conditioning: it becomes useless when you open windows. ~Linus Torvalds

On Tue, 8 Apr 2008 13:22:26 +0200 Xavier wrote:

On Tue, Apr 8, 2008 at 8:50 AM, David Moore wrote:

...

One of the reasons I stay subscribed to this list is so that I can learn more about my system. In that light, would you mind sharing with us why exactly you did drop the idea? I would really like to know.

http://archlinux.org/pipermail/arch-dev-public/2008-April/005643.html If you are interested about your system, please read arch-dev-public, don't write to arch-general. Thanks.

But why? A public dev list is a valuable opportunity for us all to see how the devs are thinking, but I would never dream of posting to it. The devs would probably disregard anything I had to say as noise, - and quite right too. Why should not people like me be able to discuss system issues here? Geoff

On Mon, Apr 07, 2008 at 01:52:21PM +0200, Thomas Bächler wrote:

RedShift schrieb:

...

...

...

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.

There is in fact a valid reason why we should not hardcode devpts and I am thinking of dropping the thought, but none of you even cared to bring it up, instead you bitch about your weird principles, which you claim to be Arch's principles, insulting developers and being an ass on the way. I am following KISS and trying to make things simpler, while you want to keep things more complicated, because you think that's what Arch is about.

This discussion has actually helped me think through something. The entire thread is pretty much an argument about principle. Thomas suggested we do something a different way because he thought it would be better (though maybe he wasn't explicit about the reason). Glenn argued against it because of principle, not because there was any practical reason not to do it. I think principle does have a place to guide certain things, such as how to package software. But really it's a guideline, not something to be applied dogmatically. Especially when the thing in question is something that we control totally. No one tells you how to write initscripts or distributes official linux initscripts. It's our discretion as to how to improve/develop things. In the future, I think it's better not to talk about what should be done, but talk about why it's being done. Something like, "I'm going to do something because I can't think of a reason why anyone would want to do it like this and it will improve things like this. Can anyone think of a problem with doing it this way?" That way the discussion is about problems with the proposed solution instead of what the principle behind the change is. The change is proposed to improve something, not out of malice, and it should be treated as such. Jason

Would it not be possible to do something like moving all the virtual FS stuff to a specific file (say fstab.virtual or whatever you want) imported from fstab (thus easy to locate) ? To me, it would make it easy to edit while keeping the content of fstab simple, and nothing would be hardcoded... Otherwise I'm for keeping everything in fstab. -- Pierre 'catwell' Chapuis

Attila a écrit :

On Montag, 7. April 2008 12:00 Karolina Lindqvist wrote:

...

I think that is a good reason why the mount commands should be in /etc/fstab and not in some obscure init script.

I suggest the same because the fstab is the best point to collect the necessary informations about what have to be mounted. At example this be some lines on my opensuse server:

proc /proc proc defaults 0 0 sysfs /sys sysfs noauto 0 0 debugfs /sys/kernel/debug debugfs noauto 0 0 usbfs /proc/bus/usb usbfs noauto 0 0 devpts /dev/pts devpts mode=0620,gid=5 0 0

You see that some mountpoints have noauto which means that they get mounted from the initscripts. I find this a perfect mix of having the informations at one point for the users and giving the devs the possibilty to control it in the initscript if necessary.

See you, Attila

Seems nice to me. Then you can adds options to fstab, which is the purpose of fstab. I like to do this for several filesystems who needs noauto (like usb devices, fuse-ssh filesystems...) Even for devpts, it is a good example. Say one day, I want to mount devpts for a specific user (don't ask me why I just don't know), I know were to change this options, and it will be taken into account after a system upgrade (thanks to pacman). Like it was suggested, it is also possible to put comments in fstab (or rc.conf for the lo issue) that gives the user the information that "these filesystem are mounted in rc.sysinit: devpts proc sysfs ...". First goal is to help the user to find where to configure things. Second goal is to help him learning about how his system works. Personally I care to know how and I will google for things I don't know (like debugfs). A "dumb user" won't care about default configuration and will ignore it. A "very dumb user" (like me) will try to break his system, and will learn something. I'm not used to react to hot discussions, but it's true I was surprised when lo was removed from rc.conf, hoping that it was still and always mounted. Regards, Olivier P.S. Anyway thanks Attila for the productive comment.

Alessio Bolognino wrote:

Thomas, if you are afraid that users could remove that line from fstab, why don't you just put a "# Warning, do not remove these lines unless you really know what you are doing" or something like that? I think this will reduce complexity of rc.sysinit (not very much, I have to admit :)

Anyway, this thread is gone crazy, I hate when people attack devs for a minor issue like this one: whatever Thomas and the other devs will decide to do, it will be fine for me and should be fine for everyone. Seriously, this won't ever affect anyone's system.

This thread started with "should I edit one line in a file?" and ended with "ZOMG, the ubuntu revolution is coming, arch way for teh win, I hate where Arch is going, oldfags > newfags".

I totally agree, it will be fine either way.. And I hope all this nonsense for such a minor issue will end soon (I am not waiting for answers on that comment, thanks).

-------- Original Message -------- Subject: Re:[arch-general] [arch-dev-public] initscripts changes From: Alessio Bolognino To: arch-general@archlinux.org Date: lun 07 avr 2008 18:48:13 CEST

...

...

However, I know your opinion on these issues. Are there any rational reasons not to hardcode devpts?

Thomas, if you are afraid that users could remove that line from fstab, why don't you just put a "# Warning, do not remove these lines unless you really know what you are doing" or something like that? I think this will reduce complexity of rc.sysinit (not very much, I have to admit :)

I also don't understand why the devpts should be hardcoded. Do you want to protect user from his own errors ? Then you should protect all files in /etc and other places, because there are so many ways to corrupt a system. On the opposite, if you move something to a place where logically it is not supposed to be, then you will hide things and it could lead to new problems for the future. fstab is fine for me. And as a basic rule I apply: if there is something in that I don't know, then either I ask/search to cope with, or I leave it unchanged. Olivier

On 4/8/08, Michal Soltys wrote:

Thomas Bächler wrote:

...

The point is, everyone needs it mounted. Your system will be completely useless without devpts (as it is without the lo interface).

However, I know your opinion on these issues. Are there any rational reasons not to hardcode devpts?

I'm 100% with Thomas for it (along with /dev/shm). I've always wondered why Arch keeps those two in fstab (there're few other things that could be changed, but that's for a different post).

If a user wants to change it, then the rc.sysinit is the place to do so (whatever weired reason one would have for changing those mounts). If one needs it for chroot environment for some program, then just mount --bind manually - be it custom rc.d/something or anything else.

I'd also be for adding all rc* files to backup array - although as long as there's noupgrade in pacman, I'm not gonna weep ;)

Well, my 2 cents here.

What 2 cents? Without the reasons you back up brain0 your mail is totally pointless IMO. Just like most of the other ones. This is not a poll. Greg