Most (if not all) of these showed up in other places first, but it’s still a nice page both of what Minix has done and of getting a good feel for what reliability development is like.
It’s a refreshing change of thought process to approach your code from the perspective of “all code is very buggy, even what I’m writing right now”. Trying to get your “has to work” code down to the axiomatic core, layering things on top in fault-tolerant ways, reducing dependency chain lengths during architecture design – lots of fun stuff to do.
Reliability is, like security, also something you can (and should) consider at each level in the stack. For instance, the .NET CLR has a lot of reliability features that are new in the 2.0 version. Since this is the first version that was hosted in SQL Server, hopefully it’s obvious why the mandate for some of these was higher than it had been in the V1.x versions 🙂
So, as you may remember, while my motherboard’s integrated graphics passes all the individual technical tests for Aero/WDDM, Intel’s not written the driver for it, so I’m stuck with a 1.0 Windows Experience Index due to my crappy graphics. That meant I don’t get the nice Aero interface, but that’s fine by me, I don’t really care that much about it.
Well, today I go to run Windows Movie Maker (just to patch 3 avi files together) to find out they have their own requirements.
Clicking on the link, I get a help topic that says the requirement is DirectX 9. They really could have left out the second “drivers”, though 🙂 Note that I ran Windows Movie Maker just fine under XP, so I find it funny that it would suggest I check the computer and/or video card docs for whether they support that app, since clearly the version of that app in question is pretty important.
But wait! You may remember, also from that this video chip and its drivers actually do support DirectX 9 just fine (as it did under WinXP as well). Look at the entry just above the one I had highlighted back then…
So, I’m currently left with
- Windows Movie Maker not working
- a link to a help topic that describes what the video requirements are to work
- BUT, I meet the specified requirements just fine
Yes, I know it’s apparently going to require Aero-level graphics just for this, but this is clearly a pretty bad experience. Even if the user is savvy enough to know how to check for the DirectX support level of their card, there’s clearly lots of cards out there that will pass that check but still not run WMM in Vista. The only other thing to confirm is that full video acceleration is being used, which is indeed the case.
Now imagine if I had gone out and bought a DirectX 9 card based on that help topic, but WMM still didn’t run? Maybe it’s time to take all these old crappy video cards that do support DirectX 9 and pimp them on eBay as being all you need for Vista to run great! 😉
Yeah, it’s dorky, but still funny!
I am SO looking forward to the day when my hard drives are all solid state (at a reasonable cost). Thankfully it’s a matter of when and not if, but there are days when even my RAID-0 just isn’t enough.
Maybe I’ll order the hybrid hard drive for my work Vista machine and see if that makes life any better.
Maybe we did, maybe we didn’t – I don’t know yet. However, reading this blog post about WCF support for devices and taking the route of email as the transport mechanism, it’s sure phrased as if
- we thought up the idea of making method calls over email and
- we implemented it outside of the existing docs related to SOAP over SMTP.
So, at some point Mike Zintel started promoting an idea of using e-mail as a web service transport and putting a programming model on top of it. Hmm, e-mail!? I was really skeptical about this at first, as probably many of you are now.
This post is classic. Classic, I tell you!
An analysis of the 350 million lines of windows source code revealed that there were four unused TECO interpreters in there already, so it was very easy to add a fifth one.
Source: Shell Blog : Features that didn’t make the cut
This is a pre-RC2 build of Vista, and the particular bug has already been fixed, but it still makes me laugh.
In the Java world, you have the base type of java.lang.Throwable, and the subclasses of java.lang.Error (you basically never catch this, at least not in application code) and java.lang.Exception (this you can use to your heart’s content).
In .NET, for various reasons (and yes, I’ve had threads internally about this, including with Chris), there’s no such split of the hierarchy. There’s the base type System.Exception. There’s also a subclass called ApplicationException, where the idea was that we’d do our exception split there with a SystemException and ApplicationException split. However, even we couldn’t keep that straight, so now even we consider it useless.
Why bother bringing this all up now?
Because it looks like Python 3.0 is going to get it right. They’re doing what I think .NET should do at this point – give Exception a new superclass. Is it trivial? No. Will it break existing source? Yes. Is it the right long-term answer? I think so.
In addition to the deprecation of raising strings as exceptions, Python 2.5 also rearranged the exception class hierarchy. The new
BaseException class is the base class for
Exception. You should now derive all your custom exception classes from
Exception, or from a class derived from
Two other exception classes,
SystemExit, also extend
BaseException, but not
Exception. Thus, you can trap your own exceptions, and then trap all other exceptions derived from
Exception. This will trap every exception except
SystemExit. Why would you not want to trap those two exceptions? That way your program will end when the user presses Ctrl+C without you having to manually catch and respond to Ctrl+C, or without you having to manually skip catching Ctrl+C to let the system handle it. The same is true with the
SystemExit exception, which should force the program to stop.
This particular new feature, then, is less of a feature and more of a requirement: Recode your exception classes to extend
Exception. Then you’ll be fine when Python 3.0 arrives.
Another little useful XP thing I find gone in Vista is the ability of the terminal services client (mstsc) to save credentials (user/pass) to the RDP file. In particular, in the RDP file the “password:” entry would be written hashed (presumably with something about the machine as the salt, since it doesn’t work on other machines, but I’ve never dug into it)
Where you used to have a username and password set of text boxes (and could then save these to the RDP file), you now just get a notification that you will be prompted. Tellingly, the size of the “Logon settings” group box is the same, so you have a big empty gray area to remind you of the functionality lost.
It’s worth noting that the client still respects the RDP files written by earlier clients, though, so if you can get that password: entry written by something other mechanism (*cough*) then you’ll still be fine.
This is one of those places that highlight that usability and security exist on opposite sides of a gradient. Will security be a bit better now that the common user won’t be able to save their credentials to RDP files? Probably, but now the client’s a little less usable for many people. C’est la vie.