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

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

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

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

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.


(Log in to post comments)

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!


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