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

GNU + Linux = broken development model.

GNU + Linux = broken development model.

Posted Jul 29, 2009 19:02 UTC (Wed) by berndp (guest, #52035)
In reply to: GNU + Linux = broken development model by mheily
Parent article: A tempest in a tty pot

Your perception of the kernel development model is broken: It's not that 2.6.30-rc5 (or 2.6.31) hits the desktop of Joe Plumber the day
after publication on http://www.kernel.org/ of distributions. That's the job of distributors (and it's the same in the
BSD world - they are distributing the complete OS so they must be compared the Linux distributors).

Assuming that "kdesu" is broken, there is plenty of time for "kdesu" to get fixed (and pushed expedited downstream because it's a bug fix!).
Maintaining bug compatibility is plain simply not worth the effort (and it is IMHO violating any sane open-source development model
where it's at least possible to *fix* bugs and not maintain an enormous amount of bug compatibility code - and maintenance effort - for ages.
Why else should Windows needs exponentially more resources with each release?).

If someone wants eternal backward bug compatibility, please *do* it - but do not complain to others or even ask them.
Especially not for some random buggy app which just happen to not trigger a race condition.


(Log in to post comments)

GNU + Linux = broken development model.

Posted Jul 29, 2009 19:32 UTC (Wed) by mheily (guest, #27123) [Link]

Sometimes it's not clear which codebase is "broken" and needs to be fixed. Alan Cox's changes may have been totally legal according to the RS-232 standards, but if Emacs and many other programs depend on the old behavior, it's difficult to say that all userspace programs must be changed. One person's "bug" is another person's "feature" :)

I do agree with Linus that increased kernel parallelism should avoid impacting userland code that depends (rightly or wrongly) on serialization.

GNU + Linux = broken development model.

Posted Aug 7, 2009 11:24 UTC (Fri) by efexis (guest, #26355) [Link]

"Why else should Windows needs exponentially more resources with each release?"

Sloppy development, greater number of features we're greater for, and greater number of features that we're really really not.

Windows uses subsystems for different API sets (whether it's dos, posix, win16, win32, .net etc) that are loaded on use, with backward compatibility confined within the subsystem, or even different versions of the library or live patching. MS are also always pushing their newest 'bestist' API sets, which means if you're not running old software, you tend to not be needing to load the old APIs (you can have windows run with win16/dos support completely removed for example) so there's no extra resource requirement there... and if you are running old software, then of course you need the old support.

Win7 looks to have lower requirements than Vista (I can even run it on my laptop, something I couldn't dream of with Vista), but still, it's much slower for basic functionality than my 2003 install. Basic stuff like recursive file meta data scanning, more progress bars (which require two-pass operations, one to find out how much stuff there is to be done, and the second to do it) slows down the UI. Services to control CPU scheduling for media applications adds complexity there, as do the various annoyance^H^H^H^H^H^H^H^H^Hsecurity services. It's genuine complexity of the OS combined with less than optimal coding that makes it chug, backward compatibility cruft really isn't as big a player as you might think.


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