
The OS Doesn’t Matter… - mjfern
http://www.mondaynote.com/2010/10/03/the-os-doesn%E2%80%99t-matter/
======
larsberg
This post is amusing because it writes off Windows, but then claims that the
UX and the developer tools are the two areas where there's a lot of work to be
done on modern UNIX systems.

For those who haven't used them professionally, Microsoft's developer tools
are absolutely fantastic. And not just the editors, debuggers, and code
assistance -- the profiling, system monitoring, and large project workflow
tools are years ahead of anything that you can get off-Windows. Even if you're
willing to pay Real Money to IBM, the only other serious tools vendor left, or
pre-merger Sun, which had the best non-Windows profiling support in-system.
Coming back to XCode, the GNU stack, and Eclipse after years on the MSFT
platform was like taking a flying leap back into 1998.

UX is pretty consistent on both the Apple and Windows platforms. Once you
learn a couple of apps, you've basically learned them all. I can't say that
for the Linux desktop, where apps still seem to be roughly as consistent as
architectural patterns across 3rd party Java frameworks. It's hard to imagine
something "better" without moving to a new device factor so that you don't
alienate your user base.

~~~
poet
"The profiling, system monitoring, and large project workflow tools are years
ahead of anything that you can get off-Windows."

It's patently false that the profiling and system monitoring tools you can get
on Windows are _years_ ahead of anything you can get on a different platform.
In fact, it's the opposite [1, 2]. And I wont even get into the fact that
we're still catching up to 30 year old Lisp machines in the areas of editor
integration, debuggers, and code assistance.

[1] <http://en.wikipedia.org/wiki/DTrace>

[2] <http://valgrind.org/>

~~~
gaius
I don't think you've experienced the level of integration Visual Studio brings
to this. DTrace and Valgrind are great but they would need to be _seamlessly_
integrated into Eclipse to be comparable.

~~~
Groxx
In-application integration is necessary? Higher integration just means that
your debugging task is modal instead of allowing you to edit your comments
while the debugger is running. It also means your application eats up more
memory and takes longer to launch. It _also_ means you can't substitute it as
easily for something different.

I'll take my separation + hooks for launching _any_ day over massive
integration that means doing what you want is hard / impossible.

~~~
kenjackson
Actually you get both. I can edit comments while debugging and I can edit code
that gets recompiled on the fly while debugging.

~~~
Groxx
Depends on the language / framework. ASP.NET 2.0 with VB, for instance, does
not. Furthermore, modifying a WebService doesn't inform the web server that
it's been updated, so it keeps serving up old versions of your code.

ie, even MS's own products don't play nicely with each other. But you're more
stuck with them than you would be with something more atomic and disconnected.

------
j_baker
To me, this is like a automotive executive saying "the engine doesn't matter,
they're all the same anyway". The engine probably _doesn't_ directly matter to
most customers and they _are_ mostly the same. However, it's lunacy to say
that the heart of your product isn't important. If the engine has problems,
your customers have problems. If the OS has problems, your customers have
problems too.

Yeah, developer tools and APIs are very important, but they're only as good as
the platform they target.

~~~
KeithMajhor
The majority of available operating systems provide similar system interfaces.
The same is not true for user experience, developer tools and APIs. His point
is that these peripheral features will determine the success of operating
systems.

Consumers are more concerned with the shape of a car than the engine that's
inside.

~~~
j_baker
Customers _do_ care about the engine, just not explicitly. They may want a car
that goes fast, gets good gas milage, and is reliable. They won't ask about
the engine, but it has an effect on those things.

By that same token, customers want a mobile phone that is fast, gets good
battery life, and is reliable. Again, they won't ask about the OS, but it has
an effect on those things. Thus, customers care about the OS; they just don't
know it. Plus, I shouldn't have to tell you that similar interface != the same
thing.

------
soult
Actually Windows NT was a completely new kernel that had nothing to do with
the old Windows 3.1/95/98/ME stuff.

~~~
Terretta
"Actually", his sentence begins with the word "Initially".

> _Initially built on top of DOS, Microsoft painstakingly added version after
> version, always striving for backward compatibility while, at the same time,
> adding new features._

It was "initially" built on DOS. And over time, Microsoft painstaking strove
for backward compatibility, not giving it up even for a major architecture
change. NT offered a DOS VM (VDM) / Windows VM (WoW)[1], and Windows 7 offers
an XP VM [2].

[1] <http://kb.iu.edu/data/acxn.html> [2]
<http://www.microsoft.com/windows/virtual-pc/download.aspx>

~~~
gaius
Yes and "initially" Unix could only run one process at a time. But modern Unix
is far in advance, and modern Windows is far in advance of DOS.

