In stunning news today, fast food chain Burger King has filed a suit in civil court accusing the giant food chain of levereging its monopoly in the Big Mac to induce them into buying McDonald's brand Fries.
"It's despicable what they're doing. I went into the mall the other day, and went up to the 'mini-McDonalds' counter. I tried to order a Big Mac and some Burger King fries. They actually refused! This is outrageous abuse of their monopoly power."
Basing a monopoly on intellectual property is ridiculous, first of all. Antitrust law only makes sense for limited physical resources. So on that level, this whole fiasco is asinine.
On another level, they obviously do not have a monopoly. People have a _myriad_ of choices and they still choose Microsoft. How does this translate to any wrongdoing on MS's part?
Say I sell these really cool T-shirts. People love them and buy them up because I've got some unique trademarked design. Do I suddenly have a fucking monopoly?? Ridiculous.
And don't kid yourselves, a computer OS is not that important in the scheme of things. Also, there are _countless_ alternatives to Windows, and several alternatives to every MS product that is supposedly a monopoly.
This post is completely on the mark, I wish I had moderator points. The reason the Xbox has been anywhere near successful is that it's easy to develop on Xbox _or_ PC and port to the other.
Also, developers understand the x86 architecture, and there are a shitload of tools for it. This is asinine on Microsoft's part.
You're somehow managing to come off as both arrogant and senile.
1. You're arguing with two people, but you keep using the same ad-hominem attacks on both as if it's one single White Whale you're arguing with. It's like some obsessive Vietnam vet who just won't let go of the past. Has Microsoft really traumatized you that badly?
2. You seem to assume that you're the only person who knows all this arcane information about Microsoft's OS design, and you're special because you've developed in Unix and Windows. This simply isn't so. You want hard-core, talk to compiler developers, people who write things like VNC, debuggers, terminal services, etc...
_I_ code. I know exactly what you're talking about. The problem is _you_ don't understand. Of _course_ there is the concept of the local super user, there -has- to be on ANY OS. Whoopee!
Grand revelation: "There has to be some account with absolute power over the local machine on any (consumer/business) OS!".
I don't care that admin can grant himself rights over local objects. These are the salient facts:
1. In Windows, you have far more ability to delegate rights so you don't _have_ to give 'root'/admin access to users or services. In Unix, it's either/or.
2. In Unix, in the vast majority if real-world installations(*), if you have 'root' on a workstation you have the keys to the kingdom for the _entire_ domain.
3. Unix has been plagued by the exact same issues Windows has been over its entire lifetime. The problem is Windows is much, much more widely used and deployed so the bugs are exploited far more often.
(*) Now, I will grant that just as you _Can_ secure a windows installation you _Can_ secure a Unix installation by using AFS or kerberized filesystems.
Also, you're confusing two replies - this is the first post from "drsmithy". We're two different people.
And _I_ have done security programming on windows, and even some Samba programming (I did a patch to allow secure passing of AFS credentials to the samba daemon over RPC so you could obtain multiple tokens securely from a Windows client).
Uhh, no. You're not going to gain fat and lose muscle mass on a 1200 calorie diet. At worst, you'd lose muscle and lose fat, but lose muscle at a faster rate than fat which is not good obviously as it decreases your BMR.
Secondly, ultra-low carb diets are a fad. End of story. You're not going to lose 50% lean muscle mass on a reduced calorie diet. In fact, you seem to misunderstant a very simple fact.
Any method you use to lose weight is a reduced-calorie diet. All these fab diets do is shift the ratio of macronutrients one way or another.
Your best bet for a diet is something around 40% protein, 20% far, 40% (low GI) carbs with 2-3 hours of cardio a week and weights 2-3 times a week.
Lastly, Testosterone.net is generally marketing fluff. They occasionally have some good stuff, but they mainly exist to sell their overpriced products.
Of course you do anything on a local host. My point is that NFS is what most people use, and it's flawed.
The Anti-MS crowd must find it convenient to make these distinctions in one case, and ignore them in another.
NFS isn't Unix, but when the latest Outlook or IE flaw comes around it's all lumped in and they claim the OS itself has a bad design. How convenient.
NFS is the _main_ remote file system protocol in Unix. Put a map of of all Unix installations, throw a dart, and you will probably hit a site using good old NFS v2 or maybe v3.
I'm sure when there's a CIFS bug you're quick to point out that this doesn't reflect badly on Windows, it's only one of many filesystems available?
Pure hypocrisy. Unix has a terrible history of security flaws. Sendmail, X11 (still insecure), RPC, buffer overflows in miscellaneous applications, NFS, NIS, OpenSSL/SSH flaws that affect _multiple_ applications, setuid binary flaws, environment variable/LD_LIBRARY_PATH/LD_PRELOAD type flaws, apache bugs, the list does not end.
The Windows low level architecture is more powerful, you have more control over _everything_. In Unix you basically have "root" or "not root". And if you look at the contortions people have gone through to get around that flaw it's really humorous.
Windows's problems are more of common trend of sloppy programming in specific instances, not inherent design flaws. The same issues have plagued (and still plague) Unix for decades.
Windows does not have root in the same sense Unix does. You cannot, even as a _service_ with full local system access, access network data unless you have the password (or a delegated token) for the network user. In the real world (the vast majority of real Unix installations) this is how Unix works.
Now, I agree if you use a kerberized filesystem, AFS or secure NFS, then you've eliminated this particular issue. But how many people actually do that?
The same can be said of Windows - if you know what you're doing and make the effort you can certainly setup a secure environment.
Come on, if you're going to be a Unix advocate you've got to try to keep up:)
Here's a hint: You can login via ssh/rsh without a password _or token_ of any kind being given to the remote machine and have full network access.
Here's another hint: Login to any workstation in a typical NFS environment, and 'su' to an NFS user's account. At this point you are, to NFS, indistinguishable from that user. End of story.
You don't have to allow root access. Since root can effectively impersonate any local user, root has access to any (standard) NFS file. You simply 'su' to the user whose files you want to read and do what you want.
It's a flawed and ancient design.
The OS ends at what's included on the OS CD. I'll admit Microsoft has a lot of work to do, but the overall design of the low-level OS is pretty good on a security level. Almost everything is securable from tokens to threads to processes to files.
Umm, design flaws - no. Windows has a vastly superior (and admittedly more complicated) security _model_ to Unix. This is not debatable. You not only don't have to run as 'root' (which is a Unix concept, not a Windows concept), you can revoke and grant specific priveleges.
Seriously, get a clue. Windows's security problems are related to application coding, not OS design. The design is far in advance of Unix.
Let's see.. I have root on a Unix WS. I have local Admin access on a windows workstation. Guess which OS grants me global access to network file systems? It ain't Windows.
Wow, somebody's been dipping into the "wishful thinking" punch a little much, eh? This blatent evangelization is laughable.
Mismanagement? Umm, do you understand how much money Microsoft has made, and continues to make? You can cry "monopoly" all you want, but it doesn't affect reality.
Seriously, this little diatribe read like a prospectus for a time-sharing scheme in Florida.
Umm, no. It's an evolution. It's like saying that Linux kernel 2.6 suddenly makes 2.4 based distributions outdated, and you should stop installing 2.4 based distributions.
There's no fork() in windows. So what, you use threads, it's a better model anyway.
But as far as passing handles, you can do it any of a several ways. First, if it's STDIN/STDOUT you can pass the handle in CreateProcess. You can also just pass the handle as an integer and use DuplicateHandle (like Unix dup()).
Sockets are system file handles. You can case a SOCKET to a HANDLE in almost any situation. Including child processes - you can connect a socket as STDIN/STDOUT/STDERR to a child process, and the child will read/write over a socket, for e.g. inetd type functionality.
Half the problem Unix people have with Windows is they don't understand it very well because they never tried - they've always seen it as just a cheesy GUI-based OS with no real power. Windows, as a development platform, is quite powerful.
They don't have either. NT has a complex API, granted, but it's very very powerful. You can make it do damn near anything you want.
Visual Studio.NET 2003 is _very_ nice, and very mature (it's been maturing since the early Visual Studio versins). I do have some gripes about their IntelliSense not always working, but that's rare unless you're using specific libraries.
1. You can most certainly pass file handles between Windows processes, I'm not sure what you're talking about there. 2. You can't _share_ a socket in either OS, at least not in any easy way, unless you use a mutex. 3. HTTP.SYS, what in god's name are you talking about?
Just as a note, real programmers don't use ssh, vi, and gcc unless they _have_ to. And you pretty much have to in Unix, unless you use Java (Eclipse or NetBeans are good there). Hence one of the reasons it's easier to develop in Windows.
That move from 16-32 bit was, umm, a long long time ago.
If you're still cranky over that, then I'm sure that MS-DOS config.sys syntax really sinks your panties.
The people who say it's easier to write in Unix are the same ones who wrote Makefiles in Windows, and used 'vi'. Ridiculous.
You look at any large project, especially involving a graphical component, and it's far quicker to develop with C++ or C# (VB is effectively dead, though judging from your 16-32 bit comment you're probably refering to VB 2.0).
Take even your average tiered network application - piece of cake in Windows, pain in the ass in Unix (unless you use Java).
Ooh, I know, I'll use sockets and custom protocols! That's, umm, fast and maintainable!
Uhh, yeah....NET is far easier to develop with than either. And I was referring to RMI..NET remoting will get more features as time goes by, but right now it's very useable.
Linux is no more secure, it's just that a few factors make it seem like it is:
1. The number of Linux machines is low compared to Windows, so people don't target it. 2. The various flavors of Linux make it hard to target because you never know which version you're on.
In real life, you can secure your Windows machines fairly well, and it's far easier to write code in Windows.
Yes, it is very similar..NET remoting is more advanced in a few areas. The big one is inter-language support. I can write, in about 10 minutes, a C++ client that can connect to a C# object and call methods on it over the network.
In stunning news today, fast food chain Burger King has filed a suit in civil court accusing the giant food chain of levereging its monopoly in the Big Mac to induce them into buying McDonald's brand Fries.
"It's despicable what they're doing. I went into the mall the other day, and went up to the 'mini-McDonalds' counter. I tried to order a Big Mac and some Burger King fries. They actually refused! This is outrageous abuse of their monopoly power."
Enough said.
Basing a monopoly on intellectual property is ridiculous, first of all. Antitrust law only makes sense for limited physical resources. So on that level, this whole fiasco is asinine.
On another level, they obviously do not have a monopoly. People have a _myriad_ of choices and they still choose Microsoft. How does this translate to any wrongdoing on MS's part?
Say I sell these really cool T-shirts. People love them and buy them up because I've got some unique trademarked design. Do I suddenly have a fucking monopoly?? Ridiculous.
And don't kid yourselves, a computer OS is not that important in the scheme of things. Also, there are _countless_ alternatives to Windows, and several alternatives to every MS product that is supposedly a monopoly.
Not really, the 3D engines will be _completely_ different. Porting between them won't be any easier than it is now.
How is this a Troll?! You people are crazy.
This post is completely on the mark, I wish I had moderator points. The reason the Xbox has been anywhere near successful is that it's easy to develop on Xbox _or_ PC and port to the other.
Also, developers understand the x86 architecture, and there are a shitload of tools for it. This is asinine on Microsoft's part.
You're somehow managing to come off as both arrogant and senile.
1. You're arguing with two people, but you keep using the same ad-hominem attacks on both as if it's one single White Whale you're arguing with. It's like some obsessive Vietnam vet who just won't let go of the past. Has Microsoft really traumatized you that badly?
2. You seem to assume that you're the only person who knows all this arcane information about Microsoft's OS design, and you're special because you've developed in Unix and Windows. This simply isn't so. You want hard-core, talk to compiler developers, people who write things like VNC, debuggers, terminal services, etc...
_I_ code. I know exactly what you're talking about. The problem is _you_ don't understand. Of _course_ there is the concept of the local super user, there -has- to be on ANY OS. Whoopee!
Grand revelation: "There has to be some account with absolute power over the local machine on any (consumer/business) OS!".
I don't care that admin can grant himself rights over local objects. These are the salient facts:
1. In Windows, you have far more ability to delegate rights so you don't _have_ to give 'root'/admin access to users or services. In Unix, it's either/or.
2. In Unix, in the vast majority if real-world installations(*), if you have 'root' on a workstation you have the keys to the kingdom for the _entire_ domain.
3. Unix has been plagued by the exact same issues Windows has been over its entire lifetime. The problem is Windows is much, much more widely used and deployed so the bugs are exploited far more often.
(*) Now, I will grant that just as you _Can_ secure a windows installation you _Can_ secure a Unix installation by using AFS or kerberized filesystems.
Also, you're confusing two replies - this is the first post from "drsmithy". We're two different people.
And _I_ have done security programming on windows, and even some Samba programming (I did a patch to allow secure passing of AFS credentials to the samba daemon over RPC so you could obtain multiple tokens securely from a Windows client).
Uhh, no. You're not going to gain fat and lose muscle mass on a 1200 calorie diet. At worst, you'd lose muscle and lose fat, but lose muscle at a faster rate than fat which is not good obviously as it decreases your BMR.
Secondly, ultra-low carb diets are a fad. End of story. You're not going to lose 50% lean muscle mass on a reduced calorie diet. In fact, you seem to misunderstant a very simple fact.
Any method you use to lose weight is a reduced-calorie diet. All these fab diets do is shift the ratio of macronutrients one way or another.
Your best bet for a diet is something around 40% protein, 20% far, 40% (low GI) carbs with 2-3 hours of cardio a week and weights 2-3 times a week.
Lastly, Testosterone.net is generally marketing fluff. They occasionally have some good stuff, but they mainly exist to sell their overpriced products.
Of course you do anything on a local host. My point is that NFS is what most people use, and it's flawed.
The Anti-MS crowd must find it convenient to make these distinctions in one case, and ignore them in another.
NFS isn't Unix, but when the latest Outlook or IE flaw comes around it's all lumped in and they claim the OS itself has a bad design. How convenient.
NFS is the _main_ remote file system protocol in Unix. Put a map of of all Unix installations, throw a dart, and you will probably hit a site using good old NFS v2 or maybe v3.
I'm sure when there's a CIFS bug you're quick to point out that this doesn't reflect badly on Windows, it's only one of many filesystems available?
Pure hypocrisy. Unix has a terrible history of security flaws. Sendmail, X11 (still insecure), RPC, buffer overflows in miscellaneous applications, NFS, NIS, OpenSSL/SSH flaws that affect _multiple_ applications, setuid binary flaws, environment variable/LD_LIBRARY_PATH/LD_PRELOAD type flaws, apache bugs, the list does not end.
The Windows low level architecture is more powerful, you have more control over _everything_. In Unix you basically have "root" or "not root". And if you look at the contortions people have gone through to get around that flaw it's really humorous.
Windows's problems are more of common trend of sloppy programming in specific instances, not inherent design flaws. The same issues have plagued (and still plague) Unix for decades.
Windows does not have root in the same sense Unix does. You cannot, even as a _service_ with full local system access, access network data unless you have the password (or a delegated token) for the network user. In the real world (the vast majority of real Unix installations) this is how Unix works.
Now, I agree if you use a kerberized filesystem, AFS or secure NFS, then you've eliminated this particular issue. But how many people actually do that?
The same can be said of Windows - if you know what you're doing and make the effort you can certainly setup a secure environment.
What are you talking about? IE is distributed with the OS, it's not a part of the OS. It runs in user space.
GDI should be in kernel space, this hasn't caused any real problems despite the constant bleating about it by the clueless.
Come on, if you're going to be a Unix advocate you've got to try to keep up :)
Here's a hint: You can login via ssh/rsh without a password _or token_ of any kind being given to the remote machine and have full network access.
Here's another hint: Login to any workstation in a typical NFS environment, and 'su' to an NFS user's account. At this point you are, to NFS, indistinguishable from that user. End of story.
You don't have to allow root access. Since root can effectively impersonate any local user, root has access to any (standard) NFS file. You simply 'su' to the user whose files you want to read and do what you want.
It's a flawed and ancient design.
The OS ends at what's included on the OS CD. I'll admit Microsoft has a lot of work to do, but the overall design of the low-level OS is pretty good on a security level. Almost everything is securable from tokens to threads to processes to files.
Wow, you're clueless aren't you. With standard NFS root can 100% impersonate any local user on a workstation.
NFS trusts local identification, hence root can 'become' anyone and access any file in NFS.
Umm, design flaws - no. Windows has a vastly superior (and admittedly more complicated) security _model_ to Unix. This is not debatable. You not only don't have to run as 'root' (which is a Unix concept, not a Windows concept), you can revoke and grant specific priveleges.
Seriously, get a clue. Windows's security problems are related to application coding, not OS design. The design is far in advance of Unix.
Let's see.. I have root on a Unix WS. I have local Admin access on a windows workstation. Guess which OS grants me global access to network file systems? It ain't Windows.
Hint: 'sudo -u cat ~some_user/somePrivateFile'.
Wow, somebody's been dipping into the "wishful thinking" punch a little much, eh? This blatent evangelization is laughable.
Mismanagement? Umm, do you understand how much money Microsoft has made, and continues to make? You can cry "monopoly" all you want, but it doesn't affect reality.
Seriously, this little diatribe read like a prospectus for a time-sharing scheme in Florida.
Umm, no. It's an evolution. It's like saying that Linux kernel 2.6 suddenly makes 2.4 based distributions outdated, and you should stop installing 2.4 based distributions.
Get real.
Like, a broken Devo record or something.
Seriously, nobody in the real world gives a shit about this, and the idea of a "monopoly" based on intellectual property is laughable.
It ain't oil, it ain't air, it ain't water, and it ain't food. Nobody's dying in the streets over MS's dominance in the OS market.
What's funny is they, by definition, do not have a monopoly. I mean, there are innumerable choices - this is not an arguable item.
And yet here you nerds go, all chiming in with your "they got a slap on the wrist"'s and "the law doesn't understand technology"'s.
Next you'll start in with "won't someone please think of the CHILDREN!!!!". Egads, how ridiculous.
There's no fork() in windows. So what, you use threads, it's a better model anyway.
But as far as passing handles, you can do it any of a several ways. First, if it's STDIN/STDOUT you can pass the handle in CreateProcess. You can also just pass the handle as an integer and use DuplicateHandle (like Unix dup()).
Sockets are system file handles. You can case a SOCKET to a HANDLE in almost any situation. Including child processes - you can connect a socket as STDIN/STDOUT/STDERR to a child process, and the child will read/write over a socket, for e.g. inetd type functionality.
Half the problem Unix people have with Windows is they don't understand it very well because they never tried - they've always seen it as just a cheesy GUI-based OS with no real power. Windows, as a development platform, is quite powerful.
They don't have either. NT has a complex API, granted, but it's very very powerful. You can make it do damn near anything you want.
.NET 2003 is _very_ nice, and very mature (it's been maturing since the early Visual Studio versins). I do have some gripes about their IntelliSense not always working, but that's rare unless you're using specific libraries.
Visual Studio
Buh?
1. You can most certainly pass file handles between Windows processes, I'm not sure what you're talking about there.
2. You can't _share_ a socket in either OS, at least not in any easy way, unless you use a mutex.
3. HTTP.SYS, what in god's name are you talking about?
Just as a note, real programmers don't use ssh, vi, and gcc unless they _have_ to. And you pretty much have to in Unix, unless you use Java (Eclipse or NetBeans are good there). Hence one of the reasons it's easier to develop in Windows.
That move from 16-32 bit was, umm, a long long time ago.
If you're still cranky over that, then I'm sure that MS-DOS config.sys syntax really sinks your panties.
The people who say it's easier to write in Unix are the same ones who wrote Makefiles in Windows, and used 'vi'. Ridiculous.
You look at any large project, especially involving a graphical component, and it's far quicker to develop with C++ or C# (VB is effectively dead, though judging from your 16-32 bit comment you're probably refering to VB 2.0).
Take even your average tiered network application - piece of cake in Windows, pain in the ass in Unix (unless you use Java).
Ooh, I know, I'll use sockets and custom protocols! That's, umm, fast and maintainable!
Uhh, yeah... .NET is far easier to develop with than either. And I was referring to RMI. .NET remoting will get more features as time goes by, but right now it's very useable.
That's because you're clueless.
Linux is no more secure, it's just that a few factors make it seem like it is:
1. The number of Linux machines is low compared to Windows, so people don't target it.
2. The various flavors of Linux make it hard to target because you never know which version you're on.
In real life, you can secure your Windows machines fairly well, and it's far easier to write code in Windows.
Yes, it is very similar. .NET remoting is more advanced in a few areas. The big one is inter-language support. I can write, in about 10 minutes, a C++ client that can connect to a C# object and call methods on it over the network.