I don't know any of the details of the foreign litigation. Are they countries where trademarking of generic terms is allowed?
You might just find that the English word "windows" isn't even a word in these foreign countries/languages, so it could be happily argued that it can be trademarked.
(There are plenty of car names in the UK that are real words in some foreign language (sometimes slang obscenities - which does wonders for exports) and are trademarked in the UK.)
You might then understand why Microsoft are pursuing Lindows in foreign courts and probably hoping that they can destroy them before the US court makes a decision on the Windows trademark in the US.
The best pair programming occurs when you have two equally skilled people whose skill sets overlap but aren't the same.
The worst is when one of the pair is a chimpanzee and the other is expert: you end up with a confused chimpanzee and a suicidal expert. Oh, and no code.
I find pairing works for short stretches, followed by periods where the members of the pair can wander off, do a bit of solo coding/thinking/design, and then join up again when appropriate.
Successful pairing is not a student-teacher relationship - it is best when it is a joining of equals. If you want "teaching", send them on a course.
What you might expect to happen (as it does with, for example, netscape, kde, gnome, anjuta, acrobat, etc) is that the application creates the directory itself on first run.
And many applications do figure out what language you speak, and customise themselves to it (yes, via locale).
And some applications do look at your existing configuration/preferences and use it. (Yes, there should be more.)
But I wouldn't expect any build/install system to do it - it is a runtime thing, and I would expect the application to do it.
Re:Don't flame the devs
on
Mplayer Revisited
·
· Score: 5, Insightful
Once upon a time, many years ago, free software was wild and untamed. When you downloaded a tar-file, it may, or may not, unpack in ".". Sometimes it was a shar(k) and you had to hope it didn't eat any of your files when you ran it.
And then, once you had your nice shiny sources, you could compile it. After, of course, hand editing the Makefile. Oh, and the other one. And, damn, that silly config file. And then you would fix all the compilation problems because it had been developed on a different version of Unix, and used strdup.
But, in those days, men were real men, and hackers were real hackers.
People complained, whinged, sent patches, and things improved.
And then, miracle of miracle, automated configure and build scripts came. There was the perl one, which asked lots of questions that nobody ever knew the answers to. Then there was the GNU configure scripts, which tried out things and found what worked.
And, yea!, verily, time was saved all round the world. Things started to work. Porting to other platforms became simpler. Installation was tamed, and things went were you expected them to.
What I'm trying to get at is: the same argument about "be prepared to do your homework" was used years ago pre-autoconf. Nobody would even think of going back to hand-editing all those Makefiles.
It doesn't take a vast amount of effort to get a sane build and installation process, and the amount of time it saves everyone (including the developers themselves) is massive.
With distros it is less of an issue for mere mortals, but the benefit any open source project will get from being easy to configure and install is that developers who are willing to chase bugs will do so - because it takes no pain to build.
Slashdot Mirror
(There are plenty of car names in the UK that are real words in some foreign language (sometimes slang obscenities - which does wonders for exports) and are trademarked in the UK.)
You might then understand why Microsoft are pursuing Lindows in foreign courts and probably hoping that they can destroy them before the US court makes a decision on the Windows trademark in the US.
tar cvf etc-rc-d.tar /etc/rc.d
I'm glad we have Microsoft to innovate such things for us. Nobody has ever thought of this type of thing before.
The worst is when one of the pair is a chimpanzee and the other is expert: you end up with a confused chimpanzee and a suicidal expert. Oh, and no code.
I find pairing works for short stretches, followed by periods where the members of the pair can wander off, do a bit of solo coding/thinking/design, and then join up again when appropriate.
Successful pairing is not a student-teacher relationship - it is best when it is a joining of equals. If you want "teaching", send them on a course.
And many applications do figure out what language you speak, and customise themselves to it (yes, via locale).
And some applications do look at your existing configuration/preferences and use it. (Yes, there should be more.)
But I wouldn't expect any build/install system to do it - it is a runtime thing, and I would expect the application to do it.
And then, once you had your nice shiny sources, you could compile it. After, of course, hand editing the Makefile. Oh, and the other one. And, damn, that silly config file. And then you would fix all the compilation problems because it had been developed on a different version of Unix, and used strdup.
But, in those days, men were real men, and hackers were real hackers.
People complained, whinged, sent patches, and things improved.
And then, miracle of miracle, automated configure and build scripts came. There was the perl one, which asked lots of questions that nobody ever knew the answers to. Then there was the GNU configure scripts, which tried out things and found what worked.
And, yea!, verily, time was saved all round the world. Things started to work. Porting to other platforms became simpler. Installation was tamed, and things went were you expected them to.
What I'm trying to get at is: the same argument about "be prepared to do your homework" was used years ago pre-autoconf. Nobody would even think of going back to hand-editing all those Makefiles.
It doesn't take a vast amount of effort to get a sane build and installation process, and the amount of time it saves everyone (including the developers themselves) is massive.
With distros it is less of an issue for mere mortals, but the benefit any open source project will get from being easy to configure and install is that developers who are willing to chase bugs will do so - because it takes no pain to build.