- Digital TV foreshadows erosion of Internet rights
- The Green Delay: A timely proposal for IT energy conservation
- The return of Made in America
- New book: "Print is Dead"
- Sun's ZFS is close to perfect, but widely misunderstood
- Digital living means digital junk
- AMD's $389 big iron
- Hacking or reverse engineering?
- Question: How will you switch carriers for iPhone?
- Microsoft is right: Developers don't need PDC '07
June 18, 2008 | Comments: (0)
Digital TV foreshadows erosion of Internet rights
With regard to the free exchange of information over the Internet, we, the people, have mostly managed to hold our ground. We can thank activists, hacktivists, legislators saying "no, thanks" to money from the entertainment lobbies, and forward-thinking artists and content distributors--I'm proud that writers and publishers took the lead on this--who recognize that reach is the currency of the digital age.
We should take as a warning sign of descent down the slippery slope toward the loss of Internet freedoms Internet providers' arbitrary blocking and throttling of BitTorrent traffic. The rationale points to the bandwidth wasted by BitTorrent. That doesn't ring true. There are other flavors of traffic such as VOIP, streaming news, advertising and entertainment, photo galleries, remote PC access, Usenet repositories, denial of service attacks, and spam that consume beastly amounts of bandwidth, but somehow none of these warrants detection and control at the provider's end of the pipe. It makes one wonder, what's so special about BitTorrent that it cries out to be controlled in such a radical manner?
That's an easy one. The entertainment lobby (my shorthand to avoid spewing the alphabet soup of movie, TV, and music trade groups), having failed to get the feds to impose a tax on videotapes and recordable discs, or to hold Internet providers liable for copyrighted content transferred through their networks, or (so far) to add a piracy tax to every broadband user's monthly bill, is using the most powerful weapon yet devised: "Standards."
I put that in quotes to differentiate it from true standards. Analog television, for example, works because standards and regulations ensure the interoperation of transmitters and receivers. These standards take the public good into account. The move toward digital television, which will be complete in February 2009, is attended by standards and regulations constructed to ensure interoperability and to guard the public good as well. No broadcaster can arrange that a digital TV signal require a non-standard receiver, for example, one that bills your credit card every time you watch a popular show on an over-the-air (OTA) digital channel. As a matter of practice, most cable companies pass local broadcasters' HD channels to their basic cable subscribers.
The very characteristic that makes digital TV look so good is the one that makes it so vulnerable to restriction and manipulation: A TV broadcast is no longer a signal, it's a bitstream, one that has far fewer points of origination than the Internet and is therefore easier to control. Digital TV is rapidly heading for precisely the sort of lockdown that entertainment and broadcast lobbies desire for the Internet, and to the extent that they can be used as video players and recorders, our PCs, Macs, and notebooks.
The primary example of digital lockdown is HDMI, the High Definition Multimedia Interface. Simply put, HDMI is how you get digital video into a high-definition TV. HDMI looks like a dream come true: A single cable with a small connector passes digital video, digital audio, and control signals. HDMI has always incorporated High Definition Copy Protection (HDCP), but for a long time its enforcement was relaxed. You could hook an LCD computer monitor to a cable box or DVD player with an HDMI output. All you needed was a $20 HDMI/DVI adapter.
It doesn't work that way now. If you plug an LCD monitor into a late model DVD player or other device with an HDMI output, all you'll see is text telling you that your device is incompatible. If it were truly incompatible, it wouldn't be able to display that text. Wait, it gets better.
Let's say you do spring for an HDTV with HDMI input. Depending on the maker of your cable box or DVD player, if you plug an HDMI cable into your TV, the device turns off all of its analog outputs. Simply put, the price for upgrading your TV to digital is that your existing VCR, DVD recorder, and video-capable PC or Mac go blind. I can make recordings of digital and analog cable programs, but only if I go behind my equipment rack and yank the HDMI cable out of my set top box. It gets better still.
HDCP requires credential handshaking that's prone to errors, forcing many consumers into the ludicrous practice of rebooting their TVs (mine runs Linux) to recover permission to watch them. I've had to update the firmware on my TV and amplifier to address HDCP issues, and it's still buggy as hell.
The lesson I learned from this is not to waste my money on HDMI cables. By trying to sneak martial law into a digital video interconnect standard, entertainment forced consumers to retreat to readily recordable analog even for their high definition content. Fortunately, the quality of component video, the three-cable analog connection supported by all HDTVs and high-definition devices, is indistinguishable from HDMI in well-made equipment.
Can't a computer with a digital TV tuner and a DVD drive solve this whole mess and allow all-digital connections? It ought to. A copy of Vista Ultimate and a $129 TV tuner are ostensibly all that's required to turn a PC into a combination digital cable box and video recorder. But not so fast, friend. Have you met the broadcast flag?
The broadcast flag signals receiving equipment that recording is not allowed, not even to videotape. A broadcaster can stream this flag into any program it chooses. Nothing can be sold in the U.S. that doesn't respect the broadcast flag and pass it downstream. Yes, I am aware that the FCC's mandate for the broadcast flag was overturned by a Court of Appeals. This simply means it doesn't have federal enforcement. The entertainment lobby still has the power to impose its will on technology companies. Some companies proved more eager to eat from entertainment's hand than others.
Microsoft baked the broadcast flag into Vista, a fact that was revealed last month when NBC inadvertently flipped on the flag for an episode of American Gladiator. Vista-based Windows Media Center systems tuned to NBC refused to record the show. I'd take a cheap shot about this program's popularity among Vista users, but Vista users weren't alone. Everybody loving their new digital video recorders got hit by the blackout. NBC said "oops" and Microsoft said "so what?" Let's start a pool on how long it will take before we're paying for reruns of the network TV shows we pick up with rabbit ears or pull from basic cable.
It disappoints me deeply that not one vendor told entertainment to get stuffed. The closest thing I've gotten to a statement from a vendor that's been in the back room with entertainment came from ATI, fresh from its AMD buyout and jazzed about a recent win. "We're one of the first to ship Blu-Ray player software with our hardware." Later in the discussion, I was told that "ATI has reduced the risk of unauthorized access to the frame buffer." Given that frame buffer access enables recording video to disk, I didn't have to ask who was considered unauthorized.
It would seem that the Internet, being so anarchistic, won't have its arm twisted so readily by the entertainment lobby, but Internet rights restrictions come through your telecommunications equipment. It would take an act of Congress to force a change to firmware of networking devices to restrict traffic based on content. There will be no broadcast flag for files that don't start life as commercial content. The vendors who make the components and operating systems that run our laptops and desktops see broadband digital entertainment as the next frontier, the next great driver of sales and services. The entertainment industry declared that there is no path to riches but through them, and that path requires paving over a few of your freedoms.
Unless, that is, you download your entertainment through BitTorrent. Does it meet the definition of "irony" that it's far easier for an unskilled person to do this than to deal with HDMI, HDCP, broadcast flags, frame buffer blocks, and other nonsense created specifically to frustrate consumers' efforts to enjoy digital entertainment?
Posted by Tom Yager on June 18, 2008 03:00 AM
May 07, 2008 | Comments: (0)
The Green Delay: A timely proposal for IT energy conservation
"I hope I'm dead before I'm 50." This was said in an entirely unemotional, matter-of-fact fashion by someone who had gotten a poorly timed, age-appropriate, red state public school treatment of both sides of the global warming debate. Is it, as was presented, more likely that natural cycles and the law of averages are to blame for melting glaciers and freakish weather? Either way, his lesson came one day before the horror in Myanmar. It awakened memories of Thailand and New Orleans. It put a different timbre to the voices decrying $120-per-barrel oil when the solution that seems so obvious to a kid--if you can't afford it, don't buy it--isn't on the table.
This young man knows me, and he knows that I take as a point of pride that InfoWorld is uniquely outspoken on matters of green computing, and that my dedication to that cause predates InfoWorld's. When I write about it, I stay away from suggesting that there is any sort of "save the planet" global imperative that should drive IT toward consolidation and the purchase of more energy-efficient equipment. By pursuing energy-conscious policies, what a company conserves is capital. As energy prices inevitably rise, kilowatts, BTUs, and square feet rise above nickel-and-dime concerns. I reach out to the pragmatists with the message that conservation makes fiscal sense. I don't mind sneaking my agenda through the side door.
Journalists must always be aware of the cost of taking sides on a controversial issue, ever conscious of the fact that doing so alienates a portion of one's audience. I can't write for those who see conservation as a purely fiscal issue, because that encourages offsetting the impact of a lazy approach to energy conservation with reductions in head count, withdrawal of community projects, raising the prices of products and services, or targeting a narrower, more elite market that can afford to underwrite energy waste as a cost of doing business.
Frankly, the trouble with dressing my energy agenda in a suit of pragmatism is that it isn't getting the message across. While I'm preaching consolidation as a means of reducing energy costs, too much of IT, and too many of the server vendors who supply it, use that call to justify overconfiguration. A four-socket, 16-core rack server with a pair of 1-kilowatt power supplies can do the job of two eight-core servers with a pair of 700-watt power supplies. The trouble is, those eight-core servers are only a year old. Buying a bigger, hotter server isn't about consolidation; those eight-core servers aren't taken off-line. The new server is added to the pool of virtual machines that are ready for duty at a millisecond's notice. We may ride into the purchase of higher-density servers under the flag of consolidation, but we typically skip the second half of that exercise that involves turning off the machines we intended to replace.
It's not helping.
It's tempting to push conservation off on the big, heartless companies that are least likely to do it, but like all social change, this one needs a grassroots kick, and I have an idea. I call it the "green delay." Customers that hit your Web site, along with internal users that poll for e-mail every 10 to 30 seconds, demand near-instantaneous responses to their requests. When a Web site takes more than 7 seconds to be ready for interaction, it's said that a great many users will go elsewhere rather than wait the few additional seconds it might take to put up clickable buttons. Sure, time is money, but when did we start calculating the value of our time in increments of seconds or even milliseconds?
I think it's time to consider the flip side of the time/money equation: Time is carbon. Our impatience with technology isn't about money, and on the scale of seconds or milliseconds, is not justifiable as business necessity or competitive advantage. Whoever I am, whoever you are, we are the people who need our data right away. We need file shares to mount instantly. Our SQL query tables must populate instantly so that we can start scrolling through 500 results a few seconds sooner. Let someone else who doesn't pay as much for a particular service or technology do the waiting. The cell network is plugged up with all those consumer voice calls, and my IM and BlackBerry messages, and my mobile browser sessions, aren't going through fast enough to suit me.
I realize that for a guilt trip to work, it needs to be more concrete and specific. I have a specific proposal, a painless one that actually addresses two problems at once. Outside first-shift business hours, e-mail servers don't need to offer a quick response. E-mail protocols were designed to accommodate multihop modem links between sites and batch transfers scheduled several hours apart. In other words, the worldwide network of e-mail servers is already optimized for green operation. Let's take advantage of that. Instead of treating e-mail like instant messages when recipients can't possibly read them, let there be latency.
Figure out how few physical servers need to be online outside business hours to ensure that messages from other time zones are received by the start of the next business day. It's OK for e-mail connections to time out because fewer servers are on a hair trigger to answer SMTP connection requests. E-mail transfer protocols require that servers keep attempting delivery, not for seconds or hours, but for days. The beauty is, your users won't notice. You can crank e-mail capacity up again when your people are back on the job.
If you make e-mail wait, you gain another benefit. Spammers have zero patience. When a chunk of spam doesn't get to you on the first try, it moves on to a more eager target. E-mail-enabled attacks, like dictionary scans of user names, require fast response to each attempt. Wouldn't it be great if, by IT adopting a more ecologically sound approach, more spammers slammed into our drawbridges?
There I go again, presenting a pragmatic angle on social responsibility. I can't make this one too easy. The important part of any IT conservation effort is to set the goal of powering servers down as often as, and for as long as, possible. It's nice that a server with a 1,000-watt power supply can idle at 300 watts. A server should idle at zero watts, and it can. Modern servers will power down and back up on preset schedules. Intelligent power controllers, like iBootBar from DataProbe, can control system power via script, telnet, modem, and browser interfaces so that servers that need help can power up other servers on the LAN.
The point is, every second spent waiting for a message or a Web site can make a difference. Time really is valuable. We can't take for granted that we have an unlimited supply of it regardless of our actions.
Posted by Tom Yager on May 7, 2008 10:06 AM
April 10, 2008 | Comments: (0)
If you feed an educated, socially connected populace a steady diet of war, dirty politics, greedy CEOs, job losses, zero wage growth, ecological mayhem, $3 per gallon gasoline, homeless homeowners, and whining predatory investors, you get about what you'd expect: Some really demoralized, anxious, fed up people. A friend put it this way: "it's not fun being an American any more."
We're not sitting around moaning about it. Americans have their sleeves rolled up. I speak for a lot of you, I think, when I say that I'm resigned to working for the government for several years. Tax me. I know that the war, the bank bail-outs, and the rest of the deficit won't pay for itself. My American Dream is a simple one: To see this place cleaned up. Everywhere I turn I find that same brand of Yankee resolve, and nobody's asking who's voting for whom. Fun? Maybe not, but I am proud, and it's the first time in ten years that I've spoken to my neighbors.
There is a real push to do something now, and some around me have decided that they're overdue for some fiscal self-discipline. If spending's going to be tight, why delay the discomfort? Get used to austerity now, while you have the choice, so that it won't be such a harsh adjustment later. You can walk through Wal-Mart and feel money retreating into people's wallets. Consumer spending is down, and shouldn't it be? Isn't selfish consumerism, spending, and borrowing for stuff we don't need, one of the main reasons that America, and the Earth, are in the mess they're in? With so much serious work to do, this is a stupid time to go shopping. And yet that's what our government wants us to do. America is paying citizens $600 apiece to "spend our way out of the recession." In the midst of a serious and sober national dialog to which Washington has contributed too little, when the government finally does speak, it cracks open the door, shouts "PlayStations for everybody!" and ducks back inside.
I've been so serious-minded, so deeply analytical of this country's plight and its path out, that the stimulus initially struck me as an affront. Ours is a people on the verge of righteous revolt. Are we so stupid as to be mollified by an election-year payoff? No. I see, very clearly, what we must do with this money. We must spend it. If you look in that direction and squint, you can almost see Herbert Hoover in the White House. Under circumstances very similar to today's, with a threadbare dollar, mountains of bad debt, and a demoralized, risk-averse, cash hoarding populace, Mr. Hoover faced a choice: Stimulate the economy, liquidate the economy, or let banks, businesses, and the open market sort it out. Hoover chose the third option. Our administration has chosen stimulus. We can't know how that will pan out, but I'm sure not on Hoover's bus.
This is odd advice coming from an IT columnist, I realize. And I'm sure it's apparent that I, perhaps like you, can't quite get my thoughts on the economy straight -- there are so many angles here, and so many third rails to avoid. But I have to say with complete candor that I think America is going to come out all right. On the one hand, the global economy appears to be handing us our hat; it has clearly gone on without us. But on the other hand, we have a world full of people with rapidly rising living standards. The very places we looked to for cheap labor are themselves facing the consequences of success: Wage pressure, housing shortages, infrastructure inadequacies, and competition for materials and transport. Everywhere in the world, the cost of land, labor, and materials are skyrocketing. It can't keep up.
Here in the U.S., land and labor are cheap. We mine and grow our own materials, we have enormous unused industrial capacity, regulation is lax, crime rates are low, and the political climate is stable. We can ship anywhere. There is no smarter place in the world to build a factory now, and because of the weak, or as I say, welcoming Dollar, it's hard for any global competitor to beat the U.S. price on anything. U.S. businesses will start pulling manufacturing back into the States as well, because the labor and transport cost savings won't justify shipping it to Asia much longer.
Why spend money now? Initially, what goes around comes around. In the long run, you want American consumerism to set a good example, because within a few years, America will return to its status as the world's leading source of supply. That's a sustainable future, and it's worth a little sacrifice.
Posted by Tom Yager on April 10, 2008 03:33 PM
October 24, 2007 | Comments: (0)
This sounds like it belongs on the shelf next to "The Hummer Guide to Global Warming" and "2007 Fashion Portfolio for Telecommuters."
The site created to promote this book defends the idea of using dead trees to celebrate the end of the use of dead trees, and notes that it will be released in electronic and paper form on November 13.
Actually, I think the author is using the title to spur debate. Ben Smith and I collaborated on a cover story for BYTE titled "Is UNIX Dead?" UNIX's rapid decline to irrelevance was declared 15 years ago, just as it is now, and Ben and I wrestled with both sides of the issue. The answer? Hell, no.
A printed book about the death of print is a commentary in itself, a point that wasn't lost on the PR person who pinged me about it:
I wasn’t sure whether to send you a copy of PRINT IS DEAD: BOOKS IN OUR DIGITAL AGE, or to send you the link below to the online excerpts—but seems rather appropriate to send the latter, right?
I asked for a copy of the book. I was born a generation before cellulose intolerance.
Posted by Tom Yager on October 24, 2007 05:54 PM
October 24, 2007 | Comments: (0)
Sun's ZFS is close to perfect, but widely misunderstood
You've read about ZFS, the advanced storage management facility baked into Sun Microsystems' Solaris Unix operating system. It is Sun's invention, yet Sun has opened it to the world, including ZFS with the mass of Solaris code that Sun has open-sourced.
You've read about ZFS, but you may not know as much about it as you think. ZFS has been reported to be much faster than other file systems. That basic tidbit creates a pair of misconceptions about ZFS: First, that it is all about speed, and second, that ZFS is a file system. Neither speaks to the core purpose or advantage of ZFS. Where speed is concerned, ZFS is as fast as your disks, controllers, and device drivers. It is subject to the same hardware bottlenecks as all other means of managing storage. ZFS is also not what the majority of people, even in IT, understand as a file system. In most instances, a file system is a fixed structure laid down on a blank disk that has been split into partitions or slices. One formats a partition to create a file system, and that file system is a prerequisite for the storage of files. Without the file system, a computer wouldn't know where its files live.
ZFS tosses common understanding about file systems out the window. It begins with pools of storage. The definition of a pool is one of ZFS's most confounding aspects, but it is key to ZFS's unlimited flexibility. A ZFS pool is made up of any combination of devices, real or logical, that provide persistent storage. ZFS can take a bunch of raw disks and string them together into a striped RAID pool, with the protection of mirroring or single or double parity. A ZFS pool can be an arbitrary collection of partitions within disks. A pool can be made from an assortment of ordinary files. And a single pool can contain any mix of the device types I've described. If it presents to the system as a disk or a file, ZFS can stuff it in a pool.
A ZFS pool is handled as its name implies. It's a big vat of persistent storage that you can tap to create a hierarchical structure of directories and files, which brings us to the file system part of ZFS. But it isn't a file system as you know it. One doesn't fill buckets of finite size from a ZFS pool the way you would with any other variety of software or hardware RAID. Instead, a ZFS pool is structured like a municipal water system. The reservoir is shared by all consumers, any one of whom can drain the whole pool or use just a bit of it. What you'd associate with a file system is really just a name tag, like a street address, used for accounting and administrative convenience, but you can rename, remove, and add file systems to a ZFS pool at will -- and nondestructively while the storage is in active use. You can add storage to a pool at any time, and it is immediately available to all file systems in the pool. There is no delay for formatting because ZFS doesn't format.
It is possible to set up ZFS file systems to work as allocated storage with hard or soft limits imposed on file system nodes and on users that store data on those nodes. If you're particularly fond of limits, ZFS can create file systems that behave exactly like old-fashioned mountable volumes built on formatted partitions, but this is only a mirage. ZFS remains limitlessly flexible even when its capabilities are masked to fit the preferences of the administrator. But there's rarely a need to do this because ZFS is easy enough for a child to manage. Seriously, two commands with blissfully simple syntax run the whole show. See Paul Venezia's screencast of ZFS in action for an example.
More than anything, ZFS is unlimited. Pools can span practically infinite numbers of devices and quantities of storage. Each pool can have a practically limitless amount of file systems on it. In this context, the word "practically" refers to the bounds of practicality, such as the number of 3.5-inch hard drives that one can pack into a football stadium.
Explaining ZFS in one article is difficult only because it is so capable. The best way to sum up ZFS is that it makes it possible to do anything, no matter how insane, with persistent storage. I find ZFS to be so remarkable that you can count on it being a frequent subject of discussion here and in my blogs. If you haven't checked out ZFS yet, do, because it will eventually become ubiquitously implemented in IT. It is too brilliant not to be.
Posted by Tom Yager on October 24, 2007 03:00 AM
October 03, 2007 | Comments: (0)
Digital living means digital junk
The archives of Web-friendly JPEGs and stream-of-consciousness blogs won't make history
Nikon stopped making film cameras. This hit me right where I live because, in a life prior to my stint at InfoWorld, I was a photographer. I had my own darkroom where I made black-and-white and color prints, as well as slides from the images I captured. None of the film cameras I own ever had to be reviewed online for their shadow detail, shutter lag, startup time, purple fringing, sharpness, dead pixels, jaggies, or compression artifacts. No film camera required that I shoot a dark frame so that sensor dust and bum pixels could be subtracted from a final image. And having 12 or 36 images on a roll put me on a budget to shoot only that which was worth remembering.
I'm no less technically skilled a photographer now when I shoot digital, but one in three of my film photographs evoke memories and tell stories. Now I'm lucky if one in 30 digital images does the same thing. Most of the pictures scattered across disks and discs say little more than "I was holding a camera when this happened." Nothing makes for a good picture like being within five shots of the end of your last roll of film. Nothing makes for a DVD or a Web gallery full of throwaway snapshots like a 4 GB memory card.
Think about the reason you used to take a picture. Ostensibly, it was something you wanted to look back on, something you'd always remember, but that you knew you'd want to feel. As I see it, the idea of a photograph is to evoke emotional memories for those who were present, and to stoke the curiosity and imaginations of those who thought they had little interest in times, places, and people removed from their current experience.
If that's too deep a subject to ponder, then consider the technical issues. What brand of CD or DVD-ROM will keep your images intact for 100 years? Who will even have an optical disc reader a century from now? Your CDs, DVDs, and nonvolatile memory cards will get mixed in with the thousands of other media that you'll accumulate in your lifetime. They'll get mixed in with Quicken and ripped DVDs of TV shows. If you're diligent, you'll set the pictures apart from the rest by jotting "pix" with an indelible marker across the front of the disc. But one scratch or the slightest bend can wipe out a year of your history. The Web-friendly images and daily brain dumps on your MySpace page have no archival value, and Google Image Search is as likely to be a going concern in 2107 as fashion from 1907 is now. As I write this, I realize that it's as temporary as a pixel.
If you were going through your great grandmother's possessions and came across a cache of 250,000 photographs that required some special machine to view them, how likely is it that you'd bother to sort through them all looking for the 200 or so that were the real keepers?
A child rummaging through your old stuff in the attic can hold a negative up to a light and run to you to ask, "What kind of car is this, and who are these people standing next to it?" They can uncover a drugstore photofinishing envelope full of images with notes scribbled on the back and be taken back in time. Star ratings and metadata will be less useful a century from now than those back-of-the-print notes.
I don't doubt that these musings will be written off as nostalgia. But some things don't make the analog-to-digital leap so well. We end up measuring the quality of the history we're documenting in megapixels, samples per second, and linkbacks. We're overwhelming our analog memories (the ones we carry in our skulls) with junk that our brains, left to themselves, would toss in the trash along with our nightly dreams. There's nothing wrong with digitized everything, per se. We can undoubtedly come up with ways to make it last. But for our sake and the sake of those who might want to know something about us after we're gone, perhaps we should take pictures as if we're on our last roll of film, and write like we're using our last sheet of paper. Anything we commit to digital posterity in that frame of mind is worth archiving.
Posted by Tom Yager on October 3, 2007 03:00 AM
September 10, 2007 | Comments: (0)
For the past year, I've been immersed in research on server microprocessor and system architectures. There have been genuine breakthroughs on so many fronts. IBM's POWER6 is built around 4.7 GHz processor cores that outpace the latest Itanium in single-core performance, while advancing POWER simultaneously toward power efficiency and mainframe functionality. POWER6 is able to adjust the power utilization of CPU and core sub-components with each clock cycle, and it does so based on its own analysis of computing and I/O load rather than the operating system's. Sun's UltraSPARC T2 proves that by focusing on total throughput, a one-socket server with a comparatively low clock speed can rival, and even outperform larger, more costly, more power hungry servers. IBM and Sun put the lie to notions about RISC having run its course.
I've never seen as much new, exciting and remarkable technology emerge from microprocessor chipmakers as I've seen in the past twelve months. I've never seen computing's goalposts moved so far in such a short span of time.
For most of a year, I've also been deep in learning about AMD's new server CPU architecture, Barcelona, which makes its debut today, 9/10/07, as quad-core Opteron. I've experienced Barcelona as PowerPoint decks, block diagrams, chip masks, and discussions with AMD's CTO, engineers and Fellows. Those technical discussions weren't accompanied by remarks about Intel. AMD was bearing down on AMD's best to date. I believe that I have as deep a conceptual understanding of Barcelona as any non-engineer outside AMD, and the more I learned, the more convinced I was that I was looking at a mind-blowing architecture. Barcelona's design goals overlapped concepts executed by Sun and IBM while keeping the architecture 100 percent compatible with legacy ("standardized") x86. I developed grand expectations for Barcelona, but AMD cautioned me not to expect too much in the way of trouncing Intel in benchmarks. AMD's marketing played down the reach of Barcelona's redesign, but this didn't line up with what AMD's engineers were teaching me.
I laid my hands on Barcelona for the first time just three days ago in the form of a two-socket server with a pair of 2 GHz quad-core Opterons, model 2350. The details of that system and the results of my early testing will follow very shortly, but where Sun and IBM had me saying, "wow", "that's remarkable; who dreamed this up?" I looked at the details of Barcelona, wondering where AMD could make its mark in a field already filled with such beautiful engineering.
Now, sitting on the floor in front of Barcelona (by remote control), I am speechless. I'm running all eight cores, full-out, and watching a watt/ammeter keep a record. The evening started with an all-night burn in. During that burn-in, with all cores kicking at 100 percent, I didn't expect when I saw: 2 amps, measured at the outlet, or just 300 watts. When the workload dropped to idle the power utilization came in at 1.3 amps, or 149 watts. I continued with the testing proper, which is not yet in a state that permits me to share the results, and verified those results.
This is not a wimpily-configured box: 8 GB Registered ECC DRAM, on-CPU I/O, memory and SMP node controllers. There are two banks of RAM for each socket, and as I'll explain when I get to the results, each socket's shared third-level cache turned out to be a major win.
After all the tech magic worked by AMD, it's the price that got my blood boiling: $389! That's desktop chip money. So AMD is blazing trails in more ways than one.
It's Barcelona day, week, month, and who knows how long after that. I'm jazzed.
Posted by Tom Yager on September 10, 2007 06:43 AM
July 03, 2007 | Comments: (0)
Hacking or reverse engineering?
Scientists are reverse engineering the galaxy. So why is it illegal to reverse engineer a DVD player or the iPhone?
Even the debate pitting creationism against evolution never raises the argument that the galaxy is a secret that ought not be explored. Both sides cite science that looks at our galaxy’s present, weigh recorded history against empirical data, and hypothesize about our origins.
So how is it that the Digital Millennium Copyright Act (DMCA) -- an odious piece of lobbyist-written legislation if there ever was one -- can make a crime of reverse engineering? The DMCA circumvents laws governing copyright, patent, property, and free speech by declaring unlawful the most essential right of all: The right to know.
If you buy something, you have the right to hook it up backwards, to turn it into a piñata, to shoot holes in it with a licensed .357 Magnum, or to plant it on a pike on your front lawn. But in America, your right to take it apart to figure out how it works is in the hands of corporate lawyers. Owning specialized tools for the purpose is okay – even disassemblers that turn software into rough source code or logic probes that record the behavior of running silicon. But the people who once tried to levy a usurious tax on blank VHS tapes have succeeded in restricting the use of these and other tools of discovery.
The assumption is that in technology, reverse engineering -- the simple and essential science of learning how a thing works -- is employed to violate copyrights and patents. Yes, I could reverse engineer a microprocessor to create a clone and sell it for one tenth of the original’s price, but that would be both immoral and illegal. But what if I reverse engineered to uncover undocumented capabilities of that processor, so I could place in the hands of those who own systems with that chip the power to make more complete use of them?
Reverse engineering isn’t an easy matter to decide. Specific instances of reverse engineering illustrate the separation between use and abuse and yet highlight the difficulty in drawing the line between lawful and unlawful pursuit of knowledge. Hackers picked apart the smart cards used by direct broadcast satellite (DBS) TV providers to hold subscriber information. They then used that information to steal satellite TV service and get out of paying for pay-per-view movies. A lot of those thieves are in prison, and that’s where they belong. They indulged in theft of service. But was the dissection of satellite TV technology ipso facto unlawful?
That’s not so simple. The intent of their reverse-engineering effort was, from the start, to enable theft of service. The crackers brazenly bragged in forums and on Usenet about their progress in terms of what they were able to steal. They later opened up businesses selling hacked DBS access cards and the tools to create them. That was organized crime. But smart card readers and writers, disassemblers, logic analyzers, and other instruments used to crack access cards are legal. If you have used these tools, and you’ve learned how DBS access protection works, and you’re not among those stealing service or profiting from the knowledge, do you belong in prison?
No, you don’t. Knowledge and its pursuit can’t be unlawful. If sharing the knowledge is an unlawful act, then simply knowing violates the law. If the knowledge is unlawful, then the possession of the tools used to obtain it is sufficient probable cause for arrest. We’re not willing to go that far. Are we?
We’ll soon be putting those limits to the test. The iPhone is locked in ways that some people consider contrary to technology buyer’s interests. It is locked to a specific wireless operator, AT&T. Crackers have worked out the mechanisms for unlocking virtually all other mobile devices, and those mechanisms use back doors that handset manufacturers built into their devices to unlock them. I’m not aware of prosecution resulting from the discovery or dissemination of that knowledge. One interest group, Act For Change cites specific legal precedent for unlocking cell phones from carriers. I lack the expertise to validate the cited case.
But Apple insists that there is no such carrier-unlock back door in iPhone, so presumably an effort to free iPhone from AT&T’s service will require significantly more reverse engineering to achieve the same end that Act For Change claims is legally protected. Today, discussions of iPhone reverse engineering efforts are proceeding in public view, and bounties are being posted to reward the first to come up with a working crack for iPhone.
AT&T’s contract with Apple apparently stipulates that iPhone can’t be used in any capacity without activation on AT&T’s service. iPhone is dead as a doornail until you use iTunes to attach it to wireless service. Then it unlocks and works as a PDA, media player, and continues to work even if you remove the SIM (subscriber information module) card. An iPhone without a SIM simply can’t make phone calls or surf the Internet for free using AT&T’s service.
So where’s the legal line here? I think we’re going to find out, because I have little doubt that iPhone will be cracked. What can’t happen is a crack that gets people access to AT&T’s services for free. It won’t happen. Instead, cracks will be oriented toward giving iPhone owners the freedom to use their devices outside the restrictions placed on them by Apple and AT&T. Is that illegal? It shouldn’t be. Let’s keep a close watch on the lawyers for these two entities, because the knowledge they choose to declare as contraband will set precedent of its own.
Posted by Tom Yager on July 3, 2007 04:07 PM
June 25, 2007 | Comments: (0)
Question: How will you switch carriers for iPhone?
All iPhone units sold in the U.S. will be locked to AT&T's GSM/GPRS/EDGE mobile network. If you're already an AT&T subscriber, iPhone is a painless transition. If you're on a month-to-month contract with another operator, or you had a term contract which has now expired, you're sitting pretty for iPhone.
But if you're already under contract with a competing operator (e.g. T-Mobile, Sprint, Verizon), it might cost you as much as $300 to bail out of the one or two-year agreement that scored you a cheap price on your existing handset.
If you're in that latter category--under active contract to an AT&T competitor--but planning to buy an iPhone, how will you do it?
a) Pay the one-time fee to sever your existing contract immediately (what will it cost you?)
b) Buy iPhone and make payments on your existing phone service until its contract expires (give your phone to a relative, friend, keep it as a spare?)
c) Try to complain, threaten or loophole your way into a courtesy cancellation ("I'm being deported"; "I have petitioned ICANN for a .sucks top level domain just for you"; "My service was always horrible, but it became absolutely intolerable on June 29th"; "Return to sender: Addressee deceased"; other?)
d) Something I haven't thought of
Please weigh in via comments, and don't be shy with details.
My money's on b), but don't let that sway your vote.
Posted by Tom Yager on June 25, 2007 04:59 PM
May 29, 2007 | Comments: (0)
Microsoft is right: Developers don't need PDC '07
Microsoft axed its Fall Professional Developers Conference (PDC), and it's got the blogosphere all a-twitter with speculation about the reasons. If they accepted the reasons that Microsoft gave--developers already have access to what they'd get at PDC--there wouldn't be any controversy.
Microsoft is right: Developers don't need PDC '07, and there's a fair argument to be made that developers don't need PDCs, period. One major reason to attend PDCs past was to nab the CD packs containing preview releases of Microsoft's developer tools, OSes and Windows Server System components like SQL Server and Exchange Server. Those previews are no longer hot property. Everyone with broadband access can download pre-release Microsoft products and trialware of its shipping software.
Where PDC as a learning, networking and hobnobbing experience is concerned, Microsoft's Communities bring it all together, and you can birds-of-a-feather without making yourself presentable. You needn't be sheepish about bailing out of a lame session five minutes in, and nobody cares what's in your other browser window.
Micrsoft still throws one show worth attending. Deep knowledge of OS fundamentals, server performance scaling and system administration, which every Windows developer should have and which is harder to acquire on-line, is the domain of Tech-Ed. That's always been true. Tech-Ed '07 starts next week, but airfare is cheap, registration is still open, there are lots of hotel rooms and I'm sure you can talk your boss into it.
PDC '07's euthanasia does bring the pain to one group. PDC gives third-party vendors of Windows development tools, books and libraries a shot at a captive audience under the Microsoft big top. There are lots of non-Microsoft Windows dev shows, and banner ads and Ad Words are cheaper than booth rental. This gang, too, will get by.
The greatest disappointment voiced by developers is that they'll miss their yearly fix of Microsoft swag. Fear not; it can be replaced. Never let it be said that I don't have my finger on the pulse of the Windows enterprise developer community.
Posted by Tom Yager on May 29, 2007 12:46 PM
June 28, 2006 | Comments: (0)
Blue Pill is an attention-whoring non-threat, period
I can't believe I even have to address this.
The "Blue Pill" (BP) AMD Secure Virtual Machine (SVM) root exploit is a scam. It poses no threat to any PC secure from physical access and where administrative privileges are tightly controlled. There is no security hole in AMD's SVM implementation, and the method described by the hacker can be employed in exactly the same manner on an Intel CPU with Virtualization Technology (VT). What's more, the hacker's claim that BP cannot be discovered once it's in place is wishful hogwash. The very infection technique to which the hacker alludes (and that's all he does; there's no meat on those bones) can be used to discover and disarm the exploit.
The procedure that this hacker claims to have invented is lifted directly from AMD's Programmers Reference Manual. Any reader familiar with x86 assembly language and the PC boot sequence can hack his first baby hypervisor in a day or two. Baby hypervisor code samples abound on the 'Net, and BP is just one more. Luckily for us, this hacker promises not to release his very, very scary code sample into the wild until after his standing ovation at a hackers' convention in late July.
I don't care whether the hacker's male or female. As far as I'm concerned, all black hats are sexless in all regards.
BP might be a harmless case of "look at me! Ain't I bad?", but it also smacks of an effort to harm AMD's reputation and commerce. If that seems far-fetched, consider three things: The original post's date is just four days prior to Intel's first deliveries of Core Microarchitecture CPUs, Intel's first real competitors to Opteron. The post goes out of its way not to mention the fact that Intel CPUs with VT are designed to launch hypervisors using a nearly identical procedure. And the hacker discloses that he'll have nothing to show until late July, but, golly, he had to tell us right then, just before Woodcrest shipped, that there's proof that AMD's SVM is a major security hole.
What this hacker really set out to prove is that we're all gullible enough to take this bait and steer clear of AMD64. Get used to efforts to keep you misinformed. The anti-AMD FUD (fear, uncertainty, doubt) pump is just powering up.
Posted by Tom Yager on June 28, 2006 04:35 PM
June 29, 2005 | Comments: (0)
My apologies for the lengthy post; it's most un-blog-like, but this is the only place for it. It states my position on AMD v Intel and sets up a lot of material on that subject that will follow in print and on-line.
On June 27, 2005, Advanced Micro Devices filed a a civil suit in Federal district court charging that Intel engaged in coercion to block AMD from fair access to the microcomputer market. Coercion being an insufficiently evocative term, I'll borrow one from AMD's filing: Intel's been knee-capping OEMs (original equipment manufacturers; builders of x86 notebooks, desktops and servers) and resellers. With disturbingly consistent success, Intel has cowed businesses in the U.S. and worldwide, from Fry's Electronics and Circuit City to HP and Sony, into joining Intel's blockade preventing AMD's access to Intel's channels of sales and distribution.
Isn't that business as usual for business? After all, journalists routinely use terms like "fierce" and "no holds barred," along with other sports, nature and battle metaphors, to describe the efforts of players in the free market to acquire and maintain share. But in sports and in war, there are standards of fair behavior and a range of remedies to punish those who violate the rules and to compensate those who suffer as a result. We have always made sure that those with the advantage do not have leave to literally stop at nothing to protect it.
AMD is asking for time in front of a jury to prove that Intel did cross the line between aggressive marketing and unlawful restraint of trade. AMD's filing is a surprisingly trim 48 pages long and is devoid of legal-speak, but it pulls no punches. This from its closing section:
Intel's intentional, wrongful conduct resulted in the actual disruption of AMD's relationships with these third parties [system manufacturers]. As set forth above, Intel's conduct caused these third parties (i) to cease purchasing microprocessors from AMD, (ii) to limit their purchases of microprocessors from AMD, (iii) to abstain from purchasing microprocessors from AMD in the first instance, (iv) to restrict sales of products containing AMD microprocessors, (v) to abandon planned AMD offerings, (vi) to restrict distribution and marketing of planned AMD offerings, and (vii) to withdraw from participating in AMD product launches and promotions.
In other words, OEMs are dying to do business with AMD, but can't because the cost of Intel's retaliation always exceeds the value the OEM would derive from a relationship with AMD. It's like having a boyfriend who swears he'll kill you if you ever leave him, but hey, the choice is always yours.
For Intel's part, its consistent line is that if customers wanted AMD, Intel would be powerless to keep AMD out of the market. Intel's customers are OEMs. OEMs do want AMD, but as a monopoly, Intel has the power to control its customers through its control over their supply.
OEMs switch component suppliers frequently based on price, supply, incentives, cooperative engineering and marketing, and so on. Suppliers are played against each other to the OEM's advantage, and given the commodity status of the component market, every new model is a jump ball for suppliers. The sole component that PC OEMs cannot purchase from an alternate supplier without suffering egregious financial harm is processors. AMD doesn't stand a chance.
How does AMD do when it's free to compete on merit? Very well. Taking facts from AMD's complaint, AMD had about 22% of Japan's total PC market share at the end of 2002. Intel flew over early in 2003, offering millions of dollars each to Japanese OEMs on the condition that they cut their ties to AMD or cap AMD's share of their business to a single-digit level. Once Intel moved in, AMD's share of the Japanese PC market dropped precipitously.
U.S. OEMs are nodding their heads; this is Intel's MO. But something happened in Japan that hasn't happened in the U.S. for reasons that I can't fathom: The Japanese Fair Trade Commission investigated Intel's Japanese operation and found Intel's practices were in violation of Japan's anti-monopoly act. Intel accepted the JFTC's multiple findings of misconduct and must now undo all the blockades it set up to shut AMD out of the Japanese market.
If it's so awful being under Intel's thumb, why hasn't some stalwart OEM with an ample bankroll told Intel to go screw itself? It's been tried. What Intel can't block up front it will thwart after the fact. AMD relates in its complaint that HP offered AMD an opportunity to put AMD processors in HP commercial desktop systems. HP, knowing that Intel would retaliate, asked AMD to help offset the cost of that retaliation. AMD agreed to give HP its first million CPUs free if HP would give them a chance; you see, AMD has never asked for a break or used its underdog status to claim it's entitled to business with an OEM. HP wisely signed up and set about building and boxing. But according to AMD, Intel caught wind of the AMD-based desktop the day before it was to launch and took quick action. HP was instructed to withhold the 160,000 systems it had built from the channel the desktop was designed to target. Not surprisingly, HP didn't build any more of those AMD desktops. If you can imagine it, a well-heeled OEM left 840,000 free processors in sealed crates rather than incur any more of Intel's wrath.
AMD hasn't failed to earn the business. It hasn't failed to close deals. And this isn't a case of "AMD says." Those of us watching closely have seen AMD-equipped system models appear and then disappear from vendors' product catalogs. AMD systems that exist are usually unpromoted and are usually allowed to lag behind AMD's latest technology while Intel systems are constantly kept up to date. I maintain accounts with several distributors of computer components and I can see, just by pulling up lists of pricing and availiability of new AMD and Intel CPUs, who's been good and who's been bad in Intel's eyes. That's part of what I find so irksome: So much of what AMD claims is patently obvious. Intel's been busted in the U.S. for anti-competitive dealings with AMD. Magazine columnists and Japan's Fair Trade Commission were competent to handle the follow-up. Who the hell is minding the store in California (where the previous judgment against Intel was rendered) and Washington? AMD should not be the plaintiff here; it should be the government. But now that AMD has stepped to the plate, being left to shoulder this alone would bring shame to the agencies trusted to keep track of those with a history of misconduct.
With or without the backing it deserves, AMD's filing will shake things up. The complaint rightly compares Intel's behavior with that of Standard Oil. Intel's behavior is closer to that of one time anti-trust convicts AT&T, Kodak and IBM. All rose to dominance on the creativity and drive of their designers and engineers. Anti-competitive efforts undertaken by management at these firms amount to a vote of no-confidence in the companies' own technology and in the people who created it. Monopolistic tactics harm the market. But if that's not motivation enough to shy away from such tactics, Intel should recognize how damaging it is to the morale of its technical staff. Intel may have the engineering talent to win the CPU battle on merit. Thanks to Intel's control of the market, we can't know how good they really are, and what's worse, Intel's own engineers can't know how good they are. That's got to be demoralizing.
I have pressed AMD's case to readers for years. I'm proud of that. No InfoWorld reader can be a stranger to the era-defining marvel that is the AMD64 architecture or to the dirty tricks Intel has employed to block its uptake. I am proud of the tremendous positive response from readers--I don't believe that other readers would have been so supportive. I'm proud as well of InfoWorld for staying with the AMD story even after others had dropped it.
This isn't an awards show. It's where the ugly work starts. Now that this story is back on everybody's page one, the challenge is to use it as an opportunity to let people, especially system vendors, know the real cost of what Intel's doing. It angers me when I think about how much farther PC technology would have advanced if AMD had been allowed to compete. Had Intel let the market decide, as Intel claims the market is already free to do, then perhaps it would already be done with AMD. Yet I am certain, and livid, that we have lost three years of computing progress to Intel. Let's not lose any more.
--------Posted by Tom Yager on June 29, 2005 08:50 PM
June 25, 2005 | Comments: (0)
The perfect UNIX programming book made better
On my desk, you'll find a small group of sacred works set between old-fashioned metal bookends with cork bottoms. All of these advanced books have rare qualities in common: They do not tutor, they are not encyclopedic, and in presentation, they are clinical and succinct.
Nothing typifies this most uncommon and essential of genres better than Advanced Programming in the UNIX Environment, written by W. Richard Stevens (now deceased). Recently re-released by Addison-Wesley as a second edition, this book's inestimable relevance has been genuinely improved--a feat I thought impossible--by Stephen A. Rago.
I prize this second edition even more than the first. The first edition focused on System V UNIX, entirely appropriate for the early 90s. Rago modernizes the content by adding material related to Apple OS X, FreeBSD 5.x and Linux 2.4. Rago does this admirably, without disrupting Stevens' inimitable balance between concise and complete. Rago does this in places with annotations (flowed-in and indented as opposed to footnoted), elsewhere with tables that expose distinctions among variants of UNIX and Linux, and throughout with text that's interwoven with Stevens' original writing. The best measure of Rago's successful modernization of the first edition is that the new material does not lower the original's bar.
That's not to say that Rago hasn't expanded the audience for this book. He has done so in the best possible way, by allowing those who are already lead-level developers in any commercial UNIX or Linux to migrate their skills or port their code to a less familiar OS. In each narrowly-defined section of the book, Rago addresses differences in implementation, their potential impact and, in many places, workarounds for missing or flawed features. Rago greatly extends the mission of Advanced Programming in the UNIX Environment by making it the book to crack open when your ported project won't compile.
Every answer is in this book, but it's up to you to know where to find it and to make sense of the answer. In this regard, Advanced Programming in the UNIX Environment, Second Edition, has the welcome and necessary side effect of accurately identifying its readers' place on the scale between journeyman and master.
Exercises at the end of each section, and its $75 retail price, frame Advanced Programming in the UNIX Environment, Second Edition, as a textbook. I have never used the first edition in that role. Effective use of this book outside academia requires either a generous blend of free time and will, or the qualifications that transform this volume from a textbook to a shop manual. I consider this book without peer in its category.
I had only two disappointments that do not diminish the worth of the book, but which deserve note. The first edition's familiar and appropriately austere blue-on-white cover has been reworked such that the cover's dominant elements are now a garish red "New! Improved!" slug and a three-panel Dilbert comic. The second edition also dates itself in ways that Stevens' work did not. It editorializes on the present state of UNIX and frequently refers to features promised for future releases of OSes. Stevens' rock solid classic has been relocated to a rolling platform, something I consider inappropriate for a cornerstone work.
Nevertheless, Advanced Programming in the UNIX Environment, Second Edition is, as was its predecessor, a book that clears the bookcases of the advanced developers who buy it. I have placed this second edition where the first edition stood, and that's no small thing.
It's fitting that the book on UNIX development reminds everyone how the name of the real thing is set in type. Copy editors please note.
--------
Posted by Tom Yager on June 25, 2005 11:36 PM
June 25, 2005 | Comments: (0)
Would you put a $25 router in production?
Knocking around Fry's Electronics, I came upon some white boxes (actual white cardboard boxes, not "white box" components that now come in full color packaging--passing stacks of power supplies feels like a trip down the cereal aisle) among needlessly pricey wireless routers. The boxes contained reconditioned D-Link wireless routers for $25 each. Holding that box in my hand, I smirked and knew exactly what to expect from such a thing.
I bought it, carried it to my lab, plugged it in, spent about five minutes in its browser-based configuration and had it on the air. The router is fast as all hell and less sensitive to interference than the (nameless) $250 unit it replaced.
In the time since I purchased my last 802.11b/g router, that class of equipment has become fully commoditized, meaning that all manufacturers have equal access to quality, inexpensive parts. Commodity parts typically enable only majority-case features, but mid-tier manufacturers like D-Link and Netgear still find ways to differentiate. D-Link's router does standard 802.11b and g, but with D-Link clients, the router creates two-channel connections to boost throughput. It isn't a feature I'll use much, but it shows that D-Link has the smarts to innovate beyond commodity capabilities. Add that to an open, frequently-updated support site and you've got a product and vendor worth looking at.
Working in IT, I have encountered resistence to my tendency to prefer lesser names when purchasing commodity equipment. The common argument was, "if it breaks, we can't get a (brand) field tech out here the same day to fix it." My answer was always the same: Buy a spare.
There are cases where the major brand is the best or only choice. The brand device may have desirable proprietary features. Maybe you already fell for some lock-in scheme and can't drift from forced loyalties. But a bargain like the one I ran into is the perfect opportunity to put skepticism to the test. If you're that sure less expensive equipment can't play with the big boys, put some petty cash on the line and prove it. Maybe you'll win the day; it's always possible. You're more likely to learn that mid-tier manufacturers can fulfill typical requirements well enough that you won't dare look back at prior POs to see how much you've wasted.
--------Posted by Tom Yager on June 25, 2005 04:44 PM
June 16, 2005 | Comments: (0)
Apple and Pentium 4: I stand corrected
Readers have been outspoken about my assertion that Apple will go with Pentium 4 in Intel-based Macs. I stand corrected: Intel is sweeping NetBurst from its roadmap in favor of Pentium III-derived designs. But with the Mac, it comes down to what Mac users want and expect. Hyper Threading makes little difference on benchmarks, but it makes a considerable difference in user experience. The smooth, flowing UI that is the Mac's trademark--interaction with the user is a Mac client's top priority unless load demands otherwise--isn't workable on any Pentium M/Centrino notebook I've got. It is quite workable on the Hyper Threaded, single-core Pentium 4 desktop in my lab. On a dual-processor, dual-core, non Hyper Threaded workstation I have here, the user feel is still choppy under load.
This isn't news to Intel. In a session I attended at this year's Intel Developer Conference, a senior Intel engineer put it plainly: When you're hand-optimizing for multiple threads, code to prefer Hyper Threading first, then dual core, then SMP. The distance between cores makes a big difference. HT is the only x86 technology Intel's got that shares a single cache.
Remember Steve Jobs' demo at the Power Mac G5 launch? The 3 GHz dual Xeon box eventually filled up its caches and cleared the bus to catch up to Power Mac G5's rendering speed. But I would have cheered for the G5 if it had rendered 25% slower. The G5 started and finished rendering at its top speed. Xeon's dut....dut...dut..dut.dut.dutdutdut had "not suited to this task" written all over it. I don't even want to think about Steve's demo of eight (more? I can't recall) mixed stereo audio tracks playing in real-time while the dual Xeon box choked and sputtered.
I do digital media work on a Power Mac G5. I really am concerned about what would happen to my productivity in and rapport with Apple's Pro Tools if they were running on Pentium D or its progeny. If the drive isn't silky smooth, the what-if compositing and effects that are my working style will suffer.
I'd use Pro Tools on a single-processor Power Mac with confidence. I run Final Cut Express on my 1.5 GHz PowerBook. But Centrino? Pentium D? I'll work hard to open my mind to the idea. A Pentium 4 EE with HT on a 1 GHz bus seems nowhere near as wide a leap from G5. An Opteron or Athlon FX is no leap at all.
As for what Mom and Pop let little Skyler use to surf in his jammies before bed, that isn't remotely on my radar. The power utilization characteristics of the 80486 are very appealing and the compute capabilities are overkill for AOL. Apple's consumer market will be overjoyed with Pentium M.
--------
Posted by Tom Yager on June 16, 2005 05:34 PM
June 15, 2005 | Comments: (0)
Apple didn't go with AMD. Sighed, moved on.
From a reader:
Oh, Geee, Tom....
Where is your pining and whining why AMD - YOUR PERFECT MATE FOR APPLE ( Ha !) - inside the MAC !!
Stand on your principles, why don't you?
Apple and AMD would have made beautiful music together. I still believe it would have been the right choice given AMD's overwhelming design leadership. But in considering the practicality of it, I was so caught up in the technology that I neglected to consider the politics. I left out one important variable: Sun already got the AMD exclusive. Apple didn't want to go "me, too" with Sun, and Intel wants in on commercial Unix now that Unix's survival is assured.
It'll be fun to watch Apple and Sun pitted against each other in the PC Unix arena. But you can't blame me for wishing that Apple had chosen to take advantage of Hypertransport, Direct Connect, NUMA and all the high-performance goodness that only AMD brings to the table. Apple will have to rely on software leadership to distinguish itself from Linux (and now Solaris x86/x64), which will be a stroll in the Spring rain for Apple.
--------Posted by Tom Yager on June 15, 2005 12:51 PM
June 14, 2005 | Comments: (0)
I feel fifteen years younger. Last week, I got swept away in the sweet, sweet BSD Unix that is the Darwin 8.x core of Apple's Mac OS X Tiger. Today, I'm delightedly up to my chin in Open Solaris, the official drop of the "express" cut of Solaris 10 for Sparc and x86.
Do Darwin 8 and Open Solaris really matter? Hell, yes. More than you can imagine. If you just like a good fight, the battle lines are drawn: Sun and AMD on one front, Apple and Intel on another. I don't see them battling Windows. They're aiming at each other, and at Linux. Sun and Apple are challenging the presumption that Linux will grab all the rack space lost to the declining sales of low to midrange Unix systems.
It's bath night for my son, and bubbles (and most other things) always take precedence over blogging for me. I'll take this up in my next column. But be assured: This has been a momentous couple of weeks where the future of computing is concerned. Hail the return of real Unix to the x86.
A quick side note: During the conference call announcing the 6/14 launch of Open Solaris, Sun officials were asked to predict what kinds of solutions customers might develop using Open Solaris. The consensus was that "the number of new distributions will be our metric for success." Just before that company line was delivered, a lone Sun voice said that hey, we're hoping that the community will port Solaris to PowerPC for us.
I love this freakin' job.
--------Posted by Tom Yager on June 14, 2005 06:28 PM
June 09, 2005 | Comments: (0)
The quickest quick start guide for new Mac developers
So, you want to get a jump on developing apps for the coming onslaught of Intel-based Macs but you don't own a Mac? Don't bother with the Intel prototype system that Apple is loaning out (you have to return it in a year) for $999 plus the cost of a Premier-level membership to Apple Developer Connection (ADC). Get a Mac mini for $499. It comes with OS X Tiger, the very version that will run on Intel boxes. Use the free ADC membership to download Xcode 2.1 and go to town. Mac mini is a PowerPC, but the instant the first Intel-based Macs hit the market, tell Xcode on your Mac mini to compile to a universal (PowerPC plus Intel) binary and distribute your app. Buying yourself an Intel-based Mac at that point will be optional.
Yeah, it really will work like that if you follow the basic guidelines for portable apps that apply to all OSes. Avoid hand-coding to PowerPC's Altivec (if you don't what that is, it won't be a problem for you). If you need fast math, use Apple's Accelerate framework. Don't make assumptions about byte ordering, which means, among other things, don't blast a struct out to disk and expect it to load back in properly. Use the Core Data framework instead; it will handle byte ordering for you, along with transactions, undo/redo, dry martinis...Look at the other frameworks, too. I won't spoil it for you. Tiger is an amusement park for developers, with the fringe benefit that regular people will be able to use what you stayed up all night creating.
Don't pull a Linux and suck down every app, class library, scripting language, window manager, database and blah blah you can find. Most of what you'd go hunting for is already in Tiger in stable, validated form. Use the command line or Spotlight to hunt things down before you assume they're not there; Apple uses a really strange directory layout. And if you're writing command line or background apps, learn about launchd.
If you want to code fast, sexy native Mac apps, learn Objective-C and use Cocoa, the object-oriented app framework Apple pulled over from NeXT. If you want to code in a dynamic language, take your pick. Python is probably the best integrated of the lot, but everything works. Java is sweet on the Mac.
OS X Tiger is real Unix, so you can write POSIX apps with command line or X11 interfaces that will compile and run anywhere. Most of what you'll find on Sourceforge and Freshmeat will work, but it's a lot easier to go to opendarwin.org or fink.sourceforge.net to tap into thousands of open source apps that have been tested and packaged for the Mac.
The client version of OS X Tiger will work as a server in precisely the same way that any Linux client will run as a server. Apple pre-loads and pre-configures server software on OS X, but doesn't enable it by default.
That'll get you started. Go get 'em, Tiger.
--------Posted by Tom Yager on June 9, 2005 09:50 PM
June 09, 2005 | Comments: (0)
Apple, Mac developers and Mac users are going to thrive
Okay, everybody, chill out about Apple and Intel. The Intel-based Mac is a bona fide Mac. It looks, feels and drives like a Mac. Pentium 4 Hyper-threading, symmetric multiprocessing and SIMD (single instruction, multiple data) are all supported. Apple's Universal Binary Programming Guidelines are frank about which Pentium 4 features are exploited and about pain points in the transition from PowerPC to x86. The loss of PowerPC's Altivec will hurt the most, but only for the very few who use everything it does and which only run on OS X. Open source audio, video and scientific computing projects hand-optimize for both Altivec and Intel MMX/SSE/SSE2/SSE2. Commercial apps, like Photoshop, can pull their Intel SIMD code straight from their Windows releases. Intel ports will be very, very quick.
Apps that haven't yet been ported to Tiger x86 will operate without recompilation in Rosetta. Rosetta's quick on the GUI but slow as hell on the compute, and there's no Altivec support. But the productivity apps for which most existing users lack source code will run at adequate speed. It's like lightning compared to Virtual PC running on OS X.
I'm really pleased, and more than a little relieved, with what the documentation and tools portend for Apple's Intel-based Mac desktops. You should check out developer.apple.com yourself; much of what's being discussed at WWDC is there, albeit with less detail. If you knew the things that you can't yet see on the public site, you'd feel, as I do, that this Intel business is irrelevant except that there will be a lot more Macs in a lot more hands, and a lot more apps (especially open source) created by those new users, and so on.
To address the question of whether people will buy Apple-branded PCs just to run Tiger, my answer is "why not?" Unlike any other PC player, Apple is buying its system software from itself. It can fire sale OS X out to lowball a machine, as it did with Mac mini (a market test for a low-end x86 Mac, I think), or it can present OS X as significant added value to tack a couple hundred bucks to a dual processor mid-tower box.
Developers already know Intel-based Macs are worth being jazzed about. Apple's installed base, and therefore the potential market for Mac software, is going to go nuts. Analysts, you can quote me.
--------Posted by Tom Yager on June 9, 2005 08:57 PM
June 06, 2005 | Comments: (0)
Apple and Intel: Many questions answered
I'm about to enter the NDA zone at WWDC 2005. It's a self-imposed precaution, but I won't walk into the first NDA session before I post what I gathered during the last on-the-record discussion. My analysis will be in my Ahead of the Curve column in InfoWorld. But to answer some of the questions I raised here, I'll lay out the relevant facts I've acquired since my last post.
First, Apple is not switching to the software business. I make that leap too easily, knowing what a pain in the butt hardware is. It's too easy for me to imagine Apple saying "screw hardware" after IBM flat-out failed to deliver on its promises, leaving Apple swinging for failing to satisfy its customers. At any rate, Apple will remain a system maker.
A couple of salient points relate to the proprietary/commodity boundary. I mentioned earlier that Apple would be excoriated if it dared to build a proprietary box with Intel inside. Apple knows that, of course, so it chose a smart strategy: The hardware will not be proprietary, but OS X will be. In other words, you could run Windows or Linux (I reiterate, "why?") on an Intel-based Mac, but you will not be able to run OS X on non-Apple systems. Apple will sell boxed copies of OS X Tiger for Intel. They'll just come with Intel-based Macs attached. Look at it as 40 pounds of copy protection.
Apple has built some hundreds of Pentitosh desktops for developers ready to sign that $999 check. The PCs are in Power Mac G5 cases, making me wonder (with no purpose) whether Apple had extra cases assembled or relieved some Power Mac G5s of their guts. The two machines that I saw outside non-disclosure each had one single-core 3.6 GHz Pentium 4 CPU, or so Apple's About This Mac dialog reported. Apple's hardware spokesman was insistent that these machines are not representative of Apple's design.
Apple clarified its position on compilers. The open source GNU Compiler Collection (gcc) is still Apple's favored compiler back end for its Xcode IDE. Intel's interest in having its compilers generate universal binaries (x86 and PowerPC bound in one executable) is not in doubt, and neither is Apple's interest in having developers target PowerPC and Intel with every build.
As for servers, mum's the word for Apple, but Xserve G5 and Xserve RAID are the crown jewels of Apple's product line. That is not a formula with which Apple should tamper (my opinion, as always). When Apple does sweep IBM out of its lineup, Apple needs to replace it with a server that outperforms the G5. You have to look down Intel's roadmap for that.
Or Apple could look to Austin. I'm partial to my dual-core, dual CPU Opteron server. If it could run OS X Server (it already counts Darwin among its VMware-hosted children), its spindles would never touch Windows or Linux again.
That's most of it. I have to save something for print.
--------Posted by Tom Yager on June 6, 2005 09:13 PM
June 06, 2005 | Comments: (0)
Intel and Apple: An exciting road ahead, but lots of open questions remain
You have to dig back through my columns and blogs to catch these, but coming out of Steve Jobs' keynote, I need to lay down a little bragging, eat some crow, express a bit of sadness and pose my open questions.
Is Xcode front-ending Intel compilers? Yes. Xcode 2.1 does that very thing, with a Microsoft-like platform target checkbox. Does Xcode produce ultra-fat binaries (x86/PowerPC/64-bit PowerPC)? Yes and no. There was no mention on stage about 64-bit anything. I'll get that answer shortly.
Did power consumption, my pet cause, figure into Apple's decision? Yes, although I was more hopeful than realistic when I suggested that Apple and AMD should be buds. AMD's got the thermal thing down for x86. No, I will not quit beating that horse.
The first Intel-based Macs are going out to developers in two weeks at the dear(ish) price of $999, and that's for developers that already pay for subscriptions to Apple Developer Connection. And you have to send that system back in a year. If you really, really wanted to get the first Intel Mac, you'd have to pony up something like $4,000 for the subscription and the hardware. As Steve said, "we don't want a lot of these floating around."
I didn't post the blog I devoted to the topic (I have sooo many unposted entries), so I'll take a hit on Apple's choice for bridging the x86/PowerPC gap. I've been tracking an open source project called PearPC that hosts PowerPC executables on x86 systems running Windows or Linux. Apple's going after the same target with Rosetta [edit: Rosetta hosts PowerPC executables on OS X x86], with performance that's not stellar, but is leagues more workable than Virtual PC running on a PowerPC Mac.
What didn't I hear? Virtualization and compatibility. Apple refers to OS X Tiger x86 as something that runs on "Intel-based Macs," opening the question I posed in my previous entries about the degree to which Apple will hew to the commodity path. I assume that Intel-based Macs will run Windows or Linux, if just for the sake of doing it; Apple would get crucified for rolling out a locked-down x86 box. But what concerns me more is the question of whether OS X will run on commodity PCs, and for higher-end boxes, whether it will run as a hosted OS. Geeks don't mind dual-booting their boxes, but the general public is incompetent to do it. Their failed attempts to do so would result in an avalanche of bad press about Apple's software quality. So there's a quandry.
I wouldn't call pushing OS X out to the masses a mine field, but Apple's down to strategizing for people who insist on commodity hardware but would shoot themselves on the foot without a one-click install that's paired with a one-click uninstall.
Steve went to great pains to clarify that Apple's PowerPC work is not finished. That's another call I got right. PowerBooks with Freescale CPUs are the only notebooks worth carrying if you work on a computer for more than a couple of hours a day. I get four hours of battery life out of my 17-inch PowerBook. It doesn't die, and that's not just a matter of the PowerBook's chassis design. Apple's move to Intel for desktops--and that's all Steve covered during the non-NDA portion of WWDC--makes sense for supply assurance, cost, and developer reach. But it would not make sense for notebooks. Centrino and mobile Pentium 4 are battery pigs. Freescale is where it's at on battery life and on performance per cycle on portables. If Apple were to dump out of PowerPC on PowerBook before Intel came up with a genuinely thermal and battery-friendly architecture, Apple's notebooks really would sink to the bottom with all of those clones shown at Computex.
What else is news? I alluded to it in an earlier post that I couldn't transform into anything resembling English (this is the best I can do leaning against a window at Moscone Center). Steve said nothing about servers. Not a peep. That's odd, considering that the OS X Server ports to x86 have unquestionably walked hand-in-hand with Apple's x86 client work. Steve touted a new release of OS X, named Leopard, to coincide with the Longhorn client. I'll hazard a guess that keeping mum on servers is a combination of factors. Those customers who have bought into Xserve G5 made a conscious total platform choice. They opted for OS X on 64-bit PowerPC, and many of those customers are recent sells. Desktop users don't care what's inside their PCs, but server customers do. If Apple threw a 1U x86 server at its Xserve customers, those customers would feel as though they'd been told to go to (snerk) Dell. And one thiing is absolutely certain: (snerk) Dell and HP will always be able to make cheaper rack server gear than Apple can.
I'll pose once again the possibility that Apple will pick up Itanium for its server line. Intel, unlike IBM, can hit its roadmaps, assuming that AMD doesn't interfere again.
Good lord, I've got to take a breath. This entry's so threadless because there's just too much to try to squeeze into one post. I'm in analytical, strategic, architectural and prognostic overdrive. Is noon too early to knock back a couple of shots?
--------Posted by Tom Yager on June 6, 2005 12:22 PM
June 06, 2005 | Comments: (0)
They're herding the press at the doors to the big hall. Steve Jobs does his keynote in a bit less than an hour. I've got the jitters. It's not the x86/PowerPC question itself that's got me chomping at the bit. It's the crowd's reaction. These are the people who hissed at Microsoft last year, but they redeemed themselves later with applause. Would they dare dis Steve?
I don't know. Apple's got killer hardware engineering talent. The x86 architecture, as implemented by its creator, is mediocre. But in Apple's hands, the potential is considerable. There's no reason in the world that Apple couldn't do, or have done for it, NUMA (non-uniform memory access; a dedicated bank of RAM per CPU) and multiple I/O buses. Apple could build x86 systems that you could use to run Windows or Linux, but as one Apple sales exec once said to me, "why would you?"
Or Apple could just buy fully populated motherboards from Intel and wrap them in heavy brushed aluminum, festoon the system's backside with I/O ports of every imaginable variety, pre-load the hard drive with OS X (yum) and settle for making best in class PCs with unremarkable guts.
Whatever the pitch, if this x86 thing goes off, the focus will be on two things: An easy, unhurried transition, and emphasis on Apple's unique added value. It could be that Apple, like Sun Microsystems (which is roaming the floor wearing VIP badges), may be coming around to the realization that above the consumer level, there's a lot more money in software.
There was a guest speaker checking in with a bag full of juggling (like bowling) pins. Are we going to get "now it's a Mac, now it's a Windows PC, now it's a Mac..."
Anyhow, long live the Mac.
--------Posted by Tom Yager on June 6, 2005 09:06 AM
June 06, 2005 | Comments: (0)
Five reasons not to hate OS X on x86
1. Apple wouldn't have to water cool a pair of Xeons.
2. Apple would have a reliable second source of supply (AMD).
3. What fool would buy commercial Linux box if OS X ran on something other than a Mac?
4. OS X on x86 would push developers to higher standards of quality and usability, just as it has done on the Mac.
5. Apple is staying in hardware, so it's certain that Apple will still innovate on design. Remember, all Apple bought from IBM was the PowerPC 970FX CPU. Apple designed the rest. No, they really, really did. And they can do the same with Intel.
6. OS X running in a virtual machine under Windows (or Linux) would inherit all of Windows' (or Linux's) device drivers.
7. Windows XP is an operating system, a game of solitaire, a file explorer and a pinball demo. Doesn't that just, like, make you cry?
8. The death of arcane Open Firmware.
8. 100,000 people at WWDC 2006.
9. Finally, some Mac-related listings on hotjobs.
10. Free and FINE Dev tools that can use anything (Intel, GNU, Pathscale) as a back end. And the docs, and the sample code, and...
11. Red Hat.
--------Posted by Tom Yager on June 6, 2005 12:09 AM
June 05, 2005 | Comments: (0)
If Apple goes Intel, it's not news, but prepare for boos
So. Yahoo News, by way of Reuters, by way of CNET says that Apple will be moving to Intel CPUs in '06 and '07. Correct or incorrect, this is cause for neither alarm nor protest. One of the IBM semiconductor honchos who opened up POWER's design said something along the lines of, "processors don't matter." True enough, from a software development and distribution point of view.
The timing for Apple's surrender to hardware mediocrity is right. The market's money is sitting precisely where Apple's strengths lie: Higher-powered desktop/workstations for gamers and other legitimate uses, high-end notebooks, centrally-managed workgroups, turnkey rack servers and, oh yeah, system software that kicks Windows' ass around the block and then calls its momma names.
I can see this getting screwed up badly. If Apple announces an x86 shift, Apple falls from a first tier volume RISC player (really, a market it has to itself) to a second tier PC player. But all is not lost. Dell (snerk) is planning a high-end (read: gamers) desktop. Apple could walk right into that space and own it, but with advance notice of that intent, every PC maker will line up to catch a ride on Apple's style-mobile.
As for me, I'd love it. My major gripe is OS X's inability to run multiple virtual machines; AMD and Intel have solutions for that, although the whole PowerPC/x86 compatibility thing is a bear. If Apple wants to hand me a squeaky-clean BSD for x86/x64, plus Quartz Extreme, plus OpenGL, plus PDF-based rendering, plus metadata-based searches, plus the Aqua top-level GUI, I'll take it. I'm a RISC fan, but hey, I can still parse x86 machine code.
I will feel burned if Apple goes with Intel instead of AMD, but that's personal. It took Intel 20 years of courtship to try to win Apple away from Motorola/Freescale and IBM. AMD makes killer technology but can't sell it. Opteron is a first-tier chipmaker now, with NUMA and HyperTransport and 8 CPUs (glueless). It can hand Apple something in G5's class. Maybe when this is over, some Apple insider will explain why AMD didn't make the cut.
It's late, and those are the only thoughts I have in mind.
But seriously, people, didn't you see thins coming?
--------Posted by Tom Yager on June 5, 2005 01:11 AM
May 18, 2005 | Comments: (0)
O say, can you C? If you can, you need to grab a copy of Darwin, the open source guts of OS X. This blended BSD is more accessible to those outside the Mac community now that Apple has elected to distribute bootable ISO CD images.
Apple keeps Darwin in sync with OS X, so the current Darwin download, version 8.1, is exactly what you'll find in the just-released OS X 10.4.1.
Why would anybody who doesn't use a Mac care about Darwin? In my view, because Darwin is a targeted, highly functional OS that is simple enough to be understood by developers. By simple, I don't mean stripped or bastardized. Those who fear that Apple has done unconscionable things to BSD to make it more of a proprietary OS really need to look at the Darwin sources.
By simple, I mean that Darwin is not Linux. Darwin is designed to target only two CPU architectures (PowerPC and x86). Apple is extremely conservative about merging new features into the core source tree. Darwin does not have a lengthy roll of committers who wander in and out of projects on which the distribution depends. And unlike some commercial Linux outfits, Apple hasn't constructed Darwin as a low-priority charity/PR project. Darwin is OS X, fire-tested and validated, minus Apple's protected intellectual property. And where IP is concerned, Apple has kicked an awful lot of its potential proprietary goodies (just consider Bonjour, QuickTime Streaming Server and Open Directory for starters) into the open source domain.
You can scour Apple's developer site day and night looking for details of OS X's internals, but you'll never find any reference as concise as the Darwin sources. The tree is small and I find it easy to digest.
Darwin does boot on a Mac as a standalone OS, and there might be occasions where you find that useful. I've got Darwin partitions stashed away on some of my machines so that I can build and road-test open source projects before deploying them to OS X. I do find Aqua a distraction when I'm working on non-GUI apps. That's most of the design and coding work I do. Having a Darwin partition also creates a rescue shell that takes up a lot less disk space than a spare instance of OS X, and Darwin is more forthcoming about and forgiving of boot-time problems than full-blown OS X.
If nothing else, you should be aware of Darwin because open source projects are often tagged with Darwin as a target, and not OS X. It's presumed that you know Darwin is OS X. With that knowledge, you're ready to knock around Fink and Darwin Ports for those thousands of open source apps you just can't live without. Be careful, though: Once you start digging, you'll find yourself falling for some projects that reach beyond what Darwin provides and therefore won't work on anything but a Mac. But even if you're a hardcore open sourcer, you might find yourself gravitating toward those true OS X apps with the familiar Mac look and feel.
--------Posted by Tom Yager on May 18, 2005 06:45 PM
May 18, 2005 | Comments: (0)
I always hand out the bad news first. Now for the good news on the Tiger upgrade front.
Upgrade-in-place (not archive/install) OS X installs of Tiger on my Power Mac G5 and OS X Server on Xserve G5 came off smooth as you please. There's something about expecting trouble that keeps it at bay.
I used an external LaCie DVD burner to install OS X Server on Xserve. Apple (thank you, thank you) ships CD-ROM media in the retail OS X Server box along with the DVD. That benefits us behind-the-timers with CD slot drives in our server boxes, but if I didn't have an external DVD drive, I'd buy one to make these upgrades and installs easier, not only on servers but on notebooks where the internal drives are so comparatively slow.
The Tiger installer's option to slurp in user data and apps from other systems or partitions is very useful for production systems. I've used this to create dual-boot Panther/Tiger setups on my Power Mac G5 and 17-inch PowerBook. There are other, faster ways to go about this, but none as simple or foolproof as the installer's one-click approach.
I walked through OS X Server 10.4's new and enhanced feature set and decided, case by case, whether I'd finesse my Panther configs or wipe them out and start clean. Sometimes configurations get crufty over time, and an OS upgrade is a good excuse to scrape off the barnacles. I expect systems to wobble a bit after these cleanings. OS X Server did wobble, but it was my own doing. I had trouble with permissions, and in places where I had mixed BSD flat-file configs with those in the Netinfo database. I can't help it. Netinfo will always be foreign to me.
It's a topic I'm saving for my upcoming print review of Tiger, but I want to mention here that this is the first OS X Server release that I'm comfortable running with a headless server. I'll keep my Xserve G5 hooked to my KVM switch, but I pulled the head off my Xserve (G4) and did a remote install. OS X Server's administration command set is still esoteric from a Unix standpoint, but all system properties are covered and management is fully scriptable. It's lovely, especially for non-Mac types who don't want to muck around figuring out what's in System Preferences and what lives in the GUI admin tools.
Apple Remote Desktop 2 went useless on me before the Tiger upgrades, freezing and crashing during active sessions. I had taken to using Chicken of the VNC to get remote GUI. That deprived me of all the remote installation, maintenance and reporting ARD has built in. After I installed Tiger, I downloaded the Remote Desktop 2.2 update from Apple and pushed it out to all of the Macs on my LAN. ARD is now working as advertised. Screen updates are slower, but I don't care.
ARD is just as valuable for servers as it is for clients. ARD is a convincer for those non-believers who look at the Mac and say, "I can't manage Macs on my {brand W} network!" Sit Mr. Windows down with a copy of ARD and the server admin tools and dare him to find something he can't manage remotely. And be sure to mention that OS X has a shell.
And while we're on that subject, Tiger now ships with KornShell. Not zsh which claims to be an almost clone, or bash which "incorporates some KornShell-like features." The real, true, David G. Korn shell that's deserving of the book of its own that bears his name. I know I had other avenues for getting KornShell, but that Apple chose to bundle it pleases me almost as much as having the shell. It's a proper language, by the way.
I have lots of other thoughts to share, but I'll close with this: I've reached the point where I believe that system-attached storage is evil. I have two Xserve G4s, an Xserve G5, a Power Mac G5 and a dual/dual Opteron tower all feeding from one Xserve RAID array. I'm running a mix of dedicated partitions and Xsan (Xsan for the Macs), and with those approaches available from a single array/switch set, there really aren't any storage configurations I can't set up. This is another instance where I took advantage of the scheduled downtime to make fuller use of the resources in my shop. I split one of my logical arrays to dedicate one to a growing collection of text files (e-books, US Code, catalogs...) to test searching and indexing, especially Spotlight. I'll let you know how that goes.
It's so much fun fiddling with Tiger that I'm almost reluctant to flip the switch that puts OS X Server back on the air.
--------
Posted by Tom Yager on May 18, 2005 09:39 AM
May 09, 2005 | Comments: (0)
I'll be all over the subjective and analytical coverage of OS X Tiger in InfoWorld's print reviews, my Ahead of the Curve column and this blog. I think Tiger is just grand, and I'm way past the "Apple can't suck" stage of my working relationship with the Mac. But as much as I admire this OS, putting myself in the shoes of what I considered to be a relatively new user--one who came to the platform late in OS X 10.2's life or during 10.3's--left me thinking that this isn't an upgrade I'd recommend to a non-experienced user.
I can now count myself among the ranks of experienced users. Since OS X 10.3, I haven't found the need to subject OS X to the "wait for the first service pack" rule. I've been working with seed releases of Tiger for a year, but not on production hardware. The true test was an upgrade to Tiger from OS X 10.3.9 on my 1.5 GHz 17-inch PowerBook G4. That machine is to my professional life what Diet Pepsi and trail mix are to the rest of my existence.
The upgrade was a frustrating, time-sucking exercise from the start. It failed partway through, complaining that it could not write a particular file. There was no reason for this. The hard drive passed two sector-by-sector validations as did the install DVD. The install partition showed clean on fsck (file system check, the Unix utility fronted by the Disk Utility GUI with the Verify and Repair buttons) and on Fix Permissions. Even deleting the existing file and making its parent directories world-writable didn't work.
Those familiar with OS X upgrades know that the installer can't handle an upgrade that failed in process. I pushed ahead as though I didn't know I couldn't continue. If I were pretending to be a Windows newcomer instead of a Mac newcomer, I'd discover that I can pull the plug on a Windows system at virtually any point during an install or upgrade and have it recover without loss of the system's original data. This raises a question about the ease-of-use advantage that Apple claims over Microsoft. I've long thought that for a substantial percentage of users, Macs' ease of use paradigm extends only to systems used as shipped or managed by experts.
With Tiger on the PowerBook, the failed upgrade-in-place meant that I was screwed. That state remained for a solid three days.
My initial upgrade attempt required the use of a LaCie external FireWire DVD drive. My PowerBook's internal SuperDrive cratered just before the install. I had another external drive, an LG DVD+/-/RAM device (a sweetheart of a drive--see a follow-up post), that I installed in a Belkin USB 2.0 external chassis. The combo gets along famously with my Power Mac G5, Xserve G5 and every PC box in my shop.
When I attempted to boot the 17-inch PowerBook from the LG drive, the drive spun up promisingly but the PowerBook booted (rather, failed to boot) from the busted hard drive image. My first cheat was to try activating the Mac's boot media list by holding down the option key at power-up. It did not see the OS X install DVD at all.
It rang a distant bell that PowerBook couldn't boot from USB. The junkiest PC in my pile boots USB. I'm writing this on the third generation of PowerBook that's run through my lab. It hadn't occured to me that a late-model PowerBook would not boot from a USB optical drive.
I ended up putting the 17-inch PowerBook in target disk mode, which for the uniniated is a nifty, life-saving hack that turns a Mac system into an external FireWire hard drive. I installed to the 17-inch 1.5 GHz notebook machine from an 867 MHz 12-inch PowerBook. It took a while. It's a lucky thing I had another Mac. If the 17-inch PowerBook had been my only machine, I'd have been up the creek. Of course I had backups, but making this work in-place was a requirement of the exercise.
Running the 17-inch PowerBook in target disk mode did get OS X through the upgrade process to its be right back reboot. I felt relieved and called it a very late night.
Success required not only using target disk mode, but switching from an in-place upgrade to archive-and-install, the latter being a method that moves existing system files to a safe directory before clobbering them with the new OS. This trick is helpful for those of us who speak Unix, but who else would know what to do with those backed up files? There's no opportunity to back out the upgrade, boot from the safe copy of the system files or pull in portions of those files to fill gaps in the new installation (e.g, an app that's missing its run-time preferences).
I woke the next day ready to celebrate my victory, but the 17-inch PowerBook would not boot. T