A list like this is difficult to compile. If you included every single film that made an advance in CG, you'd end up with a mile-long list. Since the original poster asked for influential uses of CG, I'm only going to include films that had a big impact on Hollywood and its view and use of CG. Films that, while certianly worthy in their own right, didn't impact Hollywood in regards to their use of CG are excluded from my list.
They are: Willow (first film to use morphing) The Abyss (water tentacle) T2: Judgement Day (T-1000; was more than just the standard 2D morph) Jurassic Park (dinosaurs) Forrest Gump (Various invisible 2D effects, digital removal of Gary Sinise's legs the most notable and most well done) Titanic (realistic CG water, CG stunt doubles) The Lord of the Rings: The Two Towers (Gollum)
I'm intentionally excluding movies like Tron and The Last Starfighter, because they weren't very influential. Tron bombed, The Last Starfighter broke even, and more importantly nobody "Ooh"'ed and "Aah!"'ed their use of CG. I'm not saying that the CG in those movies wasn't done well, just that it didn't influence many people.
Except that the plant wouldn't activate until it was out of Earth's orbit, possible not even until it landed safely on Mars. As long as the plant wasn't activated, an explosion during liftoff probably wouldn't release much radiation.
You're also missing the point. If 99% of Windows programmers didn't include an uninstaller, you wouldn't blame Windows.
Blaming Linux for program authors not including an uninstaller is stupid. The functionality for uninstallers is there. Blame the programmers for not using it.
It sounds to me like he just plea-bargained. He plead guilty in return for reduced charges.
As others have mentioned, there's no way the prosecution would've accepted anything less. If he didn't plead guilty, *bam* he's declared an enemy combatant and held indefinately without being charged.
Yes, but he also claimed that he didn't want to have to log out just to be able to unmount the drive. The only reason that I can think of why he'd have to do that is if he's using the command line and is in the directory where the CD-ROM gets mounted (in which case, unmounting won't work until you change to a directory that isn't on the CD).
Then blame the person putting together the releases for that program, not Linux.
If somebody didn't build the uninstaller for a Windows program, you wouldn't blame Windows, would you?
And I find that the number of programs that don't support "make uninstall" to be somewhat less that 99%.
Remember, if you deleted the source after you installed the program, just re-unpacking the source archive isn't enough. You've got to re-run./configure, and give it the same options as when you installed the program.
I've used RedHat since 6.0 (my current system is RH 8). RPM knows exactly what packages (down to the version number) that it depends on. I haven't used Slackware since something like version 7, so I don't remember how the package system was.
The problem you mentioned in your last paragraph is a problem with the guy who built the package, not RPM.
And how many dependencies just depends on the way the packages were built. It's entirely possible to build an RPM-based distro that only has a handful of packages on the CD. The reason this isn't done is so that the user can have more control over what's installed on their system and what isn't. Yes, this results in more packages being needed, but I don't see why that is a bad thing.
The reason your problem was the fault of the package builder is this: Let's say program X needs package Y version 0.95. Now, if someone builds an RPM for program X, but has package y version 1.0 installed, then RPM (having no way of knowing what the real minimum required version for Y is) will think that the program requires package Y 1.0 since that's what it was built with. The package builder should have known that program X only needed package Y 0.95 and built the package for X using that (unless there was some critical flaw in Y 0.95 that made building with Y 1.0 acceptable, or Y 1.0 is what came on the distro's CD).
And of course it doesn't have anything to do with the underlying code. It's entirely an issue with the person building the packages and how they decide to split things up.
The eject button just sends a signal to the OS that the user wants to eject the CD if I'm not mistaken. That's why the OS can prevent the user from opening the drive when the drive is mounted.
cd [some directory besides/mnt/cdrom] umount/dev/cdrom (or umount/mnt/cdrom if you use Mandrake)
Jesus Christ, this has nothing to do with Linux problems. It has to do with you and a lack of common sense. Not letting you unmount a drive if a program is using it is so that Linux can maintain internal consistency.
If your using the CLI and are currently in/mnt/cdrom, just "cd $HOME" before unmounting. Again, it's an internal consistency thing, and a pretty obvious one at that.
I'm not trying to flame, but Jesus Christ it took you six months to figure out that using the distro's packages whenever possible would result in fewer problems?
You would think that the reason for having all the nearly-the-same-but-with-small-changes filenames would be obvious: src means source code, not binary yellowdog means its meant for Yellow Dog Linux users (it might not work on other distros) ppc means its a binary built for PowerPC processors i386 means its a binary built for i386 and later processors i586 means its a binary built for i586 and equivalent or later processors mdk means its meant for Mandrake users
On Windows the reason there's a website with one clearly marked binary or zip is because there's only one Windows distribution, and that distribution only runs on one series of processors.
And the vendor websites usually do tell what packages are for what distro/CPU. RPMfind isn't a vendor website. Try the XMMS-Crossfade website.
Just cd to the directory containing the source code (if you deleted it after the install, unpack the archive again, and then run./configure using the same options you used when you installed the software), followed by "make uninstall" (you might have to "su" first, depending on where you installed the software).
1. the inability to cleanly uninstall software that has been installed with the usual configure/make/make install incantation
From the source directory: su make uninstall exit
If you deleted the source directory after you installed the software: Unpack the archive Run./configure again, using the same parameters as you did when you installed the software. Then go back and perform the whole "make uninstall" thing as listed above.
RPM does a pretty good job of handling dependencies (i.e. knowing what other packages package X depends on). The problem is, if one of the dependencies isn't installed, RPM (the package manager, not the file format) doesn't know where to find the package it needs to resolve that dependency.
Prior to RedHat 8's retarded RPM GUI, RedHat shipped with a RPM frontend that was actually pretty smart about dependencies. If package X depended on package Y, and package Y wasn't already installed, the frontend would mark package Y for installation as well (provided that it knew where to get package Y). Why RedHat stopped shipping that program is beyond me. Actually, I know EXACTLY why: they're trying to beat Microsoft at the "dumb down the interface" game.
Huh? I've never bought a Linux book (lie; I bought a book about the Linux API once, but that's it).
Most distros come with pretty good documentation. If printed documentation is what you need, then you should be buying boxed copies of whatever distro you use anyway. Once you get everything installed, there's always RedHat's documentation CD, which has guides for just about everything (customization, security, etc.)
Only GNU tar handles compressed files. IRIX's tar, for example, does not. And all GNU tar does is hand the files off to compress, gzip, or bzip2, which is what it should do (so that updates to compress, gzip, or bzip2 don't require updates to tar).
If you have to rename the file to.gz, it probably isn't GZIP compressed.
Also, the last time I checked, both tar and gzip could handle.tgz files just fine.
gunzip -c sends the uncompressed file to stdout so that you can use it with non-GNU versions of tar, yes? IOW "gunzip -c some_file.tar.gz | tar xvf -".
If you need to get at the contents of a.tgz,.tar.gz, or.tar.bz2, don't try uncompressing and then untarring as separate steps. Just do "tar -zxvf archive" for.tar.gz and.tgz files, and "tar -jxvf archive" for.tar.bz2 files.
And the reason gzip only supports one file type (.tgz and.tar.gz) is because it only supports GZIP compression and needs to stay small so it can fit in intial ram disks.
The reason that wildcards are expanded by the shell is because it's easier that way. If the shell didn't expand wildcards for you, every single command-line program would have to include code to do wildcard expansion (a huge waste of time and resources, another potential spot for bugs, and another potential spot where two programs don't have the same interface).
DOS and Windows do it your way. It really sucks.
And no, the "*>" instead of "*." mistake is not easy to make if you're actually paying attention to what you're typing.
As for "rm -i", the only time I've heard of it being used is when a distro has "rm" aliased to "rm -i" for root. And you should be extra careful when doing things as root.
You shouldn't be storing anything but directories in/
On my system, the kernel and friends live in/boot (nothing in / except directories IIRC), and if I tried to do a "rm *" or even "rm -f *", rm would just complain about not being able to delete the directories and exit.
And, on my RedHat 8 system, if you try to use rm as root (which should be the only way a "rm *" in / would work), it asks for confirmation of every file you delete unless you specify the -f option.
show of hands: how many of you have ever typed 'rm -r *>class,' or similar meaning for the '>' to be a '.'
I did something similar once. You know what I learned? That making sure the command will do what I want it to do BEFORE I hit the enter key is a good idea, and a strong argument for learning to touch-type (so you can see what you type as you type it).
On any sane operating system, rm should be able to tell what command-line was passed to it so that it could decide to bring up a prompt "you are about to empty this directory. Is that ok? [y/n]"
FYI, unless you give it the -r option, rm won't delete a directory.
And no, doing what you suggest is a bad idea. Just handing the program the "file.*" instead of the shell expanding it to "file.1" "file.2" "file.3" is what made writing command-line utilities suck so badly in the DOS days (and it still does, because Windows does this too), because you had to write the code to parse wildcard characters yourself (and make sure they corresponded to actual files).
show of hands again: tar. ever type 'tar cvf myarchive' and meant the character right next to c, 'tar xvf myarchive'
Show of hands again: how many people actually make sure what they're about to execute actually does what they want it to do? These are the kind of mistakes that hunt-and-peck typists make because they aren't looking at the screen when they type.
And, unless I'm mistaken, tar would just complain about being unable to create an empty archive and exit (leaving your archive untouched), since you didn't specify any files to insert.
Slashdot Mirror
As an IRIX user, this can't be good. Fuck.
A list like this is difficult to compile. If you included every single film that made an advance in CG, you'd end up with a mile-long list. Since the original poster asked for influential uses of CG, I'm only going to include films that had a big impact on Hollywood and its view and use of CG. Films that, while certianly worthy in their own right, didn't impact Hollywood in regards to their use of CG are excluded from my list.
They are:
Willow (first film to use morphing)
The Abyss (water tentacle)
T2: Judgement Day (T-1000; was more than just the standard 2D morph)
Jurassic Park (dinosaurs)
Forrest Gump (Various invisible 2D effects, digital removal of Gary Sinise's legs the most notable and most well done)
Titanic (realistic CG water, CG stunt doubles)
The Lord of the Rings: The Two Towers (Gollum)
I'm intentionally excluding movies like Tron and The Last Starfighter, because they weren't very influential. Tron bombed, The Last Starfighter broke even, and more importantly nobody "Ooh"'ed and "Aah!"'ed their use of CG. I'm not saying that the CG in those movies wasn't done well, just that it didn't influence many people.
Actually, it was animated by ILM. The people who did the animating (the entire ILM CG division at the time) broke off and formed Pixar.
Except that the plant wouldn't activate until it was out of Earth's orbit, possible not even until it landed safely on Mars. As long as the plant wasn't activated, an explosion during liftoff probably wouldn't release much radiation.
No. At least, not in the US.
Billybob's Medical Center. Stand in the center of the circle. It's the same spelling and the same word here in the states.
You're also missing the point. If 99% of Windows programmers didn't include an uninstaller, you wouldn't blame Windows.
Blaming Linux for program authors not including an uninstaller is stupid. The functionality for uninstallers is there. Blame the programmers for not using it.
It sounds to me like he just plea-bargained. He plead guilty in return for reduced charges.
As others have mentioned, there's no way the prosecution would've accepted anything less. If he didn't plead guilty, *bam* he's declared an enemy combatant and held indefinately without being charged.
Yes, but he also claimed that he didn't want to have to log out just to be able to unmount the drive. The only reason that I can think of why he'd have to do that is if he's using the command line and is in the directory where the CD-ROM gets mounted (in which case, unmounting won't work until you change to a directory that isn't on the CD).
Then blame the person putting together the releases for that program, not Linux.
./configure, and give it the same options as when you installed the program.
If somebody didn't build the uninstaller for a Windows program, you wouldn't blame Windows, would you?
And I find that the number of programs that don't support "make uninstall" to be somewhat less that 99%.
Remember, if you deleted the source after you installed the program, just re-unpacking the source archive isn't enough. You've got to re-run
I've used RedHat since 6.0 (my current system is RH 8). RPM knows exactly what packages (down to the version number) that it depends on. I haven't used Slackware since something like version 7, so I don't remember how the package system was.
The problem you mentioned in your last paragraph is a problem with the guy who built the package, not RPM.
And how many dependencies just depends on the way the packages were built. It's entirely possible to build an RPM-based distro that only has a handful of packages on the CD. The reason this isn't done is so that the user can have more control over what's installed on their system and what isn't. Yes, this results in more packages being needed, but I don't see why that is a bad thing.
The reason your problem was the fault of the package builder is this: Let's say program X needs package Y version 0.95. Now, if someone builds an RPM for program X, but has package y version 1.0 installed, then RPM (having no way of knowing what the real minimum required version for Y is) will think that the program requires package Y 1.0 since that's what it was built with. The package builder should have known that program X only needed package Y 0.95 and built the package for X using that (unless there was some critical flaw in Y 0.95 that made building with Y 1.0 acceptable, or Y 1.0 is what came on the distro's CD).
And of course it doesn't have anything to do with the underlying code. It's entirely an issue with the person building the packages and how they decide to split things up.
The eject button just sends a signal to the OS that the user wants to eject the CD if I'm not mistaken. That's why the OS can prevent the user from opening the drive when the drive is mounted.
cd [some directory besides /mnt/cdrom] /dev/cdrom (or umount /mnt/cdrom if you use Mandrake)
/mnt/cdrom, just "cd $HOME" before unmounting. Again, it's an internal consistency thing, and a pretty obvious one at that.
umount
Jesus Christ, this has nothing to do with Linux problems. It has to do with you and a lack of common sense. Not letting you unmount a drive if a program is using it is so that Linux can maintain internal consistency.
If your using the CLI and are currently in
I'm not trying to flame, but Jesus Christ it took you six months to figure out that using the distro's packages whenever possible would result in fewer problems?
You would think that the reason for having all the nearly-the-same-but-with-small-changes filenames would be obvious:
src means source code, not binary
yellowdog means its meant for Yellow Dog Linux users (it might not work on other distros)
ppc means its a binary built for PowerPC processors
i386 means its a binary built for i386 and later processors
i586 means its a binary built for i586 and equivalent or later processors
mdk means its meant for Mandrake users
On Windows the reason there's a website with one clearly marked binary or zip is because there's only one Windows distribution, and that distribution only runs on one series of processors.
And the vendor websites usually do tell what packages are for what distro/CPU. RPMfind isn't a vendor website. Try the XMMS-Crossfade website.
Just cd to the directory containing the source code (if you deleted it after the install, unpack the archive again, and then run ./configure using the same options you used when you installed the software), followed by "make uninstall" (you might have to "su" first, depending on where you installed the software).
1. the inability to cleanly uninstall software that has been installed with the usual configure/make/make install incantation
./configure again, using the same parameters as you did when you installed the software.
From the source directory:
su
make uninstall
exit
If you deleted the source directory after you installed the software:
Unpack the archive
Run
Then go back and perform the whole "make uninstall" thing as listed above.
apt-rpm
The apt tools for RPM distros.
RPM does a pretty good job of handling dependencies (i.e. knowing what other packages package X depends on). The problem is, if one of the dependencies isn't installed, RPM (the package manager, not the file format) doesn't know where to find the package it needs to resolve that dependency.
Prior to RedHat 8's retarded RPM GUI, RedHat shipped with a RPM frontend that was actually pretty smart about dependencies. If package X depended on package Y, and package Y wasn't already installed, the frontend would mark package Y for installation as well (provided that it knew where to get package Y). Why RedHat stopped shipping that program is beyond me. Actually, I know EXACTLY why: they're trying to beat Microsoft at the "dumb down the interface" game.
Huh? I've never bought a Linux book (lie; I bought a book about the Linux API once, but that's it).
Most distros come with pretty good documentation. If printed documentation is what you need, then you should be buying boxed copies of whatever distro you use anyway. Once you get everything installed, there's always RedHat's documentation CD, which has guides for just about everything (customization, security, etc.)
SCCS - Source Code Control System.
Many man pages offer examples.
But why would you type "man help"?
Only GNU tar handles compressed files. IRIX's tar, for example, does not. And all GNU tar does is hand the files off to compress, gzip, or bzip2, which is what it should do (so that updates to compress, gzip, or bzip2 don't require updates to tar).
If you have to rename the file to .gz, it probably isn't GZIP compressed.
.tgz files just fine.
.tgz, .tar.gz, or .tar.bz2, don't try uncompressing and then untarring as separate steps. Just do "tar -zxvf archive" for .tar.gz and .tgz files, and "tar -jxvf archive" for .tar.bz2 files.
.tar.gz) is because it only supports GZIP compression and needs to stay small so it can fit in intial ram disks.
Also, the last time I checked, both tar and gzip could handle
gunzip -c sends the uncompressed file to stdout so that you can use it with non-GNU versions of tar, yes? IOW "gunzip -c some_file.tar.gz | tar xvf -".
If you need to get at the contents of a
And the reason gzip only supports one file type (.tgz and
The reason that wildcards are expanded by the shell is because it's easier that way. If the shell didn't expand wildcards for you, every single command-line program would have to include code to do wildcard expansion (a huge waste of time and resources, another potential spot for bugs, and another potential spot where two programs don't have the same interface).
DOS and Windows do it your way. It really sucks.
And no, the "*>" instead of "*." mistake is not easy to make if you're actually paying attention to what you're typing.
As for "rm -i", the only time I've heard of it being used is when a distro has "rm" aliased to "rm -i" for root. And you should be extra careful when doing things as root.
You shouldn't be storing anything but directories in /
/boot (nothing in / except directories IIRC), and if I tried to do a "rm *" or even "rm -f *", rm would just complain about not being able to delete the directories and exit.
On my system, the kernel and friends live in
And, on my RedHat 8 system, if you try to use rm as root (which should be the only way a "rm *" in / would work), it asks for confirmation of every file you delete unless you specify the -f option.
show of hands: how many of you have ever typed 'rm -r *>class,' or similar meaning for the '>' to be a '.'
I did something similar once. You know what I learned? That making sure the command will do what I want it to do BEFORE I hit the enter key is a good idea, and a strong argument for learning to touch-type (so you can see what you type as you type it).
On any sane operating system, rm should be able to tell what command-line was passed to it so that it could decide to bring up a prompt "you are about to empty this directory. Is that ok? [y/n]"
FYI, unless you give it the -r option, rm won't delete a directory.
And no, doing what you suggest is a bad idea. Just handing the program the "file.*" instead of the shell expanding it to "file.1" "file.2" "file.3" is what made writing command-line utilities suck so badly in the DOS days (and it still does, because Windows does this too), because you had to write the code to parse wildcard characters yourself (and make sure they corresponded to actual files).
show of hands again: tar. ever type 'tar cvf myarchive' and meant the character right next to c, 'tar xvf myarchive'
Show of hands again: how many people actually make sure what they're about to execute actually does what they want it to do? These are the kind of mistakes that hunt-and-peck typists make because they aren't looking at the screen when they type.
And, unless I'm mistaken, tar would just complain about being unable to create an empty archive and exit (leaving your archive untouched), since you didn't specify any files to insert.