Sound advice - blog

Harry Phillips writes:

Linux does not need a "Killer app", more open source projects need to be ported to Windows.

He refers to this article as his inspiration.

The article does not appear to be well-researched. It is an opinion piece, but I think it holds a few grains of truth. This blog entry is an opinion piece too, and is probably less well-researched. Today, we already see open source software creeping onto the windows desktop. Companies like Green PC in the sub-$500 PC market appear to love the cost savings they can make with a bit of open source software (in this case, openoffice) thrown into the bundle.

It's a niche with pros and cons, but I think some of the pros are notable ones. People may start to get used to working with openoffice software at home. Slowly it creeps into educational institutions, four years later it starts to make its mark on industry.

Maybe that's a pipe-dream. Doubly-so because I would rate the software's usability at around 2/10. I hate the bastard.

Nevertheless, the crossover of open source software onto the windows desktop is very interesting indeed. The mozilla and openoffice technology stacks are mature on windows as well as unix-like and mac platforms (as a short list). GTK applications are starting to make a splash as well. Gimp now has windows support which should continue to improve over the next few gtk revisions. Some might point out qt, especially given their recent version four beta release, which has been mature and open source for some time but still has the ring of "that company owns it, not us" about it and has a strong C++ aftertaste.

Anyway, the future is looking bright for open source software under windows. Why is this important?

I think the use of open source software on the windows platform is not that useful to open source. It may have positive impacts on the individual products. They may recieve more contributions and more feedback from the wider audience they've courted. This may feed back to a better overall user experience. It may even raise the profile of open source. On the whole, though, I don't think it will be a big win in and of itself. To me, the win is in retaking the platform.

For some years, Microsoft has been able to claim all the best software because of a self-fulfilling prophecy (as well in part to a reasonably sound software development platform). You need things to work under windows, so you develop for the windows platform. Java tried to break this model with the write once, run everywhere philosophy. This philosophy has been adopted by a number of other portable platforms that have been migrated over the top of windows. As I recall, the first major beachhead was retaken with perl. It was genuinely useful to windows users, and filled a hole that Microsoft had failed to. With more and more common platform between Windows and those other camps, it is starting to become viable again to write software that will work under other operating-systems "as well".

I'm currently tinkering with (nibbling at) an accounting system written in python. To get it working under windows all I had to do was to make sure it had only gtk dependencies, not those of gnome. I use sqlite as the file-storage-slash-database, which was also available trivially. I expect that if I add further dependencies they'll be available in a similarly straghtforward fashion. I can write once, and run (test) everywhere.

I think the most important problem in software at the moment is in defining practical platforms for the development of high-level software. I think the main risk to this problem being solved entirely is still the split between the three main free desktop camps. Mozilla, openoffice, and gnome (Did I forget KDE? Oh, my bad...) are all built on essentially-incompatable software stacks with three different sets of abstractions. I believe this harms the solution not only on the free desktop but on the windows desktop. If this problem isn't solved in the next five years or so (perhaps in the timeframe of the Windows Longhorn release) I think the tide may turn back again and we may find Microsoft dictating the platform once again. Perhaps Mono or other .NET clones will help us to still write portable software in that time, but my real ambition for open source would be for Microsoft itself to eventually be forced to contribute to the one true codebase.

I'm all for open source software under Windows, especially if it means that open source platforms become defacto standards under the windows dekstop. I would love to see sufficient momentum behind those platforms that they outevolve and outdevelop Microsoft's competition on its own operating system.

Once the standard windows desktop is gnome-based, why would anyone buy windows?

Benjamin (the dreamer)

Ben fowler writes:

If you're stupid enough, despite the EULA, to use our (Microsoft Windows) software to run a nuclear reactor, weapon system or other safety critical system, then it's your funeral (and maybe everyone else's)

The trouble is, windows is everywhere.

I've been working with Solaris for the last five years, but that's coming to an end. Particularly in asia Sun is often seen by our customers as a supplier with an unsteady future ahead of it. They want commodity hardware to work with, and commodity software. Some ask for Linux by name. Some ask for Windows by name, especially for desktop machines.

The reasons are sometimes complex and varied. Sometimes they ask for a SCADA system but secretly dream of a general computing platform that they can use to access other systems as well, or maybe just trawl the internet for humor. Sometimes they want to avoid us having them over a barrel when it comes time to upgrade. They want to be able to buy their own hardware, or at least feel confident they could if they needed too.

Often the customer doesn't have as much expertise as they think they do, and what they assume anyone can do would actually introduce risks to the system unless it is very carefully considered with some reasonably in-depth knowledge. In the end, we provide a solution. When the solution needs to be updated we are probably the best people to do it (if you're still staying with our systems).

Anyway, I meander from the point.

Windows.

Windows is used in saftey-related systems. Not all of them, but many of them. People who work with safety-related systems want commodity hardware and software, too, and until recently the options have been very slim indeed. They remain slim, to be honest. When you aren't dealing with hard realtime requirements and you have a software-heavy solution you don't want to reinvent the operating system, hardware, and development environment. You use something off the shelf that does the job and doesn't cost too much money. Companies that provide these systems aren't very good at sharing with each other, so truth be known there's not a whole lot out there. Windows is said to be a good choice, at least once you've pulled out any uneccessary services and run the same version for half a decade or so. It can be a good choice. Most vendors in the field have far more experience in deploying Windows solutions than Linux or BSD solutions.