~~~
borism
What are you talking about? Even Multics was multitasking. Heck, that's
already in the name.

~~~
gaius
Unix has no code in common with Multics.

In the first Unix, starting a process from the shell did exec, not fork. When
the "child" process exited, the kernel would restart the shell. All the
process control stuff came when Unix was rewritten in C from the original
assembly.

~~~
borism
I know they have no code in common. I'm talking about the fact that both were
multitasking from the beginning. You're talking about specific early shell
behavior. Nothing to do with capabilities of kernel which provided
multitasking for two terminals at once.

 _Processes (independently executing entities) existed very early in PDP-7
Unix. There were in fact precisely two of them, one for each of the two
terminals attached to the machine._

[http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.156...](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.156.4012&rep=rep1&type=pdf)

------
aspir
Though this is slightly unrelated, I wish I could send this article to every
software company who makes the tools I need, but only makes them windows
compatible. I'm all unix on my end, but I'm having to scrape together
emergency funds for a windows box that can run ESRI and other GIS systems (my
systems are just old enough to prevent a feasible dual boot as well). It's not
huge issue, but definitely an inconvenience.

~~~
Someone
I am not familiar with current pricing, but if you need to scrape together
funds, I would guess that buying GIS software would be out of the question.
Nowadays, most specialized PC software is more expensive than the minimal
amount of hardware it needs to run.

~~~
aspir
You're correct about the software- it's brutally priced. But I have access to
University copies that, though underpowered, can work for what I'm trying to
do right now. I'm extremely lucky though.

~~~
Someone
Aha, now your statement makes sense to me. I did not think of that
possibility.

------
extension
"The OS" doesn't matter because it has been decoupled from "the platform",
which remains crucial. Developing for Android or iOS, you are exposed only to
vague clues that they are implemented on top of Unix. The only reason the OS
ever did matter is because virtual machines and complete API abstraction
layers have not always been practical.

Also, writing off QNX as just another Unix is a mistake. An RTOS with
synchronous IPC baked in to the kernel is potentially game changing
technology, though I am skeptical that RIM will manage to fully exploit it.

~~~
glhaynes
What advantages do you expect those attributes of QNX could bring to RIM and
their users? I understand that QNX has more sophisticated real time
capabilities than Android's Linux and iOS' Mach/BSD kernel, but what does that
make possible/easier for applications and frameworks on top of QNX than on top
of those other kernels?

I certainly agree with you that "the OS" doesn't just mean the kernel nor even
the basic userland anymore.

~~~
extension
It's a big topic, but in a nutshell: when you can make calls across processes,
simply and efficiently, it opens a world of possibilities for interoperation
between applications. You can't fake this with sockets, no matter what you
layer on top.

Surprisingly, it was the legacy BlackBerry OS that made me realize this. It
has seamless IPC too, but only as a side effect of a horrifically insecure and
unstable memory model.

~~~
glhaynes
Do you have any examples or links? I'm sorry, I'm really interested in what
you're saying but I'm just having trouble imagining how it would affect my
architecture or what I could do with it that I couldn't feasibly do without.
Thanks. And, yeah, things were a whole lot easier back before all this silly
security and memory protection, weren't they? :)

~~~
extension
It takes a bit of imagination, but think about replacing shared libraries,
plugins, and socket IPC with _services_ that live in their own process with
their own lifecycle and security sandbox, but can still be accessed
efficiently. Apps can be built from many such services, and services can be
shared between apps.

There have been many attempts to build this sort of capability into mainstream
operating systems, but none have become popular due to the inescapable
complexity of IPC. A recent example is D-Bus, which is supposed to be "lite"
yet still involves XML interface descriptions and serialization. It's enough
of a hassle to implement that nobody bothers, unless it's the only option or
they are evangelizing the technology.

QNX is built from the ground up to do everything this way. If it makes IPC
easy enough, it could bring this type of software architecture to critical
mass.

I realize this is still pretty vague, but I can't think of a specific example
at the moment. If you're interested, read up on QNX, or Coyotos, which is a
more experimental OS that is based fundamentally on IPC.

~~~
glhaynes
Thanks very much for the reply. Yeah, that's interesting. I wonder how much
Blackberry's new OS will leverage that, especially since they seem to be
targeting the ability to write apps that run on OS 6 and the new Tablet OS. I
suppose that's probably more at the UI level whereas services that can be
cleanly separated could still perhaps use a separate service model on the QNX
based OSes. And of course there could be some interesting implications for the
OS' ability to manage these granular processes for maximizing battery
life/etc.

