Unfortunately, the actual cost of providing that kind of customer support add up. The typical home user is very expensive to support: each has unique problems, especially in the Linux world.
I don't want their phone support. I don't want anything from them other than two things: the distribution and the security fixes. That's it. They can expect to never get a call from me or anyone else at my company, because we're capable of handling our problems ourselves.
The problem here is that Red Hat won't sell us the no-support option. They are forcing everyone to buy their whole support package, which just doesn't fit our situation. Dell realizes this and is thus encouraging them to offer something cheaper.
So how exactly were you affording to use RH products before?
Red Hat 7.3 and Red Hat 9 are still supported by Fedora Legacy. We didn't start out with a hundred servers running Linux, either; we've slowly ramped up over the last several years. It is one thing to reinstall the OS on a few legacy servers each year, but now we're getting hammered because of our increasing volume. Our requirements have matured, and Red Hat doesn't have a product that fills our needs.
And if you're that hung up on it, why not use one of the repackaged RH distributions like White Box?
Can anyone here say with any sort of certainty that White Box will be here in two years, or even six months? How about next week? They simply haven't built up a reputation, and I need some sort of reputation to back up my distribution choice to my supervisor. I'll be more willing to consider them when they've been around for a few years.
Sorry, 18 months is not an acceptable life cycle. I simply cannot afford to spend the time to reinstall operating systems on a hundred different servers every year and a half.
You've made the point perfectly -- Red Hat wants to sell you their full support and nothing less. We don't want to buy the whole nine yards of support, as we feel that we can handle things ourselves. The only support we want from them is the most basic of things for them to provide: security updates. Thus, we are at an impasse; Red Hat won't sell us a product for less money that comes with basic support, and we won't buy their mega-support contract. The end result is that Red Hat has lost our business.
You're right in saying that a company may wish to hire Red Hat to provide support instead of an in-house expert. But what about our case, where we already have in-house experts and thus don't want to hire Red Hat to duplicate that service? We have been running various versions of Red Hat for over 7 years and have never thought to buy a full support contract from Red Hat because we haven't needed it. We can do it ourselves!
Dell's point is that Red Hat is losing customers by not offering a complete range of products. They obviously believe that by not having a lower-end Linux option to offer on their servers, Dell is losing business as well. So, the end result will be one of two things: either Red Hat will offer a cheaper version of Linux with basic support, or Dell will add other, cheaper options to the mix. I personally believe that Red Hat is shooting themselves in the foot, but they are free to do so -- I just won't be the one footing the bill for it.
They did sell for $50 a year before Fedora was released, still no where near the revenue.
The primary difference is not the price, it is the license. Red Hat's license has become very draconian now, and essentially forces you into a corner -- you either buy every single copy every year or you don't buy anything and you don't get any support. People wouldn't be buying it if they could just get free copies, but Red Hat has now prevented that and thus they're making more money.
No OS was the cheapest, with RHEL next, then Windows.
Did that include the price of renewing the RHEL support contract for the next five years? You do realize, of course, that you can't just buy it once and be done with it; you have to pay that $350-$1500 every single year that you use the operating system. Nor do you have the option of dropping the contract -- once you buy in, you're legally hooked for life.
If It's too expensive why is Red Hat doubling their sales every year/quarter
The real question is what their sales would be if they offered a low-end product for $50 per year or so. Dell is not saying that Red Hat is not making money, they're saying that Red Hat could be making more money.
Yes, It's expensive for me or a 5 worker business
I work for a mid-size corporation, and it is too expensive for us. Welcome to the world of tight budgets!
Isn't it up to Red Hat as to what consumer base they want to sell to?
Of course. Read Dell's comments -- they're not suing Red Hat, they're simply warning Red Hat that they need to lower their price. Just as Red Hat has the liberty to sell whatever the hell they want, Dell has the liberty to use a cheaper distribution. At least Dell was nice enough to warn Red Hat instead of just dropping them.
For those that do want support, 3 digits is nothing
It depends on who you are. If you're Pixar, then you're right -- $350-$1500 per year per server is manageable. If you (like me) work for a mid-size corporation with a hundred servers, a shrinking IT budget, and a need for only the security updates, $35,000 per year for just the support on the operating system is too much. We have always used Red Hat products in the past and are very satisfied with them, but we simply cannot pay that much money.
Dell is right; Red Hat has lost us as a customer. We would love to stay with them, but it doesn't matter now. We are now choosing between SuSE and Debian, with Red Hat not being part of the equation.
To get any substantial benefit for existing code, you'd need to translate the entire kernel into idiomatic C++, which is a huge task.
It depends on what kind of benefit you're looking for. If it is a performance benefit, you could easily take a limited part of the kernel, use exceptions and objects, and be able to show that it is faster or slower.
You, however, seem to be more interested in the style and maintainability of the code, which is very difficult to qualify. "Easier to understand" is all in the eye of the beholder, and I doubt that the beholder that oversees Linux thinks C++ is easier to understand and maintain in a low-level kernel setting.
Speaking of maintainability, there is a huge problem with supporting new C++ code in the kernel. It is truly ugly to have multiple acceptable coding paradigms in a large project and would arguably increase the number of bugs in the kernel. You aren't going to be able to just zap away all the old C-style code; it will take years to get it all out. Thus, by supporting both C and C++ code, you end up with a big mess. Is it manageable? Maybe, but it would require a *huge* benefit (performance-wise and maintainability-wise) to justify such a steep cost.
Search Google or the kernel mailing list for "C++" and you'll come up with discussions about the whole issue. For example, see this discussion from earlier this year (which includes the quote from Linus.)
third: you can write in ASM too, but that doesn't mean you should.
No, that's not true -- sometimes, you really need to use ASM. Go poking around the linux kernel (in particular, the 'arch' subdirectory) and you'll find plenty of assembly code. The point here is that you use the right tool for the right job. Linus, obviously, feels that C is the better tool for writing an operating system kernel than C++. Obviously, there's more than one way to do things, but I tend to respect Linus' opinion on something like this.
Of course, if anyone feels like Linus is a total idiot, then they can try porting Linux to C++. I'm willing to bet that if someone could show substantial real benefits from a C++ Linux, Linus would happily eat his words.
I really don't see the use in porting these features to the Linux kernel -- they'll never be used in any mainstream kernel release. Linus has stated many times that he doesn't particularly care for C++ in the kernel:
In fact, in Linux we did try C++ once already, back in 1992.
It sucks. Trust me - writing kernel code in C++ is a BLOODY STUPID IDEA.
The fact is, C++ compilers are not trustworthy. They were even worse in 1992, but some fundamental facts haven't changed:
* the whole C++ exception handling thing is fundamentally broken. It's _especially_ broken for kernels.
* any compiler or language that likes to hide things like memory allocations behind your back just isn't a good choice for a kernel.
* you can write object-oriented code (useful for filesystems etc) in C, _without_ the crap that is C++.
In general, I'd say that anybody who designs his kernel modules for C++ is either
* (a) looking for problems
* (b) a C++ bigot that can't see what he is writing is really just C anyway
* (c) was given an assignment in CS class to do so.
TCP does not use round trip time to calculate any "congestion levels."
That's true, but TCP does implicitly rely upon the RTT in its ordinary operation; it does not increase the size of its congestion window until it sees an ACK, which implies a delay equal to the RTT. So, TCP doesn't use RTT in an explicit calculation but RTT does affect how quickly you're able to ramp up your utilization of the link after a packet loss.
TCP can indeed not only tolerate but recover from packet loss
Yes, but the question is how quickly does it recover from packet loss? This is a huge problem, especially with the advent of 1-10 gigabit ethernet.
Actually, TCP increases exponentially until the first packet is dropped. It backs off to half, then increases linearly, until another packet is dropped, backs off to half...
Well, actually, that's somewhat incorrect. TCP increases its window size exponentially (slow start) until it reaches a certain threshold, at which point it increases linearly (congestion avoidance). If a packet is lost, then the threshold is cut in half but the window size starts from zero again (i.e. redo slow start).
Tweaks to TCP have somewhat modified this behavior (e.g. a triple duplicate ACK will halve the threshold but restart the window size in congestion avoidance mode at the threshold), but the behavior described above is generally accurate.
I'm the same way with most computer books anymore; most seem too canned and simplistic. However, I've discovered that there is a word for the good stuff -- textbooks. The poster mentioned a couple of the truly great networking books that I've ever seen:
Computer Networks: A Top-Down Approach Featuring the Internet, Kurose and Ross
Computer Networks, Andrew Tanenbaum
Don't read these books for a flimsy introduction to networking, read them for a real knowledge how things work. My favorite is Tanenbaum, because he has that old UNIX-hacker-style humor intermixed with his writing that makes him so interesting and fun to read.
Do you have multiple applications accessing the database, or is it just the single web-based app? If you just have a single app, then it doesn't really matter much -- put it wherever you want. On the other hand, if you currently have or plan on eventually having multiple apps (web-based in PHP/ASP, desktop-based in C++/Java, etc...) then I'd create some stored procedures in the database. It will allow you to keep the database-oriented logic close to the data, thereby reducing how much duplication of near-identical code you'll need to write into the different apps.
In addition, depending on your situation, it shouldn't be too hard for the developers to learn how to write stored procedures for the database. Once you know one language, learning another isn't that hard. The developers might write some inefficient code at first, but they'll get better very quickly. Plus, it will give them a better idea of how the database really works and performs, improving their overall designs.
Of course, IANADBA (I am not a DBA), so take it with a grain of salt.
For all I know the Indians might be better programmers but working on the law of averages the problem solving ability of an indivdual is probably independant of their location.
Since when did the law of averages have anything to do with programming ability? I would say that Indians generally are not only better programmers, on average, but better theoretical computer scientists, too.
Go look up some of the premier computer science departments in the country (or even around the world) and take a hard look at the number of Indians (and Chinese) PhD students. Then go look at the average quantitative GRE scores of Asians and compare them to other races. Seeing anything interesting?
The reality is that the education system in India is generally more rigorous, especially when it comes to math. I doubt that Microsoft's primary motive for outsourcing is money -- they're not hurting for cash -- but instead is simply an effort to try and find a large number of great computer scientists. Unless we start increasing the effectiveness of our own elementary and secondary school systems, we're going to be slowly left behind.
Everyone seems to be saying either porn or movies (or a combination thereof), but I wonder if large amounts of bandwidth will enable more "expensive" protocols that allow for new ways of communication. Look at P2P -- it uses scads of bandwidth, but allows you to mostly take central servers out of the picture, which in turn enables a more decentralized and democratic way of communicating. Or look at things like XML, which don't try to squeeze every last byte of space out of the data but instead focus on being human-readable. These kinds of things are the result of certain resources (such as bandwidth and CPU power) becoming more and more of a commodity.
Perhaps it is like water. A person that grew up in the desert where water was scarce and critical to life could hardly imagine the fundamental changes that an abundance of water would cause. If asked what their life would be like with more water, they would probably think, "Wow, I could drink a billion gallons a day if I wanted to," when the real value comes instead from things like sanitation and the use of water in the creation of other goods.
So, while I agree that we'll see a lot of high-bandwidth media files use the new bandwidth, I also believe that we'll start rethinking the fundamental bandwidth scarcity assumptions that we've made and begin to design new protocols and data formats accordingly. There could be cascading results from it, as well, reaching into politics, education, and economics. I doubt the Earth will suddenly become a paradise, but it has the potential to improve things on a lot of different levels.
I vote against Hatch every year. Unfortunatly he's part of the local political system and the LDS Church loves him so he won't be voted out.
The LDS church doesn't back Hatch or any other politician. Of course, he is LDS and thus the Mormon majority tends to identify with him more, but that does not mean the LDS church itself "loves" him. They are very careful to avoid even the appearance of supporting a particular candidate, even going so far as to having a statement read in all church meetings every election cycle explicitly saying so.
And he knows it -- he really doesn't care what he does to the people of Utah (or the rest of you).
I don't like the positions he's taking either, but to claim that he is ambivalent to Utah and the nation's fate is wrong. Maybe you should listen to some of his speeches; you may not agree with him, but he does appear to really think he is helping people.
Complaints from the "little people" (us) don't even register.
Welcome to politics, both inside and outside of Utah.
One of the best things he's managed to do is convince the local news outlets (the biggest being owned by the LDS Church) to never report on what he is doing in Congress (aside from when he gets voted "best dressed..") If the citizens of Utah were kept up to date about the legislation he proposes and what his votes are there would be a huge outcry for him to be tossed out on his ass.
Ok, this is just totally bogus. The citizens of Utah tend to be quite conservative, thus agreeing with many, if not most, of Hatch's proposals. In addition, to claim that KSL (the LDS-owned media outlet) has an agreement of some sort with Hatch is just ridiculous. It sounds more like a conspiracy theory than a rational thought.
Why is this important? I could see the relevance of an article entitled, "PHP Moving to GPL", but this is a total non-issue. Commenting on a remote possibility that doesn't take place is typically not news-worthy.
What's next, a story called, "FSF Not Moving to BSD License", or "Bush Not Voting For Kerry"?
The OSI model is used to describe the function of a network.
Kind of, but not really. It wasn't meant to describe the function of a network, in the general sense, but the function of a specific network -- SNA, which was IBM's networking architecture at the time.
Go read about the OSI model and protocols in Andrew Tanenbaum's Computer Networks; he describes the political motivations behind OSI and why it isn't the sacred cow that a lot of network administrators think it is. He actually uses a hybrid model consisting of 5 layers to teach networking, because the OSI model is flawed, as is the TCP/IP architecture design. (One small caveat here: I have the 3rd edition, while the 4th edition is what is current.)
Of course, everyone loves to use the "OSI model" buzzword, so we'll never see it put to bed like it should be.
After reading the first couple of chapters, I must admit that I am not impressed. My first impression is that he has a lot of experience with Cisco equipment, but doesn't have an in-depth understand of networking principles. For example, while introducing the OSI model, he says:
Layer 5: The Session Layer... This is the layer that says "HEY!" I want to establish a networking session. In fact, if you have internet access from your home computer then you may even see the message "establishing session" during the connection process.
That's just wrong. The OSI model is different from what actually happens in the TCP/IP protocol stack. The Presentation and Session layers aren't actually present in the real TCP/IP world, so claiming that something happens there is incorrect. That "establishing session" message is taking place either at the Application or Transport levels, but not at the non-existant Session layer.
In addition, his informal prose ("old school", "friggin", etc...) gave the book a definite unprofessional feel; some people may think the book is more accessible this way, but I felt that it was a bit sloppy.
No; semantically, there is no difference. The point is that he stated that the only major difference was how windowing was handled, and the inclusion of the first part of the sentence does not change it. Re-read what he said:
As these -- and other -- differences have been removed
This is in the past tense, meaning that those differences no longer exist. It therefore confirms the second part of the sentence, saying that only one major difference remains.
He does claim later that "significant differences" remain, which flies in the face of what he said earlier. With such confusing and contradictory statements, I don't think the poster was crazy for interpreting that he said that the windowing system was the only difference remaining.
The article is about kernel differences, so saying "Linux is becoming more and more like Windows" is plain wrong.
Actually, that is the correct thing to say. If you want to be technical, Linux is a kernel, not a complete operating system, so a comparision between "Linux" and "Windows" should imply that it deals with the kernels. Of course, most people just refer to the whole operating system as "Linux", but it all depends on how you want to interpret it.
WTF the article poster pulled that "He says the only current difference is 'how windowing is handled.'"
To be honest, the article does claim that Russinovich said, "the only major difference between the two operating systems is how windowing is handled." He may not be claiming that it is the only difference, but he does say it is the only major difference.
Am I the only one who didn't like the phrasing on the Minix-Tanenbaum paragraph? In particular, the last sentence seems to imply that Torvalds "borrowed" code:
Although Linux creator Linux Torvalds readily admits that he based his work on Minix, both he and Tanenbaum refute claims that Torvalds borrowed more than he admitted.
The "borrowed more than he admitted" phrase implies that Linus admitted borrowing something in the first place, when the reality is that he denied taking anything from Minix.
Slashdot Mirror
I don't want their phone support. I don't want anything from them other than two things: the distribution and the security fixes. That's it. They can expect to never get a call from me or anyone else at my company, because we're capable of handling our problems ourselves.
The problem here is that Red Hat won't sell us the no-support option. They are forcing everyone to buy their whole support package, which just doesn't fit our situation. Dell realizes this and is thus encouraging them to offer something cheaper.
Red Hat 7.3 and Red Hat 9 are still supported by Fedora Legacy. We didn't start out with a hundred servers running Linux, either; we've slowly ramped up over the last several years. It is one thing to reinstall the OS on a few legacy servers each year, but now we're getting hammered because of our increasing volume. Our requirements have matured, and Red Hat doesn't have a product that fills our needs.
And if you're that hung up on it, why not use one of the repackaged RH distributions like White Box?
Can anyone here say with any sort of certainty that White Box will be here in two years, or even six months? How about next week? They simply haven't built up a reputation, and I need some sort of reputation to back up my distribution choice to my supervisor. I'll be more willing to consider them when they've been around for a few years.
Sorry, 18 months is not an acceptable life cycle. I simply cannot afford to spend the time to reinstall operating systems on a hundred different servers every year and a half.
You're right in saying that a company may wish to hire Red Hat to provide support instead of an in-house expert. But what about our case, where we already have in-house experts and thus don't want to hire Red Hat to duplicate that service? We have been running various versions of Red Hat for over 7 years and have never thought to buy a full support contract from Red Hat because we haven't needed it. We can do it ourselves!
Dell's point is that Red Hat is losing customers by not offering a complete range of products. They obviously believe that by not having a lower-end Linux option to offer on their servers, Dell is losing business as well. So, the end result will be one of two things: either Red Hat will offer a cheaper version of Linux with basic support, or Dell will add other, cheaper options to the mix. I personally believe that Red Hat is shooting themselves in the foot, but they are free to do so -- I just won't be the one footing the bill for it.
The primary difference is not the price, it is the license. Red Hat's license has become very draconian now, and essentially forces you into a corner -- you either buy every single copy every year or you don't buy anything and you don't get any support. People wouldn't be buying it if they could just get free copies, but Red Hat has now prevented that and thus they're making more money.
Did that include the price of renewing the RHEL support contract for the next five years? You do realize, of course, that you can't just buy it once and be done with it; you have to pay that $350-$1500 every single year that you use the operating system. Nor do you have the option of dropping the contract -- once you buy in, you're legally hooked for life.
The real question is what their sales would be if they offered a low-end product for $50 per year or so. Dell is not saying that Red Hat is not making money, they're saying that Red Hat could be making more money.
Yes, It's expensive for me or a 5 worker business
I work for a mid-size corporation, and it is too expensive for us. Welcome to the world of tight budgets!
Isn't it up to Red Hat as to what consumer base they want to sell to?
Of course. Read Dell's comments -- they're not suing Red Hat, they're simply warning Red Hat that they need to lower their price. Just as Red Hat has the liberty to sell whatever the hell they want, Dell has the liberty to use a cheaper distribution. At least Dell was nice enough to warn Red Hat instead of just dropping them.
It depends on who you are. If you're Pixar, then you're right -- $350-$1500 per year per server is manageable. If you (like me) work for a mid-size corporation with a hundred servers, a shrinking IT budget, and a need for only the security updates, $35,000 per year for just the support on the operating system is too much. We have always used Red Hat products in the past and are very satisfied with them, but we simply cannot pay that much money.
Dell is right; Red Hat has lost us as a customer. We would love to stay with them, but it doesn't matter now. We are now choosing between SuSE and Debian, with Red Hat not being part of the equation.
It depends on what kind of benefit you're looking for. If it is a performance benefit, you could easily take a limited part of the kernel, use exceptions and objects, and be able to show that it is faster or slower.
You, however, seem to be more interested in the style and maintainability of the code, which is very difficult to qualify. "Easier to understand" is all in the eye of the beholder, and I doubt that the beholder that oversees Linux thinks C++ is easier to understand and maintain in a low-level kernel setting.
Speaking of maintainability, there is a huge problem with supporting new C++ code in the kernel. It is truly ugly to have multiple acceptable coding paradigms in a large project and would arguably increase the number of bugs in the kernel. You aren't going to be able to just zap away all the old C-style code; it will take years to get it all out. Thus, by supporting both C and C++ code, you end up with a big mess. Is it manageable? Maybe, but it would require a *huge* benefit (performance-wise and maintainability-wise) to justify such a steep cost.
Search Google or the kernel mailing list for "C++" and you'll come up with discussions about the whole issue. For example, see this discussion from earlier this year (which includes the quote from Linus.)
third: you can write in ASM too, but that doesn't mean you should.
No, that's not true -- sometimes, you really need to use ASM. Go poking around the linux kernel (in particular, the 'arch' subdirectory) and you'll find plenty of assembly code. The point here is that you use the right tool for the right job. Linus, obviously, feels that C is the better tool for writing an operating system kernel than C++. Obviously, there's more than one way to do things, but I tend to respect Linus' opinion on something like this.
Of course, if anyone feels like Linus is a total idiot, then they can try porting Linux to C++. I'm willing to bet that if someone could show substantial real benefits from a C++ Linux, Linus would happily eat his words.
In fact, in Linux we did try C++ once already, back in 1992.
It sucks. Trust me - writing kernel code in C++ is a BLOODY STUPID IDEA.
The fact is, C++ compilers are not trustworthy. They were even worse in 1992, but some fundamental facts haven't changed:
* the whole C++ exception handling thing is fundamentally broken. It's _especially_ broken for kernels.
* any compiler or language that likes to hide things like memory allocations behind your back just isn't a good choice for a kernel.
* you can write object-oriented code (useful for filesystems etc) in C, _without_ the crap that is C++.
In general, I'd say that anybody who designs his kernel modules for C++ is either
* (a) looking for problems
* (b) a C++ bigot that can't see what he is writing is really just C anyway
* (c) was given an assignment in CS class to do so.
Feel free to make up (d).
That's true, but TCP does implicitly rely upon the RTT in its ordinary operation; it does not increase the size of its congestion window until it sees an ACK, which implies a delay equal to the RTT. So, TCP doesn't use RTT in an explicit calculation but RTT does affect how quickly you're able to ramp up your utilization of the link after a packet loss.
TCP can indeed not only tolerate but recover from packet loss
Yes, but the question is how quickly does it recover from packet loss? This is a huge problem, especially with the advent of 1-10 gigabit ethernet.
Well, actually, that's somewhat incorrect. TCP increases its window size exponentially (slow start) until it reaches a certain threshold, at which point it increases linearly (congestion avoidance). If a packet is lost, then the threshold is cut in half but the window size starts from zero again (i.e. redo slow start).
Tweaks to TCP have somewhat modified this behavior (e.g. a triple duplicate ACK will halve the threshold but restart the window size in congestion avoidance mode at the threshold), but the behavior described above is generally accurate.
Don't read these books for a flimsy introduction to networking, read them for a real knowledge how things work. My favorite is Tanenbaum, because he has that old UNIX-hacker-style humor intermixed with his writing that makes him so interesting and fun to read.
Likewise, there is no reason for a web server to be doing processing... right?
In addition, depending on your situation, it shouldn't be too hard for the developers to learn how to write stored procedures for the database. Once you know one language, learning another isn't that hard. The developers might write some inefficient code at first, but they'll get better very quickly. Plus, it will give them a better idea of how the database really works and performs, improving their overall designs.
Of course, IANADBA (I am not a DBA), so take it with a grain of salt.
Since when did the law of averages have anything to do with programming ability? I would say that Indians generally are not only better programmers, on average, but better theoretical computer scientists, too.
Go look up some of the premier computer science departments in the country (or even around the world) and take a hard look at the number of Indians (and Chinese) PhD students. Then go look at the average quantitative GRE scores of Asians and compare them to other races. Seeing anything interesting?
The reality is that the education system in India is generally more rigorous, especially when it comes to math. I doubt that Microsoft's primary motive for outsourcing is money -- they're not hurting for cash -- but instead is simply an effort to try and find a large number of great computer scientists. Unless we start increasing the effectiveness of our own elementary and secondary school systems, we're going to be slowly left behind.
Perhaps it is like water. A person that grew up in the desert where water was scarce and critical to life could hardly imagine the fundamental changes that an abundance of water would cause. If asked what their life would be like with more water, they would probably think, "Wow, I could drink a billion gallons a day if I wanted to," when the real value comes instead from things like sanitation and the use of water in the creation of other goods.
So, while I agree that we'll see a lot of high-bandwidth media files use the new bandwidth, I also believe that we'll start rethinking the fundamental bandwidth scarcity assumptions that we've made and begin to design new protocols and data formats accordingly. There could be cascading results from it, as well, reaching into politics, education, and economics. I doubt the Earth will suddenly become a paradise, but it has the potential to improve things on a lot of different levels.
The LDS church doesn't back Hatch or any other politician. Of course, he is LDS and thus the Mormon majority tends to identify with him more, but that does not mean the LDS church itself "loves" him. They are very careful to avoid even the appearance of supporting a particular candidate, even going so far as to having a statement read in all church meetings every election cycle explicitly saying so.
And he knows it -- he really doesn't care what he does to the people of Utah (or the rest of you).
I don't like the positions he's taking either, but to claim that he is ambivalent to Utah and the nation's fate is wrong. Maybe you should listen to some of his speeches; you may not agree with him, but he does appear to really think he is helping people.
Complaints from the "little people" (us) don't even register.
Welcome to politics, both inside and outside of Utah.
One of the best things he's managed to do is convince the local news outlets (the biggest being owned by the LDS Church) to never report on what he is doing in Congress (aside from when he gets voted "best dressed..") If the citizens of Utah were kept up to date about the legislation he proposes and what his votes are there would be a huge outcry for him to be tossed out on his ass.
Ok, this is just totally bogus. The citizens of Utah tend to be quite conservative, thus agreeing with many, if not most, of Hatch's proposals. In addition, to claim that KSL (the LDS-owned media outlet) has an agreement of some sort with Hatch is just ridiculous. It sounds more like a conspiracy theory than a rational thought.
What's next, a story called, "FSF Not Moving to BSD License", or "Bush Not Voting For Kerry"?
Kind of, but not really. It wasn't meant to describe the function of a network, in the general sense, but the function of a specific network -- SNA, which was IBM's networking architecture at the time.
Go read about the OSI model and protocols in Andrew Tanenbaum's Computer Networks; he describes the political motivations behind OSI and why it isn't the sacred cow that a lot of network administrators think it is. He actually uses a hybrid model consisting of 5 layers to teach networking, because the OSI model is flawed, as is the TCP/IP architecture design. (One small caveat here: I have the 3rd edition, while the 4th edition is what is current.)
Of course, everyone loves to use the "OSI model" buzzword, so we'll never see it put to bed like it should be.
Layer 5: The Session Layer... This is the layer that says "HEY!" I want to establish a networking session. In fact, if you have internet access from your home computer then you may even see the message "establishing session" during the connection process.
That's just wrong. The OSI model is different from what actually happens in the TCP/IP protocol stack. The Presentation and Session layers aren't actually present in the real TCP/IP world, so claiming that something happens there is incorrect. That "establishing session" message is taking place either at the Application or Transport levels, but not at the non-existant Session layer.
In addition, his informal prose ("old school", "friggin", etc...) gave the book a definite unprofessional feel; some people may think the book is more accessible this way, but I felt that it was a bit sloppy.
Do you see differences?
I do.
No; semantically, there is no difference. The point is that he stated that the only major difference was how windowing was handled, and the inclusion of the first part of the sentence does not change it. Re-read what he said:
As these -- and other -- differences have been removed
This is in the past tense, meaning that those differences no longer exist. It therefore confirms the second part of the sentence, saying that only one major difference remains.
He does claim later that "significant differences" remain, which flies in the face of what he said earlier. With such confusing and contradictory statements, I don't think the poster was crazy for interpreting that he said that the windowing system was the only difference remaining.
Actually, that is the correct thing to say. If you want to be technical, Linux is a kernel, not a complete operating system, so a comparision between "Linux" and "Windows" should imply that it deals with the kernels. Of course, most people just refer to the whole operating system as "Linux", but it all depends on how you want to interpret it.
WTF the article poster pulled that "He says the only current difference is 'how windowing is handled.'"
To be honest, the article does claim that Russinovich said, "the only major difference between the two operating systems is how windowing is handled." He may not be claiming that it is the only difference, but he does say it is the only major difference.
Although Linux creator Linux Torvalds readily admits that he based his work on Minix, both he and Tanenbaum refute claims that Torvalds borrowed more than he admitted.
The "borrowed more than he admitted" phrase implies that Linus admitted borrowing something in the first place, when the reality is that he denied taking anything from Minix.