Actually, no. The Wine team has essentially the same task. The fact that they are building on existing kernels is pretty irrelevant, given that Microsoft was too (I'm sure MS had to modify the NT kernle, but actually the Wine team has patches for the Linux kernel). The major task with Win2K, at least the reason stated for the delays, was that they were having trouble getting the Win32 API working with their kernel. The fact that the Wine team has been generally successful with such a small team shows how well they've done. Win2K was also just re-implementing an existing design with the win32 subsystem, which was the majority of their headaches. I have done quite a deal of design and coding. I am fully aware of what it takes.
Most of these are their own fault. As far as #2, all of the terrible hardware configurations to support are a result of their own making - like Plug-N-Play and WinModems. Older stuff doesn't need to be supported, especially since Win2K only supports 64Meg machines.
Given all of that, look at how far the Wine people have come with many, many fewer programmers. Their task is essentially the same as Win2K's.
One of the problems with all of this is that everyone is trying to push out large, bulky, crappy software. It _is_ too big to do right all-at-once. They fact that they are trying is proving either their ignorance or their contempt for their customers. Why not incrementally improve? Ask Bill Gates. He'll tell you "bugfixes don't sell software". They can't take any of their 2 Billion in _profit_ and fix your
bugs. Not to mention that you are the one who gave them 2 billion dollars, but that's a different story. Everyone would be much happier if all of IT people stopped "innovating" and just made something that worked. STOP ADDING FEATURES!
Think of every technology that someone has had to add compatibility for, and ask yourself, "was that technology really necessary? Did it help someone out?" Like WP file formats. I applaud SodiPodi for using the industry standard file format, rather than creating their own and importing/exporting. If someone makes something simplistic, everyone says, "it doesn't do X!" Well who cares! It works. It works well. If we start there, and _slowly_ add things, then we will have a true technology infrastructure, and not this bumpy road. This is another reason I love free software, because while commercial software can only sell "innovation", free software places value on bugfixing (not that free software packages are bug-free, but that what a company would pay for would be the support and fixing, not the innovation). Anyway, I'll end my rant here.
I think it's because RedHat is acquiring businesses. That's not included in your profit-and-loss because they are one-time expenditures.
Re:Didn't Steve Jobs Speak at MacWorld about....
on
Another Look At OS X
·
· Score: 2
YOU should go back and read The Mythical Man Month. What the poster was saying is that this is precisely the kind of problem that _is_ solvable by third parties. If the interface is there, more people will have it done faster. If the problem is architectural, _then_ more people will not make it go faster, which is precisely what the poster was saying. There are jobs which are very parallel, like driver-writing. Architectural jobs, however, are not. If I have X parallel jobs, then I can always get improvements with up to X number of people. For a stable system, driver-writing does not require the communication bottleneck that is described in the Mythical Man Month.
Second of all Linux probably has more than 63,000 bugs if you look at what ships from distributors. It's just that people classify bugs differently.
If I have a window that leaves artifacts if I move it around, that's a bug, even if they go away the next time something is moved over them. In fact, that may be several bugs, especially if it occurs at the driver level (it may happen on 20 drivers, so that's 20 bugs).
If Mozilla shifts an image one pixel to the left too far, that's a bug, even though anyone but the most hardcore testers may ever notice it.
Linux people tend to misunderstand what a bug is. We're used to dealing with and complaining about major bugs. Then when someone says, "the O.S. has 63,000 bugs" we think it has 63,000 major bugs. But that just isn't true. Bugs can also be potential race conditions that have never been exploited, or potential memory leaks that have never been looked at.
For example, if I'm programming, and I'm not sure if something I'm doing will cause a memory leak, I should add that as a bug. If the program is "notepad", there's no reason to ever even examine that bug, simply because notepad isn't a long-running app that will be affected by memory leaks.
Anyway, I agree that software has too many bugs, and that its the fault of both the distributor for not testing and the consumer for not demanding better. However, I do think you should take any bug count with a grain of salt because many of them refer to conditions that most people may not think of as bugs.
Charging is not the problem. Noone has a problem with charging. The problem comes that if I pay my $30, and then want to email the article to a friend. If I can't do that, it's bad, if I can, it's good. Information wants to be free, as in, have freedom, not as in "not paid for".
Re:This is big news! (For losers, of course.)
on
XFree 4.0.3 Released
·
· Score: 2
However, a comparison with Win95 is totally irrelevant, only a comparison with NT is relevant. So, at least compare to NT3.5 or something.
The problem is that the certificate holders hold secret information (namely, your private key). Passport issuers don't have the same problem. There is nothing that guarded that they are holding. I trust my goverment with a picture, a name, and an address. I will not trust them with my private keys.
You're missing the point. Your car _has_ a number. Your car isn't a number. I am not stealing your car by emailing my friend your VIN. Ideas _can't_ be owned. That's all there is to it. The basis of copyright law even says that copyright is a gift of the public to the author for the purposes of advancing the useful arts, not a mandate of nature like personal property. The reason that ideas/nonmaterial things can't be owned is that the transfer of copies does no direct harm to the original owner.
Yes, the C compiler is strict ANSI C. They have it building using just about every C compiler known to man. Some of the other languages that come with GCC require GCC to build. So, you have to build the C compiler, and then use that compiler to build the rest. Anyway, they have a "bootstrap" mode that is very, very nice.
1) The certificate authority also prevents man-in-the-middle attacks, because the CA has a known public key.
2) It is up to the browser vendors to decide who has a trustworthy network and who doesn't. If you can't trust your browser vendor on security issues, who can you trust(another reason not to use IE)?
You're missing the other use of certs - they prevent the man-in-the-middle attack, because VeriSign/Thawte (a trusted party with a known public key) can validate that they are giving you the "true" public key for that site, instead of giving you the public key for a middle-man machine.
Yes they do. In fact, SGI has been a great contributor to the scalability of Linux. Look at their free software pages. They aren't holding anything back. They've release (just to name a few), XFS (journaling filesystem), a high-availability clustering solution, a Linux kernel profiler, an OpenGL toolkit, a system management framework, a Linux kernel debugger, and a host of other things that you can find on their website. Make no mistake, SGI is all about free software these days.
What's even better is that the page mentions that they will do any necessary development to bring Linux to a robust and scalable operating system if the community doesn't do it beforehand.
On their OSS pages they have a port to MIPS, even with X-windows on the Indy series. I think SGI is
more committed than even other companies to free software, which is evident if you look at their free software pages.
Actually, the best would be in assembler as an Apache module. Apache modules are nice in that they don't have to be forked/execed - they just run right in the Apache process.
You've obviously never purchased a VA box. VA's stuff is much more than just a box that will run Linux. It's a box that will run Linux _wonderfully_. VA's problem was that they made too many assumptions about market growth. Their servers are worth every penny you pay. Lots of speed and reliability. How many hardware distributors do you know that
a) ship a custom version of RedHat for their hardware
b) use teflon cabling for their SCSI drives
c) do extensive QA on their prototypes so they discover minor memory problems on exceptional conditions, so they don't ship such things to their customers
This would only surprise me if they released source code. My guess is one of the following:
* They will release source code, but it's just a repackaging of the currently-available SOAP stuff for Linux
* They will release binaries that really, really suck, so they can say "Linux sucks"
* They will release binaries that harm your system integrity, by either sending MS information about your systems, opening up specific ports, or some other similar mechanism.
Call me paranoid, but if its anything else, I will be truly shocked and amazed.
Re:Which other protocols *also* have holes?
on
Security Hole In TCP
·
· Score: 4
You might find some good info from the creators of Samba. From what I've heard, they actually did find a huge number of security holes in the protocol. If there's docs for any of them, they'll be at http://us1.samba.org/samba/docs/
Free X server for Win32 from RedHat
on
Low-Bandwidth X
·
· Score: 3
RedHat is doing a Win32 port of X. See the scoop at
http://sources.redhat.com/win32-x11/
and
http://sources.redhat.com/cygwin/xfree/
These actually may be the same project. Says it runs on Windows 95, Windows 98, and Windows NT. I expect it would run on Windows 2000 as well.
Kernel exploits (generally) are only relevant when you have untrusted local users. So, if these were boxes that have multiple hosted sites with shell accounts, it would be a problem. If it's within a single organization, kernel patches aren't that big of a deal, unless its for a specific problem (I'm currently testing a patch to 2.2.18 to fix a VM problem). If you don't have any untrusted local users, you only need to keep your network software updated (Apache, FTP, inetd, etc).
Actually, most Linux breaches come from the other stuff distributions contain, not Apache. Apache is wonderfully great about security. Almost as good as the OpenBSD guys. The other Linux packages (ftp anyone?) seem to have more trouble.
Slashdot Mirror
Actually, no. The Wine team has essentially the same task. The fact that they are building on existing kernels is pretty irrelevant, given that Microsoft was too (I'm sure MS had to modify the NT kernle, but actually the Wine team has patches for the Linux kernel). The major task with Win2K, at least the reason stated for the delays, was that they were having trouble getting the Win32 API working with their kernel. The fact that the Wine team has been generally successful with such a small team shows how well they've done. Win2K was also just re-implementing an existing design with the win32 subsystem, which was the majority of their headaches. I have done quite a deal of design and coding. I am fully aware of what it takes.
Most of these are their own fault. As far as #2, all of the terrible hardware configurations to support are a result of their own making - like Plug-N-Play and WinModems. Older stuff doesn't need to be supported, especially since Win2K only supports 64Meg machines.
Given all of that, look at how far the Wine people have come with many, many fewer programmers. Their task is essentially the same as Win2K's.
One of the problems with all of this is that everyone is trying to push out large, bulky, crappy software. It _is_ too big to do right all-at-once. They fact that they are trying is proving either their ignorance or their contempt for their customers. Why not incrementally improve? Ask Bill Gates. He'll tell you "bugfixes don't sell software". They can't take any of their 2 Billion in _profit_ and fix your
bugs. Not to mention that you are the one who gave them 2 billion dollars, but that's a different story. Everyone would be much happier if all of IT people stopped "innovating" and just made something that worked. STOP ADDING FEATURES!
Think of every technology that someone has had to add compatibility for, and ask yourself, "was that technology really necessary? Did it help someone out?" Like WP file formats. I applaud SodiPodi for using the industry standard file format, rather than creating their own and importing/exporting. If someone makes something simplistic, everyone says, "it doesn't do X!" Well who cares! It works. It works well. If we start there, and _slowly_ add things, then we will have a true technology infrastructure, and not this bumpy road. This is another reason I love free software, because while commercial software can only sell "innovation", free software places value on bugfixing (not that free software packages are bug-free, but that what a company would pay for would be the support and fixing, not the innovation). Anyway, I'll end my rant here.
I think it's because RedHat is acquiring businesses. That's not included in your profit-and-loss because they are one-time expenditures.
YOU should go back and read The Mythical Man Month. What the poster was saying is that this is precisely the kind of problem that _is_ solvable by third parties. If the interface is there, more people will have it done faster. If the problem is architectural, _then_ more people will not make it go faster, which is precisely what the poster was saying. There are jobs which are very parallel, like driver-writing. Architectural jobs, however, are not. If I have X parallel jobs, then I can always get improvements with up to X number of people. For a stable system, driver-writing does not require the communication bottleneck that is described in the Mythical Man Month.
First of all, cars have bugs.
Second of all Linux probably has more than 63,000 bugs if you look at what ships from distributors. It's just that people classify bugs differently.
If I have a window that leaves artifacts if I move it around, that's a bug, even if they go away the next time something is moved over them. In fact, that may be several bugs, especially if it occurs at the driver level (it may happen on 20 drivers, so that's 20 bugs).
If Mozilla shifts an image one pixel to the left too far, that's a bug, even though anyone but the most hardcore testers may ever notice it.
Linux people tend to misunderstand what a bug is. We're used to dealing with and complaining about major bugs. Then when someone says, "the O.S. has 63,000 bugs" we think it has 63,000 major bugs. But that just isn't true. Bugs can also be potential race conditions that have never been exploited, or potential memory leaks that have never been looked at.
For example, if I'm programming, and I'm not sure if something I'm doing will cause a memory leak, I should add that as a bug. If the program is "notepad", there's no reason to ever even examine that bug, simply because notepad isn't a long-running app that will be affected by memory leaks.
Anyway, I agree that software has too many bugs, and that its the fault of both the distributor for not testing and the consumer for not demanding better. However, I do think you should take any bug count with a grain of salt because many of them refer to conditions that most people may not think of as bugs.
It did have too many obvious trollmarks. You're right it was probably humorous. I'll have to reboot my funnybone.
Obviously a troll, but I'll respond.
Charging is not the problem. Noone has a problem with charging. The problem comes that if I pay my $30, and then want to email the article to a friend. If I can't do that, it's bad, if I can, it's good. Information wants to be free, as in, have freedom, not as in "not paid for".
However, a comparison with Win95 is totally irrelevant, only a comparison with NT is relevant. So, at least compare to NT3.5 or something.
The problem is that the certificate holders hold secret information (namely, your private key). Passport issuers don't have the same problem. There is nothing that guarded that they are holding. I trust my goverment with a picture, a name, and an address. I will not trust them with my private keys.
Because this still doesn't solve the man-in-the-middle attack
You're missing the point. Your car _has_ a number. Your car isn't a number. I am not stealing your car by emailing my friend your VIN. Ideas _can't_ be owned. That's all there is to it. The basis of copyright law even says that copyright is a gift of the public to the author for the purposes of advancing the useful arts, not a mandate of nature like personal property. The reason that ideas/nonmaterial things can't be owned is that the transfer of copies does no direct harm to the original owner.
Yes, the C compiler is strict ANSI C. They have it building using just about every C compiler known to man. Some of the other languages that come with GCC require GCC to build. So, you have to build the C compiler, and then use that compiler to build the rest. Anyway, they have a "bootstrap" mode that is very, very nice.
1) The certificate authority also prevents man-in-the-middle attacks, because the CA has a known public key.
2) It is up to the browser vendors to decide who has a trustworthy network and who doesn't. If you can't trust your browser vendor on security issues, who can you trust(another reason not to use IE)?
You're missing the other use of certs - they prevent the man-in-the-middle attack, because VeriSign/Thawte (a trusted party with a known public key) can validate that they are giving you the "true" public key for that site, instead of giving you the public key for a middle-man machine.
Yes they do. In fact, SGI has been a great contributor to the scalability of Linux. Look at their free software pages. They aren't holding anything back. They've release (just to name a few), XFS (journaling filesystem), a high-availability clustering solution, a Linux kernel profiler, an OpenGL toolkit, a system management framework, a Linux kernel debugger, and a host of other things that you can find on their website. Make no mistake, SGI is all about free software these days.
What's even better is that the page mentions that they will do any necessary development to bring Linux to a robust and scalable operating system if the community doesn't do it beforehand.
On their OSS pages they have a port to MIPS, even with X-windows on the Indy series. I think SGI is
more committed than even other companies to free software, which is evident if you look at their free software pages.
Actually, the best would be in assembler as an Apache module. Apache modules are nice in that they don't have to be forked/execed - they just run right in the Apache process.
You've obviously never purchased a VA box. VA's stuff is much more than just a box that will run Linux. It's a box that will run Linux _wonderfully_. VA's problem was that they made too many assumptions about market growth. Their servers are worth every penny you pay. Lots of speed and reliability. How many hardware distributors do you know that
a) ship a custom version of RedHat for their hardware
b) use teflon cabling for their SCSI drives
c) do extensive QA on their prototypes so they discover minor memory problems on exceptional conditions, so they don't ship such things to their customers
VA makes a great server product.
The problem is that they called the police _after_ a staff member confirmed their story.
You also said
--who takes the blame when kids get killed????
The killers, maybe?
This would only surprise me if they released source code. My guess is one of the following:
* They will release source code, but it's just a repackaging of the currently-available SOAP stuff for Linux
* They will release binaries that really, really suck, so they can say "Linux sucks"
* They will release binaries that harm your system integrity, by either sending MS information about your systems, opening up specific ports, or some other similar mechanism.
Call me paranoid, but if its anything else, I will be truly shocked and amazed.
You might find some good info from the creators of Samba. From what I've heard, they actually did find a huge number of security holes in the protocol. If there's docs for any of them, they'll be at http://us1.samba.org/samba/docs/
RedHat is doing a Win32 port of X. See the scoop at
http://sources.redhat.com/win32-x11/
and
http://sources.redhat.com/cygwin/xfree/
These actually may be the same project. Says it runs on Windows 95, Windows 98, and Windows NT. I expect it would run on Windows 2000 as well.
Kernel exploits (generally) are only relevant when you have untrusted local users. So, if these were boxes that have multiple hosted sites with shell accounts, it would be a problem. If it's within a single organization, kernel patches aren't that big of a deal, unless its for a specific problem (I'm currently testing a patch to 2.2.18 to fix a VM problem). If you don't have any untrusted local users, you only need to keep your network software updated (Apache, FTP, inetd, etc).
Actually, most Linux breaches come from the other stuff distributions contain, not Apache. Apache is wonderfully great about security. Almost as good as the OpenBSD guys. The other Linux packages (ftp anyone?) seem to have more trouble.