Mathematically, no betting strategy can guarantee more than a 98% return on your money in roulette.
From a purely mathematical standpoint, yes. However there are other factors that can influence the outcome. Ball size (there are typically 3 sizes and weights), force upon which the ball is "flicked", What number is under the ball when the ball is started, etc... Now, it's impossible for a human to accurately take those factors into account every time, but they can help you to gain a slight advantage over the other players (may not enough to overcome the house advantage, but still).
The difference, at least in my mind, between an OS that is Unix or Unix-like, and one that is merely Unix compatible is that Unix-like OS's allow *all* code to run on any other Unix-like OS (with the usual Unix portability caveats), while an OS that is merely unix compatible means that Unix applications can run on it, but it's native applications cannot run on other Unix systems.
That means that BeOS, Plan9, MacOS (even OS X), etc.. are all Unix compatible, but they are not Unix-like (with the exception that OS X is, in fact, Unix in the base OS... the other layers they put on top are NOT unix layers).
QNX and BeOS are not UNIX. They certainly have some unix-like characteristics, but they aren't by a long shot. Both QNX and BeOS have posix compatibility, but that doesn't make them Unix. Hell, Windows has Posix compatibility (Posix.1) out of the box, and has a free full Posix subysystem for download. That doesn't make Windows Unix.
BeOS was written entirely in C++, even the kernel. It used a C++ based API for applications (other than posix). It had a totally different kernel from any Unix system on the market. It was not Unix in any way, shape, or form.
QNX, while like I said is far more unix-like than most others, isn't really unix either, but because it's primary API is posix, i'll grant that.
Plan 9 isn't Unix, though it originated from Unix. It's an entirely filesystem based API. Some of the concepts of Plan 9 have been port to Unix and Linux, like/proc.
You also didn't say "general purpose OS", you said "no operating system in the world". That's pretty specific.
You didn't say "no, non-lame, non-general purpose os that in the world that wasn't somehow, no matter how far you stretch it "unix-like" ".
If BeOS is Unix, by your definition, so was Windows.
By 1997 (one decade ago) there was no operating system in the world that wasn't either UNIX-based, transitioning to UNIX, or shipping with a functional hosted UNIX environment... other than Windows.
Yes... other than AmigaOS, AtariOS, QNX (though it is fairly unix-like), BeOS, MacOS (though they had just bought NeXT), Plan9, Netware... the list could go on and on.. I think you might want to re-think that statement.
What surprises me the most is that this actually has to be said. It is ridiculous that mono is so actively used to actually make programs for official gnome, we got python, we got Java, we got Ruby, we certainly did not need MONO here.
What suprises ME most is you feel the need to regulate the languages and technology other developers can use, simply because you don't like where they come from. Linux is about freedom. That includes the freedom to choose what technology you want to use. Does it not?
Where do you get the gall to demand that people not use any given technology?
First, no. Not everyones intention in creating open source is to make Free software. Many people just want to make cool stuff and give it to others, and they don't give a rip what they do with it, including commercializing it. You may not like that, but who are you to tell them differently?
Secondly, C# is an *ISO* standard. It has no patent restrictions. It is 100% Free to implement. The base class libraries are also patent restriction free, and are 100% Free to implement.
Yes, there are theoretical intellectual property issues in implementing parts of.NET that are not included in the standard, but Mono has taken great pains to seperate those into different library sets, so they can be used optionally. Meanwhile, there are lots of open source developed libraries that depend only on ISO standard.net, like gtk#.
Don't be so full of yourself as to believe that you know best for everyone else, and you should at least try to understand the issues before running off on rants.
Samba? That's only used so you can work with legacy Windows systems. SMB is a crap protocol, so there's no reason to bother with it unless you're required to work with legacy Windows system. If you're Windows-free, it has no real use.
That may be, but it's better than NFS. I know of many shops that use Samba, even between Linux and Unix systems, because NFS has so many issues. Why hasn't the Linux world taken network filesystems into their own hands, relying instead on protocols designed by Microsoft or Sun?
If everyone likes C# so much, then we should take matters into our own hands and implement a language with the features we like that is under our control!
PowerShell doesn't come with Vista, but it will come with Windows 2008 Server, which is what we're talking about.
And I was talking about the encrypted Windows Remote Shell (WinRS) when I said secure shell, not ssh. Both of those things are included with Windows 2008 Server standard.
Well, if you remember... back in the 9x days, whenever you needed to install a new piece of hardware, or make some change, it often asked you for your windows CD. That's been gone for a while, but the "solution" was to basically put all those files on your hard disk. Then came Windows File Protection, which keeps backup copies of files so that if they're deleted or overwritten with something else, windows would automatically restore those copies. Well, vista goes even further on that, and it wastes a ton of space in my opinion.
Your argument is silly, considering that PowerShell is probably the most advanced and powerful shell for any platform today. So your "but they might want a powerful command line" argument really doesn't work.
Microsoft has secure means, like the article mentions. Both RDP and Secure Shell.
I think the issue is more related to resources and security. Microsoft likely doesn't want to develop their own SSH code base, and they don't want to rely on a third party one because the third party doesn't confrom to their new security processes. While OpenSSH is good, it's had a number of security flaws in recent years as well.
When it boils down to it, SSH isn't needed to do Windows administration, so why would MS want to add to their security liability by including it?
Both Vista and 2008 suffer from 'backup-itis', use a tool like SpaceMonger on a fresh install of either and you'll see that well over 50% of the used space is copies of system files (sometes 3 or 4 copies). This is all part of the "self-healing" bit, but I think it's a waste of space.
Lots of people, including myself, use server versions of the OS as a desktop OS (I even have it on my laptop). The reason is simple. I'm a developer, and I work on code that needs services that are only available on the server version (multiple web sites, for instance).
The "web" version of Windows 2003 server isn't much more expensive than XP Pro.
I'm curious. Besides Star/Open Office (same app really, just marketed under two names.. one with some extras), what app suite implements the entire ODF spec? None that I know of.
In order for an app to implement the entire format, it must have every feature the format supports. Since ODF, by definition, supports the entire OpenOffice feature set, that means that any app that doesn't support every OpenOffice feature cannot implement the entire spec.
Well, actually. Yes, there is a reason why they shouldn't be disclosing everything they do upfront. Tht reason is ignorant users. These are people that freak out whever they see anything they don't understand, and gobbledygook about patches will send them screaming for IT support lines around the world.
Having said that, there should be ways to find out what was done, just not "up front".
In my experience, software is almost *ALWAYS* late. Even when it's not. Typically, most companies cannibalize testing time for development time, extending the development time and shrinking testing time so they can meet the schedule (or something aproximating it).
This is a result of many things, but the largest being that most shops are expected to give a firm estimate when they have the least amount of knowledge about what they're doing. This is because the users expect that when they say "it'll take 12 months" that it does, in fact, take 12 months.
Look at Microsoft. They get royally roasted every time they slip their schedule. So much so that they were forced to ship Vista before it was ready in order to appease the public. And don't say "5 years wasn't enough?" because things changed after Vista development started, all the requirements changed, security became a huge priority, retraiing, redesigns, re-doing XP and Windows 2003, etc.. Vista, when they finally got to work on it in earnest only started in late 2004 after all that other stuff was done. What's worse is that this fixed schedule likely forced many design compromises to get it done on time, not just shipping before it was ready.
That's fine for online, where computer can be built to order, or you have a whole world of customers to make it worth stocking every variation, but what about brick and morter stores? What about Walmart? Are you going to trust Walmart to install your OS?
So what you're saying is that everyone that sells a computer now has to either a) stock inventory of every possible OS configuration or b) accept the burden and liability of installing the OS and then, likely supporting the OS because they were the ones that did the installation?
Sure, the Dell's and Gateways can do this. Probably even the Best Buy's and Circuit City's, but that is a lot of burden to put on smaller shops unless they want said burden (many will see it as a way to make more money). Further, it means PC prices will likely have to go up, because the cost of the installation now moves from the VERY efficient OEM to the distribution chain which will have varying degrees of efficiency.
I agree with you, but the problem comes down to assessing the benefits vs cost. Ask nearly any programmer who's stuck maintaining code he didn't write and he'll tell you that the maintenance costs of maintaining the old code will be too high, and a rewrite needs to occur to reduce maintenance costs. Of course, even if that happens successfully, the next programmer put on maintenance will say the same thing of the new code.
It's often very difficult to migrate an application, piece by piece, to a new design. Look at Microsoft Office, for example.
I can think of very few applications in which text-throughput is an issue. I mean, if the throughput is is slowed down that much, then the data is going by so fast the user can't read it anyways. Which tells me that the data doesn't really need to go to the screen at all.
Take, for instance, a vt100 terminal connected to a mainframe that spews forth pages and pages of text. Most likely, that text doesn't need to be drawn to the screen, it could be dumped to a buffer and read (one screen at a time) or printed from that.
Can you provide an example of a use that REQUIRES text throughput to the screen?
I don't necessarily disagree with the points, but the conclusions don't follow from the problem space..NET is very mature technology, as is SQL Server. The choice of those technologies was not the problem (other than throwing away something that worked).
AJAX is not particularly immature, though many frameworks are. AJAX has been around for almost 10 years (it just wasn't called AJAX then). And the choice of AJAX in this case was bad, not because of AJAX, but because the requirements didn't call for it.
Traditional apps don't offer more flexibility than Web-based Apps *in every circumstance*. Again, it depends on the requirements. If you need an app that is useable from anywhere in the world, without installing software on the client machine, the traditional apps are significantly LESS flexible, for instance. That wasn't the case in this situation, so the choice of a web-based app was silly.
The choice of Text based UI versus GUI is also silly. A well designed GUI app is just as usable via keyboard as a text one, it's just a different presentation framework.
I disagree with the vast majority of those points. The only two that I agree with is giving consideration to scalability and getting user feedback. The rest are illogical conclusions based on a failed project whos real failure was poorly specified requirements.
Certainly, Web UI's are not appropriate for everything. They should really only be used if there is some overpowering need (like the ability to access the data from anywhere without having client apps installed). They also apparently gave zero thought to existing processes and staff skillsets.
Avoiding AJAX or any other technology because you tried to use it for something it wasn't good at is patently stupid. There are good uses for the technologies. This just wasn't one of them.
Slashdot Mirror
Mathematically, no betting strategy can guarantee more than a 98% return on your money in roulette.
From a purely mathematical standpoint, yes. However there are other factors that can influence the outcome. Ball size (there are typically 3 sizes and weights), force upon which the ball is "flicked", What number is under the ball when the ball is started, etc... Now, it's impossible for a human to accurately take those factors into account every time, but they can help you to gain a slight advantage over the other players (may not enough to overcome the house advantage, but still).
The difference, at least in my mind, between an OS that is Unix or Unix-like, and one that is merely Unix compatible is that Unix-like OS's allow *all* code to run on any other Unix-like OS (with the usual Unix portability caveats), while an OS that is merely unix compatible means that Unix applications can run on it, but it's native applications cannot run on other Unix systems.
That means that BeOS, Plan9, MacOS (even OS X), etc.. are all Unix compatible, but they are not Unix-like (with the exception that OS X is, in fact, Unix in the base OS... the other layers they put on top are NOT unix layers).
QNX and BeOS are not UNIX. They certainly have some unix-like characteristics, but they aren't by a long shot. Both QNX and BeOS have posix compatibility, but that doesn't make them Unix. Hell, Windows has Posix compatibility (Posix.1) out of the box, and has a free full Posix subysystem for download. That doesn't make Windows Unix.
/proc.
BeOS was written entirely in C++, even the kernel. It used a C++ based API for applications (other than posix). It had a totally different kernel from any Unix system on the market. It was not Unix in any way, shape, or form.
QNX, while like I said is far more unix-like than most others, isn't really unix either, but because it's primary API is posix, i'll grant that.
Plan 9 isn't Unix, though it originated from Unix. It's an entirely filesystem based API. Some of the concepts of Plan 9 have been port to Unix and Linux, like
You also didn't say "general purpose OS", you said "no operating system in the world". That's pretty specific.
You didn't say "no, non-lame, non-general purpose os that in the world that wasn't somehow, no matter how far you stretch it "unix-like" ".
If BeOS is Unix, by your definition, so was Windows.
Try this:
http://www.linuxinsight.com/files/ols2006/kirch-reprint.pdf
By 1997 (one decade ago) there was no operating system in the world that wasn't either UNIX-based, transitioning to UNIX, or shipping with a functional hosted UNIX environment... other than Windows.
Yes... other than AmigaOS, AtariOS, QNX (though it is fairly unix-like), BeOS, MacOS (though they had just bought NeXT), Plan9, Netware... the list could go on and on.. I think you might want to re-think that statement.
What surprises me the most is that this actually has to be said. It is ridiculous that mono is so actively used to actually make programs for official gnome, we got python, we got Java, we got Ruby, we certainly did not need MONO here.
.NET that are not included in the standard, but Mono has taken great pains to seperate those into different library sets, so they can be used optionally. Meanwhile, there are lots of open source developed libraries that depend only on ISO standard .net, like gtk#.
What suprises ME most is you feel the need to regulate the languages and technology other developers can use, simply because you don't like where they come from. Linux is about freedom. That includes the freedom to choose what technology you want to use. Does it not?
Where do you get the gall to demand that people not use any given technology?
First, no. Not everyones intention in creating open source is to make Free software. Many people just want to make cool stuff and give it to others, and they don't give a rip what they do with it, including commercializing it. You may not like that, but who are you to tell them differently?
Secondly, C# is an *ISO* standard. It has no patent restrictions. It is 100% Free to implement. The base class libraries are also patent restriction free, and are 100% Free to implement.
Yes, there are theoretical intellectual property issues in implementing parts of
Don't be so full of yourself as to believe that you know best for everyone else, and you should at least try to understand the issues before running off on rants.
Samba? That's only used so you can work with legacy Windows systems. SMB is a crap protocol, so there's no reason to bother with it unless you're required to work with legacy Windows system. If you're Windows-free, it has no real use.
That may be, but it's better than NFS. I know of many shops that use Samba, even between Linux and Unix systems, because NFS has so many issues. Why hasn't the Linux world taken network filesystems into their own hands, relying instead on protocols designed by Microsoft or Sun?
If everyone likes C# so much, then we should take matters into our own hands and implement a language with the features we like that is under our control!
My, doesn't that sound just like Microsoft.
PowerShell doesn't come with Vista, but it will come with Windows 2008 Server, which is what we're talking about.
And I was talking about the encrypted Windows Remote Shell (WinRS) when I said secure shell, not ssh. Both of those things are included with Windows 2008 Server standard.
Well, if you remember... back in the 9x days, whenever you needed to install a new piece of hardware, or make some change, it often asked you for your windows CD. That's been gone for a while, but the "solution" was to basically put all those files on your hard disk. Then came Windows File Protection, which keeps backup copies of files so that if they're deleted or overwritten with something else, windows would automatically restore those copies. Well, vista goes even further on that, and it wastes a ton of space in my opinion.
Your argument is silly, considering that PowerShell is probably the most advanced and powerful shell for any platform today. So your "but they might want a powerful command line" argument really doesn't work.
Microsoft has secure means, like the article mentions. Both RDP and Secure Shell.
I think the issue is more related to resources and security. Microsoft likely doesn't want to develop their own SSH code base, and they don't want to rely on a third party one because the third party doesn't confrom to their new security processes. While OpenSSH is good, it's had a number of security flaws in recent years as well.
When it boils down to it, SSH isn't needed to do Windows administration, so why would MS want to add to their security liability by including it?
Both Vista and 2008 suffer from 'backup-itis', use a tool like SpaceMonger on a fresh install of either and you'll see that well over 50% of the used space is copies of system files (sometes 3 or 4 copies). This is all part of the "self-healing" bit, but I think it's a waste of space.
Lots of people, including myself, use server versions of the OS as a desktop OS (I even have it on my laptop). The reason is simple. I'm a developer, and I work on code that needs services that are only available on the server version (multiple web sites, for instance).
The "web" version of Windows 2003 server isn't much more expensive than XP Pro.
I'm curious. Besides Star/Open Office (same app really, just marketed under two names.. one with some extras), what app suite implements the entire ODF spec? None that I know of.
In order for an app to implement the entire format, it must have every feature the format supports. Since ODF, by definition, supports the entire OpenOffice feature set, that means that any app that doesn't support every OpenOffice feature cannot implement the entire spec.
Well, actually. Yes, there is a reason why they shouldn't be disclosing everything they do upfront. Tht reason is ignorant users. These are people that freak out whever they see anything they don't understand, and gobbledygook about patches will send them screaming for IT support lines around the world.
Having said that, there should be ways to find out what was done, just not "up front".
In my experience, software is almost *ALWAYS* late. Even when it's not. Typically, most companies cannibalize testing time for development time, extending the development time and shrinking testing time so they can meet the schedule (or something aproximating it).
This is a result of many things, but the largest being that most shops are expected to give a firm estimate when they have the least amount of knowledge about what they're doing. This is because the users expect that when they say "it'll take 12 months" that it does, in fact, take 12 months.
Look at Microsoft. They get royally roasted every time they slip their schedule. So much so that they were forced to ship Vista before it was ready in order to appease the public. And don't say "5 years wasn't enough?" because things changed after Vista development started, all the requirements changed, security became a huge priority, retraiing, redesigns, re-doing XP and Windows 2003, etc.. Vista, when they finally got to work on it in earnest only started in late 2004 after all that other stuff was done. What's worse is that this fixed schedule likely forced many design compromises to get it done on time, not just shipping before it was ready.
That's fine for online, where computer can be built to order, or you have a whole world of customers to make it worth stocking every variation, but what about brick and morter stores? What about Walmart? Are you going to trust Walmart to install your OS?
So what you're saying is that everyone that sells a computer now has to either a) stock inventory of every possible OS configuration or b) accept the burden and liability of installing the OS and then, likely supporting the OS because they were the ones that did the installation?
Sure, the Dell's and Gateways can do this. Probably even the Best Buy's and Circuit City's, but that is a lot of burden to put on smaller shops unless they want said burden (many will see it as a way to make more money). Further, it means PC prices will likely have to go up, because the cost of the installation now moves from the VERY efficient OEM to the distribution chain which will have varying degrees of efficiency.
Large OEM's, sure. They have the staff to manage that. Smaller OEM's, however, would never be able keep up with hardware changes from week to week.
I agree with you, but the problem comes down to assessing the benefits vs cost. Ask nearly any programmer who's stuck maintaining code he didn't write and he'll tell you that the maintenance costs of maintaining the old code will be too high, and a rewrite needs to occur to reduce maintenance costs. Of course, even if that happens successfully, the next programmer put on maintenance will say the same thing of the new code.
It's often very difficult to migrate an application, piece by piece, to a new design. Look at Microsoft Office, for example.
I can think of very few applications in which text-throughput is an issue. I mean, if the throughput is is slowed down that much, then the data is going by so fast the user can't read it anyways. Which tells me that the data doesn't really need to go to the screen at all.
Take, for instance, a vt100 terminal connected to a mainframe that spews forth pages and pages of text. Most likely, that text doesn't need to be drawn to the screen, it could be dumped to a buffer and read (one screen at a time) or printed from that.
Can you provide an example of a use that REQUIRES text throughput to the screen?
I already responded to these further down the thread. Read what I wrote there.
I don't necessarily disagree with the points, but the conclusions don't follow from the problem space. .NET is very mature technology, as is SQL Server. The choice of those technologies was not the problem (other than throwing away something that worked).
AJAX is not particularly immature, though many frameworks are. AJAX has been around for almost 10 years (it just wasn't called AJAX then). And the choice of AJAX in this case was bad, not because of AJAX, but because the requirements didn't call for it.
Traditional apps don't offer more flexibility than Web-based Apps *in every circumstance*. Again, it depends on the requirements. If you need an app that is useable from anywhere in the world, without installing software on the client machine, the traditional apps are significantly LESS flexible, for instance. That wasn't the case in this situation, so the choice of a web-based app was silly.
The choice of Text based UI versus GUI is also silly. A well designed GUI app is just as usable via keyboard as a text one, it's just a different presentation framework.
I disagree with the vast majority of those points. The only two that I agree with is giving consideration to scalability and getting user feedback. The rest are illogical conclusions based on a failed project whos real failure was poorly specified requirements.
Certainly, Web UI's are not appropriate for everything. They should really only be used if there is some overpowering need (like the ability to access the data from anywhere without having client apps installed). They also apparently gave zero thought to existing processes and staff skillsets.
Avoiding AJAX or any other technology because you tried to use it for something it wasn't good at is patently stupid. There are good uses for the technologies. This just wasn't one of them.