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.
"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.
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.
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.
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.
Uh, I have access to GDB, Valgrind, and DTrace through Emacs (either through GUD or a separate mode). The integration is seamless enough for me, and if it wasn't, I could spend an hour writing an Emacs Lisp extension to fix it. This is classic FUD.
As I noted in my previous post, it's pretty much out-of-the-box for Emacs as well. But even if it wasn't, who cares? You're going to spend the next decade at least using your development tools. The smart thing to do is to pick the highest quality tools and spend the time to learn them.
In no other creative or engineering profession is there this expectation that the most advanced tools are shrink wrapped together. Who gives a shit if you can buy paint together with your brushes? Just buy the best damn paint and brushes you can find, regardless of who sells them.
I'm not arguing with you about what is the "best" development toolchain. FWIW I'm an Emacs user myself.
But my point stands: if you do want the fully-integrated IDE experience, VS is state-of-the-art, there's nothing like it on any other platform. That is why I don't say "better" or "worse" I say "not comparable".
Incidentally, you should check out a guy named Richard P Gabriel. His company made Energize, an Emacs-based IDE (in fact they were responsible for the Emacs/Xemacs schism). You may judge the interest in full IDEs in the Unix world from the fact that it no longer exists...
I dunno, I've got a hate-hate relationship going with Visual Studio. I've encountered so many bugs in the system (a particularly good one: UI designer executing code which made the window I was building work, calling the DB, autocompleting its own variable name with the results, filling drop-downs and everything) and so many basic functions are a PITA or non-existent that I routinely find myself wishing they'd just give me a gdb terminal.
Personal main peeve: the debugger is far from intuitive, frequently chops off strings in the inspector w/o giving any way to read the rest of them (no magnifying glass), and offers no way to test anything which cannot be done in a single line of code - ie, anything to do with enumerators, and nearly 1/2 the .NET framework I've encountered.
I'll agree that UX consistency certainly isn't as good as it could be on Linux, but I wouldn't hold up Microsoft as a paragon of that. Every version of Office for the last decade has done things its own way and differently to the underlying system; most of those have just been visual (XP + 2003) but of course 2007 is considerably different with its funny logo thing in the top left and the Ribbon.
Windows 7 seems to be full of things like that; most programs still have the classic menu strip at the top; Office has a sort of one with the Ribbon and hides parts of it under that logo thing; Explorer doesn't have one at all any more and Paint has a Ribbon too but a funny blue lozenge instead of a logo.
I would contend that Ubuntu Lucid is rather more consistent than that; every preinstalled app I've used is GTK-based so they all look pretty much the same.
I used Visual Studio for a very long time, and I think you're overrating it. The developer tools on Linux are just as powerful but they are different from what you'd use in a Windows environment. Sometimes people confuse difference for inferiority.
So why, oh god why, do the Windows Driver Framework examples in their latest kit include no integration with Visual Studio? You need a command line build to build drivers.
Yeah. I was kind of disappointed that the tech literature boasted over and over "Hey! This is the new easy to use driver framework!" but did absolutely nothing with the toolchain.
I'm just pushing through this aspect of the project so I can get back to linux kernel driver hacking, which is now looking like summer vacation.
I can't agree on the web side(asp.net, sharepoint, web parts, etc) but on the desktop (.net, c#, wpf, silverlight, parallel programming) I can't found something similar and when somebody speaks about HTML5 replacing the desktop I can't find any sense (I can hold my bet for the next 4 years.) There are few people with strong experience in many technologies to have a good argument in favor of the WEB with RIA. I simple example: there are not strong graph libraries (like Tom Sawyer, Jung) in html/JavaScript except prefuse in Flash.
Of course, since your professional career has been spent at Microsoft working in the Visual Studio group, it is no wonder you would perpetuate this view.
Xcode is far superior to microsoft's development tools. I think you're simply exhibiting stockholm syndrome. Please go back to developing only for windows. Thank you.
That really is where he's coming from. I worked at Microsoft a few years back, with some Vista and IM guys, and none of them used Visual Studio, despite pleas for feedback from DevDiv. It was all gvim and build.exe and windbg (the latter vastly more powerful than the VS debugger, even though I think the same team produced both).
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.
On top of that, the border between OS and libraries is fuzzy; OS providers will move it to get a competitive advantage. 3D graphics (historically, even 2D graphics), virtualisation, garbage collected runtimes, the list is endless.
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.
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.
"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].
His sentence does seem misleading to me: it reads like he thinks Windows at the core OS level (the scheduling/memory-management/drivers/etc. stuff he mentions in the intro) is still incrementally built on top of the old DOS-lineage code, as opposed to recognizing that it underwent a complete rewrite. If he's just arguing that the API evolution has been constrained by the need for backwards compatibility, that's true, but doesn't make much sense to his point in this context.
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.
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.
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.
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.
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.
"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.
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.
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.
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? :)
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.
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.
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.
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?
> 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/
> 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.
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.
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.
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.
> 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.
Saying that the App Store is an improvement over apt is a huge stretch though; it's not nearly as comprehensive.
>There's very little out there that Apple can honestly lay claim to having invented.
Please study computer history before making statements like this. All of your examples are false, and you didn't even scratch the surface of original inventions to come out of Apple.
You may not be familiar with the history of Apple, and may not use Apple products. That's fine. But please refrain from repeating the rationalizations of anti-apple zealots as if they were fact. Like Apple or not, there is no bay area tech company that has invented more in the area of personal computers.
When many database systems or language implementations rely on os cache, scheduling, threading and eventing implementations among other things then yes, the os matters.
>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.
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.]
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.
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.