and turning off register_globals, will result in better results.
I couldn't agree more. register_globals really should be off, but often can't be.
In the developement of our PHP application suite we've run into a big problem with the persistance of object trees. Basically, if you put a tree of objects that contain references into the $_SESSION array without register_globals on, when you get them back in another execution cycle the references will be all jumbled up with copies of the objects to boot. For some reason this works fine with the exact same code and register_globals=ON.
Hopefully PHP5 will stablize soon and fix all of this nonsense.
"Moore's law" does not refer to the speed of processors doubling, but that the number of transistors that can be fit into a given area doubling every 18 months or so.
The shrinking of transistor sizes has lead to smaller, cooler, faster, more powerful chips, but the speed increase is just a side effect of the smaller transistors. Were chip engineers more interested in packing more operations each cycle onto a chip, then you would see slower clock speeds with similar densities of transistors on larger areas (with more heat buildup being the speed limiter) -- something akin to the PowerPC chips vs the high-speed Pentiums. Similar densites of transistors and the PPCs actually do more floating-point operations per second (flops) than a Pentium that runs at about twice the clock.
Get application developers for Linux to conform to some standard for app installs and getting people to convert will be alot easier.
Its been tried for years. Good luck. The other problem is that developers don't necessarily have the resources to compile binaries for even all the major distros. However, good documentation (like Apple's PostgreSQL docs linked to in the grandparent) allows people of any knowlege level to get the software working.
Compiling with instructions like "./configure, make, make install" is just an example of a place where the documentation requires knowledge on the part of the reader that the reader has no way to know they need or know how to find out. ESR's piece on CUPS that I linked to, as well as how to set up joysticks under Transgaming's Point2Play (expects a knowlege of what the "joystick name returned by jstest" is), as well as instructions on mounting a Firewire HD (requires knowledge of which line was in portant in a device scan), as well as etc.
The problem isn't compiling, but the expectation in the documentation that the person knows more of the workings of the system than they do.
Actually, granny would have a better chance of success with the various GUI wrappers for apt/yum/etc. Xandros, for instance, puts a link to its "Xandros Networks" apt-GUI right on the desktop. Opening this application shows you a list of new software availible, software installed, and a "shop" section with TuxRacer, Opera, and some other stuff in it. Clicking install (and entering the root password) for any app downloads and installs it with no fuss. Though I haven't used it, the "shop" section is particularly usable, since it has nice graphical icons and more detailed descriptions of each application.
All in all, the apt/yum/etc-GUI install has got to be the most usable system created. Its so much easier than searching for a website that has executable for download, downloading the executable, then clicking through the wizard, selecting an install place, etc. Just click "install" and know that you got the latest version and that apt will update it later along with everything else.
Along similar usability lines, I am currently running Xandros as a pilot to see if it is "mom" (or grandmom) ready as it is advertised as "very user friendly". In the process of this pilot, I've done detailed documentation of every step I've done to get my Xandros fully working. My hope is that these step-by-step instructions will help my various friends who seem interested, but are a bit scared of Linux.
My big problem with Linux documentation in general (and what I am trying to do differently in my own) is the assumptions of knowledge on the part of the reader. My key example is documentation for installing software from source that goes like the following: ----
Download the source. (rest as root)
untar the archive: # tar -xzf someapp.tar.gz
cd to the source directory
#./configure
# make
# make install
----
How many times have you seen instructions like this?
The other comments on the steps mentioned say "Thanks, that works great!" and things like that, but my compile threw errors and didn't work for me.
The problem is, which I learned after 3 years of daily linux use and 5 distros (including FreeBSD), is that you often need to specify options for the "./configure" step, and those option are found by doing "./configure --help". NOBODY EVER MENTIONS THIS! (sorry for use of caps, but this is a pretty huge problem.)
Compounding the problem is that once you do do a "./configure --help", you are given a huge list of options, but have no clue which ones (and what parameters you need to specify) to get your software to compile. Please tell me where I can find this if there is documentation as to a general process for trouble-shooting compile-options, because I have yet to find it.
Instead of the above example, how about some instructions like the following:
--- All steps are done as root (administrator). # is the root prompt of a command-shell, more info.
1. Change to the source-download dirctory: # cd/usr/local/src/
2. Download the source (someapp-1.x.x.tar.gz, where the x's are replaced by the latest version numbers, see http://www.mysite.org/releases/ for the latest version information. # wget ftp://dist.mysite.org/releases/someapp-1.x.x.tar.g z
3. Untar the archive: # tar -xzf someapp-1.x.x.tar.gz
4. Change to the uncompressed source directory: # cd someapp-1.x.x/
5. Configure the installer.
Most systems will need to specify the location of your Perl executable: #./configure --perl=/usr/bin/perl Use the following command to find your Perl executable: # locate perl | grep bin
As CommanderFoxTrot says, wrecking on skis is generally much better than wrecking on pavement/dirt/grass/etc since you generally just slide. Watch the olympic or world cup downhill races and you can see this in action. In the vast majority of falls, the skier will be simply sliding, straight or maybe spinning on the snow with no more harm than bruising/ice-rash.
Injury occurs in one or both of two places: either the skier's skis are still on and catch on the snow, starting a bone/joint/neck-breaking tumble, or the skier runs into some unmovable object before slowing down. Hitting trees, rocks, hay-bales, spectators, snowmobilies or large cliffs at high speed is gennerally detrimental to one's continued membership in the living.
I have seen videos in which a speed skier has fallen at VERY high speed and been ok -- they are going straight on an open, groomed, pitch with nothing to hit. However, as far as I know some have died from high speed falls as well, generally from tumbling.
#1: speed is measured at the rear wheels (for a front-wheel drive). Ever floor your car in mud? The wheels spin, but the speedo doesn't say you're doing 200Mph
On my car, a 93 Acura Integra (Honda), the speed is most definately measured at the drive wheels. Once, on a nice snowy day I floored it and got the front tires spinning at 80mph in 5th gear while crawling forward (up a slight hill) at walking speed. The nasty smell of hot rubber and road salt -- as well as the thought that this probably wasn't going to be all that good for my drivetrain should the tires catch -- convinced me to let off a bit.:-)
P.S. Doing doughnuts in an empty, snowy parking lot is probably one of the best things one can do to improve their driving skill. This activity should be encouraged.
while a GUI allows you to do common things faster.
I think that this is where we are having a slight misunderstanding. The 2D GUI isn't faster than the CLI, but has other added benefits (easier to see relationships, ability to see multiple outputs on the screen at the same time, viewing of fonts/markup, etc) that outweigh the added slowness. For a speed comparison, several common tasks are below:
GUI: 1. Go to "MyComputer" or "Finder" 2. [Double]Click on "Documents" 3. Go to "MyComputer" or "Finder" again or move hands to keyboard for CTRL+N to get a second window 4-6. click several times to browse the second window to/somewhere/else 7. Drag the icon for mypaper.txt from the first to the second window.
Playing resizing an image:
CLI: 1. type $ mogrify -resize 640x480 cockatoo.jpg
GUI: 1-3. Open a filebrowser and browse to the image OR 1. Go to "StartMenu" --> applications --> Adobe --> Photoshop 2. Click File --> Open 3+. Browse to cockatoo.jpg, click ok 4. Click Image --> Image Size 5. enter your resize values in the fields, click ok 6. Click File --> Save OR 6. Click CTRL+S
In these and most other situations, the CLI will be much much faster, however, the added value of the 2D GUI is huge. For instance, being able to see what your image looks like when its resized is a great added value. Likewise, being easily able to see the hierarchy tree when using the filebrowser means that you don't have to keep as much in your head. How this applies to the 3D desktop is that the 3D interface does not have to maintain or reduce the overhead of interaction over the 2D environment, but it must add enough value to the environment to make that extra interaction overhead worth the trouble.
I have yet to try a true 3D desktop and will wait until I have to make judgements on whether the interface overhead is worth the benefit.
Where do you live where consumer electronics volume controls are mostly anticlockwise?
I just checked a Sherwood receiver and an RCA CD player and they are both volume-up==clockwise (when looking at the front of the box. This is in the USA.
Being able to carry out multiple tasks in parallel, to have several applications available to facilitate workflow......the multiple application, flexible workflow side of things is what truly mattered...
Have you used SCREEN by any chance?
Screen is a full-screen window manager that multiplexes a physical terminal between several processes, typically interactive shells. - From SCREEN - window manager
The History shows that version 3 of SCREEN was release on 3.00.01 1991-07-08, so that would make it older than Windows 3.1, though I'm not sure on the original creation date for SCREEN v.1.
While the CLI is still 1D, SCREEN sort of adds another dimension to it. Anyway, its a pretty old app, but its still incredibly useful.
So to make use of 3D, you have to somehow do it in a way that "eliminates" what would already be additional movement in 2D.
This is somewhat true, but is not the whole salami. Why to I like the one-dimensional command-line? Because I don't have to switch my hand to the mouse then drag the pointer around to click on the correct GUI box. The 2-D environment definately adds more user overhead to the environment, but the value it adds is also significant.
A 3D environment/interface doesn't have to eliminate added controller movement, (as it really can't), but it has to provide enough value to the interaction that the extra movement is justified/worth-while for the applications its being applied to. From the other comments, it seems that it is worth it for CAD apps. Is it worth it for the desktop? That remains to be seen.
For about 3 months (Nov-Jan) my Mozilla Thunderbird went from catching about 90% of spam to 15% as spammers changed tactics several times. I just kept training though and now its back up to 70% and climbing.
The random words did the trick for a while, as did the miss-spelling, but now that they are all pushed through the filter training
FUL|L RE|FUND IF NOT DELIGHTED!
is just like using red text and trashed.
Re:Why not use these skills for something useful ?
on
Linux for iPod Matures
·
· Score: 1
But do we need all the Unix-like mechanisms...?
Short answer: yes
Medium answer: yes, but they can be hidden from the user.
Long answer: The "Unix-like" fs is what all of the currently availible apps for *nix understand and expect. Yes, it could be restructured, but there just isn't much benefit to anyone in doing so.
If you look at the screenshot, the file browser is simply the last option in the UI. If the Linux-on-iPod features like mp3, ogg, etc playback get up to snuff enough for a "common user", then the unix-like nature of the firmware could be easily hidden by removing options that show it from the UI.
At the same time, without Linux (or some other documented OS) underneath the UI, writing apps to run on the iPod is next to impossible. Apple doesn't release the nessisary information to allow us to write for the existing firmware, so someone must replace that with a system we can write for.
Cool. I did not know that. My BA in Physics didn't extend to General Relativity, so I never got all that straightened out. Taking fluid dynamics instead was probably the more useful choice, but at the same time it would be nice to just know this stuff. Anyway, thanks for the info.
I found the transcript the quote was taken from and you are correct. I thank you for calling me on this. My sig has been updated to a more in-context quote from that same transcript until I find a better one.
You are most correct in that gravitational forces on the atomic level don't have an effect on whether or not an atom stays together. However, like all the rest of the forces mentioned, the force of gravity between any two things of mass is non-zero. It may be extremely tiny, so much so that it is far beyond immessurable (when the masses are very small) and its effects are zero, but the force is still non-zero. The force of gravity on a massless photon is zero.
BTW - gravity was included just to make the list slightly more exhaustive, as it is the only other "sucking" force I could think of off the top of my head.
Actually, they are not. While energy does correlate to mass (via the famous E=mc^2 formula) and a photon (just energy, no mass) could become mass with less energy; a sub-atomic partical a photon is not.
The wave-partical duality refered to in quantum-mechanics says basically that since a photon is not a wave of constant amplitude (a picture), it can behave like a particle in some sense (albeight a massless one). Additionally, particles with mass also have wave properties, but with extremely high frequencies.
All that said, not all particles are sub-atomic particles. The particles of potato-chip at the bottom of my bag are not sub-atomic particles. Likewise, nutrinos and photons, while they can pass through atoms and collide with or originate from them, are not subatomic particles. Aside from light being massless, photons are not sub-atomic particles because they are not "glued" inside an atom by electrostatic forces, strong nuclear forces, weak nuclear forces, gravitational forces, or any other kind of force. When an electron/other sub-atomic particle falls into a lower energy state and releases its excess energy as a photon, that photon leaves the atom. Hence, the stars, LEDs, light-bulbs, and all other light-emitting things "work".
Re:What, no editorial?
on
Red Hat Recap
·
· Score: 5, Informative
Red Hat Linux itself is a collective work under U.S. Copyright Law. Red Hat grants you a license in this collective work pursuant to the GNU General Public License.
Nothing in the EULA says anything about not being able to copy the software.
Now, from browsing around their site I gather that what RedHat is charging for (and restricting on a per-machine basis, is a connection-to/right-to-use their update service. I wasn't able to see anything that said that you couldn't take one ISO of Advanced Server and put it on two machines. However, you would need to pay twice to be able to update both of them via RedHat's update system.
If you want to install RedHat AS and then compile all updates your self, it seems that you would be welcome to, but why then use RedHat?
This kinda actually makes sense as a business plan. If you have mission-critical servers, but not the expertise to admin them under Debian, *BSD, Gentoo, etc, buy a RedHat license and have it "just work"(TM).
Dick Cheney's 2001 financial disclosure statement, states that the Halliburton is paying him a "deferred compensation" of up to $1million a year following his resignation as chief executive in 2000. -- from CorpWatch
Slashdot Mirror
and turning off register_globals, will result in better results.
I couldn't agree more. register_globals really should be off, but often can't be.
In the developement of our PHP application suite we've run into a big problem with the persistance of object trees. Basically, if you put a tree of objects that contain references into the $_SESSION array without register_globals on, when you get them back in another execution cycle the references will be all jumbled up with copies of the objects to boot. For some reason this works fine with the exact same code and register_globals=ON.
Hopefully PHP5 will stablize soon and fix all of this nonsense.
"Moore's law" does not refer to the speed of processors doubling, but that the number of transistors that can be fit into a given area doubling every 18 months or so.
The shrinking of transistor sizes has lead to smaller, cooler, faster, more powerful chips, but the speed increase is just a side effect of the smaller transistors. Were chip engineers more interested in packing more operations each cycle onto a chip, then you would see slower clock speeds with similar densities of transistors on larger areas (with more heat buildup being the speed limiter) -- something akin to the PowerPC chips vs the high-speed Pentiums. Similar densites of transistors and the PPCs actually do more floating-point operations per second (flops) than a Pentium that runs at about twice the clock.
Colorado State Mechanical Engineering is do some cool R&D on Mass Production of [Thin-Film] Photovoltaic (PV) Modules which could drastically reduce the cost of PV cells in the future.
Get application developers for Linux to conform to some standard for app installs and getting people to convert will be alot easier.
Its been tried for years. Good luck. The other problem is that developers don't necessarily have the resources to compile binaries for even all the major distros. However, good documentation (like Apple's PostgreSQL docs linked to in the grandparent) allows people of any knowlege level to get the software working.
Compiling with instructions like "./configure, make, make install" is just an example of a place where the documentation requires knowledge on the part of the reader that the reader has no way to know they need or know how to find out. ESR's piece on CUPS that I linked to, as well as how to set up joysticks under Transgaming's Point2Play (expects a knowlege of what the "joystick name returned by jstest" is), as well as instructions on mounting a Firewire HD (requires knowledge of which line was in portant in a device scan), as well as etc.
The problem isn't compiling, but the expectation in the documentation that the person knows more of the workings of the system than they do.
All in all, the apt/yum/etc-GUI install has got to be the most usable system created. Its so much easier than searching for a website that has executable for download, downloading the executable, then clicking through the wizard, selecting an install place, etc. Just click "install" and know that you got the latest version and that apt will update it later along with everything else.
Along similar usability lines, I am currently running Xandros as a pilot to see if it is "mom" (or grandmom) ready as it is advertised as "very user friendly". In the process of this pilot, I've done detailed documentation of every step I've done to get my Xandros fully working. My hope is that these step-by-step instructions will help my various friends who seem interested, but are a bit scared of Linux.
My big problem with Linux documentation in general (and what I am trying to do differently in my own) is the assumptions of knowledge on the part of the reader. My key example is documentation for installing software from source that goes like the following:
----
----
/usr/local/src/
./configure --perl=/usr/bin/perl
How many times have you seen instructions like this?
The other comments on the steps mentioned say "Thanks, that works great!" and things like that, but my compile threw errors and didn't work for me.
The problem is, which I learned after 3 years of daily linux use and 5 distros (including FreeBSD), is that you often need to specify options for the "./configure" step, and those option are found by doing "./configure --help". NOBODY EVER MENTIONS THIS! (sorry for use of caps, but this is a pretty huge problem.)
Compounding the problem is that once you do do a "./configure --help", you are given a huge list of options, but have no clue which ones (and what parameters you need to specify) to get your software to compile. Please tell me where I can find this if there is documentation as to a general process for trouble-shooting compile-options, because I have yet to find it.
Instead of the above example, how about some instructions like the following:
---
All steps are done as root (administrator). # is the root prompt of a command-shell, more info.
1. Change to the source-download dirctory:
# cd
2. Download the source (someapp-1.x.x.tar.gz, where the x's are replaced by the latest version numbers, see http://www.mysite.org/releases/ for the latest version information.
# wget ftp://dist.mysite.org/releases/someapp-1.x.x.tar.g z
3. Untar the archive:
# tar -xzf someapp-1.x.x.tar.gz
4. Change to the uncompressed source directory:
# cd someapp-1.x.x/
5. Configure the installer.
Most systems will need to specify the location of your Perl executable:
#
Use the following command to find your Perl executable:
# locate perl | grep bin
Other common options that may be needed
As CommanderFoxTrot says, wrecking on skis is generally much better than wrecking on pavement/dirt/grass/etc since you generally just slide. Watch the olympic or world cup downhill races and you can see this in action. In the vast majority of falls, the skier will be simply sliding, straight or maybe spinning on the snow with no more harm than bruising/ice-rash.
Injury occurs in one or both of two places: either the skier's skis are still on and catch on the snow, starting a bone/joint/neck-breaking tumble, or the skier runs into some unmovable object before slowing down. Hitting trees, rocks, hay-bales, spectators, snowmobilies or large cliffs at high speed is gennerally detrimental to one's continued membership in the living.
I have seen videos in which a speed skier has fallen at VERY high speed and been ok -- they are going straight on an open, groomed, pitch with nothing to hit. However, as far as I know some have died from high speed falls as well, generally from tumbling.
#1: speed is measured at the rear wheels (for a front-wheel drive). Ever floor your car in mud? The wheels spin, but the speedo doesn't say you're doing 200Mph
:-)
On my car, a 93 Acura Integra (Honda), the speed is most definately measured at the drive wheels. Once, on a nice snowy day I floored it and got the front tires spinning at 80mph in 5th gear while crawling forward (up a slight hill) at walking speed. The nasty smell of hot rubber and road salt -- as well as the thought that this probably wasn't going to be all that good for my drivetrain should the tires catch -- convinced me to let off a bit.
P.S. Doing doughnuts in an empty, snowy parking lot is probably one of the best things one can do to improve their driving skill. This activity should be encouraged.
Wow, vehicular manslaughter -- with no one dead!
Playing resizing an image:
:-)
Opps, brain-fart.
That should have been just:
Resizing an image:
I need coffee.
Please move along folks, nothing to see here. Please ignore the man in the chicken suit.
while a GUI allows you to do common things faster.
/home/adam/mypaper.txt /somewhere/else/
/somewhere/else
I think that this is where we are having a slight misunderstanding. The 2D GUI isn't faster than the CLI, but has other added benefits (easier to see relationships, ability to see multiple outputs on the screen at the same time, viewing of fonts/markup, etc) that outweigh the added slowness. For a speed comparison, several common tasks are below:
Copying a file:
CLI:
1.type $ cp
GUI:
1. Go to "MyComputer" or "Finder"
2. [Double]Click on "Documents"
3. Go to "MyComputer" or "Finder" again or move hands to keyboard for CTRL+N to get a second window
4-6. click several times to browse the second window to
7. Drag the icon for mypaper.txt from the first to the second window.
Playing resizing an image:
CLI:
1. type $ mogrify -resize 640x480 cockatoo.jpg
GUI:
1-3. Open a filebrowser and browse to the image
OR
1. Go to "StartMenu" --> applications --> Adobe --> Photoshop
2. Click File --> Open
3+. Browse to cockatoo.jpg, click ok
4. Click Image --> Image Size
5. enter your resize values in the fields, click ok
6. Click File --> Save
OR
6. Click CTRL+S
In these and most other situations, the CLI will be much much faster, however, the added value of the 2D GUI is huge. For instance, being able to see what your image looks like when its resized is a great added value. Likewise, being easily able to see the hierarchy tree when using the filebrowser means that you don't have to keep as much in your head. How this applies to the 3D desktop is that the 3D interface does not have to maintain or reduce the overhead of interaction over the 2D environment, but it must add enough value to the environment to make that extra interaction overhead worth the trouble.
I have yet to try a true 3D desktop and will wait until I have to make judgements on whether the interface overhead is worth the benefit.
Where do you live where consumer electronics volume controls are mostly anticlockwise?
I just checked a Sherwood receiver and an RCA CD player and they are both volume-up==clockwise (when looking at the front of the box. This is in the USA.
Being able to carry out multiple tasks in parallel, to have several applications available to facilitate workflow... ...the multiple application, flexible workflow side of things is what truly mattered...
Have you used SCREEN by any chance?
Screen is a full-screen window manager that multiplexes a physical terminal between several processes, typically interactive shells. - From SCREEN - window manager
The History shows that version 3 of SCREEN was release on 3.00.01 1991-07-08, so that would make it older than Windows 3.1, though I'm not sure on the original creation date for SCREEN v.1.
While the CLI is still 1D, SCREEN sort of adds another dimension to it. Anyway, its a pretty old app, but its still incredibly useful.
So to make use of 3D, you have to somehow do it in a way that "eliminates" what would already be additional movement in 2D.
This is somewhat true, but is not the whole salami. Why to I like the one-dimensional command-line? Because I don't have to switch my hand to the mouse then drag the pointer around to click on the correct GUI box. The 2-D environment definately adds more user overhead to the environment, but the value it adds is also significant.
A 3D environment/interface doesn't have to eliminate added controller movement, (as it really can't), but it has to provide enough value to the interaction that the extra movement is justified/worth-while for the applications its being applied to. From the other comments, it seems that it is worth it for CAD apps. Is it worth it for the desktop? That remains to be seen.
I have an nForce based ABit AN-7 with a AthalonXP in it running Xandros. I've not had any problems with the board or the Linux drivers.
For about 3 months (Nov-Jan) my Mozilla Thunderbird went from catching about 90% of spam to 15% as spammers changed tactics several times. I just kept training though and now its back up to 70% and climbing.
The random words did the trick for a while, as did the miss-spelling, but now that they are all pushed through the filter training
FUL|L RE|FUND IF NOT DELIGHTED!
is just like using red text and trashed.
But do we need all the Unix-like mechanisms...?
Short answer: yes
Medium answer: yes, but they can be hidden from the user.
Long answer:
The "Unix-like" fs is what all of the currently availible apps for *nix understand and expect. Yes, it could be restructured, but there just isn't much benefit to anyone in doing so.
If you look at the screenshot, the file browser is simply the last option in the UI. If the Linux-on-iPod features like mp3, ogg, etc playback get up to snuff enough for a "common user", then the unix-like nature of the firmware could be easily hidden by removing options that show it from the UI.
At the same time, without Linux (or some other documented OS) underneath the UI, writing apps to run on the iPod is next to impossible. Apple doesn't release the nessisary information to allow us to write for the existing firmware, so someone must replace that with a system we can write for.
Cool. I did not know that. My BA in Physics didn't extend to General Relativity, so I never got all that straightened out. Taking fluid dynamics instead was probably the more useful choice, but at the same time it would be nice to just know this stuff. Anyway, thanks for the info.
Ah, but "they" want you to buy two, or even three copies of everything!
:-)
Its only fair of course since they are poor, starving, publishers who do nothing but support their artists.
Did you purposefully misquote this in an attempt to mislead, or was it accidental?
Accidental this was. The quote came directly from a "Presidential Mis-Speak" calendar.
I found the transcript the quote was taken from and you are correct. I thank you for calling me on this. My sig has been updated to a more in-context quote from that same transcript until I find a better one.
You are most correct in that gravitational forces on the atomic level don't have an effect on whether or not an atom stays together. However, like all the rest of the forces mentioned, the force of gravity between any two things of mass is non-zero. It may be extremely tiny, so much so that it is far beyond immessurable (when the masses are very small) and its effects are zero, but the force is still non-zero. The force of gravity on a massless photon is zero.
BTW - gravity was included just to make the list slightly more exhaustive, as it is the only other "sucking" force I could think of off the top of my head.
Actually, they are not. While energy does correlate to mass (via the famous E=mc^2 formula) and a photon (just energy, no mass) could become mass with less energy; a sub-atomic partical a photon is not.
The wave-partical duality refered to in quantum-mechanics says basically that since a photon is not a wave of constant amplitude (a picture), it can behave like a particle in some sense (albeight a massless one). Additionally, particles with mass also have wave properties, but with extremely high frequencies.
All that said, not all particles are sub-atomic particles. The particles of potato-chip at the bottom of my bag are not sub-atomic particles. Likewise, nutrinos and photons, while they can pass through atoms and collide with or originate from them, are not subatomic particles. Aside from light being massless, photons are not sub-atomic particles because they are not "glued" inside an atom by electrostatic forces, strong nuclear forces, weak nuclear forces, gravitational forces, or any other kind of force. When an electron/other sub-atomic particle falls into a lower energy state and releases its excess energy as a photon, that photon leaves the atom. Hence, the stars, LEDs, light-bulbs, and all other light-emitting things "work".
I just read the EULA and it specifically says,
Red Hat Linux itself is a collective work under U.S. Copyright Law. Red Hat grants you a license in this collective work pursuant to the GNU General Public License.
Nothing in the EULA says anything about not being able to copy the software.
Now, from browsing around their site I gather that what RedHat is charging for (and restricting on a per-machine basis, is a connection-to/right-to-use their update service. I wasn't able to see anything that said that you couldn't take one ISO of Advanced Server and put it on two machines. However, you would need to pay twice to be able to update both of them via RedHat's update system.
If you want to install RedHat AS and then compile all updates your self, it seems that you would be welcome to, but why then use RedHat?
This kinda actually makes sense as a business plan. If you have mission-critical servers, but not the expertise to admin them under Debian, *BSD, Gentoo, etc, buy a RedHat license and have it "just work"(TM).
Oops, I just checked GoogleNews and Haliburton is is back in it. Lying about Iraq contracts.
Definately no scandal.
I'd like you to name a bidding scandal then.
Dick Cheney's Haliburton was awarded contracts for Iraqi oil-field work without even bidding.
Dick Cheney's 2001 financial disclosure statement, states that the Halliburton is paying him a "deferred compensation" of up to $1million a year following his resignation as chief executive in 2000. -- from CorpWatch
Nope, no scandal here...