noexec on /dev/shm

[Miloslav Trmač]

Casey Dahlin píše v Čt 16. 12. 2010 v 11:19 -0500:
> On Thu, Dec 16, 2010 at 12:27:34PM +0000, Richard W.M. Jones wrote:
> > What you don't understand is that you are throwing away the experience
> > and knowledge of thousands of Unix system administrators.  Almost of
> > all of them do not even read this mailing list.
> > 
> > Rich.
> 
> I hate this argument.
> 
> The "experience and knowledge" claim applies to everything we could possibly
> change.
> 
> Change.\nIs.\nGoing.\nTo.\nHappen.

That's a too black-and-white view.  Of course there is and will be
change - what would we all be doing here if there were nothing to
change, after all?  The thing that needs to be appreciate is that every
change has _costs_ on the user-base.

I can't quickly find out good numbers on the number of server users of
Fedora and Fedora-derived distributions; based on
http://www.centos.org/modules/newbb/viewtopic.php?topic_id=18728&forum=14 , let's stipulate that there are 1,000,000 installations (which is almost certainly a huge understatement), with 10 servers per administrator on average, so 100,000 Linux system administrators.  Better numbers would be welcome.

* You simplify existing code, which changes a rarely-used configuration
value that "shouldn't affect anything in most cases", nevertheless
requires a release note.  Say 10% of the system administrators reads the
release notes, and reading the release note takes 10 seconds.  The code
simplification just cost our userbase more than 3 working days, with
nothing to show for it.  Did the code simplification save the
programmers 3 days, so that at least overall there was a net benefit?

* You replace a configuration file, or change its syntax, so that old
knowledge and old kickstart scripts no longer apply.  Say, again, that
this change affects 10% of the system administrators, and that the
change is fairly trivial, so reading the documentation and updating
existing configuration scripts takes only 1 hour, and validating the
change and the associated administrative overhead (keeping track of the
change) takes 3 hours.  Now the configuration file change has cost our
userbase about 19 working _years_.  To be worth it across the population
of system administrators, the change needs to save the average system
administrator 24 minutes before the configuration method changes again,
or provide some other equivalent benefit.  Saving the average system
administrator 24 minutes is not easy (try thinking of a configuration
change that would do that), and the more frequent changes of the
configuration are, the more pronounced the benefits of the feature need
to be.

* You replace a whole subsystem, requiring _each_ system administrator
to study the new subsystem for 10 hours, and to update the existing
configuration, validate it and so on, which takes 30 hours.  The change
has cost our userbase a working week; to be worth it, it also needs to
save each system administrator a working week.  Again, the more frequent
the subsystem changes are, the more pronounced the benefits of the
changes need to be.

So, yes, change is going to happen, and some change is clearly good.
But when there are 10 programmers on a project and 100,000 users, each
change has to be _very obviously_ good, or it might be better avoided.  

Especially minor changes that don't bring any measurable benefit
(perhaps making the system "cleaner" or making programmer's life more
convenient) but require time from each user to adapt are better
abandoned than implemented.
	Mirek