Well, now, that is a legitimate excuse. The MS oS was fairly popular for a long time because it was the only commercial choice. However, when other OS's for the PC became available, MS launched a campaign to prevent vendors from selling computers without a MS OS.
OEM's were given sweetheart deals on MS OSes, but usually on the conditiont that there was to be no other. They even kept OEM's from selling "naked" boxes by offering licences that were per PC shipped, regardless of whether or not it had an OS.
Now, I have a friend who bought a PC from one of the rare vendors who would sell it naked. He bought his own copy of Win95 (of his own free will, yes, and concious choice), and installed it himself. The hardware, however, was fairly defective. The vendor had a no-lemon policy, and so the third time the machine had to be sent in, they bought the machine back from him at the original price. This was a year and a half after he bought the machine, and he could now get a much nicer PC for the same money. So, he was now in the market for a new PC. At this point, though, it was impossible to find a vendow that didn't package Windows on the box. So my friend was forced to by an additional copy of an OS that he didn't need. He had his copy of '95 retail. Not even a EULA of dubious legality was keeping him from using it again. No copyright violation at all (the old machine had it's drives wiped). But he still had to buy Windows again
Now, you might counter with "well, why didn't he just get parts," or "this vendor this vendor and this vendor would be happy to sell naked PC". Well, parts wasn't an option. While he ws fairly software savvy, he needed the hardware support that you can only get from a big vendor (especially after the horror of hardware problems he'd had before). But all of the big vendors were coerced into signing exclusive agreements with MS.
So, while I suppose he doesn't use Windows against his will, he did have to buy it once against his will, and that, sir, is harmful to a consumer/consumers.
In that he thought that a PC was too much of a bitty box to be worth anything with. PC's were mostly no good because DOS blew chunks, and didn't come close to taking advantage of the hardware.
When he broke down and bought a PC, he got Minix because DOS blew. Linux was written because he felt he could right something decent. Later, as linux matured (approched v1.0), the goal (of Torvalds and the community) did become to write a PC OS to kick all of the others' collective asses. I suppose there were no explicit anti-MS sentiment, in that the MS offerings were so bad that they weren't worth making a comparison to. No hate of MS, but plenty of disdain. Truckloads of disdain.
The content is going to stay free due to basic free-market effects. The barriers to entry are so low as to be non-existant. Therefore any idiot can start producing content. You can even produce pretty good content for next to nothing (like/.). In a market where anybody can enter, competition will drive the price down to the minimum amount that will allow the manufacturers to stay open. And since there are nearly no fixed costs, that cost is the marginal cost, which as stated before, is darn near zero.
A meatspace example is farming. The barriers to entry to farming are pretty low. Anyone can get a loan to buy a couple hundred acres, get a load for seed/equipment/chemicals, and pay someone else to actually do the work for a low hourly wage. As a result, the cost of food has approached the cost of producing it. That is because as soon as the price of food rises much above the cost of production, somebody else will enter the market and supply more.
The only reason that more products aren't that cheap is barriers to entry. Take, for example, CPU's. It takes a lot of money to develop a CPU, and it is very risky. The barriers to entry are quite high. There are, then, only a handful of major CPU makers (Intel, IBM (S390), AMD, Sun (UltraSpark), Compaq (Alpha)). Since there are only a few firms competing, they act like an oligopily (read: sorta-monopoly), and can charge a higher price. On the other hand, RAM is dirt cheap (as far as chips go), mainly because it is so easy to design and fab RAM, leading to low(er) barriers to entry. Can you even count the number of RAM-chip producers? I thought not.
Now, that doesn't mean that you can't charge for information. Copyright allows an easy way to manufacture a barrier to entry (legally too). For example, take a look at how much the ACM's Digital Library cost (for the lazy, $38 for students, $185 otherwise, must already be a ACM member too). I pay that (and get my money's worth), because there is no other way to get that particular (and very high quality) content. The material is copyrighted, and ACM is (usually) the copyright holder (sometimes ACM doesn't have the copyright, but is one of few holders of distribution rights).
So, yes, that's exactly it. It's cheap because there is a "strong incentive" (market forces) to provide it for cheap.
Well, that is one way in which the XBox could make it all work. Since they are a 800 lb gorilla, I'm sure they can talk Intel into giving them chips with a low clock multiplier and a fast bus. They would need fast ram, and there is quite a premium for, say, 200 MHz SDRAM. However, from what I've heard, they are using a 133 or 100 MHz bus like everyone else.
Also, if they do fancy thing with dual-port RAM and whatnot, they increase their reliance on specialized hardware. Overall, they have a small handfull of devices (CPU, GPU, sound, DVD, controller) which are going to be competing for those resources. To get it to work well will complicate the design. They could have, however, just gone with a plain old non-unified architecture, and grabbed all of their parts off the shelf, or whatever special stuff they did design, would be equally applicable to PCs, and PC sales could help absorb the development costs.
Really, what I'm saying is that if you are 95% percent identical to a PC architecture already, you may as well just use a standard PC architecture. It works pretty damnn well, and while there is room for improvement in that you only care about 1 particular task (games), it isn't worth the extra design effort to deviate from standard. A commodity CPU on a commodity chipset with commodity RAM and a commodity DVD drive hanging off of a commodity IDE bus is pretty cheap, and can be made wicked fast at little expense. Yeah, you need nVidia's fancy new GPU, but nVidia is going to spread the development/manufacturing costs between MS and the PC gamer market, so it's just as good as if MS was buying a commodity video card too. Well, standard at least.
First off, a meg is huge for an embedded OS. Hell, my boot image is a (fairly bloated, IMHO) 700K. Handles all standard IDE/EIDE devices, SCSI, AGP, a dozen NIC's, more filesystems than I can count, and 3-4 sound cards. All without any modules. It is by no means an embedded OS. You, however, need a freakin' meg to bring up your DVD drive? I mean, that's all your ROM needs to do, is bring up the disk and finish booting from that.
Second, there are too drivers. They just ship on the game media, and don't need to be handled by the user. So, I suppose it is true that there are "non that the user will ever know about". Of course, if a game ships with buggy drivers, then there is no way to fix that, so you're just screwed. And I don't believe for a minute that you can write totally bug free drivers for something as complicated as a DirectX implementation. At least not without cutting out all of the features that make DirectX a viable choice as a 3D graphics library.
Third, are you serious about calling unified memory a plus? There is a very good reason why only cheap PC's use unified memory: it is waay tooo slooow. I remember a benchmark about a year back analysing the performance hit a unified memory architecture gave. It was about 7% for standard stuff, and pushing 20% for graphics-intensive stuff. Unified memory loses so bad that I doubt that your statement is even accurate. There is no way you can have the GPU and the CPU competing for the same memory bandwidth and still get a decent framerate. If it is a "unified" architecture, then I'd bet that the GPU has so much cache/buffer on it that it really isn't unified in any way but name.
If you want to do any good for the XBox, you should leave the PR to the people who have been hired to do it. Or at least get a clue first.
But I do agree with many of your points. I think really that the market has focused on being the coolests -- that is, having pretty graphics and slick features.
How many people here remember the Quest for Glory series (was also the Hero's Quest series) by Sierra? Wonderful games. Very fun, with relatively few bugs (well, terrible race conditions in QfG4, but those only surfaced several years later). Sadly, there will be no more QfG, as they lost a lot of money on QfG5. Why? Because they busted a wad on a fancy 3-D engine, and very detailed 3-D character models and other expensive artwork. QfG5 grossed more than any of the other games in the series, but it was just too expensive to code, debug, and produce artwork for.
The focus on fancy graphics is killing the PC gaming industry, yes. But isn't because there is anything inherently wrong with the PC as a gaming platform. I'd rather the quality of PC games increase. I have to have a fairly top of the line computer anyway for work. Going out and buying a console just to play games is an additional expense for me, not a cheaper alternative.
You may also want to make a chroot jail. Make a temporary directory, (say,/test). Copy/bin to/test/bin,/lib to/test/lib, and/usr/lib to/test/usr/lib. Then "chroot/test bash" after loging into nobody.
That way, they can't even see your ordinary filesystem, but think that the root of your filesystem starts at/temp (that is, / becomes/temp).
Both emacs and xemacs are GPL. I don't think vi or vim are gpl'ed, but they are "open source"
And if code developed with open source tools is out, well, I'd be very very surprised if there exists a BSD developer who didn't use emacs. Or gcc. Or gdb. Or gzip. Or gmake. Or gas. Or GNU tar. Or Mozilla. Or any of hundreds of fast, stable, portable, reliable GPLed development tools.
If you can't use code that was developed using open source tools, then I doubt that there is much in the way of code that you can use at all.
Those non-informational messages do contain information -- in their negative space. Sometimes things fail silently. There are no error messages. If you are expecting a success message, however, and don't recieve one, then the lack of a message indicates failure
On the other hand, some of the messages are useless. When my sound card driver loads, it outputs three lines:
es1371: found chip, vendor id 0x1274 device id 0x1371 revision 0x08
es1371: found es1371 rev 8 at io 0x1080 irq 11
es1371: features: joystick 0xx
That much information is overkill (and unneeded). Go ahead and throw out the results of profiling code. Go ahead and ditch the ReiserFS built in ad. Go ahead and throw out the copyright notices. But please keep the sucess messages - they are just as important as failure ones.
Yeah. Switch Hailstorm and Passport as needed. In any case I'm just pointing out the stupidity of massive centralized authentication/data storage. Leaves you with one big fat target to take down.
What version of g++/the c++ libs are you using?
Templates are the reason that C++ code tends to be big, and I'm running a fairly new 2.9whatever (moving to 3.0 as soon as I get around to updating glibc). Different versions of g++ have support templates to varying degrees, with varying effeciency (run-time speed and code size). Also, the compiler flags that are passed can make a big difference. I'm not sure what my default flags are (aliases, environment variables, and the configure options passed at compiler time (compiler compile time)), but they do generate fast code, just not small code. -fno-templates, -s, -no-unroll-loops, etc. affect code size quite a bit.
But really, using the obvious g++ foo.cc on my system generates fairly large binaries when you use C++. I'd would like to know why yours are so small.
But what Hailstorm is is having the same centralized authentication for many separate sites.
If the local NIS server gets 0wn3d, my/. login is still safe. If/. is hacked, my home box is still secure. And my credit card information isn't on any of them.
But if passport is hit, then it's all gone. Even worse, because of the way Passport has to authenticate for other sites, they have to store the tokens there for many sites. With NIS, the local machine passes on my password to the NIS machine, which checks it for validity. The NIS server doesn't know my password, it just is able to positively ID my password. Not necessarily true of Passport.
First off, yes it is true that my example doesn't scale. Cutting 99% is a fairly extreme.
But consider MS Office. Many of the DLL's were statically linked, even when there was no reason too, or if another portion of the same binary required the DLL anyway. Excel 95 did have that flight sim in it. And how much sheer cruft did they have anyway (megs of clipart, the damn paperclip, overlapping functionality, etc).
My point is that just about all programs can be put on a huge diet.
Another small point. Look the size of linux binaries. Compare them to equivilent Windows binaries (equivilent! compare CLI picture viewer to CLI picture viewer, compressor to compressor, etc). The linux binaries are almost always much smaller (half or less), for the simple reason that GCC makes very efficient use of shared libs. It almost never generates statically linked code. That cuts down the binaries to what is fairly unique to them. On the other hand, Windows programmers are familiar with DLL hell - the random and undetectable changing of DLL's that their programs require. Becuase it isn't safe to use dynamic linking, almost all 'doze
binaries are statically linked, and if they are dynamic, they include a copy of the dll in the distro, and require it to be located in the same directory as the binary to work. They may have code reuse, but there is no binary lib reuse.
Here is a little anectdote relating to executable size
I recently recompiled my kernel, and put in the MagicSysRq support. I had been playing with fork, and the killall/nukem-now support it offers was attractive. However, can be dangerous, and as such you have to put a '1' into/proc/sys/kernel/sysrq before it will work. Putting a '0' in instead will also work.
Now, I wanted to be able to turn this on/off from my user account w/out going to root. A script wouldn't do it as/proc isn't world writable, and you can't suid a script safely. Therefore I needed a very simple binary program. Being the lazy person that I am, I wrote it in C++:
int main(){
ofstream out;
out.open("/proc/sys/kernel/sysrq");
out << "1";
return 0;
}
Now, when I compiled it, I noticed that the filesize was a whopping 354K. 354K just to write a single character!!! That is way too much. So I decided to put it on a diet. First step: strip. Strip removes all of the debugging information from a file, which can really shrink it's size. It did, but still left a whopping 71K.
I then realized that the problem was using C++. So I switched to C, using file pointers, fopen, putc, and so on. This brought things down to a mere 12K. Stripping this brought a final size reduction to 3276 bytes. A very very slight reduction could be achieved by using the more raw calls to open() write() and close(), but only a couple of bytes.
Now, what is the moral of the story? It was a little harder to write the small version. I had to look up the exact semantics for fopen (I don't use C very often). I had to know about the existence of strip (or the -s flag for gcc will do the same). And I had to have the will to cut the size down. As a result I cut the binary to less than 1% of it's original size.
Now how many end-user apps:
have been written with absolutely no attemt to keep the size of the binary down?
haven't had their debugging symbols stripped?
statically link to common libraries rather than dynamically link?
statically link multiple times to the same library, and then dynamically link once or twice more just for good measure (hint: MS Office).
have lots and lots of extra features that only a small percentage of people use?
have totally unnecessary things (a whole flight sim in Excel!!)?
are written in "big" languages like C++ (especially for GUI work), or are written by people who would rather save themselves 5 minutes coding rather than slim something down, even a large amount?
The answer is "a lot"
Network computing is perfectly possible. It just takes a small amount of effort
Just consider for a moment the security implications.
You must remember that this is MS running the servers. Now, last I checked, they didn't exactly have a very good track record on security. Just think of what bad things could happen the first time somebody breaks into the Hailstorm servers and steals millions of people's login info at once. Or credit card info too, as there is talk about using Hailstorm to handle online purchasing too.
The very idea of a centralized single signon is moronic. I would hope that most people on/. realize that by now.
Seriously, when I first saw the article, I thought exactly the same thing. I don't remember the last time/. has had a technical article of this level, and I like it. THIS is the reason that I started reading/. in the first place.
Of course, since the article was posted on/., I had a hard time reading it, but if it wasn't on/. I wouldn't have know about it at all, so...
The PIII will be Intel's bread and butter until their 64-bit stuff is at least 9 months old.
Yes, Intel loves selling thousands and thousands of Celerons to the masses. But they'd rather sell hundreds and hundreds of PIII-based Xeons to the the server market. Street prices for some of those high-end Xeons run close to $2000. For one bloody CPU. Most big servers are at the minumum dual rigs. Many are quad.
Intel needs to have an excellent server offering to keep their lead there. They are starting to loose (already have lost?) the low-end to AMD. They still have the server market locked up, because AMD didn't have any SMP offerings. Now that AMD dual boards are out, Intel needs to offer something better than the current PIII's.
The trouble with Python is that it isn't a mainstream language. A CS program should really only teach a few languages, and as such the ones that are taught must be choosen carefully, and be fairly mainstream. That means that in order to cover the biggies (C/C++ and Java) there is a big incentive to use one of them for the intro. As I pointed out, both are fine, except that people tend to shove all of the OO crap onto into programmers when they use C++ or Java, and that C/C++ require pointers and memory management. If you can avoid the bad bits, both will work fine. It's easier to avoid the OO in Java than it is to avoid the OO, pointers, and memory management in C/C++, and therefore Java is a good choice.
Now, I really think you must agree that Python is NOT a mainstream language at all. Very few people know it compared to Perl, Java, C/C++, or Pascal. Heck, there may be more old Cobol programmers than there are Python programmers. It is a nonstandard, rarely used language. If you teach it as the intro language, you have taught your students something that they may not use much again, as nobody else knows it. You then also still need to teach them a "heavy" mainstream language, and may not have time (even in 4 years) to teach them another mainstream language.
Don't get me wrong, I am very impressed by Python. For my high school CS class, for a final project me and a friend wrote a fully-featured MUD. The teacher was worried that it was too much to chew, so to prove that it could be done, my friend did in real quick in Python. It took him 12 hours.
Together we spent the next 4 weeks to not quite fully reimplement it in C++. That says some bad things about C++ and some good things about Python.
Until Python has many many more users, though, I don't think that it is a good choice for an intro language. On the other hand, if someone is considering learning Perl, Python is a very good alternative. (BTW, Perl would be a terrible learning language. New programmers need structure, and while it is possible to write pretty Perl, it is way too easy to write very very ugly Perl).
Da. Stimmt. Very true. You are very right that variables, flow control, functions et al. are what are important.
The problem is that most CS departments don't like teaching languages. Therefore they must use a real (read: very powerful/widely used) language (C/C++/Java) for the into courses, so that later on, when students are doing more real-world things, they already have the language skills to do it.
Now, the first programming course I took (in high school) was a semester of C, then a semester of C++. Personally, I think that this is one of the best ways to go. C doesn't have any of the fancy OO stuff. It encourages you to use loops and function calls. It isn't some "pure" language (Smalltalk = pure OO, Lisp = pure functional, etc), and can therefore be used to teach a variety of styles. Porcedural-type programming is the simplest thing for a beginner to understand, but they do need to be introduced to recursion and OO too. C is a fairly solid, usable, simple language and allows such.
OK, now for the disclaimer. I said simple. There are 2 topics in C that are not simple, and I wish that there was a version of C where they were unneeded. Pointers and memory management. A lot of people find learning C difficult for the simple reason that pointers and memory management are confusing complex topics, and very integral to effective use of C.
Disclaimer part 2: I said usable. Another problem with C is that you can't do neat shit with it right away. Beginners want eye candy. They want to do something impresive, without too much difficulty. C is bad at that. No fancy graphics. No easy network code. None of the nifty things that other languages make fairly easy and removed from the hardware. You say that libraries aren't important for the first 3-6 months. I'd revise that to say teaching libraries isn't important for the first 3-6 months. But if you can provide some code that lets your students easily do something cool (they write maze-solving code, you write a graphical frontend for them), then they are more likely to stick with it.
Given that, I think that Java isn't that bad of a choice. Yes, Java is OO, which is a count against it as a teaching language. But it is garbage collected. It also has no pointers. These two things are very very nice for an intro language. I know that when we started pointers/memory management in HS, we lost 1/4 the class (and they had to take a drop). At the semester (where there was no drop penalty) we lost half again. The lack of these difficulties makes Java a very tempting choice. Also, Java has all of the eye candy one could possibly want, and then some. Yes, it isn't good to teach all of those fancy libraries to beginners, but giving them code that lets them use some of the fancy stuff is good encouragement.
Now, Java is OO. Most people teaching it as an intro language introduce the OO features. This is probably not good. But just because it has OO doesn't mean you have to use the OO. So there is some magic "public class fooclass{" stuff around all of your code. And instead of "int main(){" you have "public static int main(String []..." garbage. But you can still pretend that it is functional, or procedural, or whatever. Like C, Java is a hybrid language.
So, you say language features are unimportant. Fancy features are unimportant, but the simple features of
Garbage collection
No pointers
Hybridness
make Java, IMNSHO, a decent choice of an intro language.
Oh, and I'm not talking entirely out of my ass. My first CS course in high school was in C, but the intro college course I took was taught in Java. CS 101, while it did focus more on OO than I thought healthy, was a very good intro class nevertheless. The labs had a lot of provided code, and then ask you to fill in simple methods for it to work well. Overall, an excellent course, if a bit slow for someone who already knows how to program.
I guess it sums up that Java isn't a bad language to teach in, but that you need to teach it correctly (no OO, no libraries) for it to be good.
Re:Disappearing lines on maps
on
LED Flashlights
·
· Score: 1
One good thing about LEDs is that they simply grow dimmer as the battery runs down, unlike incandescents which have a tendency not to glow at all once the voltage falls below a critical point.
Umm, LED stands for Light Emmiting Diode. Diodes need to overcome a certain critical voltage (the reverse bias voltage) before they let more than nanoamps of current through (~.7 volts for silicon at room temperature). Less than that and they act as a close to ideal break. Much more and they closely approximate a short.
Perhaps you meant to say that they work well at low currents.
Yeah. Everybody's going to scream about OSHA and whatnot here in the US, but hear me out.
The safety, fair conduct, and labour laws here in the US don't do a whole lot to improve the safety and wellbeing of employees. The standards set by the government act as minimums, below which no company is allowed to sink. This has the effect of making the demand curve of safety to go vertical at the minimum. No matter what the cost of supplying safety, corps will buy at least the regulated amount of it (or go out of business). However, the remainder of the demand curve is mostly unaffected by the regulations, and remain about what they would be without them.
Now, what percentage of US companies exceed safety regulations? Almost all of them exceed them somewhat. That means that they are buying at a point to the left of the sharp jag in the demand curve. A point that is unaffected by the regulations. Therefore, as the laws are a minimum, most firms are acting as they would without the laws.
Now, there are areas where regulation helps. However, it is demonstratable that this is usully due to problems with negative externalities and property ownership. A quick overview, negative externalities are anything that someone does that is bad for people other than themselves that they don't take into consideration when they do it. So, if your coworker doesn't consider how you feel about it when they smoke in the office, that's a negative externality. If a company doesn't consider the environmental cost of polluting (because it doesn't affect them but rather everyone else) that is an externality.
The best way to deal with these problems is to internalize them. In the smoking example, you could clearly define the property rights. Two ways to do it are: everybody has an intrinsic right to smoke, or everybody has an intrinsic right to clean air. If you suppose the right to smoke, it is possible then for you to pay your coworker not to smoke (or smoke less). Depending on how much you dislike smoking, and how much he likes to smoke, there will be so much smoke in the air. If clean air is worth $50 to you, and smoking is worth $49.99 to your coworker, you can pay them $50, and have your clean air. They're up a penny (because they are forgoing smoking rights that they value at 49.99), and you get your clean air (for exactly as much as it's worth to you).
If you look at it the other way, there is an interesting twist. Now, how much do you really like clean air? Would you let your coworker smoke for $50.01? You can have your clean air, but perhaps you are forgoing $50 to get it. In other words, it is costing you $50 to get clean air, just as much as it costs your coworker $50 to smoke. Interstingly, the $50 figure is the same no matter which way you look at it. This isn't artificial, but would happen in the real world. (Please note since that I treated smoking as an all or nothing thing I had to jigger around with 49.99 and 50.01. If the quantity is a smooth function then that's unneccesary). The amount of smoking is the same either way too.
Now, this system is already being (successfully) used to moniter sulfer dioxide emmisions. Large emmiters of sulfer dioxide need to purchase permits. They can purchase the right to pollute so many tons a year. However, these permits are limited in number, and anyone can buy them (or sell them). As such, the right to emit sulfer dioxide has a strictly defined property right. If you, as a private citizen, think that too much SO2 is in the air, you can buy up licences (at the market price) and retire them. If an already low-emmiting company had a fairly cheap way to cut their emmissions, earlier they had no incentive to. Now, if they cut their emissions, they can sell their now unneeded licences. If a company has a high-emmiting plant, that would be terribly expensive to clean up, rather than shut it down, they can buy more licences. And when the EPA decides that there is too much SO2 around, they can retire some licences, and the market will have to adjust. BUT, they will adjust in the most efficient (moneywise) way. Yes, it is the invisible hand of the market choosing who pollutes. And it costs so much less that way. All that was needed was to define the property rights to SO2 emmision.
Alright, so that isn't exactly laisse-faire. But it isn't a regulation saying "you can only pollute so much." It is mearly refining existing property rights (or creating new ones) to eliminate a negative externality. Defending property rights isn't really regulation, but one of the essential purposes of government.
On a personal note, I see that SO2 scheme as one of the most effective environmention actions possible. However, as it is distasteful to some environmentalists that a company may actually have the right to pollute, similar programs for other pollutants may never happen. It's too bad too, since they would likely be very effective at minimal cost.
I presume that what Ballmer meant to say was "The only thing we have a problem with is when the government funds GPL'd work. Government funding should be for work that is available to everybody."
Well, maybe in an ideal world government money would only be spent on projects available to everybody (BSD licence/public domain). But there are numerous examples of the government paying for work, and then the researchers patenting it, and making a commercial product out of it. Now, I don't know about you, but GPLed code is a lot better than unreleased, patented, proprietary code.
First, I'd like to give a classic example of strongly correlated things with no causation.
Airconditioner useage is very strongly correlated with deaths by heatstroke. It's a very very strong correlation. In the past decade, almost nobody has died of heatstroke while airconditioner usage was low.
In this example, it is very easy to spot the third-variable effect: temperature. Nobody dies of heatstroke when it is cold outside. Also, nobody runs their airconditioner when it is cold. If it is 95 and humid out, many people will die of heatstroke. By the same token, everybody who is able will be running their airconditioner.
So, as you can see, it is very possible for two things to be correlated and not have a shred of causality between them either way. Now that that's done with, I'd like to talk about CD sales patterns amoung college students. There was a study done that quite thoughourly showed that there was a strong correlation between internet access at colleges and CD sales at nearby stores. The more internet access there was, the fewer CD's were sold.
Now, the study was done such that any possible third variable effects were tightly controlled. They compared entering freshmen classes to previous freshmen classes, and they compared classes against themselves (this years sophmores against last year's freshmen). To control any differences between these groups (this year's freshmen aren't into music, older students don't have as much free cash, etc), they also compared different universities against eachother, that as best the researchers could tell, differed only in how fast they rolled out Ethernet in the dorms. By trying very hard to control third-variable effects, the study could then claim to show causality.
The writeup of the study that I saw drew the conclusion that as more and more students got fast internet access, they became able to download their music from Napster, and therefore didn't need to buy CD's. However, a later study showed that students were buying more CDs than before. Now, we have to wonder, why did theearlierstudyfail?
The moral of the story is: yes, correlation doesn't necessarily mean causation, but if you're careful with third variable effects, it can mean causation. Even so, be sure you choose the correct source of causality.
I whole heartedly agree that 2600's argument style reflects favorably on their case. It is a much more honest and legitimate technique. The BS that the other two lawyers (read the transcript of the trial) tried to pull is one of the reasons that I have overall unfavorable feelings towards the whole legal proffesion.
As for stronger chances, it worries me that the judges even considered 2600 to be any different from the New York Times. In the transcript, they point out that 2600 is arguing as if everybody had been injoined from distributing DeCSS, rather than just them. At another time, one of the judges says something along the lines of "the injunction is very specific: YOU can't distribute DeCSS," and then hints that as such the 1st Amendment is not applicable.
Indeed, it scares me that they would consider the injunction and the lower court's interpretation of the DMCA to be constitutionally valid for the simple reason that only one person's speech is being controlled. A quote I've seen that well expresses my feelings on this is
If all mankind minus one, were of one opinion, and only one person were of the contrary opinion, mankind would be no more justified in silencing that one person, than he, if he had the power, would be justified in silencing mankind. -- On Liberty, John Stuart Mill
Slashdot Mirror
It came on my computer, i had to buy it
Well, now, that is a legitimate excuse. The MS oS was fairly popular for a long time because it was the only commercial choice. However, when other OS's for the PC became available, MS launched a campaign to prevent vendors from selling computers without a MS OS.
OEM's were given sweetheart deals on MS OSes, but usually on the conditiont that there was to be no other. They even kept OEM's from selling "naked" boxes by offering licences that were per PC shipped, regardless of whether or not it had an OS.
Now, I have a friend who bought a PC from one of the rare vendors who would sell it naked. He bought his own copy of Win95 (of his own free will, yes, and concious choice), and installed it himself. The hardware, however, was fairly defective. The vendor had a no-lemon policy, and so the third time the machine had to be sent in, they bought the machine back from him at the original price. This was a year and a half after he bought the machine, and he could now get a much nicer PC for the same money. So, he was now in the market for a new PC. At this point, though, it was impossible to find a vendow that didn't package Windows on the box. So my friend was forced to by an additional copy of an OS that he didn't need. He had his copy of '95 retail. Not even a EULA of dubious legality was keeping him from using it again. No copyright violation at all (the old machine had it's drives wiped). But he still had to buy Windows again
Now, you might counter with "well, why didn't he just get parts," or "this vendor this vendor and this vendor would be happy to sell naked PC". Well, parts wasn't an option. While he ws fairly software savvy, he needed the hardware support that you can only get from a big vendor (especially after the horror of hardware problems he'd had before). But all of the big vendors were coerced into signing exclusive agreements with MS.
So, while I suppose he doesn't use Windows against his will, he did have to buy it once against his will, and that, sir, is harmful to a consumer/consumers.
In that he thought that a PC was too much of a bitty box to be worth anything with. PC's were mostly no good because DOS blew chunks, and didn't come close to taking advantage of the hardware.
When he broke down and bought a PC, he got Minix because DOS blew. Linux was written because he felt he could right something decent. Later, as linux matured (approched v1.0), the goal (of Torvalds and the community) did become to write a PC OS to kick all of the others' collective asses. I suppose there were no explicit anti-MS sentiment, in that the MS offerings were so bad that they weren't worth making a comparison to. No hate of MS, but plenty of disdain. Truckloads of disdain.
And if I may expand on this a bit...
The content is going to stay free due to basic free-market effects. The barriers to entry are so low as to be non-existant. Therefore any idiot can start producing content. You can even produce pretty good content for next to nothing (like /.). In a market where anybody can enter, competition will drive the price down to the minimum amount that will allow the manufacturers to stay open. And since there are nearly no fixed costs, that cost is the marginal cost, which as stated before, is darn near zero.
A meatspace example is farming. The barriers to entry to farming are pretty low. Anyone can get a loan to buy a couple hundred acres, get a load for seed/equipment/chemicals, and pay someone else to actually do the work for a low hourly wage. As a result, the cost of food has approached the cost of producing it. That is because as soon as the price of food rises much above the cost of production, somebody else will enter the market and supply more.
The only reason that more products aren't that cheap is barriers to entry. Take, for example, CPU's. It takes a lot of money to develop a CPU, and it is very risky. The barriers to entry are quite high. There are, then, only a handful of major CPU makers (Intel, IBM (S390), AMD, Sun (UltraSpark), Compaq (Alpha)). Since there are only a few firms competing, they act like an oligopily (read: sorta-monopoly), and can charge a higher price. On the other hand, RAM is dirt cheap (as far as chips go), mainly because it is so easy to design and fab RAM, leading to low(er) barriers to entry. Can you even count the number of RAM-chip producers? I thought not.
Now, that doesn't mean that you can't charge for information. Copyright allows an easy way to manufacture a barrier to entry (legally too). For example, take a look at how much the ACM's Digital Library cost (for the lazy, $38 for students, $185 otherwise, must already be a ACM member too). I pay that (and get my money's worth), because there is no other way to get that particular (and very high quality) content. The material is copyrighted, and ACM is (usually) the copyright holder (sometimes ACM doesn't have the copyright, but is one of few holders of distribution rights).
So, yes, that's exactly it. It's cheap because there is a "strong incentive" (market forces) to provide it for cheap.
Well, that is one way in which the XBox could make it all work. Since they are a 800 lb gorilla, I'm sure they can talk Intel into giving them chips with a low clock multiplier and a fast bus. They would need fast ram, and there is quite a premium for, say, 200 MHz SDRAM. However, from what I've heard, they are using a 133 or 100 MHz bus like everyone else.
Also, if they do fancy thing with dual-port RAM and whatnot, they increase their reliance on specialized hardware. Overall, they have a small handfull of devices (CPU, GPU, sound, DVD, controller) which are going to be competing for those resources. To get it to work well will complicate the design. They could have, however, just gone with a plain old non-unified architecture, and grabbed all of their parts off the shelf, or whatever special stuff they did design, would be equally applicable to PCs, and PC sales could help absorb the development costs.
Really, what I'm saying is that if you are 95% percent identical to a PC architecture already, you may as well just use a standard PC architecture. It works pretty damnn well, and while there is room for improvement in that you only care about 1 particular task (games), it isn't worth the extra design effort to deviate from standard. A commodity CPU on a commodity chipset with commodity RAM and a commodity DVD drive hanging off of a commodity IDE bus is pretty cheap, and can be made wicked fast at little expense. Yeah, you need nVidia's fancy new GPU, but nVidia is going to spread the development/manufacturing costs between MS and the PC gamer market, so it's just as good as if MS was buying a commodity video card too. Well, standard at least.
Gads. Where to begin?
First off, a meg is huge for an embedded OS. Hell, my boot image is a (fairly bloated, IMHO) 700K. Handles all standard IDE/EIDE devices, SCSI, AGP, a dozen NIC's, more filesystems than I can count, and 3-4 sound cards. All without any modules. It is by no means an embedded OS. You, however, need a freakin' meg to bring up your DVD drive? I mean, that's all your ROM needs to do, is bring up the disk and finish booting from that.
Second, there are too drivers. They just ship on the game media, and don't need to be handled by the user. So, I suppose it is true that there are "non that the user will ever know about". Of course, if a game ships with buggy drivers, then there is no way to fix that, so you're just screwed. And I don't believe for a minute that you can write totally bug free drivers for something as complicated as a DirectX implementation. At least not without cutting out all of the features that make DirectX a viable choice as a 3D graphics library.
Third, are you serious about calling unified memory a plus? There is a very good reason why only cheap PC's use unified memory: it is waay tooo slooow. I remember a benchmark about a year back analysing the performance hit a unified memory architecture gave. It was about 7% for standard stuff, and pushing 20% for graphics-intensive stuff. Unified memory loses so bad that I doubt that your statement is even accurate. There is no way you can have the GPU and the CPU competing for the same memory bandwidth and still get a decent framerate. If it is a "unified" architecture, then I'd bet that the GPU has so much cache/buffer on it that it really isn't unified in any way but name.
If you want to do any good for the XBox, you should leave the PR to the people who have been hired to do it. Or at least get a clue first.
But I do agree with many of your points. I think really that the market has focused on being the coolests -- that is, having pretty graphics and slick features.
How many people here remember the Quest for Glory series (was also the Hero's Quest series) by Sierra? Wonderful games. Very fun, with relatively few bugs (well, terrible race conditions in QfG4, but those only surfaced several years later). Sadly, there will be no more QfG, as they lost a lot of money on QfG5. Why? Because they busted a wad on a fancy 3-D engine, and very detailed 3-D character models and other expensive artwork. QfG5 grossed more than any of the other games in the series, but it was just too expensive to code, debug, and produce artwork for.
The focus on fancy graphics is killing the PC gaming industry, yes. But isn't because there is anything inherently wrong with the PC as a gaming platform. I'd rather the quality of PC games increase. I have to have a fairly top of the line computer anyway for work. Going out and buying a console just to play games is an additional expense for me, not a cheaper alternative.
You may also want to make a chroot jail. Make a temporary directory, (say, /test). Copy /bin to /test/bin, /lib to /test/lib, and /usr/lib to /test/usr/lib. Then "chroot /test bash" after loging into nobody.
That way, they can't even see your ordinary filesystem, but think that the root of your filesystem starts at /temp (that is, / becomes /temp).
Both emacs and xemacs are GPL. I don't think vi or vim are gpl'ed, but they are "open source"
And if code developed with open source tools is out, well, I'd be very very surprised if there exists a BSD developer who didn't use emacs. Or gcc. Or gdb. Or gzip. Or gmake. Or gas. Or GNU tar. Or Mozilla. Or any of hundreds of fast, stable, portable, reliable GPLed development tools.
If you can't use code that was developed using open source tools, then I doubt that there is much in the way of code that you can use at all.
Those non-informational messages do contain information -- in their negative space. Sometimes things fail silently. There are no error messages. If you are expecting a success message, however, and don't recieve one, then the lack of a message indicates failure
On the other hand, some of the messages are useless. When my sound card driver loads, it outputs three lines:
es1371: found chip, vendor id 0x1274 device id 0x1371 revision 0x08
es1371: found es1371 rev 8 at io 0x1080 irq 11
es1371: features: joystick 0xx
That much information is overkill (and unneeded). Go ahead and throw out the results of profiling code. Go ahead and ditch the ReiserFS built in ad. Go ahead and throw out the copyright notices. But please keep the sucess messages - they are just as important as failure ones.
Not Gephardt. Can't you even read the little blurb on /. (much less the article itself)?
Yeah. Switch Hailstorm and Passport as needed. In any case I'm just pointing out the stupidity of massive centralized authentication/data storage. Leaves you with one big fat target to take down.
I re-wrote the code to check it too.
I did #include both fstream.h and iostream.h
What version of g++/the c++ libs are you using? Templates are the reason that C++ code tends to be big, and I'm running a fairly new 2.9whatever (moving to 3.0 as soon as I get around to updating glibc). Different versions of g++ have support templates to varying degrees, with varying effeciency (run-time speed and code size). Also, the compiler flags that are passed can make a big difference. I'm not sure what my default flags are (aliases, environment variables, and the configure options passed at compiler time (compiler compile time)), but they do generate fast code, just not small code. -fno-templates, -s, -no-unroll-loops, etc. affect code size quite a bit.
But really, using the obvious g++ foo.cc on my system generates fairly large binaries when you use C++. I'd would like to know why yours are so small.
But what Hailstorm is is having the same centralized authentication for many separate sites.
If the local NIS server gets 0wn3d, my /. login is still safe. If /. is hacked, my home box is still secure. And my credit card information isn't on any of them.
But if passport is hit, then it's all gone. Even worse, because of the way Passport has to authenticate for other sites, they have to store the tokens there for many sites. With NIS, the local machine passes on my password to the NIS machine, which checks it for validity. The NIS server doesn't know my password, it just is able to positively ID my password. Not necessarily true of Passport.
First off, yes it is true that my example doesn't scale. Cutting 99% is a fairly extreme.
But consider MS Office. Many of the DLL's were statically linked, even when there was no reason too, or if another portion of the same binary required the DLL anyway. Excel 95 did have that flight sim in it. And how much sheer cruft did they have anyway (megs of clipart, the damn paperclip, overlapping functionality, etc). My point is that just about all programs can be put on a huge diet.
Another small point. Look the size of linux binaries. Compare them to equivilent Windows binaries (equivilent! compare CLI picture viewer to CLI picture viewer, compressor to compressor, etc). The linux binaries are almost always much smaller (half or less), for the simple reason that GCC makes very efficient use of shared libs. It almost never generates statically linked code. That cuts down the binaries to what is fairly unique to them. On the other hand, Windows programmers are familiar with DLL hell - the random and undetectable changing of DLL's that their programs require. Becuase it isn't safe to use dynamic linking, almost all 'doze binaries are statically linked, and if they are dynamic, they include a copy of the dll in the distro, and require it to be located in the same directory as the binary to work. They may have code reuse, but there is no binary lib reuse.
Here is a little anectdote relating to executable size
I recently recompiled my kernel, and put in the MagicSysRq support. I had been playing with fork, and the killall/nukem-now support it offers was attractive. However, can be dangerous, and as such you have to put a '1' into /proc/sys/kernel/sysrq before it will work. Putting a '0' in instead will also work.
Now, I wanted to be able to turn this on/off from my user account w/out going to root. A script wouldn't do it as /proc isn't world writable, and you can't suid a script safely. Therefore I needed a very simple binary program. Being the lazy person that I am, I wrote it in C++:
int main(){ofstream out;
out.open("/proc/sys/kernel/sysrq");
out << "1";
return 0;
}
Now, when I compiled it, I noticed that the filesize was a whopping 354K. 354K just to write a single character!!! That is way too much. So I decided to put it on a diet. First step: strip. Strip removes all of the debugging information from a file, which can really shrink it's size. It did, but still left a whopping 71K.
I then realized that the problem was using C++. So I switched to C, using file pointers, fopen, putc, and so on. This brought things down to a mere 12K. Stripping this brought a final size reduction to 3276 bytes. A very very slight reduction could be achieved by using the more raw calls to open() write() and close(), but only a couple of bytes.
Now, what is the moral of the story? It was a little harder to write the small version. I had to look up the exact semantics for fopen (I don't use C very often). I had to know about the existence of strip (or the -s flag for gcc will do the same). And I had to have the will to cut the size down. As a result I cut the binary to less than 1% of it's original size.
Now how many end-user apps:
The answer is "a lot"
Network computing is perfectly possible. It just takes a small amount of effort
Just consider for a moment the security implications.
You must remember that this is MS running the servers. Now, last I checked, they didn't exactly have a very good track record on security. Just think of what bad things could happen the first time somebody breaks into the Hailstorm servers and steals millions of people's login info at once. Or credit card info too, as there is talk about using Hailstorm to handle online purchasing too.
The very idea of a centralized single signon is moronic. I would hope that most people on /. realize that by now.
Da! Yes! I agree!!
Seriously, when I first saw the article, I thought exactly the same thing. I don't remember the last time /. has had a technical article of this level, and I like it. THIS is the reason that I started reading /. in the first place.
Of course, since the article was posted on /., I had a hard time reading it, but if it wasn't on /. I wouldn't have know about it at all, so...
The PIII will be Intel's bread and butter until their 64-bit stuff is at least 9 months old.
Yes, Intel loves selling thousands and thousands of Celerons to the masses. But they'd rather sell hundreds and hundreds of PIII-based Xeons to the the server market. Street prices for some of those high-end Xeons run close to $2000. For one bloody CPU. Most big servers are at the minumum dual rigs. Many are quad.
Intel needs to have an excellent server offering to keep their lead there. They are starting to loose (already have lost?) the low-end to AMD. They still have the server market locked up, because AMD didn't have any SMP offerings. Now that AMD dual boards are out, Intel needs to offer something better than the current PIII's.
The trouble with Python is that it isn't a mainstream language. A CS program should really only teach a few languages, and as such the ones that are taught must be choosen carefully, and be fairly mainstream. That means that in order to cover the biggies (C/C++ and Java) there is a big incentive to use one of them for the intro. As I pointed out, both are fine, except that people tend to shove all of the OO crap onto into programmers when they use C++ or Java, and that C/C++ require pointers and memory management. If you can avoid the bad bits, both will work fine. It's easier to avoid the OO in Java than it is to avoid the OO, pointers, and memory management in C/C++, and therefore Java is a good choice.
Now, I really think you must agree that Python is NOT a mainstream language at all. Very few people know it compared to Perl, Java, C/C++, or Pascal. Heck, there may be more old Cobol programmers than there are Python programmers. It is a nonstandard, rarely used language. If you teach it as the intro language, you have taught your students something that they may not use much again, as nobody else knows it. You then also still need to teach them a "heavy" mainstream language, and may not have time (even in 4 years) to teach them another mainstream language.
Don't get me wrong, I am very impressed by Python. For my high school CS class, for a final project me and a friend wrote a fully-featured MUD. The teacher was worried that it was too much to chew, so to prove that it could be done, my friend did in real quick in Python. It took him 12 hours.
Together we spent the next 4 weeks to not quite fully reimplement it in C++. That says some bad things about C++ and some good things about Python.
Until Python has many many more users, though, I don't think that it is a good choice for an intro language. On the other hand, if someone is considering learning Perl, Python is a very good alternative. (BTW, Perl would be a terrible learning language. New programmers need structure, and while it is possible to write pretty Perl, it is way too easy to write very very ugly Perl).
Da. Stimmt. Very true. You are very right that variables, flow control, functions et al. are what are important.
The problem is that most CS departments don't like teaching languages. Therefore they must use a real (read: very powerful/widely used) language (C/C++/Java) for the into courses, so that later on, when students are doing more real-world things, they already have the language skills to do it.
Now, the first programming course I took (in high school) was a semester of C, then a semester of C++. Personally, I think that this is one of the best ways to go. C doesn't have any of the fancy OO stuff. It encourages you to use loops and function calls. It isn't some "pure" language (Smalltalk = pure OO, Lisp = pure functional, etc), and can therefore be used to teach a variety of styles. Porcedural-type programming is the simplest thing for a beginner to understand, but they do need to be introduced to recursion and OO too. C is a fairly solid, usable, simple language and allows such.
OK, now for the disclaimer. I said simple. There are 2 topics in C that are not simple, and I wish that there was a version of C where they were unneeded. Pointers and memory management. A lot of people find learning C difficult for the simple reason that pointers and memory management are confusing complex topics, and very integral to effective use of C.
Disclaimer part 2: I said usable. Another problem with C is that you can't do neat shit with it right away. Beginners want eye candy. They want to do something impresive, without too much difficulty. C is bad at that. No fancy graphics. No easy network code. None of the nifty things that other languages make fairly easy and removed from the hardware. You say that libraries aren't important for the first 3-6 months. I'd revise that to say teaching libraries isn't important for the first 3-6 months. But if you can provide some code that lets your students easily do something cool (they write maze-solving code, you write a graphical frontend for them), then they are more likely to stick with it.
Given that, I think that Java isn't that bad of a choice. Yes, Java is OO, which is a count against it as a teaching language. But it is garbage collected. It also has no pointers. These two things are very very nice for an intro language. I know that when we started pointers/memory management in HS, we lost 1/4 the class (and they had to take a drop). At the semester (where there was no drop penalty) we lost half again. The lack of these difficulties makes Java a very tempting choice. Also, Java has all of the eye candy one could possibly want, and then some. Yes, it isn't good to teach all of those fancy libraries to beginners, but giving them code that lets them use some of the fancy stuff is good encouragement.
Now, Java is OO. Most people teaching it as an intro language introduce the OO features. This is probably not good. But just because it has OO doesn't mean you have to use the OO. So there is some magic "public class fooclass{" stuff around all of your code. And instead of "int main(){" you have "public static int main(String []..." garbage. But you can still pretend that it is functional, or procedural, or whatever. Like C, Java is a hybrid language.
So, you say language features are unimportant. Fancy features are unimportant, but the simple features of
- Garbage collection
- No pointers
- Hybridness
make Java, IMNSHO, a decent choice of an intro language.Oh, and I'm not talking entirely out of my ass. My first CS course in high school was in C, but the intro college course I took was taught in Java. CS 101, while it did focus more on OO than I thought healthy, was a very good intro class nevertheless. The labs had a lot of provided code, and then ask you to fill in simple methods for it to work well. Overall, an excellent course, if a bit slow for someone who already knows how to program.
I guess it sums up that Java isn't a bad language to teach in, but that you need to teach it correctly (no OO, no libraries) for it to be good.
One good thing about LEDs is that they simply grow dimmer as the battery runs down, unlike incandescents which have a tendency not to glow at all once the voltage falls below a critical point.
Umm, LED stands for Light Emmiting Diode. Diodes need to overcome a certain critical voltage (the reverse bias voltage) before they let more than nanoamps of current through (~ .7 volts for silicon at room temperature). Less than that and they act as a close to ideal break. Much more and they closely approximate a short.
Perhaps you meant to say that they work well at low currents.
Yeah. Everybody's going to scream about OSHA and whatnot here in the US, but hear me out.
The safety, fair conduct, and labour laws here in the US don't do a whole lot to improve the safety and wellbeing of employees. The standards set by the government act as minimums, below which no company is allowed to sink. This has the effect of making the demand curve of safety to go vertical at the minimum. No matter what the cost of supplying safety, corps will buy at least the regulated amount of it (or go out of business). However, the remainder of the demand curve is mostly unaffected by the regulations, and remain about what they would be without them.
Now, what percentage of US companies exceed safety regulations? Almost all of them exceed them somewhat. That means that they are buying at a point to the left of the sharp jag in the demand curve. A point that is unaffected by the regulations. Therefore, as the laws are a minimum, most firms are acting as they would without the laws.
Now, there are areas where regulation helps. However, it is demonstratable that this is usully due to problems with negative externalities and property ownership. A quick overview, negative externalities are anything that someone does that is bad for people other than themselves that they don't take into consideration when they do it. So, if your coworker doesn't consider how you feel about it when they smoke in the office, that's a negative externality. If a company doesn't consider the environmental cost of polluting (because it doesn't affect them but rather everyone else) that is an externality.
The best way to deal with these problems is to internalize them. In the smoking example, you could clearly define the property rights. Two ways to do it are: everybody has an intrinsic right to smoke, or everybody has an intrinsic right to clean air. If you suppose the right to smoke, it is possible then for you to pay your coworker not to smoke (or smoke less). Depending on how much you dislike smoking, and how much he likes to smoke, there will be so much smoke in the air. If clean air is worth $50 to you, and smoking is worth $49.99 to your coworker, you can pay them $50, and have your clean air. They're up a penny (because they are forgoing smoking rights that they value at 49.99), and you get your clean air (for exactly as much as it's worth to you).
If you look at it the other way, there is an interesting twist. Now, how much do you really like clean air? Would you let your coworker smoke for $50.01? You can have your clean air, but perhaps you are forgoing $50 to get it. In other words, it is costing you $50 to get clean air, just as much as it costs your coworker $50 to smoke. Interstingly, the $50 figure is the same no matter which way you look at it. This isn't artificial, but would happen in the real world. (Please note since that I treated smoking as an all or nothing thing I had to jigger around with 49.99 and 50.01. If the quantity is a smooth function then that's unneccesary). The amount of smoking is the same either way too.
Now, this system is already being (successfully) used to moniter sulfer dioxide emmisions. Large emmiters of sulfer dioxide need to purchase permits. They can purchase the right to pollute so many tons a year. However, these permits are limited in number, and anyone can buy them (or sell them). As such, the right to emit sulfer dioxide has a strictly defined property right. If you, as a private citizen, think that too much SO2 is in the air, you can buy up licences (at the market price) and retire them. If an already low-emmiting company had a fairly cheap way to cut their emmissions, earlier they had no incentive to. Now, if they cut their emissions, they can sell their now unneeded licences. If a company has a high-emmiting plant, that would be terribly expensive to clean up, rather than shut it down, they can buy more licences. And when the EPA decides that there is too much SO2 around, they can retire some licences, and the market will have to adjust. BUT, they will adjust in the most efficient (moneywise) way. Yes, it is the invisible hand of the market choosing who pollutes. And it costs so much less that way. All that was needed was to define the property rights to SO2 emmision.
Alright, so that isn't exactly laisse-faire. But it isn't a regulation saying "you can only pollute so much." It is mearly refining existing property rights (or creating new ones) to eliminate a negative externality. Defending property rights isn't really regulation, but one of the essential purposes of government.
On a personal note, I see that SO2 scheme as one of the most effective environmention actions possible. However, as it is distasteful to some environmentalists that a company may actually have the right to pollute, similar programs for other pollutants may never happen. It's too bad too, since they would likely be very effective at minimal cost.
Hmm... I seem to have wandered a bit. Oh well.
I presume that what Ballmer meant to say was "The only thing we have a problem with is when the government funds GPL'd work. Government funding should be for work that is available to everybody."
Well, maybe in an ideal world government money would only be spent on projects available to everybody (BSD licence/public domain). But there are numerous examples of the government paying for work, and then the researchers patenting it, and making a commercial product out of it. Now, I don't know about you, but GPLed code is a lot better than unreleased, patented, proprietary code.
First, I'd like to give a classic example of strongly correlated things with no causation.
Airconditioner useage is very strongly correlated with deaths by heatstroke. It's a very very strong correlation. In the past decade, almost nobody has died of heatstroke while airconditioner usage was low.
In this example, it is very easy to spot the third-variable effect: temperature. Nobody dies of heatstroke when it is cold outside. Also, nobody runs their airconditioner when it is cold. If it is 95 and humid out, many people will die of heatstroke. By the same token, everybody who is able will be running their airconditioner.
So, as you can see, it is very possible for two things to be correlated and not have a shred of causality between them either way. Now that that's done with, I'd like to talk about CD sales patterns amoung college students. There was a study done that quite thoughourly showed that there was a strong correlation between internet access at colleges and CD sales at nearby stores. The more internet access there was, the fewer CD's were sold.
Now, the study was done such that any possible third variable effects were tightly controlled. They compared entering freshmen classes to previous freshmen classes, and they compared classes against themselves (this years sophmores against last year's freshmen). To control any differences between these groups (this year's freshmen aren't into music, older students don't have as much free cash, etc), they also compared different universities against eachother, that as best the researchers could tell, differed only in how fast they rolled out Ethernet in the dorms. By trying very hard to control third-variable effects, the study could then claim to show causality.
The writeup of the study that I saw drew the conclusion that as more and more students got fast internet access, they became able to download their music from Napster, and therefore didn't need to buy CD's. However, a later study showed that students were buying more CDs than before. Now, we have to wonder, why did the earlier study fail?
The moral of the story is: yes, correlation doesn't necessarily mean causation, but if you're careful with third variable effects, it can mean causation. Even so, be sure you choose the correct source of causality.
I whole heartedly agree that 2600's argument style reflects favorably on their case. It is a much more honest and legitimate technique. The BS that the other two lawyers (read the transcript of the trial) tried to pull is one of the reasons that I have overall unfavorable feelings towards the whole legal proffesion.
As for stronger chances, it worries me that the judges even considered 2600 to be any different from the New York Times. In the transcript, they point out that 2600 is arguing as if everybody had been injoined from distributing DeCSS, rather than just them. At another time, one of the judges says something along the lines of "the injunction is very specific: YOU can't distribute DeCSS," and then hints that as such the 1st Amendment is not applicable.
Indeed, it scares me that they would consider the injunction and the lower court's interpretation of the DMCA to be constitutionally valid for the simple reason that only one person's speech is being controlled. A quote I've seen that well expresses my feelings on this is