humble suggestion to Fedora developers

[Reindl Harald]

Am 01.02.2013 19:34, schrieb Joe Zeff:
> On 02/01/2013 06:41 AM, Bill Oliver wrote:
>>
>> And it will approach 1 for *any* such distro.  Changing distros doesn't
>> help this problem, unless you go to one of the minimal distros that are
>> still oriented towards simplified manual configuration (if there is such
>> a one nowadays).
> 
> AIUI, Slackware probably comes closest.  Maybe we should design a distro with no configuration tools, GUI or text
> and call it "Luddite Linux," just to see how many people use it.  I'll bet there will be people installing it just
> for the bragging rights of "see how old-school my Linux box is."

no - for the bragging rights not PERMANENTLY get knowledge
destroyed because all the happy shiny new things are not
only change their internals, no they ALWAYS change their
configuraion interface compared with the things they replace

this si a really dumb attitude in the last few years

there are even command-line tools suggested to replace
well known ones with completly different switches
this is not how a replacement works

the guys which designed unix did a damned good job
their base worked over decaeds, was understandable and had a
well documanetation and a lifetime where the time to learn things
worth - these days you must be an idiot trying to undrstand how
the new shiny crap really works because before you finished
your study they all replaced again
_______________________________

the reason?

lazy and dumb developers with a poor attitude how software should
behave because if they would make things longliving it would
take more time and maybe get finished someday - no this must
not happen, things must not be final, never because after
that the new generation of developers would be bored

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 263 bytes
Desc: OpenPGP digital signature
URL: <http://lists.fedoraproject.org/pipermail/users/attachments/20130201/277ae0f0/attachment.sig>