No, it is censorship, it is wrong, and capitalism won't fix it.
The contracts won't tell you up front that you're being censored. It will be covered in the contract by some provision to the effect of: "We reserve the right to do anything we damn well please, in which case you'll just have to take it up the ass from us"
In most markets (telecomms included) there are always three major players that dominate the market once it matures. It's really easy for all three to agree to the same underhanded tactics, and then your capitalism as a savior goes out the window.
It's nto the consumers' ignorance that leads them into these traps. Lots of companies (dare I say "most" large US corporations) are quite underhanded in dealing with their customers, and quite good at hiding that fact from the unwashed masses. The end result is that they are very effectively duped, they don't have any way of knowing ahead of time they crap they're going to end up taking, and they don't have any capitalistic alternative because all the competing companies do the same.
For examples of all of the above, look at the US long distance market, the cable/broadcast/satellite television markets, the local phone market, the broadband access market, airlines, hell even markets like grocery stores.
No ifs, ands, or buts. Censorship is just a bad thing. If they have bandwidth problems, they can rate limit the users. That's an entirely different concept than limiting them based on the content of the traffic.
It's true about AMDs speeding up, but what I meant originally by "processor specific" still does apply. AMD is an IA32 clone of sorts and it's just that AMD and Intel x86 are close enough that there are general x86 techniques that help both. If icc were ever ported to MIPS or something, I would expect much of the speed gains they had in x86-land would have to be re-engineered from scratch.
In contrast, while gcc has processor-specific optimizations for a number of targets, they have also concentrated on deeply generic optimizations in parts of the code generation that are common to all languages and platforms. Some of the code in gcc has a certain symmetry with very important and often-ill-defined central CS concepts because of this.
By all means use icc for your production code. What I'm anti-advocating is retrofitting standard linux distributions to compile with icc, because I feel that would detract large hordes from the gcc userbase, causing it to suffer. As stated elsewhere, the fact that gcc even comes close is remarkable, considering the age of the compiler, and the fact that it supports a gadzillion different platforms and several different language front-ends to the same code-generating back-end. icc just supports one language family on one architecture, and happens to be written by the same company that designed the cpu for that architecture:)
For that matter, thinking about this icc thing has brought me around to another point of view as well: Since C is such a ubiquitous language, especially for systems software and kernels... A chip vendor providing a free compiler should almost be mandatory, much like a video card manufacturer providing a free driver. Kinda nice that Intel does seem to agree with this way of thinking. Of course I'd be 10 times happier if Intel would GPL icc and let the more robust gcc suck up their x86 optimizations. Other commercial companies and donated significant r&d efforts into donated optimization code to gcc, why not Intel?
But it's also my understanding that the Linux kernel code likes to have more control over the resulting binary than ANSI C really dictates, and that they use lots of trickery specific to gcc (and even to certain revisions of gcc) to get thigns done. Seems supporting all this trickery in another compiler would lead to even more #ifdefs and bloat and bugginess to me.
Please people, don't go making patches and whatnot for all the standard linux distro package source code to get everyone compiling on this Intel compiler. For normal system services, the performance gain isn't worth the loss of the highly multiplatform and highly GPL gcc we have today, and it would be a shame for gcc to fall by the wayside in common use (probably 80% of gcc compilations are x86 linux) because of small performance gains you won't really notice.
The Intel compiler sounds pretty damn good, but it should really be left for those one-off needs (like compiling a custom scientific application for your beowulf cluster), not general use.
The consensus (probably correct) is that it's going to be quite difficult to implement, and it will always have corner cases which cause problems and maintenance nightmares, or worse hijacking of public sites.
So here's a semi-manual different approach:
Setup the yadda yadda yadda firewall+nat+dhcp standard setup, assuming that all clients are set for dhcp.
Build a "laptop checker" box with a port hanging out at the reception desk. Inform clients that if they use DHCP (autodetect) like most companies do, they will be fine. If they have doubts or don't know, you can test their laptop's network compatibility for them.
They plug into the network jack, either a green, yellow or red light lights up near the jack (linux can easily control LEDs:)
Green means the test machine got a DHCP request from the laptop, so it should be ok.
Yellow means no DHCP request, and we saw traffic sourced from some random IP. The IP was pinged for on the outside internet, and found to be non-responsive (unlikely hijacking), and doesn't seem wierd in any other way (multicast IP, or the IP of one of your routers, or the IP of another Yellow Light customer currently checked in, or anything else goofy). The receptionist can then (from some little gui) tell the network tester to allow them access. This turns on a special route for them on the inside, and sets it to be removed when they check out. They are warned that if they got the yellow light, we can't support any technical problems they may experience.
A Red light means there was no DHCP response, and either we didnt see any traffic at all to look at, or they have some bad IP we dont want to assign. We dont add any routes, and we tell them it won't work.
In both yellow and red conditions, you probably want a little handout to give them that walks through the basics of making your laptop autoconfig so it will work "properly".
First off, for security this gateway box should be running OpenBSD. Nothing else can compete when it comes to being a secure firewall that's open source, flexible, and feature-rich. That aside...
Run a stateful packet filter and NAT, do all the standard stuff so that they can get out via HTTP, mail protocols, FTP, and VPN (i.e. Cisco vpn cleints).
Run a DHCP service for the (hopefully majority of) users that either use DHCP anyways, or have the smarts to set their network control panel in winbloze to "autodetect" when they plug into the hotel.
It's the handling of the wierdos that is problematic. One can assume that the worst case you're willing to support is a guy with a static network configuration of a certain IP, gateway, netmask, and nameservers, all of which don't from the hotel (they are from some company's intranet).
First off, get a real subnet for the internal NATted DHCP, so that hopefully nobody but you will have used it (i.e. if you used 192.168.x.x, a lot of static config laptops might just happen to use it too, and it would be hard to tell them from your well-behaved DHCP clients).
Have a sniff on the inside network logging all packets whose source address doesn't match your assigned network. Dynamically insert a rule into your PF and your routing table to make things work for any IP you see on the wire (i.e. you see a source packet from 1.2.3.4, you add into your PF/NAT/Routing setup rules/routes/etc that allow that IP to work). The real trick here is avoiding the problem of someone's laptop having www.yahoo.com's IP address. You might ahve to play some funny rule or policy/tagging trickery to make sure that these added routes don't apply to outbound traffic from other clients.
Proxy arp for EVERYTHING but your internal assigned client IPs on your internal interface, this should take care of their random default gateway setting. Grab all DNS requests (port 53) and silently redirect them to the local DNS service regardless of where they were supposed to go.
etc... etc...
I'd have to actually set up a test environment and do this once to find all the flaws and fix them, but you should be able to go down that general path and make it work.
EULAs *are* immoral. Proprietary software *is* immoral. If you're giong to make a proprietary binary software and sell it to me, I would feel much less wronged if you actually sold me the binary, instead of a license to use as you see fit.
I feel no need to back up my "EULAs are immoral statement", and it's not sloppy of me to just throw it out there. To back it up one merely has to reference numerous papers published in the free software community. Basic knowledge of the premises of these papers is required reading for participating in a slashdot discussion on software licensing, so it's reasonable for me to make a simple statement of which side of the fence I'm on and assume you know why.
If you really need pointers, start with a look around gnu.org, lpf.ai.mit.edu, osi, www.tuxedo.org/~esr, etc...
Aside from the "real" issue that EULAs are morally wrong, surely an appeal can be made to non-enforcement. I don't know the legal wording, but it seems there's probably a way to say in legal terms "Look, this law/contract gets broken hundreds of times per day, and nobody really cares or enforces it, therefore when you single me out and enforce a EULA on me, you're really being discriminatory and using the law/contract to acheive some other goal".
There must be some legal precedent for the concept of "If you never actively enforce a law, and allow it to be broken (in obvious publicly-visible ways) over and over, you can't then go at a later date enforcing it at will on specific people you decide to target, it's not right".
For that matter, if such a legal principle exists, I'd really like to see someone apply it to the traffic ticket system as well.
They also don't explicitly recognize any of the other myriad technical terms from hundreds of other special fields. The essential problems being programmed for in Medical Billing probably share 99% with those encountered in Random_Industry_X billing. There's no reason one can't write sufficiently extensible and flexible generic financial software.
It's an invented, contrived category. The proper solution is a flexible, extensible generic financial system, which could apply itself to Medical Billing among many other things. You might ahve better luck searching for open source billing/financial software than "medical billing" and modifying it to taste.
Could someone please explain the extent to which space imagery in general (and particularly today's stunning hubble images) is altered by artists? I'm of the understanding that the original image was not actually of visible light, due to the doppler shift, and therefore the color image is "constructed" from an uglier image.
Is there some science to "unshifting" the colors such that the colors in the picture are "correct", or are they just picked on a whim by an artist?
Also the sharply pointed glare/lensfx spikes around the bright stars look like they are faked-in as well to me... Were they artistically added, were they artifacts of the original camera, or does it "really" look that way?
I'd appreciate these stories (i.e. Washington Post article) more if they would be mroe direct with the public about how much is "real" and how much is pure art. I'm sure 99% of their viewers (sheep) believe these are direct camera snapshots of the universe and nobody is telling them any different.
Investors need to get their heads out of their asses and realize that they can't let companies do this. For one, most investors are employees of *some* other company. Two, we all know in the long run hurting your employees hurts you as a company. If the investors (that's us, working joes with our etrade accounts) would unload a company's stock when they see the company take anti-employee action in a pinch, it would teach them to cut the golf trips and multi-million-dollar executive bonuses before they cut into the real employees.
Yeah your paper is fairly close to a what a real hashing out of the ideas in my 30-seconds-of-thought comment above would have been. The difference is that you seem to have an emphasis on payment being kinda automatic and built-in, with it left to the user to "hack out" the system if they dont want to pay. I prefer an opt-in setup where people continue to get their art/music completely for free, but there's an obvious and easy method for them to donate if they like doing so, tagged into the media much like your scheme.
At one time artists were funded by voluntary money from rich patrons. The public enjoyed the art for free. Why hasn't a similar modern system been developed? Perhaps artists should publish their work (whatever the medium) free and redistributable, with embedded linkage/instructions for donating money to the artist. If simple payment infrastructures on the net made this completely painless for the end user, they would probably contribute a dollar or two to the artists they like... and those with more money might donate more. Artists with enough worth and/or popularity would probably make their fair share, and trash would simply die away penniless.
Problems:
1) A lot of popular and/or good artists are entrenched in the current scheme, leaving only the small-fries to try this method, and a majority of them will fail to make money this way, seemingly proving that it just doesn't work.
2) Even if it worked very well, the high end artists would probably bank less than they do now, so they don't have much incentive.... but then again maybe I underestimate the cut of the production/distrubtion monopolies. Perhaps by going direct from studio to consumer and reaping all the money themselves, the actual net intake of the artist would remain the same.
I know a lot of hardcore Geeks think only Dorks play these kinds of games, but they really have value and you should check them out. To me EverQuest is an evolutionary step towards what VR environments will be like in the future. I first started thinking that about the Doom/Quake series, but EverQuest took it to a whole new level, albeit in a different genre. The immersiveness is amazing, just don't get hooked on the social crap there.
Search the web, EMP bombs are reality already. Aside from more customized methods, the standard off-the-shelf EMP bomb (for a national military to use anyways) is to detonate a standard nuclear warhead miles above a city, its EM shockwave works fine. At least so I remember reading...
Hmmmm well perhaps RMS isn't a communist (beats me, I haven't really looked for it).
On a totally different extreme, Eric Raymond is a vocal Liberterian, which is certainly fringe whacked politics from the point of view of the norm. I'm sure there's other examples of fringe political views in open source. I just think it's irrelevant to the software debate.
1 - "The viral nature of the GPL" is a bunch of crap. The counter-argument goes like this: I wrote my own damn code, and gave it to you for free. If you want to use it that's fine, but you have to give it away like I did. If you don't like that idea, then go write your own damn code. It's really that simple.
2 - Communism. Yeah so what if some FSF members support some whacked political theories. It doesn't have much bearing on the GPL. The GPL is not communism, it's more akin to realizing that software is much more like art or music than it is like a watch or an auto part, and the way we go about licensing, copyrighting, and patenting software should reflect this.
3 - Microsoft's "release of OSS code" and their attempt to join the OSS community and nothing but PR stunts. They have no interest in sharing any vital code under any reasonably open license. For that matter, they have a large interest in not letting anyone see their code, and in not letting anyone even know how to interoperate with it.
4 - Yes, some "OSS teams" produce commercial closed-source software, but they are in the minority and it's ok to bash them. For the most part OSS teams tend to go commercial in much nicer ways. Take a look at the Crossover plugin stuff related to the WINE code. They are selling a commercial product, but they're also giving the code back to the community where it belongs.
Slashdot Mirror
No, it is censorship, it is wrong, and capitalism won't fix it.
The contracts won't tell you up front that you're being censored. It will be covered in the contract by some provision to the effect of: "We reserve the right to do anything we damn well please, in which case you'll just have to take it up the ass from us"
In most markets (telecomms included) there are always three major players that dominate the market once it matures. It's really easy for all three to agree to the same underhanded tactics, and then your capitalism as a savior goes out the window.
It's nto the consumers' ignorance that leads them into these traps. Lots of companies (dare I say "most" large US corporations) are quite underhanded in dealing with their customers, and quite good at hiding that fact from the unwashed masses. The end result is that they are very effectively duped, they don't have any way of knowing ahead of time they crap they're going to end up taking, and they don't have any capitalistic alternative because all the competing companies do the same.
For examples of all of the above, look at the US long distance market, the cable/broadcast/satellite television markets, the local phone market, the broadband access market, airlines, hell even markets like grocery stores.
No ifs, ands, or buts. Censorship is just a bad thing. If they have bandwidth problems, they can rate limit the users. That's an entirely different concept than limiting them based on the content of the traffic.
I guess that's one way to spin it.
It's true about AMDs speeding up, but what I meant originally by "processor specific" still does apply. AMD is an IA32 clone of sorts and it's just that AMD and Intel x86 are close enough that there are general x86 techniques that help both. If icc were ever ported to MIPS or something, I would expect much of the speed gains they had in x86-land would have to be re-engineered from scratch.
In contrast, while gcc has processor-specific optimizations for a number of targets, they have also concentrated on deeply generic optimizations in parts of the code generation that are common to all languages and platforms. Some of the code in gcc has a certain symmetry with very important and often-ill-defined central CS concepts because of this.
By all means use icc for your production code. What I'm anti-advocating is retrofitting standard linux distributions to compile with icc, because I feel that would detract large hordes from the gcc userbase, causing it to suffer. As stated elsewhere, the fact that gcc even comes close is remarkable, considering the age of the compiler, and the fact that it supports a gadzillion different platforms and several different language front-ends to the same code-generating back-end. icc just supports one language family on one architecture, and happens to be written by the same company that designed the cpu for that architecture
For that matter, thinking about this icc thing has brought me around to another point of view as well: Since C is such a ubiquitous language, especially for systems software and kernels... A chip vendor providing a free compiler should almost be mandatory, much like a video card manufacturer providing a free driver. Kinda nice that Intel does seem to agree with this way of thinking. Of course I'd be 10 times happier if Intel would GPL icc and let the more robust gcc suck up their x86 optimizations. Other commercial companies and donated significant r&d efforts into donated optimization code to gcc, why not Intel?
But it's also my understanding that the Linux kernel code likes to have more control over the resulting binary than ANSI C really dictates, and that they use lots of trickery specific to gcc (and even to certain revisions of gcc) to get thigns done. Seems supporting all this trickery in another compiler would lead to even more #ifdefs and bloat and bugginess to me.
Please people, don't go making patches and whatnot for all the standard linux distro package source code to get everyone compiling on this Intel compiler. For normal system services, the performance gain isn't worth the loss of the highly multiplatform and highly GPL gcc we have today, and it would be a shame for gcc to fall by the wayside in common use (probably 80% of gcc compilations are x86 linux) because of small performance gains you won't really notice.
The Intel compiler sounds pretty damn good, but it should really be left for those one-off needs (like compiling a custom scientific application for your beowulf cluster), not general use.
Please, for the love of god, don't leave patient medical info floating around the airwaves unencrypted.
This article is a dupe from late last week....
The consensus (probably correct) is that it's going to be quite difficult to implement, and it will always have corner cases which cause problems and maintenance nightmares, or worse hijacking of public sites.
So here's a semi-manual different approach:
Setup the yadda yadda yadda firewall+nat+dhcp standard setup, assuming that all clients are set for dhcp.
Build a "laptop checker" box with a port hanging out at the reception desk. Inform clients that if they use DHCP (autodetect) like most companies do, they will be fine. If they have doubts or don't know, you can test their laptop's network compatibility for them.
They plug into the network jack, either a green, yellow or red light lights up near the jack (linux can easily control LEDs
Green means the test machine got a DHCP request from the laptop, so it should be ok.
Yellow means no DHCP request, and we saw traffic sourced from some random IP. The IP was pinged for on the outside internet, and found to be non-responsive (unlikely hijacking), and doesn't seem wierd in any other way (multicast IP, or the IP of one of your routers, or the IP of another Yellow Light customer currently checked in, or anything else goofy). The receptionist can then (from some little gui) tell the network tester to allow them access. This turns on a special route for them on the inside, and sets it to be removed when they check out. They are warned that if they got the yellow light, we can't support any technical problems they may experience.
A Red light means there was no DHCP response, and either we didnt see any traffic at all to look at, or they have some bad IP we dont want to assign. We dont add any routes, and we tell them it won't work.
In both yellow and red conditions, you probably want a little handout to give them that walks through the basics of making your laptop autoconfig so it will work "properly".
First off, for security this gateway box should be running OpenBSD. Nothing else can compete when it comes to being a secure firewall that's open source, flexible, and feature-rich. That aside...
Run a stateful packet filter and NAT, do all the standard stuff so that they can get out via HTTP, mail protocols, FTP, and VPN (i.e. Cisco vpn cleints).
Run a DHCP service for the (hopefully majority of) users that either use DHCP anyways, or have the smarts to set their network control panel in winbloze to "autodetect" when they plug into the hotel.
It's the handling of the wierdos that is problematic. One can assume that the worst case you're willing to support is a guy with a static network configuration of a certain IP, gateway, netmask, and nameservers, all of which don't from the hotel (they are from some company's intranet).
First off, get a real subnet for the internal NATted DHCP, so that hopefully nobody but you will have used it (i.e. if you used 192.168.x.x, a lot of static config laptops might just happen to use it too, and it would be hard to tell them from your well-behaved DHCP clients).
Have a sniff on the inside network logging all packets whose source address doesn't match your assigned network. Dynamically insert a rule into your PF and your routing table to make things work for any IP you see on the wire (i.e. you see a source packet from 1.2.3.4, you add into your PF/NAT/Routing setup rules/routes/etc that allow that IP to work). The real trick here is avoiding the problem of someone's laptop having www.yahoo.com's IP address. You might ahve to play some funny rule or policy/tagging trickery to make sure that these added routes don't apply to outbound traffic from other clients.
Proxy arp for EVERYTHING but your internal assigned client IPs on your internal interface, this should take care of their random default gateway setting. Grab all DNS requests (port 53) and silently redirect them to the local DNS service regardless of where they were supposed to go.
etc... etc...
I'd have to actually set up a test environment and do this once to find all the flaws and fix them, but you should be able to go down that general path and make it work.
EULAs *are* immoral. Proprietary software *is* immoral. If you're giong to make a proprietary binary software and sell it to me, I would feel much less wronged if you actually sold me the binary, instead of a license to use as you see fit.
I feel no need to back up my "EULAs are immoral statement", and it's not sloppy of me to just throw it out there. To back it up one merely has to reference numerous papers published in the free software community. Basic knowledge of the premises of these papers is required reading for participating in a slashdot discussion on software licensing, so it's reasonable for me to make a simple statement of which side of the fence I'm on and assume you know why.
If you really need pointers, start with a look around gnu.org, lpf.ai.mit.edu, osi, www.tuxedo.org/~esr, etc...
Aside from the "real" issue that EULAs are morally wrong, surely an appeal can be made to non-enforcement. I don't know the legal wording, but it seems there's probably a way to say in legal terms "Look, this law/contract gets broken hundreds of times per day, and nobody really cares or enforces it, therefore when you single me out and enforce a EULA on me, you're really being discriminatory and using the law/contract to acheive some other goal".
There must be some legal precedent for the concept of "If you never actively enforce a law, and allow it to be broken (in obvious publicly-visible ways) over and over, you can't then go at a later date enforcing it at will on specific people you decide to target, it's not right".
For that matter, if such a legal principle exists, I'd really like to see someone apply it to the traffic ticket system as well.
They also don't explicitly recognize any of the other myriad technical terms from hundreds of other special fields. The essential problems being programmed for in Medical Billing probably share 99% with those encountered in Random_Industry_X billing. There's no reason one can't write sufficiently extensible and flexible generic financial software.
It's an invented, contrived category. The proper solution is a flexible, extensible generic financial system, which could apply itself to Medical Billing among many other things. You might ahve better luck searching for open source billing/financial software than "medical billing" and modifying it to taste.
Could someone please explain the extent to which space imagery in general (and particularly today's stunning hubble images) is altered by artists? I'm of the understanding that the original image was not actually of visible light, due to the doppler shift, and therefore the color image is "constructed" from an uglier image.
Is there some science to "unshifting" the colors such that the colors in the picture are "correct", or are they just picked on a whim by an artist?
Also the sharply pointed glare/lensfx spikes around the bright stars look like they are faked-in as well to me... Were they artistically added, were they artifacts of the original camera, or does it "really" look that way?
I'd appreciate these stories (i.e. Washington Post article) more if they would be mroe direct with the public about how much is "real" and how much is pure art. I'm sure 99% of their viewers (sheep) believe these are direct camera snapshots of the universe and nobody is telling them any different.
Investors need to get their heads out of their asses and realize that they can't let companies do this. For one, most investors are employees of *some* other company. Two, we all know in the long run hurting your employees hurts you as a company. If the investors (that's us, working joes with our etrade accounts) would unload a company's stock when they see the company take anti-employee action in a pinch, it would teach them to cut the golf trips and multi-million-dollar executive bonuses before they cut into the real employees.
Now that's quite ingenious. I had never seen that before. The Street Performer Protocol is quite cool.
Yeah your paper is fairly close to a what a real hashing out of the ideas in my 30-seconds-of-thought comment above would have been. The difference is that you seem to have an emphasis on payment being kinda automatic and built-in, with it left to the user to "hack out" the system if they dont want to pay. I prefer an opt-in setup where people continue to get their art/music completely for free, but there's an obvious and easy method for them to donate if they like doing so, tagged into the media much like your scheme.
At one time artists were funded by voluntary money from rich patrons. The public enjoyed the art for free. Why hasn't a similar modern system been developed? Perhaps artists should publish their work (whatever the medium) free and redistributable, with embedded linkage/instructions for donating money to the artist. If simple payment infrastructures on the net made this completely painless for the end user, they would probably contribute a dollar or two to the artists they like... and those with more money might donate more. Artists with enough worth and/or popularity would probably make their fair share, and trash would simply die away penniless.
Problems:
1) A lot of popular and/or good artists are entrenched in the current scheme, leaving only the small-fries to try this method, and a majority of them will fail to make money this way, seemingly proving that it just doesn't work.
2) Even if it worked very well, the high end artists would probably bank less than they do now, so they don't have much incentive.... but then again maybe I underestimate the cut of the production/distrubtion monopolies. Perhaps by going direct from studio to consumer and reaping all the money themselves, the actual net intake of the artist would remain the same.
Yeah, the social scene in these games is nothing short of pathetic. To participate in it actively would be the ultimate ascension to dorkdom.
I know a lot of hardcore Geeks think only Dorks play these kinds of games, but they really have value and you should check them out. To me EverQuest is an evolutionary step towards what VR environments will be like in the future. I first started thinking that about the Doom/Quake series, but EverQuest took it to a whole new level, albeit in a different genre. The immersiveness is amazing, just don't get hooked on the social crap there.
Search the web, EMP bombs are reality already. Aside from more customized methods, the standard off-the-shelf EMP bomb (for a national military to use anyways) is to detonate a standard nuclear warhead miles above a city, its EM shockwave works fine. At least so I remember reading...
Hmmmm well perhaps RMS isn't a communist (beats me, I haven't really looked for it).
On a totally different extreme, Eric Raymond is a vocal Liberterian, which is certainly fringe whacked politics from the point of view of the norm. I'm sure there's other examples of fringe political views in open source. I just think it's irrelevant to the software debate.
1 - "The viral nature of the GPL" is a bunch of crap. The counter-argument goes like this: I wrote my own damn code, and gave it to you for free. If you want to use it that's fine, but you have to give it away like I did. If you don't like that idea, then go write your own damn code. It's really that simple.
2 - Communism. Yeah so what if some FSF members support some whacked political theories. It doesn't have much bearing on the GPL. The GPL is not communism, it's more akin to realizing that software is much more like art or music than it is like a watch or an auto part, and the way we go about licensing, copyrighting, and patenting software should reflect this.
3 - Microsoft's "release of OSS code" and their attempt to join the OSS community and nothing but PR stunts. They have no interest in sharing any vital code under any reasonably open license. For that matter, they have a large interest in not letting anyone see their code, and in not letting anyone even know how to interoperate with it.
4 - Yes, some "OSS teams" produce commercial closed-source software, but they are in the minority and it's ok to bash them. For the most part OSS teams tend to go commercial in much nicer ways. Take a look at the Crossover plugin stuff related to the WINE code. They are selling a commercial product, but they're also giving the code back to the community where it belongs.