Tomcat 5.5 pure Java application and web server can match Apache speeds for many cases.
Again with the speed comparisons to apache-httpd? Please compare features with apache-httpd, but speed with any of thttpd, lighttpd or and-httpd (or insert any number of actually efficient webservers here).
I think it's fair to say that one of the problems with "higher than C" languages is that in many ways it's harder to do efficiently than C. Which explains why most of the slowest/hugest applications on my desktop are all Java and python based.
Note that a US gallon is smaller than a UK gallon, see wikipedia's gallon entry. 25 US ~= 30 UK... which still isn't great, but we don't care because it's so cheap;)
You seem to be ignoring the facts that IE was never sold
The OS was sold, and IE was tied to the OS. Please read what I said.
...and the technical aspect of a shared browser component is a perfectly valid piece of functionality for an OS to include (and has since become commonplace).
Name one other OS that does. You can use/remove/change the browser on Linux/Mac OS X. You might be thinking of Konqueror, which comes with KDE, but you can remove KDE and you can remove konqueror and keep the rest of KDE.
Funny how people never seem to get their knickers in a twist about Windows including a TCP/IP stack, GUI and file manager. I've never been able to figure out if they simply can't see the hypocrisy or just ignore it.
They weren't a monopoly at the time they were writting their GUI/file manager and networking stack (TCP/IP might have come at the point where you could argue they were a monopoly, but I'm not sure). And those components were integrated into other OSes before MS did it. Both of which are a big deal legally.
The outrage from Slashdot readers comes from the idea that managers and execs in Microsoft are saying they want to "kill" the competition. This is largely because most of them have never been anywhere near an upper-level management meeting and hence don't realise that colourful language like that is commonplace and harmless.
I assume you are young, or in a small company. Because in large businesses the execs sure as hell should have known about illegal tying... and deliberatley breaking the law isn't nearly as common as you suggest. Writting down that you intend to break the law and then doing it, even less so.
See the way criminal tying works is that you have a monopoly on something that people want (like, say, and OS), and you tie the sale of that thing with something unrelated (like, say, a browser). This is because it generally reduces competition (like, say, killing Netscape).
Or, simply, it would be fine if Apple execs wanted to "kill MS" and they could do a lot of things to try to make that happen (like, say, "tying" their browser to their OS)... however MS are held to a higher legal std., because they are a _monopoly_ so for instance stopping development of MS Office for Mac OS X would probably be not so clever.
frankly you seem to be implying that they are somehow trying to impede progress or shut developers out of Open Solaris
I wasn't trying to say that, I think people wouldn't have missed my point if I'd said the same thing in person... Ahh well, communication via. text sucks sometimes.
Personally I think that the license and the time of release have impeaded adoption of OpenSolaris, and has certainly imeded people from contributing (everyone I know has been told that legally they can't even look at it, as they'd become tainted for any Linux work -- but then a lot of people I know are employed doing Linux work). None of that is any Sun engineers fault though.
I wasn't trying to say that no good engineers are at Sun, merely that not _all_ of the good ones are there. I wasn't trying to say that you don't need to exercise caution when accepting patches, merely that FreeBSD/Linux/etc. engineers already do this as do Red Hat/SuSe/Ubuntu... and they process a lot more than 70 changes a year from "the community".
I wasn't trying to say Solaris doesn't still have benifits over Linux, merely that it's not all benifits.
That being the case, do these people really think that Sun is just going to say, "Oh, I see. You tested it in a limited fashion and we tested it in a limited fashion in the matter of a few months. Okay, we'll release it to the customers who run massive databases and financial applications on our servers because of a few months of limited testing."
That's right, all of the best software engineers in the world are working for Sun and everyone else is on crack... and Linux is losing to Solaris in such a big way on Wall St. and Sun have been able to keep using their same old development methodologies, don't change what works right?
However back in the real world, the changes people submit to a project they haven't been contributing to generally don't involve re-writting the VM or network stack, they involve the lots of much smaller "annoying itch" type things that a competant maintainer should just be able to quickly read and ACK (or NACK, or munge and ACK). The fact they've only got about one submission every three days, for their entire subset of OS they've released, and have ack'd less than half of those does not bode well for OpenSolaris.
Also, don't forget, that they're pushing an entire new FS/block device design (layers, who needs layers)... and have re-written the network stack for Solaris 11 (to be competitive with FreeBSD/Linux). So if you think change is bad, you really need to migrate from Solaris.
If there was a decent ISP that provided both IPv4 and IPv6 connectivity with little to no overhead, I'd seriously start looking and doing pilot projects. Until that happens or the IPv6 killer app comes along, I don't see much movement from IPv4.
This is the killer bit for me, I recently moved my network from a/26 to a/28 Ipv4 (it was faster)... and it cost a non-trivial amount. I asked about only having a/29 with ipv4 and having ipv6 too, assuming it would be cheaper (and I could handle a bunch of machines being ipv6 only), but my ISP doesn't offer any ipv6... and they said it's because it would cost them more than just getting ipv4 addresses.
Even discounting the whole ipv6 migration problem, the fact you can't even realistically get ipv6 conectivity years, and years after it was introduced is stopping it.
You should look at dietlibc and fnord, they are tiny but I wouldn't use the words well written. I'd like to give QNX more benifit of the doubt than assuming it's just as bad, but small is not the same as beautiful.
So you tell your customers that their ISP is broken, and they should get a new one. It is already the case that sometimes (mostly, even) your customers are on modem's and so will be on slow as crap connections. There are already network problems between you and them. As with all things, if these problems happen too much people can move to a different service.
I understand that VoIP providers don't want to get screwed by the telecom companies, but that seems like it'd be monopoly bundling anyway (and it's not obvious to me that the VoIP companies wouldn't succeed anyway). Where the delusion that adding government regulation to network design is going to help comes from, I don't know.
Imagine that a DSL provider could sell 100mbit connections, which might be QoS limited to 1mbit connections for various reasons... or they could provide 1mbit connections to "everyone, all the time". With regulation they'd be forced to provide the later.
Eclipse certainly isn't Java when it is running on GCJ... etc.
So Eclipse the source code suddenly changes based on how it was compiled? Admitedly Sun designed all this talking at cross purposes into how they named a language a runtime and an ABI all the same thing.
Sure, when compiled into ELF binaries Eclipse (the binary) isn't in Java (binaries) anymore (duh!)... but Eclipse (the source) is sure as hell is still written in Java (the language).
2. apt-get was ported to use rpms, but was slower and buggier than yum due to rpm having features dpkg didn't and noone putting the time into the port to fix them
3. When I had a debian box I almost always had to do: apt-get update && apt-get install -y foo... which has all the same problems as "yum install -y foo"
4. open carpet was by far better than both yum or apt-get in this respect, so I think it's fair to say noone cares too much
5. all of the package management solutions are crap, just some are slightly less crap than others. For your wheel analogy to work we'd have to actually have a decent round wheel, and we don't.
Well, call people a liar. If that's what you want, fine, go hate people who don't have trouble being effective with mutexes and semaphones. If that makes you feel better, go ahead.
Take it personally if you want, I don't care. You are saying that water flows uphill when all evidence is to the contrary... feel free to not like me, or reallity.
PP of the thread suggested that using threads is bad, he/she said never to use threads and to always separate it in processes. That is just a completely ill-advised assertion ...
The deadlocks and races that you refer to didn't exist until after they moved from a global kernel lock to very fine grained locking.
...
Point is: It's as complicated as you make it, and for very decent synchronization and communication performance at a level much higher than what you can get between processes, you don't have to make it even close to as complicated as in-kernel synchronization. Using mutexes and semaphores in threads is actually very simple.
For threads, the locking/synchronization requirements are such that using some very simple synchronization techniques, it is very simple to get great performance that beats any IPC method that you can do between processes (except shared memory).
You start with: "deadlocks and races didn't exist until they used threading"... Duh, but fine, I'll give you that. But then you magically get to "just a little bit of threading is amazingly fast, and totally reliable"... do you have any data for that?
You can keep saying water goes uphill... but until I see some data both myself and reality will keep pointing out the obvious:
1. FACT: Oracle and postgres both use a process model with explicit sharing, and are considered extremely fast (much faster, more reliable and have more features than MySQL which uses the threading model, in fact).
2. FACT: thttpd / lighttpd / and-httpd are extremely fast web servers (beating netscape, IIS, etc. which are threaded).
3. FACT: apache-httpd uses a single process per. connection and even that is "fast enough" most of the time, but again it has beaten those "extremely fast" threaded designs in at least some benchmarks.
4. FACT: While some Coverity errors are false-positives, it is still finding a huge amount of real errors in projects it is running on... and one of it's biggest assets is that it can "understand" locking rules and show flaws in them (and companies are buying it just for this... because no human can get it right all the time).
5. FACT: kernel developers have a huge advantage for threading, in that they can create their own primitive interfaces (you're stuck with pthread, unless you are totally insane) and have a much higher collective threading knowledge than pretty much any other project... and still they are failing, again and again.
6. FACT: out of the "user space" applications that I use which are threaded (firefox, pan), I repeatedly see threading related bugs... these just don't need "amazing" performance, but it'd be nice if they didn't crash/deadlock.
7. FACT: as soon as you "just add a little bit" of threading to an application, you can't just consider the code inside the mutex you have to consider one thread inside and as many other threads as possible in as many other places as possible in your code.
On top of that, I've spoken to enough younger programers who have been told "threading is easy" and believed it but produce crap, and of course it "seems to work" so they happily continue with their fantasy that threading is easy and tell even more people of their new toy.
Again... if this was true then the patches for the Linux or FreeBSD kernels wouldn't be full of deadlock and race condition fixes. And coverity wouldn't be finding 1000s of bugs in both... but yet there are, and they do.
So, either you consider yourself much better than any of the top Linux kernel developers... or you are just lying to yourself.
The main difference was that if 2.4.x was good for you there was a very good chance that 2.4.(++x) would be good for you as well. Now, however, nothing is off-limits; so that is less true.
You are, of course, forgetting about the (at least one) huge VM change. And then that even though it was somewhat "true", it also meant that the huge pile of people who needed/wanted, one of the many year+ old features like O1 scheduler, NPTL, epoll and AIO you were just screwed (although it was somewhat fun speaking to the newbies who wanted to run NPTL on their debian stable 2.4.x and refusing to be told the truth).
2.6.x is much like 2.4.x, you either need a team of highly skilled Linux kernel developers following vanilla... or you hope/assume/outsource it to Red Hat/SuSE/Ubuntu/etc.[1] If you aren't doing one of the above you are just playing russian roulette with your boxes.
[1] Anyone with arguments of the form "*BSD is better as they have a real stable" is referred to fig. 1... Red Hat etc. are providing the stable branches, and having choice isn't a bad thing.
So why ignore the obvious? If American healthcare is so broken, why are cancer survival rates almost uniformly higher (and usually by a good %) than in Europe? Look it up, the data is there.
Not that I'd total trust the above stats. either way. For instance I'm not sure that the stats. are calculated in the same way... it doesn't account for either country not diagnosing the cancer etc. What you really want is total number of people dying, or being sick, say (oh, wait... that's what the article was about).
I've never understood the (frequently European) mindset that when there is a possibility of making money, people instantly turn completely evil and ruthless.
I've never understood the (frequently American) mindset that when things are obviously broken it's socially unacceptable to fix it if someone is making money out of the status quo.
It's not just the doctors/CEOs that suddenly change. I recently saw someone I know on a respirator, having her lungs sucked out, for two weeks because "going to see a doctor" was too expensive (she was currently unemployed).
The two things they did to screw me over was: 1) Say "return by Friday", but not say it had to be returned by 10am Friday. 2) Deceptivly confused me about "long rental" offers, so you keep a movie for days longer than you should (and they don't tell you).
I've been BB free for a couple of years, and never had any late fee problems with my local video rental store.
I don't think you need to use adblock to disable javascript entirely, but it would be great if there was a "from originating site only" option as per "Load Images" and cookies.
Or the mildly sociopathic types who'll get a perverse thrill out of signing up for distance learning Web CT classes, then informing the instructor that they won't be able to check their validated campus email because they run Linux;)
Having a spouse who had to take those, I feel their pain... although everything mostly works if you just use Agent switcher to lie to them (which is even more sad, in it's own way). Notable exceptions was the "Java chat" like "collaboration service"... but even the people using windows couldn't get that to work.
Just FYI: Calling fork gives you another thread of execution. Just because I used the word 'threads' doesn't mean I meant it in the posix sense.
Oh... come ON, if you'd have said task without qualifying it, then I might have hoped you didn't mean pthread_create() but I still wouldn't have put a lot of money on it.
I meant it as a computer science term, and not an implementation specific term. Multiple processes using IPC of one form or another is a parallel programming technique.
Yes, well done... threads and processes have well defined meanings as computer science terms. And I can guarantee that any non-four digit/. user is going to take:
"If you can't mentally compartmentalize the threads of a program you're writing, you [...] have no business being a professional software engineer."
...and interpret it as "professional software engineers" can easily use pthread_create() and manage the outcome that results. fork() is certainly not going to enter the equation.
After 10 years experience as a professional software engineer, I can say that certainly isn't true of most programmers I've worked with. People like that, quite honestly, have no business writing code that can run in a place that may bring the system down.
Again with the "developers just need to understand threads" theory? Unless you are talking about everyone moving to some new language that significantly helps developers manage syncronization and sharing... then I call your "theory" and raise you real the world data that OS kernel developers (Linux, Solaris, FreeBSD) repeatedly have problems managing the above threading problems. Coverity has found hundreds if not thousands of threading bugs in Linux, and there must certainly be many it hasn't.
So you (and "most programmers" you've worked with) either believe that you really are much better than all of the Linux and Solaris kernels developers... or, more likely, idiots who can't judge their own incompetance.
So listen up, exposing large parts of your entire application to run at multiple points simultaneously is really hard to do well. And if you have a real OS (Ie. not from microsoft) then doing fork() and explicitly stating which bits of data you want to share is less prone to errors, more maintainable and just as efficent/scalable.
Yes, sometimes, you'll then be required to design the interfaces to communicate between the processes instead of just hacking it... but again, often, just hacking it with threads produces buggy unmaintainable crap.
I never quite understood why something like autopackage wasn't adopted as a universal package format and native package systems could be retrofitted to play nicely with it.
Because one of the few things all the package maintainers for distributions can agree on is that autopackage is horribly broken, and even the autopackage people themselves basically say `just use this for addons, it doesn't work for "the system"'... where "the system" is really code for "the hard cases our broken design doesn't work with".
Oh, and I don't believe that installing an office suite is easier on Windows than on Linux. Sure, installing Micrsoft Flight simulator is harder to do on Linux... but that's like saying it's harder to install And-httpd on Windows, true but yet totally worthless for the discussion.
this argument can be simply stated, on both sides, with 3 words:
1: Guns
2: Alcohol
3: Cigarettes
Wow, impressive... you're comparing the government not removing people's freedom to do what they want (which, you think, is bad), with Microsoft trying to remove people's freedom to do what they want (which, you think, is bad).
Slashdot Mirror
Again with the speed comparisons to apache-httpd? Please compare features with apache-httpd, but speed with any of thttpd, lighttpd or and-httpd (or insert any number of actually efficient webservers here).
I think it's fair to say that one of the problems with "higher than C" languages is that in many ways it's harder to do efficiently than C. Which explains why most of the slowest/hugest applications on my desktop are all Java and python based.
Note that a US gallon is smaller than a UK gallon, see wikipedia's gallon entry. 25 US ~= 30 UK ... which still isn't great, but we don't care because it's so cheap ;)
The OS was sold, and IE was tied to the OS. Please read what I said.
Name one other OS that does. You can use/remove/change the browser on Linux/Mac OS X. You might be thinking of Konqueror, which comes with KDE, but you can remove KDE and you can remove konqueror and keep the rest of KDE.
They weren't a monopoly at the time they were writting their GUI/file manager and networking stack (TCP/IP might have come at the point where you could argue they were a monopoly, but I'm not sure). And those components were integrated into other OSes before MS did it. Both of which are a big deal legally.
I assume you are young, or in a small company. Because in large businesses the execs sure as hell should have known about illegal tying ... and deliberatley breaking the law isn't nearly as common as you suggest. Writting down that you intend to break the law and then doing it, even less so.
Yeh, phew ... I'm so glad I don't have to do that anymore.
See the way criminal tying works is that you have a monopoly on something that people want (like, say, and OS), and you tie the sale of that thing with something unrelated (like, say, a browser). This is because it generally reduces competition (like, say, killing Netscape).
Or, simply, it would be fine if Apple execs wanted to "kill MS" and they could do a lot of things to try to make that happen (like, say, "tying" their browser to their OS) ... however MS are held to a higher legal std., because they are a _monopoly_ so for instance stopping development of MS Office for Mac OS X would probably be not so clever.
AINAL, I just play one on /.
I wasn't trying to say that, I think people wouldn't have missed my point if I'd said the same thing in person ... Ahh well, communication via. text sucks sometimes.
Personally I think that the license and the time of release have impeaded adoption of OpenSolaris, and has certainly imeded people from contributing (everyone I know has been told that legally they can't even look at it, as they'd become tainted for any Linux work -- but then a lot of people I know are employed doing Linux work). None of that is any Sun engineers fault though.
I wasn't trying to say that no good engineers are at Sun, merely that not _all_ of the good ones are there. I wasn't trying to say that you don't need to exercise caution when accepting patches, merely that FreeBSD/Linux/etc. engineers already do this as do Red Hat/SuSe/Ubuntu ... and they process a lot more than 70 changes a year from "the community".
I wasn't trying to say Solaris doesn't still have benifits over Linux, merely that it's not all benifits.
That's right, all of the best software engineers in the world are working for Sun and everyone else is on crack ... and Linux is losing to Solaris in such a big way on Wall St. and Sun have been able to keep using their same old development methodologies, don't change what works right?
However back in the real world, the changes people submit to a project they haven't been contributing to generally don't involve re-writting the VM or network stack, they involve the lots of much smaller "annoying itch" type things that a competant maintainer should just be able to quickly read and ACK (or NACK, or munge and ACK). The fact they've only got about one submission every three days, for their entire subset of OS they've released, and have ack'd less than half of those does not bode well for OpenSolaris.
Also, don't forget, that they're pushing an entire new FS/block device design (layers, who needs layers) ... and have re-written the network stack for Solaris 11 (to be competitive with FreeBSD/Linux). So if you think change is bad, you really need to migrate from Solaris.
This is the killer bit for me, I recently moved my network from a /26 to a /28 Ipv4 (it was faster) ... and it cost a non-trivial amount. I asked about only having a /29 with ipv4 and having ipv6 too, assuming it would be cheaper (and I could handle a bunch of machines being ipv6 only), but my ISP doesn't offer any ipv6 ... and they said it's because it would cost them more than just getting ipv4 addresses.
Even discounting the whole ipv6 migration problem, the fact you can't even realistically get ipv6 conectivity years, and years after it was introduced is stopping it.
You should look at dietlibc and fnord, they are tiny but I wouldn't use the words well written. I'd like to give QNX more benifit of the doubt than assuming it's just as bad, but small is not the same as beautiful.
So you tell your customers that their ISP is broken, and they should get a new one. It is already the case that sometimes (mostly, even) your customers are on modem's and so will be on slow as crap connections. There are already network problems between you and them. As with all things, if these problems happen too much people can move to a different service.
I understand that VoIP providers don't want to get screwed by the telecom companies, but that seems like it'd be monopoly bundling anyway (and it's not obvious to me that the VoIP companies wouldn't succeed anyway). Where the delusion that adding government regulation to network design is going to help comes from, I don't know.
Imagine that a DSL provider could sell 100mbit connections, which might be QoS limited to 1mbit connections for various reasons ... or they could provide 1mbit connections to "everyone, all the time". With regulation they'd be forced to provide the later.
So Eclipse the source code suddenly changes based on how it was compiled? Admitedly Sun designed all this talking at cross purposes into how they named a language a runtime and an ABI all the same thing.
Sure, when compiled into ELF binaries Eclipse (the binary) isn't in Java (binaries) anymore (duh!) ... but Eclipse (the source) is sure as hell is still written in Java (the language).
Take it personally if you want, I don't care. You are saying that water flows uphill when all evidence is to the contrary ... feel free to not like me, or reallity.
You start with: "deadlocks and races didn't exist until they used threading" ... Duh, but fine, I'll give you that. But then you magically get to "just a little bit of threading is amazingly fast, and totally reliable" ... do you have any data for that?
You can keep saying water goes uphill ... but until I see some data both myself and reality will keep pointing out the obvious:
On top of that, I've spoken to enough younger programers who have been told "threading is easy" and believed it but produce crap, and of course it "seems to work" so they happily continue with their fantasy that threading is easy and tell even more people of their new toy.
Again ... if this was true then the patches for the Linux or FreeBSD kernels wouldn't be full of deadlock and race condition fixes. And coverity wouldn't be finding 1000s of bugs in both ... but yet there are, and they do.
So, either you consider yourself much better than any of the top Linux kernel developers ... or you are just lying to yourself.
You are, of course, forgetting about the (at least one) huge VM change. And then that even though it was somewhat "true", it also meant that the huge pile of people who needed/wanted, one of the many year+ old features like O1 scheduler, NPTL, epoll and AIO you were just screwed (although it was somewhat fun speaking to the newbies who wanted to run NPTL on their debian stable 2.4.x and refusing to be told the truth).
2.6.x is much like 2.4.x, you either need a team of highly skilled Linux kernel developers following vanilla ... or you hope/assume/outsource it to Red Hat/SuSE/Ubuntu/etc.[1] If you aren't doing one of the above you are just playing russian roulette with your boxes.
[1] Anyone with arguments of the form "*BSD is better as they have a real stable" is referred to fig. 1 ... Red Hat etc. are providing the stable branches, and having choice isn't a bad thing.
The references I see, don't obviosly say that: US mortality rate of 27 out of 135 ... vs. UK survival rate of 80% for breast cancer in the 1998-2001 period. Which is identical.
Not that I'd total trust the above stats. either way. For instance I'm not sure that the stats. are calculated in the same way ... it doesn't account for either country not diagnosing the cancer etc. What you really want is total number of people dying, or being sick, say (oh, wait ... that's what the article was about).
I've never understood the (frequently American) mindset that when things are obviously broken it's socially unacceptable to fix it if someone is making money out of the status quo.
It's not just the doctors/CEOs that suddenly change. I recently saw someone I know on a respirator, having her lungs sucked out, for two weeks because "going to see a doctor" was too expensive (she was currently unemployed).
The two things they did to screw me over was: 1) Say "return by Friday", but not say it had to be returned by 10am Friday. 2) Deceptivly confused me about "long rental" offers, so you keep a movie for days longer than you should (and they don't tell you).
I've been BB free for a couple of years, and never had any late fee problems with my local video rental store.
You want the "No script" extension.
I'm not sure about that ... the parent companies of Coke and Pepsi own almost all the major soda brands.
Having a spouse who had to take those, I feel their pain ... although everything mostly works if you just use Agent switcher to lie to them (which is even more sad, in it's own way). Notable exceptions was the "Java chat" like "collaboration service" ... but even the people using windows couldn't get that to work.
Oh ... come ON, if you'd have said task without qualifying it, then I might have hoped you didn't mean pthread_create() but I still wouldn't have put a lot of money on it.
Yes, well done ... threads and processes have well defined meanings as computer science terms. And I can guarantee that any non-four digit /. user is going to take:
Again with the "developers just need to understand threads" theory? Unless you are talking about everyone moving to some new language that significantly helps developers manage syncronization and sharing ... then I call your "theory" and raise you real the world data that OS kernel developers (Linux, Solaris, FreeBSD) repeatedly have problems managing the above threading problems. Coverity has found hundreds if not thousands of threading bugs in Linux, and there must certainly be many it hasn't.
So you (and "most programmers" you've worked with) either believe that you really are much better than all of the Linux and Solaris kernels developers ... or, more likely, idiots who can't judge their own incompetance.
So listen up, exposing large parts of your entire application to run at multiple points simultaneously is really hard to do well. And if you have a real OS (Ie. not from microsoft) then doing fork() and explicitly stating which bits of data you want to share is less prone to errors, more maintainable and just as efficent/scalable.
Yes, sometimes, you'll then be required to design the interfaces to communicate between the processes instead of just hacking it ... but again, often, just hacking it with threads produces buggy unmaintainable crap.
Because one of the few things all the package maintainers for distributions can agree on is that autopackage is horribly broken, and even the autopackage people themselves basically say `just use this for addons, it doesn't work for "the system"' ... where "the system" is really code for "the hard cases our broken design doesn't work with".
Oh, and I don't believe that installing an office suite is easier on Windows than on Linux. Sure, installing Micrsoft Flight simulator is harder to do on Linux ... but that's like saying it's harder to install And-httpd on Windows, true but yet totally worthless for the discussion.
Wow, impressive ... you're comparing the government not removing people's freedom to do what they want (which, you think, is bad), with Microsoft trying to remove people's freedom to do what they want (which, you think, is bad).