------
jsz0
I got interested in technology at the time when the mantra was "UNIX is dead,
Windows is the future" It's amazing how much things have changed. It's
probably a testament to how good Windows actually is that Microsoft has been
able to hold onto the desktop computer market while the rest of the technology
industry has adopted Linux/UNIX on such a large scale. It's a fun exercise to
make a mental note of all the various Linux/UNIX devices you see in a day.
SOHO routers, TIVOs, TVs, SmartPhones etc. It's everywhere.

------
iuguy
> The App Store genre, invented or not in Cupertino, is now part of that loop,
> a killer OS component, one that deserves a Monday Note of its own.

There's very little out there that Apple can honestly lay claim to having
invented. Refined, improved, made look silky smooth, sure. Invented? No. OSX
is built on ... *Step technology. The Mac OS Classic GUI is taken from the
Lisa, which is taken from the Xerox Parc. The MP3 Player? Nope, not theirs
either.

All of those are great examples of something Apple has taken from elsewhere,
refined and improved. The App Store concept had been implemented some time
beforehand by Linspire (with Click 'n' Buy for Lindows) which in turn was a
front-end to Debian's APT package management tool.

~~~
protomyth
The basic idea is from Xerox (bought a paid by Apple stock), but the
refinements done by the Mac team are really not given enough credit. I wish
Parc had been able to release their stuff, but one should really go search for
how their windowing system actually worked. The Mac team did some serious
refinements (not to mention an amazing job of getting it to run on such a
resource starved system).

Truthfully though, the current Apple is really more of an NeXT takeover of
Apple and *Step is a direct legacy.

~~~
lzw
It is fair to say that the Mac team invented the GUI, while Xerox invented the
Mouse.

~~~
jff
That would be fair, except that the mouse was invented at SRI. Also, Xerox did
release a commercial GUI product before the introduction of the Mac, as did
Three Rivers (PERQ) and AT&T/Teletype (the Blit). So there's that.

~~~
prodigal_erik
They did invent overlapped windows, and clipping efficient enough to get away
with it. They thought they had seen overlapped windows at PARC, but those were
actually just tiled.

Also auto-configured network clients.

------
dbrannan
To me it looked like Apple would scrap OS 9 for BeOS, but after Steve Jobs
came back it was forgotten. I remember playing around with BeOS at the time
and thought it was pretty fun, though I don't know much about it. Is it UNIX
based? Has it gone anywhere since?

~~~
masklinn
> To me it looked like Apple would scrap OS 9 for BeOS, but after Steve Jobs
> came back it was forgotten.

Erm... Jobs came back because the BeOS deal didn't go through. That was the
point: Apple could go on their own, with Be or with NeXTSTEP. NeXTSTEP was
Jobs's company.

> Is it UNIX based?

No, though it has a POSIX compatibility layer (and therefore access to BSD CLI
utils)

> Has it gone anywhere since?

Be, Inc was sold to Palm for a penny in 2001 and BeOS was killed. Fans are
writing an OpenSource BeOS (with no IP-relations to the original one, but
goals of being able to run BeOS binaries unmodified for instance) with Haiku:
<http://haiku-os.org/>

~~~
dbrannan
So, now BeOS is owned by HP?

~~~
masklinn
Technically yes, though actually BeOS is dead (unless you count Haiku).

------
melipone
Let's not forget Lisp OSes like Genera or Xerox's. Plus ca change, plus c'est
la meme chose.

------
siculars
When many database systems or language implementations rely on os cache,
scheduling, threading and eventing implementations among other things then
yes, the os matters.

------
Groxx
> _Windows will live on — in a PC industry now at a plateau._

In America, maybe. Are they claiming the number of PCs will not increase
significantly? Especially given their losing ground to OSX, they're most
certainly not at a plateau that isn't self-inflicted.

~~~
billswift
Yes, but large parts of the world are explicitly trying to avoid becoming
dependent on MS software. While Windows is still growing in other countries,
quite a few are subsidizing or requiring the use of other OSes (usually
linux), trying to avoid too much lock-in. [Added: OK, I see what you are
getting at, I had read the original paper to mean that Windows on PCs was at a
plateau; it is pretty common to use PC to mean a PC with Windows. And with
iPads, netbooks, smart phones and the like, the PC form factor might actually
be at a plateau itself, or approaching one.]

~~~
Groxx
Certainly. But that does not imply at _all_ that the _PC industry_ is at a
plateau, simply that MS may be.

------
RexRollman
I wish the writer of this article, Jean-Louis Gassée, could have had better
luck leading Be Inc and BeOS, as it was my all time favorite OS. I still run
it in emulation, from time to time.

