Quick iPad review

April 23rd, 2010

Two of my colleagues from IT and I stopped by the Apple Store today; several faculty members have requested iPads, and we received authorization to get one for ourselves, to become familiar with it. We weren’t able to take delivery today, though. (The Apple sales rep at the store actually said that “because of the demand” it “didn’t make sense to stock product.” I kid you not.)

I’m glad I’m not from Planet Cupertino.

We did, however, get to try the iPad, since they did have a couple dozen or so demonstrator units on display for people to play with. As with everything Apple, there’s a lot of good, but mixed in with some bad and some downright ugly.

First of all, hardware-wise, I think Apple has a winner. Apple’s engineering has nearly always been quite good (we’ll forgive them the original iMac, since they seem to have learned their lesson.) The iPad feels solid and professionally made, while still being light and usable. Apple claims that the battery life is ten hours. I’m guessing that they mean ten hours reading a single page of an eBook with brightness set to minimum and WiFi off — more like four or five hours, the way I’d probably use it.

The good:

  • The display is gorgeous. Bright, crisp, and (mostly) easy to see. The glossy screen does mean that if you’re viewing dark images, you will tend to see a distinct reflection, which hurts the experience. It’s generally pretty dark in my Geek Cave, though, so this isn’t a big deal.
  • It has an accelerometer, and puts it to good use just like the iPhone does; most apps will rotate around to follow the way the iPad is being held, switching smoothly from portrait to landscape mode and back within a few seconds. The demonstrators at the Apple Store included a really fun ball-in-the-maze game, complete with all kinds of obstacles and puzzles only possible in a computer game.
  • Pinch-zoom and scroll are generally very snappy; the Google-powered Maps app that it comes with makes a great demonstration. Whatever Apple has under the hood, it gets the job done nicely.
  • As with most Apple offerings these days, it feels like a solid, quality product. Apple’s hardware engineers do tend to “do it right.”

Some drawbacks:

  • 3G isn’t available until a few weeks from now; the iPads available now (well, “now” being “in a few business days since we at the Apple store can’t be bothered to stock product”) are WiFi-only.
  • There’s no real keyboard (unless perhaps a Bluetooth one will work), and the onscreen keyboard is about on par with the iPhone’s — that is to say, slightly south of a “meh” in my book. I had expected faster, more accurate response, especially since there is so much more screen real estate to work with.
  • As mentioned above, the screen is glossy and therefore very reflective. This made it difficult to see at times, when darker content was being viewed. (The environment was the Apple Store, lit similarly to a modern office.)
  • The sound was just barely audible in the (admittedly somewhat noisy) store. The (very cool if a bit unresponsive) Piano app that I tried (a great use of multitouch if I ever saw one) was very difficult to hear, even with the app and system volume controls set to max.
  • It runs Apple iPhone OS. This does make it easy and fairly intuitive to use, but to someone used to “real” computers (Linux, and even Windows), it has the distinct Apple mindset of “you’re-not-supposed-to-be-using-this-for-things-that-Apple-doesn’t-want-you-to.”
  • It’s too big to put in your pocket — even in cargo pants. Size-wise, it’s definitely in netbook territory, only a lot thinner.
  • The screen could possibly be a bit larger (but that’s personal preference). This would allow more touchscreen apps like a full-size, playable piano, or a much easier-to-use onscreen keyboard.

Showstoppers (for me):

  • The Apple-way-or-no-way-at-all groupthink is in full force here. I was curious as to how well the iPad would work as a Remote Desktop client, and tried downloading a free RD client from the App Store. Unfortunately, you need to register with Apple, even to download free content. Contrast this with Linux or Windows, where you can download a tarball, zipfile, msi or exe installer, or Linux installation package of your choice from anywhere, anonymously. Registering shouldn’t even be required for payware content (other than to pay the developer) — let alone for free apps.
  • The lack of a keyboard would relegate the iPad to use as a eBook reader (which it admittedly is great at), casual game device (which it does okay at, especially with the accelerometer), and/or map device (which it also is great at.) Unless it were an emergency, though, I wouldn’t want to write code, documents, or emails, on it. Typing anything more than a very occasional search phrase was very aggravating (even typing in an address into the Maps app was painfully slow compared to using a real keyboard.)
  • The iPhone OS means, to me, that it isn’t a “real” computer — and therefore could never replace a laptop. If I had a laptop with me, I just don’t see using an iPad all that much.
  • Most importantly, Apple hasn’t seen fit to change their totalitarian ways. Guys, you build some awesome hardware — if the iPad ran Linux, I would seriously consider buying one at some point. By all means, make it available as it is with the iPhone OS or any other proprietary OS — but throw us hardcore geeks a bone and make a Linux distro for it (with proprietary hardware drivers, if you must.)

Finally, an idea — why not make a portable docking station for the iPad — where it could be used as a semi-intelligent monitor for a laptop platform, detachable to work on its own as a slate computer when needed? You would have the functionality of a netbook with a great touchscreen display, with the ability to disconnect it and use it as a native iPad whenever you wanted? This would seem to be the ideal way to bridge both worlds.

