Windows 7 Reviewed

Posted on 2010-03-15 by M. Eric Carr

A few weeks ago, I finally decided to try Windows 7. Not being the trusting sort, I got a second hard drive (okay, fourth, but whatever) and installed Win7 alongside XP. Having heard mixed reviews of it, I wasn’t sure what to expect: I had heard that it was like Vista (not a good thing), but that they had fixed a lot of the bugs (good), but that maybe they had added DRM (always bad.) I hate the direction they’re going with the ribbon interface, and so I was worried about how that would influence the GUI, on top of everything else.

So far, so good, though — it looks like this one’s a keeper! Here are the benefits that I’ve seen so far, in rough order of their importance to me:

THE GOOD:

 

  • It’s 64-bit (at least that’s what I installed). I’m running a Core i7 now, and even though I’m only at 3GB of memory, it’s time to get the 32-bit barrier out of the way. So far, though, Win7 has done a great job of seamlessly merging 32-bit and 64-bit apps. It’s more-or-less run almost everything I’ve thrown at it nicely so far, from Flight Sim X to MS Office to Firefox to the various FreeBASIC apps I mess around with. Yeah, I know there’s a 64-bit version of XP, too — but I’ve heard that finding the right drivers for it can be a nightmare.
  • It seems very stable, at least so far — even with an almost-1GHz overclock. Sweet.
  • It still has Remote Desktop access support. (A good thing; if not, it would not stay installed for long.)
  • It has the new Math Input Panel! Draw math equations in freehand and they become nicely-formatted, professional-looking equations, complete with all of the symbols I’ve ever seen and a lot that I swear were developed by an advanced alien civilization. I gotta get a drawing pad! Very nice addition, MS.

  • They added a sweet Mahjongg-solitaire game. So much for actually learning more math or doing anything else productive at home. Oh, well.
  • Minesweeper got a major facelift: the squares now scale along with the window and have all kinds of cool 3D effects.

  • Freecell and Solitaire now scale intelligently, too.
  • It seems to have excellent driver support. For instance: I plugged in my Panasonic MiniDV camcorder to the FireWire interface, and Windows figured out what it was automagically. A small thing, but very slick.

    (Incidentally, it seems to have “semi-automatic” driver installation, for some devices. It didn’t automatically install a driver for my USB-to-RS232 adapter, but it *did* find the right driver on the Prolific website, and point me to it, so I could manually download, extract, and install it. Oookaaay.)

THE INDIFFERENT:

 

  • Win7 seems to think in terms of “libraries.” So do I, ‘cept I prefer to do the organizing myself. I may yet grow to like it, though, since this approach does give it the ability to sort/search things like my mp3 collection various ways (by artist, by genre, by year, etc). This is OK, since Windows doesn’t insist that you use this functionality.
  • The “Aero Glass” interface. I suppose it will grow on me — and I suppose it gives the GPUs something to do when I’m not running FSX or playing Oblivion.
  • Some of the games from the King’s Quest Collection don’t want to work correctly, at least not yet. (However, they are over twenty years old, so I think I’ll cut Windows some slack on this one.)
  • Same ol’ Notepad. Good to see Hell still hasn’t frozen over. <g>

THE UGLY (or at least annoying):

 

  • Where did my right-click-to-search option go, MS? I know you can search from the start menu now, but no breaking existing functionality, guys. Party foul.
  • Why is the show-the-desktop button all the way on the lower right? I’ve had it set up on the Quick Launch bar next to the Start button since the first Clinton administration. Grr.
  • Task Manager now has a “services” tag? Uh oh. Note to self: do not install Win7 at folks’ place without a LONG explanation of why you do not touch this. It’s bad enough they learned how to kill processes. A little knowledge can be a dangerous thing, when you (the family IT geek) live several hundred miles away. Yeah, it’s kind of handy to have on my own box — I figure it’ll save me ten or twenty seconds every so often. Maybe. Better would to have made it an optional customization, turned off for the Muggles. But then, the same goes for the Process list.
  • Sound Recorder has become even more of a joke than it previously was. Time was, it could change formats, record, playback, etc. Now, it can record, resume, and save. That’s it. No format selection (WMA; who-knows-what sample rate, number of channels, and resolution.) Good thing we have Audacity.
  • Paint and WordPad have been infected with the Ribbon interface. BOO.
Posted in Current Events, System Administration | Leave a comment

iDont, or Why The iPhone Is Evil

Posted on 2010-03-15 by M. Eric Carr

Tim Bray has been hired by Google as a “Developer Advocate.” On his personal blog, he describes what this means and why he is excited to have the job. It’s a good read, and definitely recommended. In particular, his take on the iPhone is dead-on: it’s not good for developers, definitely not good for the Web, and not even good for consumers, in the long run. Here is his explanation (excerpted from his blog post) of why the Android is better than the iPhone:

The iPhone vision of the mobile Internet’s future omits controversy, sex, and freedom, but includes strict limits on who can know what and who can say what. It’s a sterile Disney-fied walled garden surrounded by sharp-toothed lawyers. The people who create the apps serve at the landlord’s pleasure and fear his anger.

