Classical composers "ripped off" each other all the time
'All the time'? Hardly. In fact, it's extremely rare. I can think of very few cases of plagiarism, and most fall into one (or more) of the following categories:
Taken from the composer's own work. (Handel was a notorious self-plagiarist, for example; a good few of the themes in Messiah were based on his earlier work.) No question of 'ripping off' here; a composer can use their previous material in any way they like.
Shot Snippets: a few bars, perhaps, just enough for people to recognise. The quotes will be well-known enough that the audience is expected to recognise them, so there's no question of passing off, and they form a tiny fraction of the work, so the vast majority is original.
Based upon well-known 'public domain' works. Of course, 'public domain' wouldn't have had the same meaning then, but we're talking about works which had been around for decades or centuries, and which had no known author. (e.g. the hundreds of variations on La Folia.)
A variation upon or addition to an existing work (e.g. Gounod's Ave Maria over the top of Bach's Prelude in C major; the tons of variations upon Paganini's Caprice #24; Vaughan Williams' Fantasia on a Theme of Thomas Tallis). These contain significant new material, but fully credit the original composer.
An arrangement of an existing work, e.g. for different instruments or voices. Although arrangements can be quite creative, usually the bulk of creativity is from the original work; but usually the original composer gets top billing anyway.
Of course, it depends what you mean by 'ripping off', but for me that would need: trying to pass off someone else's work as your own, profiting from someone else's work without adding anything significant to it, or using a new work to bring the original into disrepute. And I can't think of a single occurrence of any of those in the classical music world.
But then, all this is moot anyway, because none of the sorts of copyright we're talking about would usually have applied then:
Copyright in the music material itself. Back then, this probably wouldn't have lasted for nearly a century after the composer's death...
Print copyright -- in an edition of the printed score. If you're creating new music, it will by definition need its own edition in print, so there's no infringement there.
Mechanical copyright -- in a recording of the music. While an awful lot of people would be hugely interested to hear how classical works were first performed, not many recordings survive from those times...
So I don't think you can't really compare any of that with the sort of 'ripping off' we see today.
Re: What is wrong with GPL v2
on
Drafting GPL3
·
· Score: 1
Personally, I don't see the need to make organisations a special case. Wouldn't it be simpler -- and express the purpose better -- just to say that whoever gets to use the software must also be able to get the source, whether they're inside an organisation or not?
Mmm. I too let iTunes do its thing and love the results.
But that doesn't scale directly to an entire filesystem.
For one thing, iTunes is handling just one sort of file: music. It may play AIFFs, WAVs, MP3s, AACs, and ALEs, but they're fundamentally holding the same sort of data, and -- more importantly -- have the same kind of metadata. They all have lengths, names, last played dates, &c. And most have artist, track number, &c. So keeping track of that metadata is easy -- you store the same stuff for each file.
But on a filesystem you have umpteen types of file, with umpteen types of metadata, so you need to cope with each file having a different type of metadata. Which isn't easy. (That's why it's really impressive that Apple seem to have managed it efficiently.)
OTOH, there's one great idea we could pinch. We've talked about Smart Folders, which are the filesystem equivalent of Smart Playlists. But iTunes also has (dumb) Playlists, which are the equivalent of filesystem folders. iTunes dumb playlists are different, though: a track can be in more than one playlist, or it can be in none (other than your 'whole library' one). And I think that would work wonderfully on a filesystem, solving most of the problems people are mentioning here.
You could use dumb folders just like at present, with each file in exactly one. Or you could put a file into two different folders at once, which would remove the need for aliases or symbolic links. You might even be able to get rid of the Trash, too -- removing a file from a folder wouldn't delete it, and if you wanted to you could tell it to physically delete all files that aren't in any folders.
The one thing that the iTunes-model folders wouldn't have is nesting, but I can't see any problems adding that. Then you'd have a model where smart folders and dumb folders could coexist neatly on a filesystem, giving all the benefits of both an iTunes-like repository and a traditional filesystem, and lots more!
Quick, wait here while I dash off to the Patent Office...
I think you've missed the power of Spotlight here. While the current UI is neat, there are really two major new things going on underneath it.
The second is obvious: the OS automatically indexes everything written to the disk, no matter how (i.e right down at the FS level). Because the index is always up-to-date, searches are immediate and quick.
But the first isn't so obvious. To find what to index on, it's not just searching the data for text strings. Instead, it understands about different file types, and extracts metadata from the file contents using that knowledge. It knows about text files, HTML, Word docs, PDFs, emails, JPEGs, MP3s, MPEGs, and most other common types of file. And app writers can tell it about their own filetypes too, via an API.
This differs fundamentally from the BeOS/etc. model you describe because the metadata is part of the file datastream, not separate from it. That may seem non-ideal, but it has several major advantages today: you can move or copy files with any tool, across all existing filesystems and OSs, without losing that metadata. It doesn't need to be stored in a special filesystem. And most file creators and editors, on all OSs, already understand and write it, so you can share files with non-Spotlight-aware apps on Macs and other machines, and have them all using the same metadata.
It means I can download an MP3, and as soon as I write it to disk, Spotlight reads the ID3 tags and indexes them. Ditto practically any type of file. And all that's here working right now, without the major changes (filesystems, apps, OSs, transfer protocols, &c) that external metadata would need.
At present, the UI for this is very simplistic. But you can bet that more powerful searching will soon be available, if not from the Finder then via other apps.
Me too. I had several hundred MDs, from my own CDs -- all gone. Everything's now on my HD and iPod, where it's much, much, much more accessible.
I don't think it was just the lock-out that harmed MD, though. It also suffered from:
bad timing (being released before it was ready, to fight DCC, and so gaining an unfair reputation for bad sound quality),
bad marketing (or indeed any marketing),
and a completely artificial distinction between consumer and pro-level MD (which they made incompatible and ludicrously expensive).
But lock-out (being unable to access the compressed stream, or access the uncompressed stream faster than real-time, as well as the Copyright Management System) was also part of it. And though they're releasing that slowly, it's too little too late -- with the rise of HD and flash players, MD's window of opportunity is fast closing.
Shame, coz it was a neat technology that could have ruled for about a decade.
Darwin's usefulness spreads far wider than just those who use it directly.
For example, as a Mac OS X user, when I discovered a problem in the MSDOS-format volume handling (specifically, a minor incompatibility with CF cards that had been used on EPOC/Symbian OS), I was able to use the Darwin source to fix it myself. I downloaded and searched the relevant source code, instrumented/recompiled/ran a few user-land programs, found the problem, fixed and tested it, and then submitted it to Apple, who (after a nice chat with one of their engineers) put it into Darwin 7 and Mac OS X 10.3. It was hardly a major change, just 3 or 4 lines IIRC, but I'd not have been able to do it without Darwin's source code.
The more advanced the mathematics, the less you dirty your hands dealing with actual numbers. It's all abstractions: algebraic structures such as rings, fields, and prime ideals; vector spaces, manifolds, and topological spaces; functions, functors, and operators; and though objects like vectors and tensors may look like arrays of numbers, they're really something far more deep and mysterious. And even when you do deal with actual numbers, chances are they're complex, transcendental, and/or transfinite.
So if you're one of those kids I hear about who images that a maths degree consists of learning how to divide 17-digit numbers, I'm afraid I have to disillusion you!
Anyway, back to the plot. One description of maths I rather like is 'the science of patterns', which seems to capture the spirit of the thing reasonably well for me.
Some broad generalisations there, which are invariably false*.
(* Far too few people get that one...)
I can't speak for too many, but I'm a member of a Baptist church here in England, and I know people from several other local churches (Baptist, Methodist, Brethren, Elim, &c); I'd guess that very very few take the literal creationist position. I certainly don't. I think 'Baptist' means something slightly different here from what it does in the southern US...
But it's not the simple yes/no question that some seem to be assuming. To take every word of the Bible absolutely literally, you'd have to accept not only that the universe was created in exactly 144 hours, but that there actually existed a man with a plank in his eye, and that St Paul actually looked at everything in a mirror ('through a glass darkly').
On the other hand, if you say you don't take every word of the Bible literally, you're then placing yourself in the same category as people who take practically none of it literally, who practise pick-n-mix religion and don't believe that there was ever an actual person called Jesus who did any of the things that were written... and I wouldn't call those people 'Christians'!
So it can get very hard to define terms here.
My view is that you have to understand the intent of the various Bible writers. Some parts were clearly not meant literally: poetic passages in the psalms, figures of speech, reports of dreams and visions, parables and stories. Other parts clearly were. And in most cases, the difference is made fairly clear from the context. But to understand which is which, we need we need to apply our wisdom and intelligence -- things which seem to be in short supply in some parts of the world!
I have the reverse perspective -- I've had my Mac for several years (never owned a PC), and it's still running Mac OS X 10.2, which is still fine for me. OTOH, it's been a while since I used a PC much, so when I recently started a new job and I had to use a PC (XP), I noticed lots of things which really annoy me.
Obviously, being a work PC, there's a lot of home-use type stuff which I haven't used. But even with just Notes, JBuilder, ClearCase, and a couple of other apps, there are still tons of little things which I miss.
A few examples: in the OS X, there's a single keystroke to close the current window/pane/tab (Cmd+W) -- in XP, it varies; sometimes, there's no shortcut at all. (Ditto Find again, and umpteen other common functions.) In OS X, if you have some highlighted text, pressing right arrow will leave the cursor at the end of it; on XP, sometimes it leaves it one character from the left of the selection. In OS X, pressing the down arrow on a single-line text field takes you to the very end; in XP, sometimes a Ctrl+combination will do the job, and other times you can't. In OS X, almost all multi-line text fields will use the system spellchecker, underlining unrecognised words &c if set to do so. (For example, it's doing so right now as I type this in Safari.) Whereas in XP, some apps have their own spellcheckers, each with its own dictionaries, keystrokes, options, &c; others have none at all. Even with ClearType turned on, I find XP text gritty and harder to read than the nice smooth elegant Mac fonts -- where everything, including menus, captions, labels, &c are all smoothed, as are icons, buttons, and everything else.
Now, taken singly, each of these points probably sounds petty and unimportant. But there are hundreds of these annoyances. And what they add up to is clumsiness, awkwardness, the feeling that it's getting in the way all the time. I hate to reuse a catchphrase, but it's true: Mac OS X just works -- it does what you expect, it's consistent, it gets out of your way and lets you get on with things.
Of course, it has many pretty major features, too. But don't underestimate the little things.
...but no-one's going to get to read it, coz it's been over 20 minutes since the story was posted. Ah well.
Anyway, it's this: Make as much as possible obvious from the code itself. And comment everything else.
It's not really about the volume of comments; it's about their content. You should usually be able to see the low-level of what the code is doing, and how; comments on that are not only superfluous, but their redundancy makes them actively dangerous when they don't get modified along with the code. What's usually much harder to see is the big picture: why it's doing it, and how that relates to the rest of the system.
As a result, comments tend to be more important at the top of classes/methods/functions/procedures than in the nitty-gritty, because that's where the high-level info fits. Literate systems, especially JavaDoc, are good at encouraging that sort of comment, but there are no silver bullets: it's down to the developer thinking about the code, and (most importantly) thinking about the poor sod having to maintain it in a few years' time. I think you really need to have been in that position in order to fully appreciate what comments should be.
Oh. I only use two FireWire devices -- my iPod dock, and a CF reader -- and neither have pass-through. OTOH, I used to have a CD writer, which did have it, so maybe I've just been unlucky in that respect.
So the unit has 3 FireWire ports, of which one has to be connected to the Mac; leaving two. But don't you also lose one of the Mac's own ports too, at the other end of the cable? So the net gain is only one extra port available?
You know, it's fascinating how a language that we take for granted can seem so alien. As a Brit, my first thought on reading the title 'Interest in CS as a Major Drops' was "as a Major What???"
Then I stopped and thought again, and my second reaction was "Fair enough; I don't see why any army ranks should be particularly interested in it."
Just thought you'd like to see how some of this reads from the other side of the Pond...
One impact I wouldn't be surprised to see is a little more attention paid to those disclaimers. If some folks do get burned by this, then the legal boilerplate which most people currently ignore might start to get read and questioned a bit.
And maybe, once people see just how little protection they have, they might realise that in practice, it doesn't have much more protection than a lot of non-commercial software (OSS &c). Which would be a Good Thing (tm) for most of us, and a serious own goal for MS.
Indeed. For me, the most important thing to remember about UML, and other methodologies, is this: They are tools to be used, not rules to be followed. Too many PHBs (and colleagues) don't seem to understand this.
The most important thing for a document is to communicate. UML is a very good way to communicate that sort of information (when everyone understands it). But it's not the only way. Use whatever's best. If a few lines of text on a scrap of paper, or an ad-hoc diagram you've just invented, will communicate better (with your memory, with your immediate colleagues, and with anyone who might be maintaining the system in future), then by all means use it! Anyone who insists on UML or whatever for the sake of it is missing the point.
The main problem with these methodologies is that there's no way to force people to think clearly. You can encourage it, certainly; you can make it easier to do, easier to communicate, and easier to spot its absence; but you can't force it. Following the procedure is no guarantee of clear thinking -- and it's that clear thinking which gets projects designed and built.
he saw each incarnation of H2G2 as a different entity in its own right and felt no compunction to translate perfectly between mediums.
Yes -- and no.
It's true that the different versions showed different events; they had different chronologies and plotlines; they introduced new characters and situations; they used different devices and features of each medium.
But they were largely consistent. Where characters appeared in different versions, they behaved in the same sorts of ways, had the same manner of speaking and the same outlook on life. Where situations were copied, they generally went the same way, with very similar dialogue, setting, and outcome.
And even more important than this is consistency of tone. Each version has the same slightly twisted, cynical, alienated [sic] outlook on life. Each displays a certain intelligence, a fascination with wordplay and a tendency to go off at tangents. Each has characters being caught up in bizarre events beyond their control, with The Guide as a smug but knowledgeable companion. Each has an undefineable but quintessential English sensibility.
It was these things that bound all the different versions together. They may not all have mentioned towels, Disaster Area or junk mail, but they were undeniably different aspects of the same entity, whether you listened to them, watched them, read them, dried yourself off with them, or typed at them in increasing frustration.
So while the movie will undoubtedly be different from all the other version, it should also be the same on some fundamental level. I've avoided seeing the trailer and the more revealing reviews, but the feeling I get from all that I've heard is that, while the movie may feature the same names and events as the others, and while DNA may have been involved in some way as a writer, it doesn't feel like Hitch-Hiker's. And that, more than any inclusion or exclusion of favourite events or lines, is what will depress me most.
I'd be very happy to be proved wrong. But I'm not optimistic.
Stuff Sonic and Zelda -- anyone here remember some of the great music accompanying some BBC Micro games? Crazee Rider, Dunjunz, Icarus, and FireTrack all had great original music that was worth listening to on its own, and pushed the little sound chip to its limits. (Most were also great games, too, but I was never a particularly avid game player.)
Not an impossibility IMO. But it would take a special sort of actress. (Or must we be politically correct and say 'female actor' now?)
I think that the crucial characteristic of the doctor is authority. He can be serious, funny, dour, cheerful, young, old, fat, thin, whatever, but you need the feeling that he knows what's going on, that he can put things right. But for that he needs authority, leadership, strength of character, intensity.
I think in general it'd be harder for a woman to pull that off, but I'm sure there are some actresses who could. (Probably a slightly older one; authority tends to go with age in women just as in men.) Helen Mirren, for example, springs to mind as someone who might be good. Even someone like Jennifer Saunders might be interesting in the role.
Mind you, my first choice would have to be Alan Rickman...
That does seem to be a common view, at least in the industry.
The argument is that while an advert may annoy the hell out of you now, people still remember the brand/product name -- and they don't associate it with the annoyance. Later on, when they're choosing a product, all they remember is that one name is more familiar than another, and so they're more likely to choose it.
Now, I don't know how true that argument is. But it doesn't seem wholly implausible to me (expert that I'm not). And even if it only has an element of truth, it's still a very worrying and ill-boding element...
I see the point, but it's honestly something I've never had a problem with. Well, maybe once... But hardly the sort of thing to outweigh the disadvantages of braces I can't match up easily (which does cause me grief from time to time, and for me has a much greater effect on code readability).
In hindsight, perhaps it would be better for C and the C-like languages to disallow an empty conditional or loop body, and to require either a (non-empty) statement or a block. Even in the very rare cases when an empty conditional or loop body makes sense, I'm always careful to make it obvious by putting the semicolon on a new line and commenting it appropriately.
Oh, yes, xargs is a much better solution than -exec, and I'd still use it for heavy-duty cases. But zsh's globbing is much simpler and more concise, and is just so handy!
Slashdot Mirror
'All the time'? Hardly. In fact, it's extremely rare. I can think of very few cases of plagiarism, and most fall into one (or more) of the following categories:
Of course, it depends what you mean by 'ripping off', but for me that would need: trying to pass off someone else's work as your own, profiting from someone else's work without adding anything significant to it, or using a new work to bring the original into disrepute. And I can't think of a single occurrence of any of those in the classical music world.
But then, all this is moot anyway, because none of the sorts of copyright we're talking about would usually have applied then:
- Copyright in the music material itself. Back then, this probably wouldn't have lasted for nearly a century after the composer's death...
- Print copyright -- in an edition of the printed score. If you're creating new music, it will by definition need its own edition in print, so there's no infringement there.
- Mechanical copyright -- in a recording of the music. While an awful lot of people would be hugely interested to hear how classical works were first performed, not many recordings survive from those times...
So I don't think you can't really compare any of that with the sort of 'ripping off' we see today.Personally, I don't see the need to make organisations a special case. Wouldn't it be simpler -- and express the purpose better -- just to say that whoever gets to use the software must also be able to get the source, whether they're inside an organisation or not?
But that doesn't scale directly to an entire filesystem.
For one thing, iTunes is handling just one sort of file: music. It may play AIFFs, WAVs, MP3s, AACs, and ALEs, but they're fundamentally holding the same sort of data, and -- more importantly -- have the same kind of metadata. They all have lengths, names, last played dates, &c. And most have artist, track number, &c. So keeping track of that metadata is easy -- you store the same stuff for each file.
But on a filesystem you have umpteen types of file, with umpteen types of metadata, so you need to cope with each file having a different type of metadata. Which isn't easy. (That's why it's really impressive that Apple seem to have managed it efficiently.)
OTOH, there's one great idea we could pinch. We've talked about Smart Folders, which are the filesystem equivalent of Smart Playlists. But iTunes also has (dumb) Playlists, which are the equivalent of filesystem folders. iTunes dumb playlists are different, though: a track can be in more than one playlist, or it can be in none (other than your 'whole library' one). And I think that would work wonderfully on a filesystem, solving most of the problems people are mentioning here.
You could use dumb folders just like at present, with each file in exactly one. Or you could put a file into two different folders at once, which would remove the need for aliases or symbolic links. You might even be able to get rid of the Trash, too -- removing a file from a folder wouldn't delete it, and if you wanted to you could tell it to physically delete all files that aren't in any folders.
The one thing that the iTunes-model folders wouldn't have is nesting, but I can't see any problems adding that. Then you'd have a model where smart folders and dumb folders could coexist neatly on a filesystem, giving all the benefits of both an iTunes-like repository and a traditional filesystem, and lots more!
Quick, wait here while I dash off to the Patent Office...
The second is obvious: the OS automatically indexes everything written to the disk, no matter how (i.e right down at the FS level). Because the index is always up-to-date, searches are immediate and quick.
But the first isn't so obvious. To find what to index on, it's not just searching the data for text strings. Instead, it understands about different file types, and extracts metadata from the file contents using that knowledge. It knows about text files, HTML, Word docs, PDFs, emails, JPEGs, MP3s, MPEGs, and most other common types of file. And app writers can tell it about their own filetypes too, via an API.
This differs fundamentally from the BeOS/etc. model you describe because the metadata is part of the file datastream, not separate from it. That may seem non-ideal, but it has several major advantages today: you can move or copy files with any tool, across all existing filesystems and OSs, without losing that metadata. It doesn't need to be stored in a special filesystem. And most file creators and editors, on all OSs, already understand and write it, so you can share files with non-Spotlight-aware apps on Macs and other machines, and have them all using the same metadata.
It means I can download an MP3, and as soon as I write it to disk, Spotlight reads the ID3 tags and indexes them. Ditto practically any type of file. And all that's here working right now, without the major changes (filesystems, apps, OSs, transfer protocols, &c) that external metadata would need.
At present, the UI for this is very simplistic. But you can bet that more powerful searching will soon be available, if not from the Finder then via other apps.
I don't think it was just the lock-out that harmed MD, though. It also suffered from:
- bad timing (being released before it was ready, to fight DCC, and so gaining an unfair reputation for bad sound quality),
- bad marketing (or indeed any marketing),
- and a completely artificial distinction between consumer and pro-level MD (which they made incompatible and ludicrously expensive).
But lock-out (being unable to access the compressed stream, or access the uncompressed stream faster than real-time, as well as the Copyright Management System) was also part of it. And though they're releasing that slowly, it's too little too late -- with the rise of HD and flash players, MD's window of opportunity is fast closing.Shame, coz it was a neat technology that could have ruled for about a decade.
Erm, he's dead. But maybe they can recreate him somehow?
Hey, how about a holographic Kirk! Every ship should have one!!!
Actually, 'virii' is based on flaws in understanding the English language that common users don't know about. But that doesn't stop it from spreading...
For example, as a Mac OS X user, when I discovered a problem in the MSDOS-format volume handling (specifically, a minor incompatibility with CF cards that had been used on EPOC/Symbian OS), I was able to use the Darwin source to fix it myself. I downloaded and searched the relevant source code, instrumented/recompiled/ran a few user-land programs, found the problem, fixed and tested it, and then submitted it to Apple, who (after a nice chat with one of their engineers) put it into Darwin 7 and Mac OS X 10.3. It was hardly a major change, just 3 or 4 lines IIRC, but I'd not have been able to do it without Darwin's source code.
The more advanced the mathematics, the less you dirty your hands dealing with actual numbers. It's all abstractions: algebraic structures such as rings, fields, and prime ideals; vector spaces, manifolds, and topological spaces; functions, functors, and operators; and though objects like vectors and tensors may look like arrays of numbers, they're really something far more deep and mysterious. And even when you do deal with actual numbers, chances are they're complex, transcendental, and/or transfinite.
So if you're one of those kids I hear about who images that a maths degree consists of learning how to divide 17-digit numbers, I'm afraid I have to disillusion you!
Anyway, back to the plot. One description of maths I rather like is 'the science of patterns', which seems to capture the spirit of the thing reasonably well for me.
(* Far too few people get that one...)
I can't speak for too many, but I'm a member of a Baptist church here in England, and I know people from several other local churches (Baptist, Methodist, Brethren, Elim, &c); I'd guess that very very few take the literal creationist position. I certainly don't. I think 'Baptist' means something slightly different here from what it does in the southern US...
But it's not the simple yes/no question that some seem to be assuming. To take every word of the Bible absolutely literally, you'd have to accept not only that the universe was created in exactly 144 hours, but that there actually existed a man with a plank in his eye, and that St Paul actually looked at everything in a mirror ('through a glass darkly').
On the other hand, if you say you don't take every word of the Bible literally, you're then placing yourself in the same category as people who take practically none of it literally, who practise pick-n-mix religion and don't believe that there was ever an actual person called Jesus who did any of the things that were written... and I wouldn't call those people 'Christians'!
So it can get very hard to define terms here.
My view is that you have to understand the intent of the various Bible writers. Some parts were clearly not meant literally: poetic passages in the psalms, figures of speech, reports of dreams and visions, parables and stories. Other parts clearly were. And in most cases, the difference is made fairly clear from the context. But to understand which is which, we need we need to apply our wisdom and intelligence -- things which seem to be in short supply in some parts of the world!
Obviously, being a work PC, there's a lot of home-use type stuff which I haven't used. But even with just Notes, JBuilder, ClearCase, and a couple of other apps, there are still tons of little things which I miss.
A few examples: in the OS X, there's a single keystroke to close the current window/pane/tab (Cmd+W) -- in XP, it varies; sometimes, there's no shortcut at all. (Ditto Find again, and umpteen other common functions.) In OS X, if you have some highlighted text, pressing right arrow will leave the cursor at the end of it; on XP, sometimes it leaves it one character from the left of the selection. In OS X, pressing the down arrow on a single-line text field takes you to the very end; in XP, sometimes a Ctrl+combination will do the job, and other times you can't. In OS X, almost all multi-line text fields will use the system spellchecker, underlining unrecognised words &c if set to do so. (For example, it's doing so right now as I type this in Safari.) Whereas in XP, some apps have their own spellcheckers, each with its own dictionaries, keystrokes, options, &c; others have none at all. Even with ClearType turned on, I find XP text gritty and harder to read than the nice smooth elegant Mac fonts -- where everything, including menus, captions, labels, &c are all smoothed, as are icons, buttons, and everything else.
Now, taken singly, each of these points probably sounds petty and unimportant. But there are hundreds of these annoyances. And what they add up to is clumsiness, awkwardness, the feeling that it's getting in the way all the time. I hate to reuse a catchphrase, but it's true: Mac OS X just works -- it does what you expect, it's consistent, it gets out of your way and lets you get on with things.
Of course, it has many pretty major features, too. But don't underestimate the little things.
Anyway, it's this: Make as much as possible obvious from the code itself. And comment everything else.
It's not really about the volume of comments; it's about their content. You should usually be able to see the low-level of what the code is doing, and how; comments on that are not only superfluous, but their redundancy makes them actively dangerous when they don't get modified along with the code. What's usually much harder to see is the big picture: why it's doing it, and how that relates to the rest of the system.
As a result, comments tend to be more important at the top of classes/methods/functions/procedures than in the nitty-gritty, because that's where the high-level info fits. Literate systems, especially JavaDoc, are good at encouraging that sort of comment, but there are no silver bullets: it's down to the developer thinking about the code, and (most importantly) thinking about the poor sod having to maintain it in a few years' time. I think you really need to have been in that position in order to fully appreciate what comments should be.
Oh. I only use two FireWire devices -- my iPod dock, and a CF reader -- and neither have pass-through. OTOH, I used to have a CD writer, which did have it, so maybe I've just been unlucky in that respect.
So the unit has 3 FireWire ports, of which one has to be connected to the Mac; leaving two. But don't you also lose one of the Mac's own ports too, at the other end of the cable? So the net gain is only one extra port available?
Then I stopped and thought again, and my second reaction was "Fair enough; I don't see why any army ranks should be particularly interested in it."
Just thought you'd like to see how some of this reads from the other side of the Pond...
Nah, that happened the other week, when I put Wikipedia on my Psion...
And maybe, once people see just how little protection they have, they might realise that in practice, it doesn't have much more protection than a lot of non-commercial software (OSS &c). Which would be a Good Thing (tm) for most of us, and a serious own goal for MS.
The most important thing for a document is to communicate. UML is a very good way to communicate that sort of information (when everyone understands it). But it's not the only way. Use whatever's best. If a few lines of text on a scrap of paper, or an ad-hoc diagram you've just invented, will communicate better (with your memory, with your immediate colleagues, and with anyone who might be maintaining the system in future), then by all means use it! Anyone who insists on UML or whatever for the sake of it is missing the point.
The main problem with these methodologies is that there's no way to force people to think clearly. You can encourage it, certainly; you can make it easier to do, easier to communicate, and easier to spot its absence; but you can't force it. Following the procedure is no guarantee of clear thinking -- and it's that clear thinking which gets projects designed and built.
Yes -- and no.
It's true that the different versions showed different events; they had different chronologies and plotlines; they introduced new characters and situations; they used different devices and features of each medium.
But they were largely consistent. Where characters appeared in different versions, they behaved in the same sorts of ways, had the same manner of speaking and the same outlook on life. Where situations were copied, they generally went the same way, with very similar dialogue, setting, and outcome.
And even more important than this is consistency of tone. Each version has the same slightly twisted, cynical, alienated [sic] outlook on life. Each displays a certain intelligence, a fascination with wordplay and a tendency to go off at tangents. Each has characters being caught up in bizarre events beyond their control, with The Guide as a smug but knowledgeable companion. Each has an undefineable but quintessential English sensibility.
It was these things that bound all the different versions together. They may not all have mentioned towels, Disaster Area or junk mail, but they were undeniably different aspects of the same entity, whether you listened to them, watched them, read them, dried yourself off with them, or typed at them in increasing frustration.
So while the movie will undoubtedly be different from all the other version, it should also be the same on some fundamental level. I've avoided seeing the trailer and the more revealing reviews, but the feeling I get from all that I've heard is that, while the movie may feature the same names and events as the others, and while DNA may have been involved in some way as a writer, it doesn't feel like Hitch-Hiker's. And that, more than any inclusion or exclusion of favourite events or lines, is what will depress me most.
I'd be very happy to be proved wrong. But I'm not optimistic.
Stuff Sonic and Zelda -- anyone here remember some of the great music accompanying some BBC Micro games? Crazee Rider, Dunjunz, Icarus, and FireTrack all had great original music that was worth listening to on its own, and pushed the little sound chip to its limits. (Most were also great games, too, but I was never a particularly avid game player.)
I think that the crucial characteristic of the doctor is authority. He can be serious, funny, dour, cheerful, young, old, fat, thin, whatever, but you need the feeling that he knows what's going on, that he can put things right. But for that he needs authority, leadership, strength of character, intensity.
I think in general it'd be harder for a woman to pull that off, but I'm sure there are some actresses who could. (Probably a slightly older one; authority tends to go with age in women just as in men.) Helen Mirren, for example, springs to mind as someone who might be good. Even someone like Jennifer Saunders might be interesting in the role.
Mind you, my first choice would have to be Alan Rickman...
The argument is that while an advert may annoy the hell out of you now, people still remember the brand/product name -- and they don't associate it with the annoyance. Later on, when they're choosing a product, all they remember is that one name is more familiar than another, and so they're more likely to choose it.
Now, I don't know how true that argument is. But it doesn't seem wholly implausible to me (expert that I'm not). And even if it only has an element of truth, it's still a very worrying and ill-boding element...
In hindsight, perhaps it would be better for C and the C-like languages to disallow an empty conditional or loop body, and to require either a (non-empty) statement or a block. Even in the very rare cases when an empty conditional or loop body makes sense, I'm always careful to make it obvious by putting the semicolon on a new line and commenting it appropriately.
Oh, yes, xargs is a much better solution than -exec, and I'd still use it for heavy-duty cases. But zsh's globbing is much simpler and more concise, and is just so handy!