Not to mention all you need to do to reset any BIOS password is change
a jumper.
True, but that is not really the problem. There are two different issues.
Can an intruder get access to the system?
Can an intruder get the password?
Obviously an intruder that can get the password can also get access to the system, but it doesn't have to be the other way around. Why is that even interesting? Well, if the same password is used in a different place, it will be interesting to protect the password even if the intruder get access to the system. Obviously encryption is not necesarry if you only want to prevent the computer from getting access. The intruder will need to get access to the system first, before he can read the password, so it doesn't matter whether the password is encrypted or not, because he already have access.
The intruder that wants to get the password and don't care about getting access, cannot use the BIOS jumper/remove battery trick, because that would delete the password he wanted. Assuming the intruder found another way to read the password (like by replacing the harddisk), it would be an advantage that the password was encrypted.
Given the facts that BIOS sizes are quite limited, and few users care whether the BIOS password is encrypted, I guess BIOSes that actually encrypt the password are rare. (Strictly encrypting is not the right term, it is more like a one way function or a hash function being used).
Why can't MS send atleast an email alert to Volume Licensees?
Doesn't Microsoft send an email with an attached patch to everybody in the world, when a security problem is found? At least I get a lot of those emails all the time, and I don't even use Windows.
How about: "We found your email address on a newsgroup and thought you might be interested in this Windows program". When I read something like that I wonder, did they loose their brain somewhere? It was a Linux newsgroup!
Because no one will every be able to find that code snippet in Windows, (maybe this is what microsoft means by security through obscurity?)
Ah, so the source is not closed to hide any trade secrets, but rather to hide the amounts of illegal copied code. Obviously the source is closed because they want to hide crimes. What we need now is a law against closed source software such that this copying of code will stop (assuming nobody will do it, when the crime they are commiting is so obvious). It is just like with encryption, if you need encryption it is because you are hiding some criminal actions, same with closed source software.
If we enter a regime where all OSS submission have to be checked against unpublished undistributed works OSS will be dead.
Verifying whether an open source system contains code from other projects might be hard. But verifying wheter a closed source system does likewise will be even harder. Who knows if Microsoft Windows contains just a tiny bit of code which Microsoft doesn't have the right to use that way? Can everybody in the entire world be held liable if that turns out to be the case? Why wouldn't that be the death of closed source software?
Probably because there is no case. SCO have a big mouth but nothing else. Everything SCO says apears not to bother IBM. IBM just do business as usual. Now if just the media would have ignored SCO the way IBM does. But if this ever goes to court IBM will defend themselves.... What will be left of SCO when that happens?
Whats the cost to Australia of all that money going to the USA
So what you are saying is, that in some cases it would be acceptable for the government to spend more money if that just means that less of the money would leave the country. I think you are right about that, it is an important point.
You seem to be exaggerating the stability of Linux though.
I'm merely stating facts. All uptimes I have stated are from real working systems. In addition to that I stated that most of the Linux crashes I experience are driver related.
Since you've not used Windows for years
I didn't make claims about Windows, I merely discuss claims made by other people using Windows.
take the latest 2.5 series. See all those great changes? The massive improvments?
Claiming a system is bad because it is being improved is ridicolous. Does that mean that it would be a great system if each release was a regression? Now please take a look on some of those improvements.
Improved threading just because it is geting better, it doesn't mean the old system was bad. Linux has been far ahead of Windows in that area for the last many years. Benchmarks have shown, that processes on Linux were as fast as threads on Windows. On each system threads are obviously much faster than processes, so Windows really was a joke OS compared to Linux.
Improved SMP it is true that Linux didn't scale well to more than two CPUs. This is mainly because very few of the developers and users had more than two CPUs. In fact I believe most users still use single CPU machines. And since this thread is about desktops, large scale SMP is not what you should base your decissions on.
Improved scheduler: I looked on the source for the old scheduler a long time before anybody considered a rewrite. And I did wonder why this slow piece of code didn't slow down the entire system to an unacceptable poor performance. But the fact was that as long as you didn't spawn hundreds or thousands of processes, it wasn't that bad. So while the old scheduler was not that good, it wasn't bad enough to destroy the performance of an otherwise efficient system.
Preemptible kernel is one of the more dubious improvements. It is very subtle, and I fear it still has lots of race conditions. The responsitivity you get from this should be achievable by simple conditional reschedules in all slow pieces of kernel code. It would be a lot of work since you find such slow code in a lot of drivers, but it would not be as prone to race conditions. Since the checks themselves takes time, it is sometimes most efficient to really preempt the kernel code. But preemption should only be needed for small parts of the code where a lot of CPU time is spent and races will not happen. Obviously I don't know whether Windows has a preemptible kernel, and few people if any here knows. And since we have no way to compare Windows with and without that feature, it really doesn't tell us much anyway. If anybody really want to take that discussion, we can probably not avoid the issue of monolitic vs. microkernel.
And when I said good design, I mostly think about the overall Unix design, and the kernel/user interface. I didn't intend to say every single part of the kernel is well designed, there are a few parts there that can be
improved.
Linux biased thread
You might consider me to be biased towards Linux. Six years ago I had no experience with Linux. I was used to AmigaOS, DOS, and Windows. I had seen Linux once and thought it was a weird system that I couldn't really use for anything. But after being forced to use UNIX systems, I started seeing some of the advantages. Anybody calling me Linux biased should consider why I make the statments I do. It is certainly not economical interests like I suspect is the reason for a lot of those people biased towards Windows. The reasons I praise Linux are purely technical and the good experiences I have with the system.
Any percieved additional instability in Windows is no doubt do the the huge amount of non-certified drivers, and massive selection of exotic hardware that Windows supports.
It would be interesting to do a fair comparision of the stability of the two systems, but it requires a good hardware platform. That requires well functional and well documenated hardware all the way through. Does anybody know how to find such a hardware platform? I don't!
You still have yet to dispute the ATA and SMP issues. Do they not
exist?
You are mixing up two different problems described. The one problem was ATA raid which I don't know anything about. Though it was claimed a lot of people have such hardware, I don't know anybody using it. The other problem was SCSI+SMP. We have four dual XEON servers with SCSI disks, and they operate without major problems. So right now there apears to be only one person who has seen the problem. It could be bad hardware.
If the Linux community would stop lying every time they open their mouth they would probably get a whole lot more respect.
Get real. I don't lie about those things. There might be people exaggerating the instability problems with Windows. I wouldn't know, I gave up on Microsoft years ago, and I haven't used Windows since (at least not on any of my own computers). The reason I started using Linux four years ago was that it was the cheapest way I could get a UNIX compatible workstation. Since then I have found a lot of advantages that I will not live without:
I can easilly get a lot of information about what is going on on my computer, that helps in debugging whatever problems I might have.
Availability of source, for multiple reasons: My own curiosity, my own desire to adjust small details in the software, and finally the possibility to fix bugs on my own rather than having to rely on somebody else to do it.
I really like the simple, clever, and flexible design of the system. (Here I mostly think about the UNIX design and the Linux kernel, not everything built on top is as good, but at least the core components are well designed.)
Who is going to take them to court to fight it? Nobody. However, this issue will be pressed by the IBM law team, and quite probably will have a favorable outcome on this point.
Anybody who owns copyright for parts of the kernel can take infrigers to court.
It can turn out to be convenient that IBM actually owns the copyright for parts of the Linux kernel.
They obviously believe that they can defeat the GPL in court.
That might be good news. AFAIK the GPL has never been taken to court before. In this case it looks very much like SCO is going to loose big time, if it really is taken to court. This could give the GPL some good precedence, much better than if the first case taken to court was one where the use of GPL was dubious.
Well, hopefully the smart guys on the Kernel team are thinking about this already
They have thought about it as much as they can possibly do not knowing what it is all about. As long as SCO will not tell what it is all about, there is nothing to be done. For all we know it might be just hot air and nothing else.
A new kernel version is a definite good reason for a whole version increment.
Had they used kernel version 2.6.0-test1, I would have agreed with you. But going from 2.4.20 to 2.4.21 really isn't that big a step. Consider that there are more differences between the kernel which came with the distribution and what you will soon be running if you just keep up with the security updates. For example RH7.1 when released was using kernel version 2.4.2-2, if you have installed the security updates, you will now be running kernel version 2.4.20-19.7.
Slashdot Mirror
I fail to see how. gets uses stdin for its input stream.
There are at least two safe ways to use gets()
Linux Trace Trollkit ;-)
...).
is that for real? or is it the obligatory intentional-typo
I'm pretty sure I saw that exact same "typo" when 2.6.0-test1 was released (or was it 2.5.75? or was it
When zlib had the double-free bug last year, XP had to be patched too.
And as usual the medias got it all wrong. From the headlines: "Linux bug affects Windows".
So what architectures will the Linux version run on, if it is not the PC?
True, but that is not really the problem. There are two different issues.
- Can an intruder get access to the system?
- Can an intruder get the password?
Obviously an intruder that can get the password can also get access to the system, but it doesn't have to be the other way around. Why is that even interesting? Well, if the same password is used in a different place, it will be interesting to protect the password even if the intruder get access to the system. Obviously encryption is not necesarry if you only want to prevent the computer from getting access. The intruder will need to get access to the system first, before he can read the password, so it doesn't matter whether the password is encrypted or not, because he already have access.The intruder that wants to get the password and don't care about getting access, cannot use the BIOS jumper/remove battery trick, because that would delete the password he wanted. Assuming the intruder found another way to read the password (like by replacing the harddisk), it would be an advantage that the password was encrypted.
Given the facts that BIOS sizes are quite limited, and few users care whether the BIOS password is encrypted, I guess BIOSes that actually encrypt the password are rare. (Strictly encrypting is not the right term, it is more like a one way function or a hash function being used).
Why can't MS send atleast an email alert to Volume Licensees?
Doesn't Microsoft send an email with an attached patch to everybody in the world, when a security problem is found? At least I get a lot of those emails all the time, and I don't even use Windows.
I wonder why the resume make a statement about Linux passwords without even mentioning whether they are talking about DES or MD5 based passwords.
This is why I use Biopassword Perhaps their encryption method is just as insecure as microsoft's
I have seen BIOSes that did not encrypt the password at all.
if this whole mess were not true.
If you want something untrue, just read SCO's claims.
The second, "You are using Linux! Send us money!"
How about: "We found your email address on a newsgroup and thought you might be interested in this Windows program". When I read something like that I wonder, did they loose their brain somewhere? It was a Linux newsgroup!
Why wait for 2.6.0 when 2.6.0-test1 is ready for testing?
Because no one will every be able to find that code snippet in Windows, (maybe this is what microsoft means by security through obscurity?)
Ah, so the source is not closed to hide any trade secrets, but rather to hide the amounts of illegal copied code. Obviously the source is closed because they want to hide crimes. What we need now is a law against closed source software such that this copying of code will stop (assuming nobody will do it, when the crime they are commiting is so obvious). It is just like with encryption, if you need encryption it is because you are hiding some criminal actions, same with closed source software.
If we enter a regime where all OSS submission have to be checked against unpublished undistributed works OSS will be dead.
Verifying whether an open source system contains code from other projects might be hard. But verifying wheter a closed source system does likewise will be even harder. Who knows if Microsoft Windows contains just a tiny bit of code which Microsoft doesn't have the right to use that way? Can everybody in the entire world be held liable if that turns out to be the case? Why wouldn't that be the death of closed source software?
IBM's quiet. Too quiet.
Probably because there is no case. SCO have a big mouth but nothing else. Everything SCO says apears not to bother IBM. IBM just do business as usual. Now if just the media would have ignored SCO the way IBM does. But if this ever goes to court IBM will defend themselves.... What will be left of SCO when that happens?
our old enemy SCO.
No, SCO is not our old enemy. SCO is our new enemy. Don't know who qualifies for the old enemy title. Perhaps M$ or RIAA?
Whats the cost to Australia of all that money going to the USA
So what you are saying is, that in some cases it would be acceptable for the government to spend more money if that just means that less of the money would leave the country. I think you are right about that, it is an important point.
Ahh, so because you don't know of any people using it. It dosn't exist?
I never said that.
I'm merely stating facts. All uptimes I have stated are from real working systems. In addition to that I stated that most of the Linux crashes I experience are driver related.
Since you've not used Windows for years
I didn't make claims about Windows, I merely discuss claims made by other people using Windows.
take the latest 2.5 series. See all those great changes? The massive improvments?
Claiming a system is bad because it is being improved is ridicolous. Does that mean that it would be a great system if each release was a regression? Now please take a look on some of those improvements.
- Improved threading just because it is geting better, it doesn't mean the old system was bad. Linux has been far ahead of Windows in that area for the last many years. Benchmarks have shown, that processes on Linux were as fast as threads on Windows. On each system threads are obviously much faster than processes, so Windows really was a joke OS compared to Linux.
- Improved SMP it is true that Linux didn't scale well to more than two CPUs. This is mainly because very few of the developers and users had more than two CPUs. In fact I believe most users still use single CPU machines. And since this thread is about desktops, large scale SMP is not what you should base your decissions on.
- Improved scheduler: I looked on the source for the old scheduler a long time before anybody considered a rewrite. And I did wonder why this slow piece of code didn't slow down the entire system to an unacceptable poor performance. But the fact was that as long as you didn't spawn hundreds or thousands of processes, it wasn't that bad. So while the old scheduler was not that good, it wasn't bad enough to destroy the performance of an otherwise efficient system.
- Preemptible kernel is one of the more dubious improvements. It is very subtle, and I fear it still has lots of race conditions. The responsitivity you get from this should be achievable by simple conditional reschedules in all slow pieces of kernel code. It would be a lot of work since you find such slow code in a lot of drivers, but it would not be as prone to race conditions. Since the checks themselves takes time, it is sometimes most efficient to really preempt the kernel code. But preemption should only be needed for small parts of the code where a lot of CPU time is spent and races will not happen. Obviously I don't know whether Windows has a preemptible kernel, and few people if any here knows. And since we have no way to compare Windows with and without that feature, it really doesn't tell us much anyway. If anybody really want to take that discussion, we can probably not avoid the issue of monolitic vs. microkernel.
And when I said good design, I mostly think about the overall Unix design, and the kernel/user interface. I didn't intend to say every single part of the kernel is well designed, there are a few parts there that can be improved.Linux biased thread
You might consider me to be biased towards Linux. Six years ago I had no experience with Linux. I was used to AmigaOS, DOS, and Windows. I had seen Linux once and thought it was a weird system that I couldn't really use for anything. But after being forced to use UNIX systems, I started seeing some of the advantages. Anybody calling me Linux biased should consider why I make the statments I do. It is certainly not economical interests like I suspect is the reason for a lot of those people biased towards Windows. The reasons I praise Linux are purely technical and the good experiences I have with the system.
Any percieved additional instability in Windows is no doubt do the the huge amount of non-certified drivers, and massive selection of exotic hardware that Windows supports.
It would be interesting to do a fair comparision of the stability of the two systems, but it requires a good hardware platform. That requires well functional and well documenated hardware all the way through. Does anybody know how to find such a hardware platform? I don't!
You still have yet to dispute the ATA and SMP issues. Do they not exist?
You are mixing up two different problems described. The one problem was ATA raid which I don't know anything about. Though it was claimed a lot of people have such hardware, I don't know anybody using it. The other problem was SCSI+SMP. We have four dual XEON servers with SCSI disks, and they operate without major problems. So right now there apears to be only one person who has seen the problem. It could be bad hardware.
planning a release with the 2.6 kernel this October.
I found this page. Doesn't mention a date for the 2.6 kernel though.
Get real. I don't lie about those things. There might be people exaggerating the instability problems with Windows. I wouldn't know, I gave up on Microsoft years ago, and I haven't used Windows since (at least not on any of my own computers). The reason I started using Linux four years ago was that it was the cheapest way I could get a UNIX compatible workstation. Since then I have found a lot of advantages that I will not live without:
Who is going to take them to court to fight it? Nobody. However, this issue will be pressed by the IBM law team, and quite probably will have a favorable outcome on this point.
Anybody who owns copyright for parts of the kernel can take infrigers to court. It can turn out to be convenient that IBM actually owns the copyright for parts of the Linux kernel.
They obviously believe that they can defeat the GPL in court.
That might be good news. AFAIK the GPL has never been taken to court before. In this case it looks very much like SCO is going to loose big time, if it really is taken to court. This could give the GPL some good precedence, much better than if the first case taken to court was one where the use of GPL was dubious.
Well, hopefully the smart guys on the Kernel team are thinking about this already
They have thought about it as much as they can possibly do not knowing what it is all about. As long as SCO will not tell what it is all about, there is nothing to be done. For all we know it might be just hot air and nothing else.
A new kernel version is a definite good reason for a whole version increment.
Had they used kernel version 2.6.0-test1, I would have agreed with you. But going from 2.4.20 to 2.4.21 really isn't that big a step. Consider that there are more differences between the kernel which came with the distribution and what you will soon be running if you just keep up with the security updates. For example RH7.1 when released was using kernel version 2.4.2-2, if you have installed the security updates, you will now be running kernel version 2.4.20-19.7.