4 ms·

This is the typical example where Linux suffers from lack of true engineering. The kernel API and libs should be stable, predictable and well documented. Ther

This is the typical example where Linux suffers from lack of true engineering. The kernel API and libs should be stable, predictable and well documented. There should be no hacks to support odd behaviour because odd behaviour should not be specified. Isn't that why we have POSIX? What with recent issues with egotistical libc maintainers, people throwing their pacifiers over having to support junk, people moaning about ext4 (even though it works fine and is poor app behaviour), it doesn't give people much confidence. Confidence is key.

varjag 17y ago
If Linux had its API frozen in 1991 there would be very little use for it now. Sometimes you have to change things to move on.
- smithjchris 17y ago
  Read this from end to end: http://msdn.microsoft.com/en-us/library/ms632680%28VS.85%29.aspx http://msdn.microsoft.com/en-us/library/ms632680%28VS.85%29.... Unchanged since 27 July 1993. Used trillions of times a day by millions/billions of computers.
  - varjag 17y ago
    Except that you are wrong, since the call includes special cases for Windows 98, ME, 2000 and XP.
tezza 17y ago
It sounds like your default state is "Full Confidence", and so Confidence is 'eaten away' in your description The better definition concerning Linux is that Confidence is "Built Up". Linux started as an unknown and has forced itself into people's confidence. Linux operates well 24x7x365 in many places, and that rate of Confidence build up is way more than any rate of loss due to Steering Committee squabbles.
davidw 17y ago
> The kernel API and libs should be stable, predictable and well documented. There should be no hacks to support odd behaviour because odd behaviour should not be specified. There should be a pony too. How can the kernel not have lots of hacks? It deals with hardware, which is often weird.
- smithjchris 17y ago
  NetBSD comes with a Pony :) POSIX rarely changes. They should start there and work backwards. UNIX nearly died because vendors wouldn't allow interoperability. Don't let it happen again. Look at Win32 - still works like it did back in '91 (with Win16).
  - jasonkester 17y ago
    Certainly you understand why Win32 still runs old Windows 3.1 code from 1991? It does so because of countless little hacks and "compatabilty mode" switches in the OS that emulate old bugs that existed in old versions that badly behaved software was taking advantage of. http://www.joelonsoftware.com/articles/APIWar.html http://www.joelonsoftware.com/articles/APIWar.html That's a good overview of how much "Maintaining weird legacy bug-compatibility code" you need in an OS with any history whatsoever.
    - smithjchris 17y ago
      I have seen the win32 subsystem source (legitimately through shared source - I used to work for the British Ministry of Defence). It's very clean and tidy and not full of junk like that believe it or not. The reason it still works is that they thought about it properly to start with. There have been very few extensions. The main one being adjusting pointer sizes (which are hidden behind a typedef like LPSTR anyway so that is irrelevent). And for the record I take anything Joel says with a pinch of salt. The guy is a trendy blog mouth piece.
      - jasonkester 17y ago
        In that case, I should have linked you directly to the Raymond Chen articles that Joel was paraphrasing: http://blogs.msdn.com/oldnewthing/archive/2003/10/15/55296.aspx http://blogs.msdn.com/oldnewthing/archive/2003/10/15/55296.a... http://blogs.msdn.com/oldnewthing/archive/2003/12/23/45481.aspx http://blogs.msdn.com/oldnewthing/archive/2003/12/23/45481.a... Here's a quote: This is just the tip of the iceberg with respect to application compatibility. I could probably write for months solely about bad things apps do and what we had to do to get them to work again (often in spite of themselves). Which is why I get particularly furious when people accuse Microsoft of maliciously breaking applications during OS upgrades. If any application failed to run on Windows 95, I took it as a personal failure. I spent many sleepless nights fixing bugs in third-party programs just so they could keep running on Windows 95.

varjag 17y ago

If Linux had its API frozen in 1991 there would be very little use for it now. Sometimes you have to change things to move on.

smithjchris 17y ago
Read this from end to end: http://msdn.microsoft.com/en-us/library/ms632680%28VS.85%29.aspx http://msdn.microsoft.com/en-us/library/ms632680%28VS.85%29.... Unchanged since 27 July 1993. Used trillions of times a day by millions/billions of computers.
- varjag 17y ago
  Except that you are wrong, since the call includes special cases for Windows 98, ME, 2000 and XP.

tezza 17y ago

It sounds like your default state is "Full Confidence", and so Confidence is 'eaten away' in your description The better definition concerning Linux is that Confidence is "Built Up". Linux started as an unknown and has forced itself into people's confidence. Linux operates well 24x7x365 in many places, and that rate of Confidence build up is way more than any rate of loss due to Steering Committee squabbles.

davidw 17y ago

> The kernel API and libs should be stable, predictable and well documented. There should be no hacks to support odd behaviour because odd behaviour should not be specified. There should be a pony too. How can the kernel not have lots of hacks? It deals with hardware, which is often weird.

smithjchris 17y ago
NetBSD comes with a Pony :) POSIX rarely changes. They should start there and work backwards. UNIX nearly died because vendors wouldn't allow interoperability. Don't let it happen again. Look at Win32 - still works like it did back in '91 (with Win16).
- jasonkester 17y ago
  Certainly you understand why Win32 still runs old Windows 3.1 code from 1991? It does so because of countless little hacks and "compatabilty mode" switches in the OS that emulate old bugs that existed in old versions that badly behaved software was taking advantage of. http://www.joelonsoftware.com/articles/APIWar.html http://www.joelonsoftware.com/articles/APIWar.html That's a good overview of how much "Maintaining weird legacy bug-compatibility code" you need in an OS with any history whatsoever.
  - smithjchris 17y ago
    I have seen the win32 subsystem source (legitimately through shared source - I used to work for the British Ministry of Defence). It's very clean and tidy and not full of junk like that believe it or not. The reason it still works is that they thought about it properly to start with. There have been very few extensions. The main one being adjusting pointer sizes (which are hidden behind a typedef like LPSTR anyway so that is irrelevent). And for the record I take anything Joel says with a pinch of salt. The guy is a trendy blog mouth piece.
    - jasonkester 17y ago
      In that case, I should have linked you directly to the Raymond Chen articles that Joel was paraphrasing: http://blogs.msdn.com/oldnewthing/archive/2003/10/15/55296.aspx http://blogs.msdn.com/oldnewthing/archive/2003/10/15/55296.a... http://blogs.msdn.com/oldnewthing/archive/2003/12/23/45481.aspx http://blogs.msdn.com/oldnewthing/archive/2003/12/23/45481.a... Here's a quote: This is just the tip of the iceberg with respect to application compatibility. I could probably write for months solely about bad things apps do and what we had to do to get them to work again (often in spite of themselves). Which is why I get particularly furious when people accuse Microsoft of maliciously breaking applications during OS upgrades. If any application failed to run on Windows 95, I took it as a personal failure. I spent many sleepless nights fixing bugs in third-party programs just so they could keep running on Windows 95.