More to the point, it doesn't actually qualify as copying. If you read the GPL, it talks about making copies, which the car's manufacturer did. Joe is transferring the copy he received from the manufacturer. He's never copied the software.
Switch to your preferred Unix-like OS (BSD or Solaris is probably
better than Linux for this--most people have heard of Linux) but get
rid KDE, GNOME or any other friendly desktop environment. Instead,
run your preferred window manager (something that looks nothing like
Windows or MacOS is better) and use xterms for all your actual
interactions. Use lynx as your web browser and mutt as your mail
client. (Or if you must use Firefox/Thunderbird, find the most
outlandish and confusing theme and set of extensions you can find.)
Then, when somebody asks to use your laptop, just say "Sure, go
ahead. This runs $FREE_OS, though, which may not be what you're used
to." If they ask for help, tell them which man page they need to
read to get the answer.
After three or four iterations of this, nobody will bother you
anymore.
(Also, it's a good idea to set up a guest account and some way to
to it, just in case you meet somebody who knows Unix. See other posts in this thread for more suggestions.)
I just downloaded it and played with it for a few minutes. Some comments:
I don't think your license actually meets the criteria for
open-source. It isn't clear to me that I legally could create a fork
of Sandbox and distribute it under the same terms. I'd be much
happier if you used a well-known open-source license (e.g. the GPL)
instead.
I also don't how your license claims the copyright of any
submitted changes. A more suspicious mind might think you're trying
to build a base of contributor games that you can then commercialize.
If that isn't your plan, I suggest you change the terms to make that
clear. Once again, using a well-known OSS license would solve the
problem.
Aside from that, I think this is a really neat idea for teaching
kids to think like programmers.
The really nice thing about query-replace and query-replace-regexp is that you can replace almost all items. It's great for cases where, say, you want to replace all uses of variable "count" while leaving the word alone when it's used in a comment.
If you just want to replace everything, you use the non-query versions, replace-string and replace-regexp. That way, you don't need to hold down the 'y' key.
When I googled to see what the vi "." did, I found this, so the answer
is no, but you can download an extension to do it.
But what I was going to say was that there are two options that
I can think of:
If you typed in the command at the M-x or M-: (lisp eval)
prompts, you can always just use the command history and rerun the
command that way.
Alternately, you can repeat the next command by typing C-u
and the number of repetitions followed by the command. So "C-u 75 -"
will draw a row of 75 dashes. You can do more complex things by first
recording a keyboard macro ("C-x (", keystrokes, "C-x )" and then
prefexing the macro eval command ("C-x e") with a repeat count. If
you're afraid of going past a certain point and don't want to
carefully figure out exactly how many times to repeat, you can use
narrow-to-region first.
Those two things, along with query-replace, automates most of my
tasks for me.
The 6502 (or variants thereof) are alive and
well and continue to be used
in the embedded systems world. I don't have time to do a lot of
research right now but a quick perusal of digikey.com shows 8-bit
microcontrollers as low as $3.50 each in quantity while ARMs go for at
least $17. For a $12 computer, that's a huge deal.
(Note: I'm getting these prices from hobbyist suppliers. I have no
doubt that you can get 6502-ish processors for under a buck in
quantity.)
This can be problematic, though, when the directory tree contains files you don't want to search (e.g. images or core files). In that case, the 'find' is useful for selecting only the file types you want to search. Your find/xargs command would do that, though.
I'm also reasonably sure that on modern operating systems, the cost of launching grep is going to be pretty low. Linux forks are fast due to their copy-on-write nature and the OS caches executables in memory for a while after they exit. The upshot is that the first fork/exec will be slow but they'll be pretty fast after that. Maybe not as fast as a 'grep -R' but not enough to worry about.
(Of course, on Cygwin under Windows, that may not be the case.)
Bought a new PC from $BIG_BOX_RETAILER, took it home and plugged it in.
Turned it on.
Clicked the "Okay" button until I got to the screen where I had to read a novel-length license agreement through a 3-by-4 inch scroll window.
Said "bugger this for a lark" in my best fake British accent, inserted my freshly-burned Fedora 8 DVD and power-cycled the machine.
Gleefully formatted the entire disk as ext3 (plus a swap partition, natch) and imagined Vista screaming as I plowed its broken bits under my mighty array of disk heads.
The whole thing was very satisfying and I can type "find . -type f -exec grep some-string {} \; -print" whenever I want and it'll work.
(I'm not trying to bash Windows here--I just like Linux better. I bought the computer as a Linux machine and wanted to see what all the fuss was about and if it was worth keeping a small Vista partition around for a bit. Vista showed me it wasn't pretty quickly but I still have the install CD and license sticker in case I change my mind.)
Saying stuff like "Those of you that like SVN would probably want to
leave the room. Because it's crap too." is very stupid.
I think it's pretty clear that Linus was deliberately being over the
top here. That is, rather than tip-toeing around his (low) opinion of
other SCMs, he made a joke of it and called their developers ugly and
stupid. That seemed pretty clear from both his manner and the
audience's reaction.
However, the blogger who embedded the video appears not to have gotten
the joke. Neither, it seems, have quite a few Slashdot posters.
I'm not in any way defending Microsoft's treatment of Jamie Cansdale
here, but I want to comment on this:
Personally I have a strong feeling that compilers in general should
be free. I don't mean to get all Mac-Fanboi here (I come from a Linux
background), but that's one thing Apple does very nicely. XCode is a
very nice development suite that is entirely free (beer, of course).
Windows (and DotNet) are platforms. Platforms are only valuable if
there is lots of software that runs on them and to get that software,
you need to get developers developers developers developers.
In order to attract lots of developers developers developers
developers, you need to make sure that (among other things):
Decent development tools are available and easy to get.
They come from a wide variety of third-party vendors.
The reasons for 1) are pretty obvious--easy access to tools encourages
people to start programming for your platform. The thing about 2) is
less obvious.
When you develop an application in a particular language or tool,
the time and money you invested in that application lives or dies by
your ability to get up-to-date versions of your toolchain. So if you
wrote your million-line ERP app in Microfoo VisualQuuxbol and Microfoo
goes under, you're pretty much screwed.
If, however, there are other companies that implement Quuxbol for
Windows, you can switch to their compiler and carry on. Your
investment is saved. So to keep developers developers developers
developers writing software for your platform, you need to convince
them that their tool chain isn't going to turn into a pumpkin some day
the way Visual Basic 6 did.
That's why Microsoft kept selling their low-end C compiler for sixty
bucks, even though they could have bundled it with Windows. The cheap
compiler encouraged developers but it also kept the price of a low end
C compiler high enough that their competitors (e.g. Borland) stayed in
business. If they'd given it away, they'd have undercut the other
vendors and run them out of business. (Compilers are frickin'
complicated. Developing and maintaining one as a commercial venture
can be expensive.)
This would have given them a monopoly in development tools but
sabotaged their monopoly in operating systems. Operating systems are
way, way more profitable.
Notice that they didn't start giving away their C compiler until long
after gcc had killed the bare C compilers market for Windows.
So I suspect that their thinking goes something like this:
VSE must be good enough that newbies can start learning DotNet with it.
VSE must not be a valid alternative to any decent third-party development tool.
TestDrive.NET improves VSE and so breaks 2), thus threatening the
DotNet tools market, hence the hammer.
Of course, open-source development tools are a new(-ish) wrinkle on
this that Microsoft doesn't seem to have addressed yet.. I see a
correlation between this and their stock price.
If GNU/Linux was the only operating system that had applications like
Firefox, OpenOffice, VLC, and so on, I think it would be a much more
attractive option than Windows is. Yet, we've ported some of our best
applications to the proprietary Windows platform, and as a consequence
of this there is less incentive for Windows users to become
users of Free Software operating systems.
If you play this game, you'll lose. Microsoft has enough resources to
rewrite every single significant open-source project from scratch.
The moment any application provides a compelling reason for a large
number of users to switch away from Windows, Microsoft will make
sure that it works under Windows or failing that, that there's a
suitable Windows-based clone.
The only competitive advantage Windows has is that it can painlessly
run (most of) the huge base of existing Windows apps. That's all. If
every software company out there decided to port all of their apps to
Linux, the Windows franchise would be dead.
But since that's not going to happen, the best way to support Linux
and F/OSS is to first wean the average user off of their Windows-only
apps. If we can get them to switch from MS-Office to OpenOffice, IE
to Firefox or Opera and Outlook to Thunderbird, then they can switch
to Linux without losing their favourite apps.
And that's why package selection for Windows is a Good Thing.
Wny don't we set up a foundation, funded by donations, to go through Microsoft's patent portfolio and contesting the dodgy ones. Given the nature of software patents, I'm pretty sure we could make most of them go away.
Not really alternate career advice, but maybe you could try starting a
business. Something that's fun and interesting and that you can do on
the side while keeping your day job. The Internet is amazing for that
sort of thing.
If it fails, hey, at least you learned something. And if it works,
you've created a job you like. This would give you an opportunity to
feel around for what else is out there while not giving up your
security.
I'm getting really, really tired of you hammer nuts and your
irresponsible advocacy. If you'd ever been on the receiving end of
drive-by carpentry, you wouldn't be so cavalier. Hammers aren't toys
and they're nothing like TV.
In real life, hammers hurt. The horror of a smashed thumb will stay
with you for the rest of your life. It's not just a case of a few
percussive bangs and then a cut to the next scene. No, hammers leave
a lasting impression.
Also, the constitution is very clear that the right to bear hammers
only applies to well regulated carpentry, not carried in some fanny
pack for "home repairs". That whole "right to arm and hammer" is all
well and good in theory but in practice, the price it imposes on the
rest of us is just too high.
That's an edge case compared to being able to install on top of an
existing file and restart the program at the end - that's really
simple the way things stand. Not so much with exclusive locked files.
If you'd actually read the post you're replying to, you'd know
exactly why this is wrong.
Overwriting a running executable will corrupt the running process.
Recompiling your database server and doing a "make install" while the
server is still running will crash the running server if you're
lucky. If not, you're gonna have to restore the database from
backup.
Proper write-locking would prevent writing to running executables
but it wouldn't keep them from being unlinked. If you delete the
existing executable before installing the new one, everything would
still work, and since you're supposed to do that anyway, you don't
lose anything but gain a certain amount of oops-proofing.
Joel Spolsky advocates dual monitors
a lot. Item 9 in this
article
goes into some detail on this. And here, he mentions the
standard developer setup in passing (toward the end of the article).
If people at your office take him seriously (which you may be able to do just by droping his name in the right way), that might be enough.
First of all, this is completely irrelevant to what I said.
Secondly, it actually would make sense to lock a running executable.
Most advanced operating systems read code pages from the executable.
That is, when they need to make room in RAM, rather than swapping out
parts of the executable, they just toss them. When they need that
part of it back, they just reload it from the executable.
So, if you do something like this while myprog is running:
vi myprog.c
gcc myprog.c -o myprog
there's a good chance that myprog will crash as a result. This is
because gcc overwrites the file "myprog" in place.
If, instead, you do this:
vi myprog.c
rm myprog
gcc myprog.c -o myprog
then you're fine, for the reason the parent described:
Basically, *nix filesystems keep a list of links to a file. The
filesystem doesn't erase the file until there are no more links to it.
Most of the time, a link is a directory name but if there's an open
filehandle to that file or if it is a running executable, that also
links to the file.
The "rm" file unlinks the file from the current directory but because
the program is still running, the file continues to exist, albeit
without a name so the program can keep running.
Of course, if you don't unlink the file before recompiling, gcc
opens the same file for writing and overwrites a new executable into
it. The OS, the next time it needs to page, reads the file from
that but since it's now a different executable, the program
crashes. This used to happen to me all the time before I wised up and
put an "rm" command before the final link in my Makefiles.
But what does this have to do with locking? Not much.
It'd be nice if Linux locked running executables in a manditory way,
but not enough to really be a bother.
And anyway, as I said in the grandparent, *nix locks are (usually)
advisory, not mandatory. Really.
It's in the FineManual.
Slashdot Mirror
More to the point, it doesn't actually qualify as copying. If you read the GPL, it talks about making copies, which the car's manufacturer did. Joe is transferring the copy he received from the manufacturer. He's never copied the software.
Simple:
Switch to your preferred Unix-like OS (BSD or Solaris is probably better than Linux for this--most people have heard of Linux) but get rid KDE, GNOME or any other friendly desktop environment. Instead, run your preferred window manager (something that looks nothing like Windows or MacOS is better) and use xterms for all your actual interactions. Use lynx as your web browser and mutt as your mail client. (Or if you must use Firefox/Thunderbird, find the most outlandish and confusing theme and set of extensions you can find.)
Then, when somebody asks to use your laptop, just say "Sure, go ahead. This runs $FREE_OS, though, which may not be what you're used to." If they ask for help, tell them which man page they need to read to get the answer.
After three or four iterations of this, nobody will bother you anymore.
(Also, it's a good idea to set up a guest account and some way to to it, just in case you meet somebody who knows Unix. See other posts in this thread for more suggestions.)
I just downloaded it and played with it for a few minutes. Some comments:
The really nice thing about query-replace and query-replace-regexp is that you can replace almost all items. It's great for cases where, say, you want to replace all uses of variable "count" while leaving the word alone when it's used in a comment.
If you just want to replace everything, you use the non-query versions, replace-string and replace-regexp. That way, you don't need to hold down the 'y' key.
When I googled to see what the vi "." did, I found this, so the answer is no, but you can download an extension to do it.
But what I was going to say was that there are two options that I can think of:
Those two things, along with query-replace, automates most of my tasks for me.
Can you please provide a link? The most I've ever seen is 4k and that was on a $10 part.
The 6502 (or variants thereof) are alive and well and continue to be used in the embedded systems world. I don't have time to do a lot of research right now but a quick perusal of digikey.com shows 8-bit microcontrollers as low as $3.50 each in quantity while ARMs go for at least $17. For a $12 computer, that's a huge deal.
(Note: I'm getting these prices from hobbyist suppliers. I have no doubt that you can get 6502-ish processors for under a buck in quantity.)
Using the electrical tape will be classed as theft,
Okay, fine. I'll use duct tape instead.
I think you meant 'grep -Rl some-string .'
This can be problematic, though, when the directory tree contains files you don't want to search (e.g. images or core files). In that case, the 'find' is useful for selecting only the file types you want to search. Your find/xargs command would do that, though.
I'm also reasonably sure that on modern operating systems, the cost of launching grep is going to be pretty low. Linux forks are fast due to their copy-on-write nature and the OS caches executables in memory for a while after they exit. The upshot is that the first fork/exec will be slow but they'll be pretty fast after that. Maybe not as fast as a 'grep -R' but not enough to worry about.
(Of course, on Cygwin under Windows, that may not be the case.)
The whole thing was very satisfying and I can type "find . -type f -exec grep some-string {} \; -print" whenever I want and it'll work.
(I'm not trying to bash Windows here--I just like Linux better. I bought the computer as a Linux machine and wanted to see what all the fuss was about and if it was worth keeping a small Vista partition around for a bit. Vista showed me it wasn't pretty quickly but I still have the install CD and license sticker in case I change my mind.)
I read the headline and thought, I bet you that whoever said that doesn't work in banking.
And surprise--I was right!
I just want to say that this is the coolest Slashdot headline I've seen in a while. All it needs is proper capitalization and punctuation:
And for best results, do a Magnus Pike impersonation when reading it.
I think it's pretty clear that Linus was deliberately being over the top here. That is, rather than tip-toeing around his (low) opinion of other SCMs, he made a joke of it and called their developers ugly and stupid. That seemed pretty clear from both his manner and the audience's reaction.
However, the blogger who embedded the video appears not to have gotten the joke. Neither, it seems, have quite a few Slashdot posters.
I'm not in any way defending Microsoft's treatment of Jamie Cansdale here, but I want to comment on this:
Windows (and DotNet) are platforms. Platforms are only valuable if there is lots of software that runs on them and to get that software, you need to get developers developers developers developers.
In order to attract lots of developers developers developers developers, you need to make sure that (among other things):
The reasons for 1) are pretty obvious--easy access to tools encourages people to start programming for your platform. The thing about 2) is less obvious.
When you develop an application in a particular language or tool, the time and money you invested in that application lives or dies by your ability to get up-to-date versions of your toolchain. So if you wrote your million-line ERP app in Microfoo VisualQuuxbol and Microfoo goes under, you're pretty much screwed.
If, however, there are other companies that implement Quuxbol for Windows, you can switch to their compiler and carry on. Your investment is saved. So to keep developers developers developers developers writing software for your platform, you need to convince them that their tool chain isn't going to turn into a pumpkin some day the way Visual Basic 6 did.
That's why Microsoft kept selling their low-end C compiler for sixty bucks, even though they could have bundled it with Windows. The cheap compiler encouraged developers but it also kept the price of a low end C compiler high enough that their competitors (e.g. Borland) stayed in business. If they'd given it away, they'd have undercut the other vendors and run them out of business. (Compilers are frickin' complicated. Developing and maintaining one as a commercial venture can be expensive.)
This would have given them a monopoly in development tools but sabotaged their monopoly in operating systems. Operating systems are way, way more profitable.
Notice that they didn't start giving away their C compiler until long after gcc had killed the bare C compilers market for Windows.
So I suspect that their thinking goes something like this:
TestDrive.NET improves VSE and so breaks 2), thus threatening the DotNet tools market, hence the hammer.
Of course, open-source development tools are a new(-ish) wrinkle on this that Microsoft doesn't seem to have addressed yet.. I see a correlation between this and their stock price.
If you play this game, you'll lose. Microsoft has enough resources to rewrite every single significant open-source project from scratch. The moment any application provides a compelling reason for a large number of users to switch away from Windows, Microsoft will make sure that it works under Windows or failing that, that there's a suitable Windows-based clone.
The only competitive advantage Windows has is that it can painlessly run (most of) the huge base of existing Windows apps. That's all. If every software company out there decided to port all of their apps to Linux, the Windows franchise would be dead.
But since that's not going to happen, the best way to support Linux and F/OSS is to first wean the average user off of their Windows-only apps. If we can get them to switch from MS-Office to OpenOffice, IE to Firefox or Opera and Outlook to Thunderbird, then they can switch to Linux without losing their favourite apps.
And that's why package selection for Windows is a Good Thing.
Wny don't we set up a foundation, funded by donations, to go through Microsoft's patent portfolio and contesting the dodgy ones. Given the nature of software patents, I'm pretty sure we could make most of them go away.
(No, not really.)
Not really alternate career advice, but maybe you could try starting a business. Something that's fun and interesting and that you can do on the side while keeping your day job. The Internet is amazing for that sort of thing.
If it fails, hey, at least you learned something. And if it works, you've created a job you like. This would give you an opportunity to feel around for what else is out there while not giving up your security.
and Microsoft's marketing team would still sell it by the bundles.
Well, the kittens are really bad for your mouse.
3. The Legal Use of Images and Thumbnails
see #2 -- Cease & Desist before lawsuit.
Forget that. You should never ever hotlink someone else's image because they'll be able to replace it with the goatse.cx image.
I'm getting really, really tired of you hammer nuts and your irresponsible advocacy. If you'd ever been on the receiving end of drive-by carpentry, you wouldn't be so cavalier. Hammers aren't toys and they're nothing like TV.
In real life, hammers hurt. The horror of a smashed thumb will stay with you for the rest of your life. It's not just a case of a few percussive bangs and then a cut to the next scene. No, hammers leave a lasting impression.
Also, the constitution is very clear that the right to bear hammers only applies to well regulated carpentry, not carried in some fanny pack for "home repairs". That whole "right to arm and hammer" is all well and good in theory but in practice, the price it imposes on the rest of us is just too high.
Every time I see a headline with "SCO" in it, I expect to see something like,
SCO Chairman Kills Puppies, Twirls Moustache, Laughs Maniacally
Really. It's like this guy read the Geek Villain HOWTO and is meticulously following the instructions.
why? So gcc works better?
No.
That's an edge case compared to being able to install on top of an existing file and restart the program at the end - that's really simple the way things stand. Not so much with exclusive locked files.
If you'd actually read the post you're replying to, you'd know exactly why this is wrong.
Overwriting a running executable will corrupt the running process. Recompiling your database server and doing a "make install" while the server is still running will crash the running server if you're lucky. If not, you're gonna have to restore the database from backup.
Proper write-locking would prevent writing to running executables but it wouldn't keep them from being unlinked. If you delete the existing executable before installing the new one, everything would still work, and since you're supposed to do that anyway, you don't lose anything but gain a certain amount of oops-proofing.
Joel Spolsky advocates dual monitors a lot. Item 9 in this article goes into some detail on this. And here, he mentions the standard developer setup in passing (toward the end of the article).
If people at your office take him seriously (which you may be able to do just by droping his name in the right way), that might be enough.
First of all, this is completely irrelevant to what I said.
Secondly, it actually would make sense to lock a running executable.
Most advanced operating systems read code pages from the executable. That is, when they need to make room in RAM, rather than swapping out parts of the executable, they just toss them. When they need that part of it back, they just reload it from the executable.
So, if you do something like this while myprog is running:
there's a good chance that myprog will crash as a result. This is because gcc overwrites the file "myprog" in place.
If, instead, you do this:
then you're fine, for the reason the parent described:
Basically, *nix filesystems keep a list of links to a file. The filesystem doesn't erase the file until there are no more links to it. Most of the time, a link is a directory name but if there's an open filehandle to that file or if it is a running executable, that also links to the file.
The "rm" file unlinks the file from the current directory but because the program is still running, the file continues to exist, albeit without a name so the program can keep running.
Of course, if you don't unlink the file before recompiling, gcc opens the same file for writing and overwrites a new executable into it. The OS, the next time it needs to page, reads the file from that but since it's now a different executable, the program crashes. This used to happen to me all the time before I wised up and put an "rm" command before the final link in my Makefiles.
But what does this have to do with locking? Not much.
It'd be nice if Linux locked running executables in a manditory way, but not enough to really be a bother.
And anyway, as I said in the grandparent, *nix locks are (usually) advisory, not mandatory. Really. It's in the Fine Manual.