Complaining doesn't work. One must transform the pain of the current experience into a set of recommendations for a future platform; then edit that document for coherence and practicality; then present it.
Read some good patents. They begin with complaints, called "knocking the prior art". But the inventors didn't stop at "this sucks!" - they continued to the next logical step, "this is how I fix the suckage."
What makes you think that the US is the only country that could produce one of these types of reactors? Strikes me as a lot of arrogance that only the US could do it.
I didn't say only the US could do it. I said that if the US chooses to do it, the US would be smart to keep it on a leash. Right now, the US sells a lot of weapons to poor countries. These weapons (think planes, not rifles) are pretty dependent on a flow of spares from the US. I believe some cryptographic equipment needs keying material that can only come from NSA. That is a smart way to enforce some dependence on the US.
other countries would be happy to provide the technology without any licensing restrictions.
Which other countries? How would we even know what restrictions are present? The topic is not likely to be discussed in public. The industrialized nations are committed to anti-proliferation. If some kind of "leash" is accepted as an anti-proliferation measure, no industrialized nation will want to break ranks and sell "unleashed" modules to risky states. It's more likely that other countries will be quietly transmitting license keys to rogue states under embargo. For example, if France had sold Saddam such "leashed" reactors, they would probably have been helping him keep them alive.
Sure didn't stop North Korea from developing nuclear weapons.
Anti-proliferation measures did stop a lot of countries from getting nukes. Just because NK has them doesn't mean we want Syria, Cuba, Sudan, etc. having them. Besides, NK doesn't have nearly as many nukes as they want. It takes a lot of reactor time and reprocessing to generate an adequate "pit" of plutonium. No sense handing them any shortcuts.
Being Canadian, I know that the Canadian government had sold a bunch of CANDU reactors to other countries, and I'd be willing to bet that we didn't try to squeeze licensing fees out of them for it. Of course, it may just be that Canada is too polite to ask.:)
I didn't mention fees. I mentioned the idea of keeping the reactor on a short cryptographic leash. Fees are orthogonal to this idea. Were the Canadian-furnished reactors financed by debt, either to Canada or the IMF? If so, the customer country is effectively paying "fees".
I think the point of these new reactors is partly that they could be installed in places too unstable for conventional reactors. I'm sure Canada has some restrictions on where they will sell the CANDU reactors.
I don't understand the pebble-bed idea. Are you saying that a) There is no plutonium in the pebbles or b) it's too hard to extract?
If b, surely there are ways. How about grinding the pebbles into fine powder, dissolving in water, and using a centrifuge to separate the elements with high atomic mass? And what happens if you dump these pebbles into nitric acid (as current reprocessors do with fuel assemblies)?
Also, what do you mean about "active refueling of the core"? I thought these units were sealed, with a lifespan of 30 years. Who would refuel? Is it out of the question for a single fuel load to last 30 years? I know it's beyond what most existing reactors are doing.
Some issues
on
Port-A-Nuke
·
· Score: 3, Insightful
I wonder how many active systems are in this module, such as cooling, moderation, turbine, etc. What happens when a part breaks? Maybe it's built very redundantly so breakage only decreases the capacity.
Does the unit make electricity or just steam? Does it contain any computers? What are the odds of needing a software upgrade sometime in the next 30 years? If there's a path for software updates, could someone write a malicious control software that causes a meltdown or something?
If the US is smart, they'll incorporate some kind of cryptographic leash into this thing. It could require monthly "operating licenses" from the US to continue functioning.
I didn't understand how the unit protects against extraction of plutonium. The article mentions a "thicket of alarms", but what happens when the alarms go off? You have to assume the local government wants to extract the plutonium. Maybe a shaped charge blows the reactor core to smithereens if the housing is penetrated. That would frustrate (or rather kill) would-be bomb makers, but create an environmental disaster around the reactor.
Awareness of suckage can be the first step to innovation. Maybe you should take the time to write a detailed list of suckpoints, possibly with proposed fixes.
We are conceptually stuck in the Unix era because nothing better has been proposed.
Maybe, but we could get a lot closer than we are now. A good general principle is that when a natural monopoly exists (phone lines, RF spectrum, etc.) the monopoly holder should not be allowed to sell other products or services related to the monopoly. How would you like it if your power utility sold appliances? Can you imagine what a limited, overpriced selection you'd have?
To apply the logic here, cellular providers should not be allowed to sell phones.
The paragraph you cite is boilerplate. It has almost no bearing on potential infringement. The actual offensive strength of the patent is solely in its claims.
Affiliate programs seem to bring out the slimiest in people, whether it's email spam or spammy slashdot comments. Won't it be wonderful to search for some obscure song on google and get a vast wasteland of affiliate link-spam pages all pointing to Apple?
I thought Apple had more class.
(Please, Apple fanboys, don't mod this down out of reflexive groupthink. Because that's lame.)
Everybody else wants a glitzier, shinier toy. This is where Linux users and Windows users are sometimes very similar - often valuing "features" over utility. My wish is completely different - I want a reliable and programmable tool.
Form factor of Motorola clamshell pagers. They look cool and the keyboard is usable. And they are small enough to fall below the annoyance threshold.
Rugged, waterproof case meeting MIL-STD-810E. Most walkie-talkies meet this spec, and increasingly ham handhelds are meeting it. This means you don't have to baby the unit - if it falls into mud or water or onto concrete, it will be OK.
Black. Not translucent, not fruity-colored, and definitely not silver-painted plastic. Painted plastic is an utter abomination - the coolest thing about plastic is its integral color, which lets it age gracefully - little nicks and bangs don't expose a contrasting color.
Long battery life, common alkaline batteries. That implies: no movies, no hi-res graphics, no color. Probably no mp3 playback. It's more important for the device to be dependable and hassle-free than to be a fragile showcase of hi-tech. An easy way to hook up external cheap batteries for extra power, like a box with 4 D cells.
A flat, waterproof connector for all external connections, as seen in the Motorola HT's. Since the connector is composed of flush brass dots, it never wears out. The mating connector should be available in an oversized 'cartridge' version that could house cool peripherals, as well as a low-profile version.
Easy to program from Linux. I don't want a science project. I should be able to open the package and have it running my own code in 15 minutes.
Very open architecture, both in hardware and in software. It should encourage a vibrant scene of free software and strange peripherals.
An OS/Shell cleverly designed for technical, keyboard, palmtop users. Not a stylus-based GUI, nor a Unix CLI, but a system with very short keyboard commands. Possibly Forth-based.
In addition to the Linux-hosted C/C++ programming environment, it should have a programming environment that's very accessible from the unit itself. It should be easy to modify and automate the behavior of built-in apps without using a PC. Again, maybe Forth.
SSH client - that's obvious, right?
802.11 would be really nice, if it can be reconciled with low power consumption.
A thumbwheel. It works well on the Blackberry.
Tactile bumps on some keys so you can type without looking.
Both versions are common. "Coding" generally doesn't mean encryption. It means replacing input data with output data that has some desirable property. Error correcting codes are bigger than the input they represent, but allow the input to be reconstructed even if some bits are changed in transmission. Huffman codes convert input symbols to variable length output strings - common symbols get short strings and rare symbols get long strings. Spreading codes are combined with baseband signals to create spread spectrum signals.
So, generally, coding/encoding is not related to encryption.
I'm running Red Hat Linux release 9 (Shrike) - actually Pink Tie, a CheapBytes copy. And fluxbox 0.1.14 - love it.
Agreed about Gentoo. I run it at work, with much help from a nearby Gentoo expert, and frequently have to put too much time into fixing it. The benefit is that I can run recent Mozilla, etc.
I added apt-get to Red Hat and it gives me some of the functionality, but most applications I want aren't available. It is much faster than emerge, of course.
I didn't immediately succeed with the author's instructions. Here's what worked for me:
cd yaAGC ./configure make sudo make install cd yaDSKY ./configure make sudo make install yaAGC --core=Validation.bin --debug In another window, still in the yaDSKY directory: yadsky --cfg=src/LM.ini (Note lowercase yadsky) Congratulations, Ronald. Pretty cool. Does the contrast on the LED display have to be so low? The background is very light.
Am I the only one here who actually tried the program?
will suck all the pictures out of many cameras. I'm not sure what kernel support you're talking about. If it's a USB camera and shows up as a USB device, you can probably do at least one of:
Mount it as a filesystem.
Use Gphoto.
I don't think the kernel needs to explicitly support your camera in any way.
At a former workplace, I got a VA Linux workstation. The keyboard had a penguin key instead of a Windows key. I turned the keyboard over, and molded into the plastic was "Designed for Windows 95".
Based on my minimal usage of MacOS X, I have the same impression. The UI is slow, and the only way to tolerate it is to enjoy it aesthetically. I tend to get a little panicky and angry when a computer is sluggish, so MacOS X is not for me.
We are a distinct minority. Most computer users simply don't notice slowness. A machine can take literally a quarter second to react, and users will swear it was instant.
Lots of Linux software is sluggish, including Mozilla.
I thought of that, but it's a bit weaker for two reasons. Musicians don't usually assign copyright to labels, so they stay very involved in adminstering the rights to their works. (Which may be bad in itself, but it's different.) Also, musicians have the name recognition. Nobody says, "let's buy a Warner CD." So the labels have never become really valuable brands that could distract consumers from the musicians.
Thinking about, though, I realize that "name" musicians and bands are brands of that type. When you listen to a great Madonna song, how many people know who the songwriter and musicians were? Arguably, they brought more to the song than the vocalist did. (Patrick Leonard wrote the good stuff, BTW).
Cornholio is the caffeine-and-sugar-induced alter ego of Beavis, from the show Beavis & Butthead. He pulls his t-shirt over his head and speaks in a high-pitched, accented voice. Most viewers hear it as Mexican, but in fact it's modeled on a Middle Eastern man.
Several of his lines include "TP" - toilet paper. "I need TP for my bunghole". "Een my cone-tree we have no TP!"
Maybe we are using the word "manager" differently, or maybe you have seen a lower quality of manager. Substitute "senior developer" if you like. Not a PHB or an MBA, but a seasoned programmer who can rapidly estimate how hard some proposed requirement is.
I am a programmer, not a manager. There has to be some kind of filter between the "customers" (marketing/legal/bizdev) and the engineer. The customers have whims that often blow over in five minutes. When an engineer is deep in the implementation of X, he doesn't need to here that maybe we'll scrap X and move to Y. Especially since it probably won't happen.
Some of the things engineers say can frighten or anger customers, because they're too literal. Likewise, the customers can cause the engineers heart palpitations with scary requirements that turn out to be trivial or simply disposable whims.
Example: Imagine that QMX is a system that took 2 man-years to write and debug. Customer: I just signed this awesome deal. We're gonna need another QMX, let's call it ZMX. It would have....
After an hour of discussion, the manager understands that we don't need a new QMX; we just need to add about 10 features to QMX that make it look like a different thing. No need to expose the QMX coders to this turbulence.
Remember, for every feature that makes it to the coders, two or three should be filtered out first. Likewise, when a coder says that "Our system sucks. It is fundamentally flawed and we should throw it out and start over," a seasoned technical manager knows this is normal and should not be passed on the customers. (All systems suck once a few years of cruft have accumulated.)
Actually, I was referring to today's emails as "memos". I haven't seen a paper memo for a long time. But a former Atari engineer named Jed Margolin has an online archive of Atari email messages from the 80s-90s. Aside from the few users who wrote in ALL CAPS, I'm impressed by the quality of these messages. Maybe people raised on typewriters retained some interest in quality when they moved to computers.
Universities were originally mere facilities in which learned professors could teach. The professor was the drawing power, and could teach in a self-rented hall or in the College. Gradually, the University has swollen in cost and power until it overshadows the professors. The University makes lots of rules to govern professors and students, and any one professor is disposable. Lately universities have been demanding ownership of online lecture produced by professors, so they can play them over and over, extracting revenue.
Software companies own the copyright to code written by their employees. Increasingly, they even own patents. So the actually creative people are legally obstructed, but the mere shell, which produces nothing in itself, is increasingly powerful. We are approaching the point where there's no value in being a programmer, because the only value is in owning the rights that enable a certain application.
The Olympics is ostensibly centered on the athletes. But more and more news stories illuminate the fact that the Olympics is a very powerful organization that can dictate terms to athletes. Although the athletes create all the value here, they own nothing.
These professors, programmers and athletes get a small share of the value they create. Most of the value goes to those who have cleverly extended the "container" and claim the individual's achievement in the name of the container.
It is an error to attribute the individual's achievement to the container in which he works.
Good post - why don't you log in so your posts won't languish at 0? There is definitely a loss of clarity in the business world. If you stumble across any memo from the 1950's, for example, it is likely to be much better written than the business documents of today. And I agree, though I can't prove, that there is some linkage between this loss of clarity and the more powerful desktop tools available today.
I have no idea if it works, but I have seen the process, and it does not consist of throwing a spec over the wall and waiting for a year. What I've seen is Indian managers, in a building in the US with marketing/legal/bizdev/etc. The manager stays in close touch with the development office in India via phone and email. He is also in close touch with the Americans, which is easy since he's in the same building.
Nothing would be gained by putting the developers in the US. You don't want marketing/legal/bizdev talking directly to programmers - you want them going through the manager.
The process seems perfectly workable to me. If it's failing, that's not why.
Unfortunately xpdf and gv (ghostview = ghostscript's postscript viewer) have the same lag. PS/PDF are complicated languages and rendering a page can require any amount of work. A good fix, though, might be to pre-render all the pages to bitmaps in RAM. A smart viewer could even save the bitmaps somewhere so when you open the PDF again it's snappier.
It would be great if a leaner format had become the standard, but it's a bit late.
Problem is - we are not the center of gravity. Unisys is close to the center of gravity, and we are very marginal. The mutual support on/. and the net in general can convince geeks that they're numerous or important.
The votes, the money, the loud and convincing (non-internet) voices are all on Unisys's side here.
As for slashdotters influencing purchasing - to the extent that I influence purchasing, I wouldn't dare bring irrelevant considerations like politics into it. A lot of geeks will rationalize this distortion by saying, "If company X screwed the geeks, they might screw their customers." But this isn't true. What geeks define as screwing is usually legal and "ethical" (by business standards) behavior. So if Unisys is pitching a solution to your employer, it is wrong to fight that solution on the basis of the GIF patent campaign. And the people who don't realize that are generally not involved in these decisions anyway.
Slashdot Mirror
Complaining doesn't work. One must transform the pain of the current experience into a set of recommendations for a future platform; then edit that document for coherence and practicality; then present it.
Read some good patents. They begin with complaints, called "knocking the prior art". But the inventors didn't stop at "this sucks!" - they continued to the next logical step, "this is how I fix the suckage."
I didn't say only the US could do it. I said that if the US chooses to do it, the US would be smart to keep it on a leash. Right now, the US sells a lot of weapons to poor countries. These weapons (think planes, not rifles) are pretty dependent on a flow of spares from the US. I believe some cryptographic equipment needs keying material that can only come from NSA. That is a smart way to enforce some dependence on the US.
Which other countries? How would we even know what restrictions are present? The topic is not likely to be discussed in public. The industrialized nations are committed to anti-proliferation. If some kind of "leash" is accepted as an anti-proliferation measure, no industrialized nation will want to break ranks and sell "unleashed" modules to risky states. It's more likely that other countries will be quietly transmitting license keys to rogue states under embargo. For example, if France had sold Saddam such "leashed" reactors, they would probably have been helping him keep them alive.
Anti-proliferation measures did stop a lot of countries from getting nukes. Just because NK has them doesn't mean we want Syria, Cuba, Sudan, etc. having them. Besides, NK doesn't have nearly as many nukes as they want. It takes a lot of reactor time and reprocessing to generate an adequate "pit" of plutonium. No sense handing them any shortcuts.
I didn't mention fees. I mentioned the idea of keeping the reactor on a short cryptographic leash. Fees are orthogonal to this idea. Were the Canadian-furnished reactors financed by debt, either to Canada or the IMF? If so, the customer country is effectively paying "fees".
I think the point of these new reactors is partly that they could be installed in places too unstable for conventional reactors. I'm sure Canada has some restrictions on where they will sell the CANDU reactors.
I don't understand the pebble-bed idea. Are you saying that a) There is no plutonium in the pebbles or b) it's too hard to extract?
If b, surely there are ways. How about grinding the pebbles into fine powder, dissolving in water, and using a centrifuge to separate the elements with high atomic mass? And what happens if you dump these pebbles into nitric acid (as current reprocessors do with fuel assemblies)?
Also, what do you mean about "active refueling of the core"? I thought these units were sealed, with a lifespan of 30 years. Who would refuel? Is it out of the question for a single fuel load to last 30 years? I know it's beyond what most existing reactors are doing.
I wonder how many active systems are in this module, such as cooling, moderation, turbine, etc. What happens when a part breaks? Maybe it's built very redundantly so breakage only decreases the capacity.
Does the unit make electricity or just steam? Does it contain any computers? What are the odds of needing a software upgrade sometime in the next 30 years? If there's a path for software updates, could someone write a malicious control software that causes a meltdown or something?
If the US is smart, they'll incorporate some kind of cryptographic leash into this thing. It could require monthly "operating licenses" from the US to continue functioning.
I didn't understand how the unit protects against extraction of plutonium. The article mentions a "thicket of alarms", but what happens when the alarms go off? You have to assume the local government wants to extract the plutonium. Maybe a shaped charge blows the reactor core to smithereens if the housing is penetrated. That would frustrate (or rather kill) would-be bomb makers, but create an environmental disaster around the reactor.
Awareness of suckage can be the first step to innovation. Maybe you should take the time to write a detailed list of suckpoints, possibly with proposed fixes.
We are conceptually stuck in the Unix era because nothing better has been proposed.
Maybe, but we could get a lot closer than we are now. A good general principle is that when a natural monopoly exists (phone lines, RF spectrum, etc.) the monopoly holder should not be allowed to sell other products or services related to the monopoly. How would you like it if your power utility sold appliances? Can you imagine what a limited, overpriced selection you'd have?
To apply the logic here, cellular providers should not be allowed to sell phones.
The paragraph you cite is boilerplate. It has almost no bearing on potential infringement. The actual offensive strength of the patent is solely in its claims.
Affiliate programs seem to bring out the slimiest in people, whether it's email spam or spammy slashdot comments. Won't it be wonderful to search for some obscure song on google and get a vast wasteland of affiliate link-spam pages all pointing to Apple?
I thought Apple had more class.
(Please, Apple fanboys, don't mod this down out of reflexive groupthink. Because that's lame.)
I can dream, can't I?
Both versions are common. "Coding" generally doesn't mean encryption. It means replacing input data with output data that has some desirable property. Error correcting codes are bigger than the input they represent, but allow the input to be reconstructed even if some bits are changed in transmission. Huffman codes convert input symbols to variable length output strings - common symbols get short strings and rare symbols get long strings. Spreading codes are combined with baseband signals to create spread spectrum signals.
So, generally, coding/encoding is not related to encryption.
I'm running Red Hat Linux release 9 (Shrike) - actually Pink Tie, a CheapBytes copy. And fluxbox 0.1.14 - love it.
Agreed about Gentoo. I run it at work, with much help from a nearby Gentoo expert, and frequently have to put too much time into fixing it. The benefit is that I can run recent Mozilla, etc.
I added apt-get to Red Hat and it gives me some of the functionality, but most applications I want aren't available. It is much faster than emerge, of course.
I don't know Orbiter - I'll take a look.
I didn't immediately succeed with the author's instructions. Here's what worked for me:
cd yaAGC
./configure
make
sudo make install
cd yaDSKY
./configure
make
sudo make install
yaAGC --core=Validation.bin --debug
In another window, still in the yaDSKY directory: yadsky --cfg=src/LM.ini
(Note lowercase yadsky)
Congratulations, Ronald. Pretty cool. Does the contrast on the LED display have to be so low? The background is very light.
Am I the only one here who actually tried the program?
gphoto2 -P
will suck all the pictures out of many cameras. I'm not sure what kernel support you're talking about. If it's a USB camera and shows up as a USB device, you can probably do at least one of:
I don't think the kernel needs to explicitly support your camera in any way.
wrong.
At a former workplace, I got a VA Linux workstation. The keyboard had a penguin key instead of a Windows key. I turned the keyboard over, and molded into the plastic was "Designed for Windows 95".
Based on my minimal usage of MacOS X, I have the same impression. The UI is slow, and the only way to tolerate it is to enjoy it aesthetically. I tend to get a little panicky and angry when a computer is sluggish, so MacOS X is not for me.
We are a distinct minority. Most computer users simply don't notice slowness. A machine can take literally a quarter second to react, and users will swear it was instant.
Lots of Linux software is sluggish, including Mozilla.
I thought of that, but it's a bit weaker for two reasons. Musicians don't usually assign copyright to labels, so they stay very involved in adminstering the rights to their works. (Which may be bad in itself, but it's different.) Also, musicians have the name recognition. Nobody says, "let's buy a Warner CD." So the labels have never become really valuable brands that could distract consumers from the musicians.
Thinking about, though, I realize that "name" musicians and bands are brands of that type. When you listen to a great Madonna song, how many people know who the songwriter and musicians were? Arguably, they brought more to the song than the vocalist did. (Patrick Leonard wrote the good stuff, BTW).
Cornholio is the caffeine-and-sugar-induced alter ego of Beavis, from the show Beavis & Butthead. He pulls his t-shirt over his head and speaks in a high-pitched, accented voice. Most viewers hear it as Mexican, but in fact it's modeled on a Middle Eastern man.
Several of his lines include "TP" - toilet paper. "I need TP for my bunghole". "Een my cone-tree we have no TP!"
Maybe we are using the word "manager" differently, or maybe you have seen a lower quality of manager. Substitute "senior developer" if you like. Not a PHB or an MBA, but a seasoned programmer who can rapidly estimate how hard some proposed requirement is.
....
I am a programmer, not a manager. There has to be some kind of filter between the "customers" (marketing/legal/bizdev) and the engineer. The customers have whims that often blow over in five minutes. When an engineer is deep in the implementation of X, he doesn't need to here that maybe we'll scrap X and move to Y. Especially since it probably won't happen.
Some of the things engineers say can frighten or anger customers, because they're too literal. Likewise, the customers can cause the engineers heart palpitations with scary requirements that turn out to be trivial or simply disposable whims.
Example: Imagine that QMX is a system that took 2 man-years to write and debug.
Customer: I just signed this awesome deal. We're gonna need another QMX, let's call it ZMX. It would have
After an hour of discussion, the manager understands that we don't need a new QMX; we just need to add about 10 features to QMX that make it look like a different thing. No need to expose the QMX coders to this turbulence.
Remember, for every feature that makes it to the coders, two or three should be filtered out first. Likewise, when a coder says that "Our system sucks. It is fundamentally flawed and we should throw it out and start over," a seasoned technical manager knows this is normal and should not be passed on the customers. (All systems suck once a few years of cruft have accumulated.)
Actually, I was referring to today's emails as "memos". I haven't seen a paper memo for a long time. But a former Atari engineer named Jed Margolin has an online archive of Atari email messages from the 80s-90s. Aside from the few users who wrote in ALL CAPS, I'm impressed by the quality of these messages. Maybe people raised on typewriters retained some interest in quality when they moved to computers.
These professors, programmers and athletes get a small share of the value they create. Most of the value goes to those who have cleverly extended the "container" and claim the individual's achievement in the name of the container.
It is an error to attribute the individual's achievement to the container in which he works.
Good post - why don't you log in so your posts won't languish at 0? There is definitely a loss of clarity in the business world. If you stumble across any memo from the 1950's, for example, it is likely to be much better written than the business documents of today. And I agree, though I can't prove, that there is some linkage between this loss of clarity and the more powerful desktop tools available today.
I have no idea if it works, but I have seen the process, and it does not consist of throwing a spec over the wall and waiting for a year. What I've seen is Indian managers, in a building in the US with marketing/legal/bizdev/etc. The manager stays in close touch with the development office in India via phone and email. He is also in close touch with the Americans, which is easy since he's in the same building.
Nothing would be gained by putting the developers in the US. You don't want marketing/legal/bizdev talking directly to programmers - you want them going through the manager.
The process seems perfectly workable to me. If it's failing, that's not why.
Unfortunately xpdf and gv (ghostview = ghostscript's postscript viewer) have the same lag. PS/PDF are complicated languages and rendering a page can require any amount of work. A good fix, though, might be to pre-render all the pages to bitmaps in RAM. A smart viewer could even save the bitmaps somewhere so when you open the PDF again it's snappier.
It would be great if a leaner format had become the standard, but it's a bit late.
Problem is - we are not the center of gravity. Unisys is close to the center of gravity, and we are very marginal. The mutual support on /. and the net in general can convince geeks that they're numerous or important.
The votes, the money, the loud and convincing (non-internet) voices are all on Unisys's side here.
As for slashdotters influencing purchasing - to the extent that I influence purchasing, I wouldn't dare bring irrelevant considerations like politics into it. A lot of geeks will rationalize this distortion by saying, "If company X screwed the geeks, they might screw their customers." But this isn't true. What geeks define as screwing is usually legal and "ethical" (by business standards) behavior. So if Unisys is pitching a solution to your employer, it is wrong to fight that solution on the basis of the GIF patent campaign. And the people who don't realize that are generally not involved in these decisions anyway.