My background over most of the past five years hasn't actually been with saftey-related software. The project I was working on involved code that was one step removed from the safety-related component. That's no longer true, so I've been immersed in saftey-related thinking relatively recently. At first it surprised me that the people who did have a lot of safety-related software experience dealt mostly with windows. It surprised me more when they told me that while they were currenly only certified with an ageing windows NT operating system base they felt confident in achieving certification very soon under Windows XP. They weren't much interested in Linux, and the idea of using Solaris seemed outright confusing to them.

Of course, we're not talking about nuclear reactors here. We're talking SIL2 systems (sometimes called non-vital in the old tongue) that tell SIL4 systems what to do. In the end it is the SIL4 systems that decide whether something is safe or not, and are perfectly willing to override the SIL2 decision when it suits them. Some of those SIL4 systems are technological. Some are procedural. Still, it's very embarrassing when your SIL2 system goes down even after accumulating several years of uptime. We prefer to see the hardware fail before the software does. Likewise, SIL2 systems do have safety-related responsibilities (otherwise they'd be SIL0). Unlike a vital safety-critical (SIL3 or SIL4) system, your non-vital saftey-related (SIL1 or SIL2) system typically generates unsafe situations when it fails badly as opposed to actually killing someone directly. We all like to be sure that ours sytems aren't going to fail badly.

Meandering again, yes.

The safety-related parts of our applications also tend to be running on secure networks, although we've seen recently that isn't always a true safeguard. Oh well.

Now what does the UK Health & Safety directorate have to say about the use of Linux and Windows? They're pretty conservative guys, but are surprisingly positive about linux. They were (very breifly) less positive about windows. That report was pulled, though, no doubt after pressure from both Microsoft and parts of the various represented industries that were more comfortable with their windows solutions than any potential linux solution.

In the end, I think we'll see a linux vs windows battle on the safety-related software front. Each one will creep up to around the high SIL2 mark and most applications will be able to make use of either one. Currenly windows is still out in front in that arena (at least from where I'm sitting) because of longer term industry exposure. When look towards the SIL4 mark we will continue to see (as we do now) lots of bespoke software and hardware that brings in enough margin not to have to commoditize. Until the market shifts to put pricing pressure on those guys I think we'll continue to see that approach. On my end of the market, though, there is a price squeeze that makes bespoke impossible. Non-commodity non-bespoke solutions such as the use of Sun hardware and software are becoming a nonsense to our sector as they are to many other sectors. Windows and Linux look like the only contenders (and linux has a lot of catching up to do).

Benjamin

I suppose I should get around to replying to this article, part of a blogosphere exchange that Adrain Sutton and myself were having about a month ago when I dropped off the net for a while.

I'll start by attempting to resummarise our respective positions. Adrian, please let me know if I've misrepresented you on any of these points:

The reason I started writing about exceptions was not to annoy the gentle reader. The spark was actually in python's pygtk module. You see, python has a problem: It doesn't detect errors at compile time. This means that whenever you make a typo or do anything equally silly you have to find out at runtime. Rather than terminating the process when these are discovered, python throws an exception.

Fine. An exception is thrown. I don't catch it. I get a stack trace on the command-line, and everyone's happy right?

No. The pygtk main loop catches it, reports it, and keeps running.

You can't really blame pygtk, can you? Just above it on the stack is the C-language gtk library code which has no exception support whatsoever. Even if it did, chances are it wouldn't support arbitrary python exceptions being thrown through it. The pygtk library has one of two choices: Catch it, or kill it.

As you might have gussed by now, my preference is "kill it!". There is supposed to be an environment variable in pygtk to govern this behaviour, but it appears to have disppeared at some point as I haven't been able to stop it from handling the exception. As a result, my program keeps running (after not fulfilling the task I gave it) and I have to explicitly check the command-line to see what went wrong. Pain-in-the-bloody-arse-exceptions.

I don't think exceptions are a great idea. I think they add more code than they reduce, and add more code paths than the (in my opinion) usually better course of action in terminating immediately. I know my views are heavily-grounded in systems where failure of the process doesn't matter because you aways have a redundant copy and where you're more worried about misleading data making its way to the user than to have them see no data at all. Still, I think my views are more applicable to the desktop world than the views of the desktop world are applicable to my world.

Save your work? That's for sissys. Use a journalling file-saving model. Save everything the user does immediately. You can support the traditional file save/load facility using checkpoints or other niceties but I fail to see why any application in this modern age of fast hard drives should ever lose data the user has entered more than a few hundred milliseconds ago.

Use exceptions because of a bug in some piece of code that's feeding you data? You're just propagating the bug and making handling it a much more complicated problem. Just fix the code in question and be done with it. Don't get me wrong, I absolutely think exceptions have some good points over returning a silly little error code. I just think that the bad outweighs the good. I believe that a refinement of the return code model rathern than the complete reimplementation we see in exceptions would have been a better course for everyone.

Benjamin