Technology: May 2005 Archives
I was writing my previous post, about the new Nokia 770 Internet Appliance, and I wanted to insert a remotely linked image in the post (from Mobile Gazette).
I was using Safari on my iMac. I ctrl-clicked on the image, selected Copy Image Address and got:
nokia-770-3.jpg
Obviously, pasting that into my post is not very helpful, as the image doesn't reside on my web server.
So I fired up Firefox, ctrl-clicked on the image, selected Copy Image Location, and got:
http://www.mobilegazette.com/images/nokia/nokia-770-1.jpg
Much more gooder.
There's a terrific article by James Surowiecki in last week's New Yorker (May 16 issue) titled Hello Cleveland, where he describes the ways in which musicians are making more money from playing live than they are from selling recorded music. Well worth a read.
The upshot is that the fortunes of musicians and the fortunes of music labels have less and less to do with each other. This may be the first stage of what John Perry Barlow, a former lyricist for the Dead, once called the shift from “the music business” to “the musician business.” In the musician business, the assets that once made the major labels so important—promotion, distribution, shelf space—matter less than the assets that belong to the artists, such as their ability to perform live. As technology has grown more sophisticated, the ways in which artists make money have grown more old-fashioned. The value of songs falls, and the value of seeing an artist sing them rises, because that experience can’t really be reproduced.
I was encouraged the other day to see Yahoo's new Yahoo Music Unlimited service announced. Unlimited downloads of music for $5 a month (if you pay for an annual plan). Currently there's over a million songs to pick from. Unfortunately, at the moment it's for Windows only, and the songs are in the heavily DRM'ed version of Windows Media, but it's a good indication that there's starting to be the right kind of downward pressure on prices in the legal download world.
Barry Ritholz points out in his blog that this brings the value of ten years of unlimited music downloads to the low, low, price of $600. He further notes that this Kinda makes it hard to argue that losses per P2P user are in the 10s of thousands of dollars annually when $600 per 10 years is what it costs for a comparable substitute.
Mark Cuban (owner of the Landmark Theater chain, the Dallas Mavericks basketball team, and the angel funder of the Grokster defense) writes that this means that :
The RIAA can no longer claim that students who are downloading music are costing them thousands of dollars each. They can’t claim much of anything actually. In essence, Yahoo just turned possession of a controlled music substance into a misdemeanor. Payable by a $5 per month fine.
Of course, RIAA staffers won’t go quietly into the night. They will continue to scream loud and hard about evils of illegal downloading. The question is, will they move the money they are currently spending on court cases and filing suit, towards promoting the new subscription services that are available. Particularly Yahoo’s dirt cheap service.
Larry Smarr is one of the people at the center of the use of high speed networks and high performance distributed computing to move scientific research forward.
There's a new video online of the keynote talk he gave in January at the JGN II symposium. Interestingly enough, he gave the talk in Seattle, and it was shown on HD video, streamed live over the Internet to Osaka.
The talk is an illuminating survey of some of the scientific activity that is being enabled by very high speed networks and some of the work that's being done to create the networks that these scientific efforts require.
In order to get the most out of the talk, you need to watch Larry in one window and click along with his presentation slides in another window.
I watched this in my office, viewing the high def 5 megabit per second version of the video, and it was amazingly clear and detailed - by far the best streamed video I've seen yet on a desktop computer. At this kind of resolution video really does become something rich and compelling, instead of just something annoying (which is what I usually find streaming video to be).
Unfortunately, the video only works with Windows Media on Windows - on the Mac I could get the audio but not the video.
It's well worth watching this presentation if you have any interest in how science is actually being done these days.
In response to my earlier post on security in Apple's new Dashboard Widgets, John Gruber, who writes the Daring Fireball blog, replies:
It's interesting that you're not getting the first-run warning, but I don't think the overall threat is any more serious than with normal Mac software. What's to stop *any* of the apps listed every day on VersionTracker from doing these things? Trojan horses are easy to write.
Exploits would be tough, because it would imply they could spread from one machine to another, or that you could have a malicious widget injected into your machine without knowing.
So, no, I don't think widgets are going to pose a security problem. That's not to say I'm certain, however.
And he's got a point.
But I do note that with Tiger, Apple has really beefed up the warning about installing executable software files, precisely at the same time as they're encouraging everyone to download and install lots of widgets.
Zephyr pointed out a Slashdot post about zaptaastic, which actually demonstrates installing a "slightly evil widget" (don't visit the page with Safari). This demonstrates the autoinstalling of widgets done by Safari. Zap makes the same point I just did above:
"So what?" you may say, "The user gets warned.". Two words: social engineering. The Macintosh user base is rapidly being conditioned that widgets are harmless little toys, and Apple's warning is fairly innocuous:
goatse.cx is being run for the first time.
Are you sure you want to run this widget?
That doesn't look particularly threatening. I haven't tried any actually destructive things; I would assume that getting root is a lot easier when you're starting from inside the host box. I wonder how many of the gmail passwords entered by users in flores and coras are the same as the root password?
It would be obscenely easy for me to harvest passwords in those applications, by the way... but I don't. I could just generate hits on http://stephan.com/watch.html?username:password and then go read my system logs.
127.0.0.1 - - [05/May/2005:02:49:11 -0400] "GET /widgets/flores/index.html?foo:bar HTTP/1.1" 200 5758
Even without root, though, there are some pretty interesting things you could do. A widget, for example, could use time when it is hidden to add tags to every .html page stored in the users home directory. If the user happens to be running a web server - or even uploading files to one - this could propagate a widget to other machines. I'm not really a security expert, I'm sure others can think of worse things to do.
Apple has significantly lowered the bar for malicious entities to install and execute damaging code in OSX. Honestly, I don't think this is that big of a deal - causing real damage is likely a bit harder than I make it sound.
Wired News has a good interview with DJ Spooky, who has a new book out called Rhythm Science. He talks about the culture of sampling and the legalities around copyright and re-use of materials.
WN: There was a recent case of NWA using a snippet of George Clinton's music, and a court ruled that even though the sample was unrecognizable, NWA still had to secure rights to use it.
Miller: That means they didn't change it enough. Basic rule of thumb: ... you don't want to get sued.
It's a nightmare. There (are) lawyers. There are websites who filter through all records -- everything. People are paid to just listen to music at this point and listen for samples....
In the same way a lot of people involved with internet hacking culture will hack your site and then call you up and say "By the way, we have security services we'd like to offer you," you might get a little phone call saying, "There is a sample on your record that we heard, and we'd be more than happy to clear it for you." Of course implying that if you don't, the next phone call will be to the people you sampled.
It's a paradoxical world. On one hand, sampling is a homage to your favorite records and favorite sounds, but you have to pay through the nose if you feel like doing that.
There's an excellent editorial in the new issue of Science magazine (May 6, 2005 issue) by our very own Ed Lazowska (professor of Computer Science here at Washington) that takes the Defense Advanced Research Projects Agency (DARPA) to task for abandoning its responsibility for funding visionary basic research in computing.
Next month, U.S. scientists Vinton G. Cerf and Robert E. Kahn will receive computing’s highest prize,
the A. M. Turing Award, from the Association for Computing Machinery. Their Transmission Control
Protocol (TCP), created in 1973, became the language of the Internet. Twenty years later, the Mosaic
Web browser gave the Internet its public face. TCP and Mosaic illustrate the nature of computer
science research, combining a quest for fundamental understanding with considerations of use. They
also illustrate the essential role of government-sponsored university-based research in producing the
ideas and people that drive innovation in information technology (IT).
Recent changes in the U.S. funding landscape have put this innovation pipeline at risk. The Defense Advanced
Research Projects Agency (DARPA) funded TCP. The shock of the Soviet satellite Sputnik in 1957 led to the creation
of the agency, which was charged with preventing future technological surprises. From its inception, DARPA funded
long-term nonclassified IT research in academia, even during several wars, to leverage all the best minds. Much of this
research was dual-use, with the results ultimately advancing military systems
and spurring the IT industry.
U.S. IT research grew largely under DARPA and the National Science
Foundation (NSF). NSF relied on peer review, whereas DARPA bet on vision and
reputation, complementary approaches that served the nation well. Over the past
4 decades, the resulting research has laid the foundation for the modern micro-
processor, the Internet, the graphical user interface, and single-user workstations.
It has also launched new fields such as computational science. Virtually every
aspect of IT that we rely on today bears the stamp of federally sponsored research.
A 2003 National Academies study provided 19 examples where such work
ultimately led to billion-dollar industries, an economic benefit that reaffirms
science advisor Vannevar Bush’s 1945 vision in Science: The Endless Frontier.
However, in the past 3 years, DARPA funding for IT research at universities
has dropped by nearly half. Policy changes at the agency, including increased
classification of research programs, increased restrictions on the participation
of noncitizens, and “go/no-go” reviews applied to research at 12- to 18-month
intervals, discourage participation by university researchers and signal a shift from pushing the leading edge to “bridging
the gap” between fundamental research and deployable technologies. In essence, NSF is now relied on to support the
long-term research needed to advance the IT field.
Apple's new Dashboard in the Tiger version of OS X allows you to place lots of handy little applications, called widgets, on a translucent layer over your main desktop, making it easy to call up the weather forecast, current time, measurement conversion utilities, etc.
It's a very nice addition to the OS, and I foresee lots of use of it.
Widgets are built using simple html, javascript, and stylesheets - all pretty easy and widely known technologies.
I was wondering what the security model for Dashboard widgets is. In Apple's Dashboard Programming Guide says, in its Security section:
sing certain resources within your widget may pose a security risk for users. In these circumstances, the widget security model provides a method for Dashboard to be aware that your widget may perform insecure tasks. If your widget is working with resources that pose a security threat to the user, the user must approve before access is granted.
Dashboard allows you to “declare your intentions” when you:
* Access files outside of your widget bundle
* Use a Web Kit or standard browser plug-in
* Access network resources
* Run a Java applet
* Run a command-line utility
* Using a widget plug-in
It also says:
If any of these keys are present in your information property list file and it’s located outside of /Library/Widgets/, a dialog is presented to users upon your widget’s first load. The dialog asks them whether or not they want to use your widget. If the request is approved, your widget is loaded and granted access to the resources that it requested. The request is not repeated on subsequent loads if approved. If the request is denied, your widget is not allowed to load. If your widget is loaded again, the request is made to the user again.
If you attempt to use any of these resources without first specifying them in your widget’s information property list file, your attempt fails.
So I loaded a sample widget from Apple's Developer tools called Which - it gives you a little box that calls the command line which utility (a unix command that shows you where a given program resides in your file system).
I installed it on both my Powerbook and my iMac - and got no warning whatsoever.
Dan who sits in a cubicle outside my office, tried installing a widget called QuickCommand, which gives you a basic terminal environment in the Dashboard and allows you to store four basic unix commands to execute in that terminal. Dan reported getting a message on installation that said:
QuickCmd is being run for the first time. Are you sure you want to run this widget?"
[Decline] [Accept]
I tried downloading the widget and again, got no such message.
But even if everybody saw the warning, there is no wording in there about the fact that this widget contains commands that could cause security risks, nor anything about what the risks of installing a random widget might be.
It would be trivial to write a widget that appeared to do something useful while executing all sorts of unix commands - like searching your disk for credit card numbers and passwords and forwarding them on to random email addresses.
Am I the only one who's worried about the security implications of Dashboard? I expect it's entirely possible that we'll see the kinds of widespread exploits on the Mac platform that we've been fighting for years on Windows.
Sigh.
The new version of Safari that comes with Mac OS 10.4 has been giving me (and lots of other people) problems when trying to use it with pages authenticated by UW NetID (via our use of the PubCookie web authentication software).
Because of that I switched back to Firefox as my main browser, and I also notice that FF seems much faster than Safari.
I don't find having a built-in RSS reader in the browser enough of a compelling reason to use a browser that breaks on lots of pages. I'm plenty happy using Bloglines to read my RSS feeds.
I know the C&C security middleware team is busy trying to resolve the problems with Safari and PubCookie - maybe this will get better over time.
I'm getting ready to order a new desktop computer, so I was pleased to hear that Apple yesterday bumped up the G5 iMac processor speeds a notch, included gigabit Ethernet, 802.11g, Bluetooth and bigger hard drives. No FireWire 800 yet, though.
Still, I thought I'd do a bit of comparison shopping, and here's what I found out.
The 20 inch G5 iMac, with a 2GHz G5 processor (fastest available), 2 gigabytes of memory, 250 GB disk, and a wireless keyboard and mouse, prices out at $2,180 (that's without AppleCare).
A Dell OptiPlex 170L (which I figured is conceptually similar to the iMac, not being the top high-tech performer of their line), with a 3.2 GHz P4 processor (fastest available), Windows XP Pro, 2 GB of memory, a 16X DVD+/-RW, a 160 GB disk (largest available on this model), and a 19 inch digital flat panel comes out to be $2,017.
That's pretty close. But the Dell doesn't come with a wide format screen, has slower networking, no wireless keyboard, less disk, no wireless networking or Bluetooth or a firewire interface.
I don't think I buy the argument that Apple is more expensive these days. While it's true that you can't get Macs for the complete bargain basement rates that you can buy Intel boxes for (except the Mac Mini), by the time you get all the add-ons you need to be really functional the iMac looks like the clear value winner here.
I just upgraded my work iMac to Tiger. Lo and behold, not only was the default browser reset from Firefox to Safari, but the association for .doc files was reset from Word to Appleworks. What's up with that?
John Gruber has an interesting article in Daring Fireball about the evolution of Adobe from a company run by passionate engineers, focused on producing great software for creative production, to one focused on sales for their own sake.
Rather than expand into untapped creative markets, Adobe seems hell-bent on expanding into the jerks-wearing-suits market, a market that’s completely at odds with the creative market they’ve dominated for nearly two decades.
Adobe’s best and core products are their oldest, and they are graphics products: PostScript, the Adobe Type Library, Illustrator, and Photoshop. InDesign is relatively new but genuinely fits alongside these products. This is why Adobe’s core customers — who still use and love many of their products — are dismayed and confused by the company’s direction in recent years. But is it any surprise that a company that is run by jerks-wearing-suits is now targeting the jerks-wearing-suits software market?
The dog having gotten me up twice to go outside between 3:30 and 5:00 this morning (a Sunday, no less) I've been up for hours.
Somehow, in trying to catch up on various readings in that time I got started reading old entries from Joel on Software that I never read before - and there is some terrific reading there!
Some favorites:
I've come up with my own, highly irresponsible, sloppy test to rate the quality of a software team. The great part about it is that it takes about 3 minutes. With all the time you save, you can go to medical school.
When you start with a schedule with rough tasks and then break it down into smaller tasks, you will find that you get a different result, not just a more precise one. It is a completely different number. Why does this happen?
When you have to pick fine grained tasks, you are forcing yourself to actually figure out what steps you are going to have to take. Write subroutine foo. Create dialog such and such. Read the wawa file. These steps are easy to estimate, because you've written subroutines, created dialogs, and read wawa files before.
If you are sloppy, and pick big "chunky" tasks ("implement grammar correction"), then you haven't really thought about what you are going to do. And when you haven't thought about what you're going to do, you just can't know how long it will take.
Painless Functional Specifications - Part 1: Why Bother?
Programmers and software engineers who dive into code without writing a spec tend to think they're cool gunslingers, shooting from the hip. They're not. They are terribly unproductive. They write bad code and produce shoddy software, and they threaten their projects by taking giant risks which are completely uncalled for.
...
When you write a spec, you only have to communicate how the program is supposed to work once. Everybody on the team can just read the spec. The QA people read it so that they know how the program is supposed to work and they know what to test for. The marketing people use it to write their vague vaporware white papers to throw up on the web site about products that haven't been created yet. The business development people misread it to spin weird fantasies about how the product will cure baldness and warts and stuff, but it gets investors, so that's OK. The developers read it so that they know what code to write. The customers read it to make sure the developers are building a product that they would want to pay for. The technical writers read it and write a nice manual (that gets lost or thrown away, but that's a different story). The managers read it so that they can look like they know what's going on in management meetings. And so on.
...
Writing a spec is a great way to nail down all those irritating design decisions, large and small, that get covered up if you don't have a spec.
Painless Functional Specifications - Part 2: What's a Spec?
Nongoals. When you're building a product with a team, everybody tends to have their favorite, real or imagined pet features that they just can't live without. If you do them all, it will take infinite time and cost too much money. You have to start culling features right away, and the best way to do this is with a "nongoals" section of the spec. Things we are just not going to do. A nongoal might be a feature you won't have ("no telepathic user interface!") or it might be something more general ("We don't care about performance in this release. The product can be slow, as long as it works. If we have time in version 2, we'll optimize the slow bits.") These nongoals are likely to cause some debate, but it's important to get it out in the open as soon as possible.
Painless Functional Specifications - Part 3: But... How?
program managers at Microsoft gather requirements, figure out what the code is supposed to do, and write the specs. There are usually about 5 programmers for every program manager; these programmers are responsible for implementing in code what the program manager has implemented in the form of a spec. A program manager also needs to coordinate marketing, documentation, testing, localization, and all the other annoying details that programmers shouldn't spend time on. Finally, program managers at Microsoft are supposed to have the "big picture" of the company in mind, while programmers are free to concentrate on getting their bits of code exactly right.
Program managers are invaluable. If you've ever complained about how programmers are more concerned with technical elegance than with marketability, you need a program manager. If you've ever complained about how people who can write good code never do a good job of writing good English, you need a program manager. If you've ever complained about how your product seems to drift without any clear direction, you need a program manager.
Painless Functional Specifications - Part 4: Tips
Rule 1: Be Funny
Yep, rule number one in tricking people into reading your spec is to make the experience enjoyable.
...
Every time you need to tell a story about how a feature works, instead of saying:
• The user types Ctrl+N to create a new Employee table and starts entering the names of the employees.
write something like:
• Miss Piggy, poking at the keyboard with a eyeliner stick because her chubby little fingers are too fat to press individual keys, types Ctrl+N to create a new Boyfriend table and types in the single record "Kermit."
Top Five (Wrong) Reasons You Don't Have Testers
Software has bugs. CPUs are outrageously finicky. They absolutely refuse to deal with things that they weren't taught to deal with explicitly, and they tend to refuse in the most childish of ways. When my laptop is away from home, it tends to crash a lot because it can't find the network printer it's used to finding. What a baby. It probably comes down to a single line of code somewhere with a teensy tiny almost insignificant bug in it.
Which is why you positively, absolutely, need to have a QA department. You are going to need 1 tester for every 2 programmers (more if your software needs to work under a lot of complicated configurations or operating systems). Each programmer should work closely with a single tester, throwing them private builds as often as necessary.
The QA department should be independent and powerful, it must not report to the development team, in fact, the head of QA should have veto power over releasing any software that doesn't meet muster.
The Guerrilla Guide to Interviewing
First of all, the #1 cardinal criteria for getting hired at Fog Creek:
Smart, and
Gets Things Done.
That's it. That's all we're looking for. Memorize that. Recite it to yourself before you go to bed every night. Our goal is to hire people with aptitude, not a particular skill set. Any skill set that people can bring to the job will be technologically obsolete in a couple of years, anyway, so it's better to hire people that are going to be able to learn any new technology rather than people who happen to know SQL programming right this minute.
At the conclusion of the interview, you have to be ready to make a sharp decision about the candidate. There are only two possible outcomes to this decision: Hire or No Hire. Turn to your computer and send immediate feedback to the recruiter. The subject line should be the name of the candidate. The first line of the email should be Hire or No Hire. Then you should spend about 2 paragraphs backing up your decision.
There is no other possible answer. Never say, "Hire, but not in my group." This is rude and implies that the candidate is not smart enough to work with you, but maybe he's smart enough for those losers over in that other group. If you find yourself tempted to say "Hire, but not in my group," simply translate that mechanically to "No Hire" and you'll be OK. Even if you have a candidate that would be brilliant at doing 1 particular thing, but wouldn't be very good in another group, that's a No Hire. Things change so often and so rapidly that we need people that can succeed anywhere. If for some reason you find an idiot savant that is really, really, really good at SQL but completely incapable of ever learning any other topic, No Hire. They don't have a future at Fog Creek.
Never say "Maybe, I can't tell." If you can't tell, that means No Hire. It's really easier than you'd think. Can't tell? Just say no! Similarly, if you are on the fence, that means No Hire. Never say, "Well, Hire, I guess, but I'm a little bit concerned about..." That's a No Hire as well.
An important thing to remember about interviewing is this: it is much better to reject a good candidate than to accept a bad candidate. A bad candidate will cost a lot of money and effort and waste other people's time fixing all their bugs. If you have any doubts whatsoever, No Hire.
This is great stuff - I also look forward to reading Joel's book on UI design.