I hate it.

I hate it even though the iPhone hardware and software are great, because freedom’s not just another word for anything, nor is it an optional ingredient.

The big thing about the Web isn’t the technology, it’s that it’s the first-ever platform without a vendor (credit for first pointing this out goes to Dave Winer). From that follows almost everything that matters, and it matters a lot now, to a huge number of people. It’s the only kind of platform I want to help build.

Apple apparently thinks you can have the benefits of the Internet while at the same time controlling what programs can be run and what parts of the stack can be accessed and what developers can say to each other.

I think they’re wrong and see this job as a chance to help prove it.

Amen, Brother Bray. Google may or may not be able to keep evil out completely, but they’ve obviously made a good hire. Go get ’em.

Posted in Coding, Current Events, Digital, Digital Citizenship, Internet | Leave a comment

CD bit size calculations

Posted on 2010-03-14 by M. Eric Carr

A question occurred to me the other day — how big (physically) are the bits on a CD?

Measuring a CD’s inner and outer diameters, I got about 119mm for the outer diameter and 44mm for the inner diameter. Multiplying these by π*r2, I got about 38,400mm2 for the area occupied by the data. According to Wikipedia, a CD-R has 867,041,280 bytes of raw data (including the error-correction code and everything). Multiplied by 8, this is 6,936,330,240 bits.

Dividing, I got about 180,600 bits per mm2. Taking the square root, it turns out that about 425 bits placed end-to-end would be 1 millimeter long. Wow.

Imagine DVD-Rs (with 6-7 times the capacity, for single-layer) or BD-R discs (with about 36 times the capacity, for single-layer). 2,400 bits to the linear millimeter? Dayumn.

I took the CD-R and looked at it using one of the stereo microscopes we have in the lab — at full magnification, I was just able to see some wavy structure. You’d need something a bit more expensive (this was just a standard $250ish lab ‘scope) to see the actual bit patterns, I think.

On a somewhat- related note, happy Pi Day, everyone!

Posted in Digital, Math | Leave a comment

Software Engineering

Posted on 2010-03-13 by M. Eric Carr

Once again, Scott Adams has it right:

I never really understood most of the methodologies behind “software engineering.” Yes, a definite code-review process and overall plan is certainly needed for projects of any reasonable size — but to me, the main takeaway from the “Software Engineering” course I took was that there is a *lot* of management going on, and it doesn’t seem to be especially effective. We clearly still have not eliminated software bugs, and yet we were told in the course that twenty or thirty lines of code per day is optimistic, for large projects.

This seems ridiculously inefficient to me. If a project is broken down into manageable modules, coding should scale reasonably well across project sizes and across varying numbers of coders working on the project (assuming that one coder works on one module when writing.)

What seems even more insane is the idea of “pair programming” — where two programmers work in close cooperation as a team, with one computer. One programmer “drives” (writing the code) while the other “rides shotgun” and apparently just watches the first one code — presumably to point out mistakes as they are made and to provide running commentary. How can this possibly be more efficient than providing each programmer with his or her own computer, even if it’s a ten-year-old eMachines piece of crap? A cheap new PC costs less than $500 these days — less than a week’s salary for a programmer.

How about this for a methodology:

* The software group meets to nail down specifications for the project, decide on a language or languages, and writes these specifications down. All design is high-level at this point, and the focus is on whether this can be done in the time allowed and within the proposed budget. The client and lead developer share responsibility for the final version of this document. Input is welcomed from all developers, but the client and lead developer sign off on the master plan. (This part should take no more than a day for most projects, and probably an hour or two for many. For something huge like a new version of an OS, perhaps a few weeks at most.)

* Once the master plan is in place, the developers meet to break the coding down into modules. Each module is described in a module contract document, specifying what language or languages will be used to run it, maximum resources allowed, the deadline for module completion, and (most importantly) what values the module will be passed and what values it will pass to other modules, along with parameters. (For instance, a “square root” module would be specified to accept a single parameter of type double and return a single parameter also of type double.) Any possible error conditions should also be enumerated, along with how to handle them. For the square root function, if it is passed a negative number as input, should it return a zero, somehow have the ability to return a complex number, or call an error routine?

* Once the contract for each module is written, it is assigned to a team, ideally comprising one programmer. This programmer (or team led by one individual responsible for the module) writes the code and ensures that it meets the specifications.

* Once the module is written, it is sent to one or more other programmers (perhaps anonymously) for testing, along with its specification document. They note its performance on all test cases — or choose a representative set of test cases that they feel has the best chance of turning up any errors.

* The “main” program is handled as a module like any other, with its own specification contract document.

This methodology, I think, would help cut through a lot of the red tape associated with “software engineering” while providing a way to ensure that the code produced is sound. It also avoids the “extreme programming” idea of having programmers working in teams, which to me sounds a lot like trying to duct-tape cats together to make a better mouse-catching machine.

Posted in Coding, Digital | Leave a comment