Superscalar — The Easy Way!

April 14th, 2010

I really enjoy taking courses with useful, practical content. It doesn’t happen all the time, but I’ve had a good run of luck recently. Tuesday’s lecture in the ECEC622 Parallel Computer Architecture course I’m taking was about OpenMP — a very easy-to-use, open-source API for C/C++ and Fortran.

OpenMP is what an API should be — both useful and very easy to incorporate into an application, even for programmers encountering it for the first time. Within a few minutes of learning the fundamentals, I was able to write a multithreaded version of the ubiquitous “Hello, World!” program.

Of course, whenever I want to really start to learn a language, architecture, or API, I use it to write a Mandelbrot Set program. Mandelbrot Set calculation lends itself extremely well to parallelization APIs like OpenMP — it’s what programmers refer to as “embarrassingly parallel.”

Here is the Mandelbrot Set calculation code. The OpenMP modifications are shown in blue. Omit them, and the code does exactly the same thing, but without the parallelization.

#include <stdio.h>
#include <omp.h>

//Mandelbrot Set calculation routine, to test
//speedup obtained from using OpenMP

//M. Eric Carr
//mec(eighty-two) .at. drexel (dot...) edu

int main(){
	const double rmin = -2.2;
	const double rmax = 1.4;
	const double imin = -1.8;
	const double imax = 1.8;
	const unsigned long long maxiter = 20000;
	const unsigned long long xres = 2000;
	const unsigned long long yres = 2000;

	double a, b, r, i, h;	//Private variables for threads

	unsigned long long totalcount=0;
	unsigned long long count=0;
	unsigned long long x,y;
	unsigned long long iter;

	double dx, dy;
	dx = (rmax-rmin)/xres;
	dy = (imax-imin)/yres;

	#pragma omp parallel for private(a,b,r,i,h,x,y,iter) reduction(+:count)
	for(y=0;y<yres;y++){
		b = imax-y*dy;
		for(x=0;x<xres;x++){
			r=0;
			i=0;
			a = rmin + x*dx;
			iter=0;
			while(iter<maxiter && r*r+i*i<=4.0){
				h=(r+i)*(r-i)+a;
				i=2*r*i+b;
				r=h;
				iter++;
				}
			if(iter>=maxiter-1){
				count++;}
			} //for x
		} //for y

	#pragma omp barrier

	printf("dx is: %F\n",dx);
	printf("dy is: %F\n",dy);
	printf("Total count is: %lld\n",count);

	dx=count*dx*dy;

	printf("Total area is: %F\n",dx);

	return(0);

	} //main

Three extra lines of code, to share the workload among however many CPU cores your system has (eight virtual cores, on a Core i7 CPU). Talk about a good return on your coding time!

Computer Art

April 14th, 2010

Take a rectangular field of arbitrary size (pick something nice like 800×600), fill it with random pixels, then iterate the following code:

* Choose a pixel and one of its neighbors
* Make the neighboring pixel the same color as the first pixel
* Repeat as desired

As an algorithm, it isn’t much to look at — but it produces interesting psychedelic pictures, and it’s fun to watch it in action.

True 8-bit computing!

April 2nd, 2010

A while ago, I realized that the DrACo/Z80 was actually quite a bit more complex than it needed to be, to suit the purposes of the EET325 class. Since it is programmed in machine code, the programs written for it tend to be very small, both in terms of code size and memory usage.

Since wire-wrapping all of the connections is by far the most time-consuming part of the build process, this suggested a possible shortcut. Instead of wiring up all sixteen address lines, why not make it a true 8-bit computer — with only eight address lines? Sure, it will only be able to access the first 256 bytes of its memory, but nobody ever uses more than that in the class, anyway. (…and if any students get that ambitious, it can still be upgraded to 16-bit easily enough.)

Here are the updated schematics (including a few bug fixes and annotations). The 74LS245s between the Z80 and the bus have been removed, as well, since even the original 16-bit prototype runs well enough without them.

DrACo/Z80 Control Panel (8-bit version)

DrACo/Z80 Core (8-bit version)

LOLcode

March 30th, 2010

I just came across LOLcode. Best laugh I’ve had in a LONG time. This one’s even funnier than Tenne-C!

Google has even implemented it as a searchable language in Google Code Search. Sweet!

And to think, just today my professor mentioned that we might consider picking up a new language for the parallel-computing project for the class.

Hilarity, as the saying goes, ensues!

Windows 7

March 15th, 2010

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.

iDont, or Why The iPhone Is Evil

March 15th, 2010

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.

CD bit size calculations

March 14th, 2010

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!

Software Engineering

March 13th, 2010

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.

If it ain’t broke — tweak it!

March 12th, 2010

2.66GHz to 3.57GHz, so far — running air cooling and staying within voltage specs. Apparently all the hype about the Core i7’s overclockability isn’t just hype, after all. Wow.

CPUID screenshot of system running at 3.57GHz