User: Password:
|
|
Subscribe / Log in / New account

The "philosophy" was dead for a long, long time aready... deal with it

The "philosophy" was dead for a long, long time aready... deal with it

Posted May 22, 2010 6:38 UTC (Sat) by dmadsen (guest, #14859)
In reply to: The "philosophy" was dead for a long, long time aready... deal with it by khim
Parent article: The trouble with the TSC

The problem I have is not necessarily with this particular instance; it's with the philosophy of restricting someone else's freedom "for their own good".

I should not have to pay because "more and more clueless people appeared". Shall we all then live to the lowest common denominator? My God, soon we'd all be using Windows Starter Edition! :-)

One way I got to be a "knowledgable, responsive [responsible?] user" was to hurt myself doing "stupid" things. Ctrl-Alt-Backspace *should* hurt -- once.

And you know, code review isn't so bad: when I coded at the keypunch, it required more debugging than when I used the coding pad. Writing code that I (and hopefully others) reviewed not only made better code then, but taught me (and others) to write better in the future. (I would recommend reading "The Psychology of Computer Programming" by Gerald M Weinberg for more information). And if I talked to someone who'd done rm -rf incorrectly, maybe I could avoid their pain.

If it is true that natural evolution is to produce buggy code quicker, than perhaps we should resist. Maybe sometimes celerity isn't a virtue, and the modern motion of the inevitability of bugs in code isn't true.

The assumption that kernel code is somehow special and should be specially treated is wrong -- *someone* is going to depend on code you write no matter how big or small the project, and an error in that code is gonna cause *someone* some trouble. If you don't believe that, than you should not be writing code for others to use.

File permissions, quotas, etc are there to mainly stop a system user from hurting other system users. That's one of the normal policies of an OS. On the other hand, training wheels are fine for novices, but they are meant to come off.

Again, I'm not talking about removing for everyone the equivalent of safety gear in a program. What I'm talking about is deliberately engineering something so that any safety gear is [almost] impossible to remove. In normal use, I should be able to use something safely, but, in my freedom, I must be able to remove or modify it *even if you don't think I should*.

Keeping up with the car analogy, would you buy a car deliberately built so it cannot go faster than 65 MPH and attempts to circumvent that would be illegal?

I do understand -- and appreciate -- the point that they aren't only trying to protect others, but that the kernel devs don't want to hear clueless whining.

My point -- and really my main point -- is that when you operate to remove another's freedom, it had better be at more than just a whim, and more than your convenience. In this case, that fact that you have a couple people saying "don't do it!" to me means that it shouldn't be done.

It's not as if there aren't a lot of other kernel decisions that people can't whine about, you know. This is just yet another reason for those on LKML to say "RTFM. Go Away.". :-)


(Log in to post comments)

Look around you before answering... please...

Posted May 22, 2010 10:26 UTC (Sat) by khim (subscriber, #9252) [Link]

I should not have to pay because "more and more clueless people appeared".

You are not paying "more". If anything you pay less - old systems can be bought for cheap (unless they are very old and reach the antique category). You want new stuff for cheap? Sorry, it's not for you - it's cheap because of the economy of scale and this economy is only possible because it's not for you.

One way I got to be a "knowledgable, responsive [responsible?] user" was to hurt myself doing "stupid" things.

You think that being a "knowledgable, responsible user" is worthwhile goal and worth spending time. Most users don't think so - and since systems are created for them the rules are adjusted for them.

Maybe sometimes celerity isn't a virtue, and the modern motion of the inevitability of bugs in code isn't true.

Bug-free software is absolutely impossible. Deal with it. You can create tiny kernel which is mostly bug-free (and no, linux is way too big for that), but the rest of system will be bug-infested no matter what the programmers will be doing.

The assumption that kernel code is somehow special and should be specially treated is wrong -- *someone* is going to depend on code you write no matter how big or small the project, and an error in that code is gonna cause *someone* some trouble.

Brilliant observation! That's why I have zero sympathy for freetype developers. They brought the problems on themselves by exposing private interfaces - so not they should deal with the fallout. They should have done what all sensible people are doing: attached the visibility ("hidden") to all internal functions.

File permissions, quotas, etc are there to mainly stop a system user from hurting other system users. That's one of the normal policies of an OS. On the other hand, training wheels are fine for novices, but they are meant to come off.

Helmet, on the other hand, is meant to be used by everyone. Yes, some things should only be enabled in debug libraries (like _GLIBCXX_DEBUG) and some should be enabled all the time.

What I'm talking about is deliberately engineering something so that any safety gear is [almost] impossible to remove.

This is the right way to design things. Safety gear must be built robustly - or else it'll not work. It can always be removed by direct modification of program source (or even binary if the need is really strong). The ability to turn it off easily is actively harmful.

Keeping up with the car analogy, would you buy a car deliberately built so it cannot go faster than 65 MPH and attempts to circumvent that would be illegal?

Brilliant example. Of course not! 65 MPH is not enough - there are roads where you can travel faster! Real car's speed limit is set to 155mph or 112mph (depending on country). On the other hand, if you meat to say that artificial limits in cars is something unimaginable you've utterly failed: not only it's imaginable - it's widespread in real world!

My point -- and really my main point -- is that when you operate to remove another's freedom, it had better be at more than just a whim, and more than your convenience.

See the freetype example above. API usage freedom is not right, you must earn it - by showing use cases where it's needed and where nothing else really fits. See the recent dicussion related to such right: it looks like Google will get the wakelocks in the end, but it was not an easy sell. And this is good thing. Often it's much easier to just muck with system internals rather then use proper interfaces - but this leads to the Windows-like mess, where you can't change anything without breaking something.

Look around you before answering... please...

Posted May 23, 2010 5:40 UTC (Sun) by dmadsen (guest, #14859) [Link]

It is clear to me that we have rather different world views in the areas we have discussed.

This has brought home to me in a personal way the difficulties that a successful project manager must have when working with a diverse population, especially regarding cohesiveness and consistency of vision. Gentlemen, my hat's off to you!

Look around you before answering... please...

Posted May 23, 2010 13:49 UTC (Sun) by nix (subscriber, #2304) [Link]

There was no portable way to enable hidden visibility when FreeType 2.0 was released. GCC's visibility attribute is much newer. (But, yes, they should have hidden their internal interfaces *somehow*.)

I can understand SNAFU with freetype 2.1, but why persist in folly ?

Posted May 23, 2010 17:54 UTC (Sun) by khim (subscriber, #9252) [Link]

You are right, of course. Freetype 2.1 was released in 2002 and gcc only got visibility attribute in 2003. And other methods are not as nice. But we are in 2010 - and yet Freetype 2.3.12 (released just a few months ago) does not use visibility(hidden). Not even as option!

The "philosophy" was dead for a long, long time aready... deal with it

Posted May 30, 2010 4:32 UTC (Sun) by fredi@lwn (guest, #65912) [Link]

I agree on most of what you said. Except for one thing; you're talking about freedom, freedom to use your hardware as you please. And kernel people taking out that freedom. Here is where i dont agree, look, you have the sources, is not that the fact that there's no interface kernelside to use eg. RDTSC limits you, you have the source, so ... in case you need it, just add another syscall and use it.

The "philosophy" was dead for a long, long time aready... deal with it

Posted Jun 1, 2010 5:30 UTC (Tue) by dmadsen (guest, #14859) [Link]

I understand your point: if I don't like the code, I'm free to modify it as I please. And that is such a good thing, because it means that no matter what anyone does, if I feel strongly enough about it to spend money/time/effort, I can change it.

But I'm also talking about something a bit more subtle, which says "[don't restrict me] ** only because you think it's for my own good **". In this case, the reasoning is "let's disable it because it's not reliable and someone using it might have negative results". As a philosophy, this says "protect people from harming themselves".

My point is that to go down this path *in a general way* is a slippery slope; where do we stop in making a "safe" system, one where a {user,developer} can't hurt himself? Shall we, for example, as a policy decision, eliminate the ability to remove files from users and make it for root only?

I am aware, of course, that different functionality is directed towards users of different experience levels, and how that might affect any let's-protect-the-user-from-himself decisions.

But much learning comes from making mistakes -- and the "baby-proofing" one does in a home with toddlers is only enough to so that the baby doesn't get permanently damaged before he learns.

So I re-emphasize that we must be careful not to *blindly* apply the "let's remove that function for his own good" philosophy. Each case must be thought about carefully. And even then, should the decision to be made to protect the user from himself, it should be easy for that user to say "I've learned I can hurt myself, and I don't want to be coddled/restricted anymore because I've also learned how to use that sharp knife you were shielding me from". That's where freedom comes in.

And I re-state that the particular function in this article is surely not likely to be used by someone who doesn't already have the level of knowledge to understand the potential pitfalls. That is, he should not need to be protected, as he knows the stove is hot already.


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds