Lets forget about the jokes. And instead lets try to imagine, what Microsoft Linux would really be like, if it was ever released.
I'm pretty sure it would include patches to the kernel, and they might even play by the rules and release the source for those. But there might very well be some closed source kernel modules as well. In addition you will not be allowed to copy those kernel modules. We can start guessing about what modules there will be. But I'm pretty sure one of them would be an ntfs driver.
Microsoft could get their usual GUI to run on top of Linux. Since
others have done most of it, Microsoft could do it as well. The exact details about how Microsoft would do it are not easy to guess. They could use parts of Wine, but maybe, Microsoft want to do it another way. If they are going to use Wine, they could either use the latest version, or the last non GPL version.
But Microsoft could take a completely different route and not use any Wine code at all, instead they could use as much of the existing Windows code as possible. I wonder if this would be best done in a library or a kernel module. Probably they would like a real binfmt_exe.o kernel module with its own personality. It is probably going to map some large DLLs into the process address space, and maybe even some shared memory.
I believe programs written for Windows when running on this Microsoft Linux will have access to some NTFS features, that are not easilly accesible by normal Linux programs. It could be done either by the closed source library knowing about some secret ioctl implemented by msntfs.o, or by cooperation between msntfs.o and binfmt_exe.o. Possibly a combination; an ioctl, which is not only secret, but also only allowed to programs running with the exe personality.
I wonder what graphics drivers are going to look like. I guess they will probably ship with closed source kernel modules implementing drivers for various graphics chips. But of course they are probably going to be incompatible with XFree86. And might even prevent the ones needed for XFree86 from being loaded at the same time.
That is not the hardware Microsoft would choose to perform a comparision between Linux and Windows. Instead they would choose hardware they know works better with Windows than Linux. I remember a test some years ago, back in the days when Linux was designed for no more than 768MB RAM and couldn't possibly use more than 2GB. Personally I didn't have access to any computer with more than 64MB, but of course that was already a lot. However Microsoft choosed to perform the test with 4GB RAM because they did have some kernel that could utilize that amount.
Yes, and if the GPL were ruled unenforceable, that would mean that M$ could make deals with the authors of code, offering them money
Nothing prevents M$ from doing that already today. There are of course a few practical limitations:
The code they want to use can have many different authors.
They must find the authors for all the pieces of code.
They must get permission from each of the authors.
It wouldn't get any easier by attacking the GPL. Do you really think authors of the GPL code would like to cooperate with M$ after they performed an attack on GPL. The real great part is, that people using GPL code as it was originally intended would be completely unaffected by the GPL being ruled unenforceable. You could simply keep using it just as you used to.
Microsoft interoperability testing? Who would have thought that? OK some people probably think Microsoft only do that testing to ensure it doesn't work. If it does work something have to be changed.
I have found multipledocuments stating that the first DOS version to support harddisks were MSDOS 3.0 from 1984. But the partition support in that version was so bad, that it might as well have been absent. It looks as it was something Microsoft added because they were somehow forced to, not because it was something they intended to use for anything reasonable.
I did a litle more search and found what apears to be the original
assembler source code for the partition table and parsing code. Notice the comment that indicates this was written by IBM two years before a DOS version with harddisk support were released.
the format of the partition table itself is an MS-DOS partition
table.
The partition table format is not OS specific. That particular format is supported by all OSes I know for the PC. (And for good reason). Linux does support other formats as well, but the "native" format when compiled for IA32 is the same as the one DOS uses.
Re:Now if only...
on
Clammy Modding
·
· Score: 2, Insightful
nasty keyboard "spills"
Some keyboards can actually be disassembled and cleaned. Reassembling the keyboard is the tricky part. As soon as you have opened the keyboard, you will know if it is one of the easy or the difficult to reassemble. If there are more than 100 pieces scattered over the floor, it is going to be difficult. Trust me I have tried it. OTOH I actually have one keyboard where there were only five pieces inside. Easy to clean and reassemble. I have yet to find a shop, that will let me see how a keyboard looks inside before I buy it.
Well, it is not a tower model, and I don't try lots of internal cards as this computer have no expansion slots at all. I was just copying a 120GB harddisk (takes a long time with only a single ATA33 channel). The only good things to say about this computer is, that it was cheap, and it make very litle noise. (And the i810 graphics actually works quite well with Linux.)
You are wrong about that. Each entry in the partition table contains a one byte type field, that tells you which filesystem is on the partition. Not that Linux cares. Linux will use the filesystem specified in/etc/fstab, on the command line, or autodetected by looking on the super block. But DOS and Windows do care about the type specified in the partition table. Did you ever try the l command in the Linux fdisk program. It will list a lot of those partition types. I could see 16 different types of FAT partitions. And only four types of Linux partitions, because Linux doesn't really care about those types. Some Linux install programs do however read the types.
Whish I had been there. Unfortunately I have only seen it on a low quality.mov file. Even looked like the camcorder was affected by some electrical interference when the computer was rebooted. But it was of course still a funny clip.
you would need a key of a size equal to the total storage of the hard drive itself for a true "one time pad" encryption of the HD.
You are wrong. That is simply not enough. It would be enough if you never changed any contents on the HD. But as soon as you change something, you would need more key bits.
I have seen a research document suggesting an algorithm to produce a pseudo one time pad from a key, and use that for encrypting the disk. For practical purposes it might be as secure as a one time pad. But since the one time pad is only secure as long as you never change anything on the disk, I don't consider that a good solution.
When I realized that might be state of the art in disk encryption, I decided to start researching it myself. Perhaps I should submit an article for slashdot when I have something interesting and new to tell the world about.:-)
So you're saying an excess of ventilation causes your computer to overheat?
Nope. The ventilation in my computer only works as intended when the case is closed. I once had the computer running for an hour open. The CPU was at 75C when I turned it off.
A USB storage keychain holds 128MB, which we can assume is XOR'd against each 128MB block on the hard drive.
I have heard such claims too often by people not understanding just how easy such an encryption is broken. One of those people once put up a 147 byte challenge in a security newsgroup. He didn't tell us how long the key was. Half an hour later I could tell everybody that the key length was 13 bytes. A simple statistical analysis clearly revealed the key length. The percentage of identical pairs of bytes was three times higher than for any other tried key length in the range 1-25. And shortly thereafter I had guessed the key. I wrote a program to make simple guesses about each char based on statistics. The program guesed 12 out of 13 chars in the keyword correct. The last one was trivial to fix by hand. Keep in mind, that some of those chars were only used 11 times. Encrypting a 128GB harddisk with a 128MB key and XOR encryption would cause key bytes to be used a thousand times. Far more than enough to guess most of the key.
Do you really want your CPU factoring primes every time you read a sector of your hard drive?!
No problem. It is easy to factor primes. Not that you'd use that for disk encryption though. Most of that would be done with symetric ciphers. Symetric ciphers are much faster (and maybe more secure) than the algebraic encryptions. I have come up with a disk encryption that needs a single RSA encryption per sector written to the disk, but that was because I came up with some ridicolous security requirements, including that anybody who get a copy of my RAM may not be able to decrypt anythng I write to the disk in the future.
Possibly because software encryption kills performance?
AES ceratinly was designed with performance in mind. And it can be implemented efficiently on 8-bit and 32-bit general purpose architectures as well as dedicated hardware. What interests me even more is what mode of operation they are using. I'm researching in modes aimed at disk encryption. It certainly is more complicated than just using CBC and be done with that.
Now if all you wanted to do was ECB mode encryption of the disk, that could be done very efficient in hardware. With 512 byte sectors and 256 bit blocks, you would have 16 blocks per sector, which could be encrypted and decrypted in parallel by 16 independend AES circuits. But of course that is not particular secure.
I have designed a more secure encryption that uses a tree structure on the disk. And involves both hashing and symmetric and assymetric encryption. Obviously it does have a price in terms of disk space, memory requirements, and I/O efficiency. But you get impressive security properties.
I doubt ABIT have done any of that, because the customers probably only want encryption if they can get it for free. Besides it would be stupid anyway considering the ridiculously small key of just 40 bits as mentioned in the specification. They claim it is adequate for general users. I say it is adequate for anybody who doesn't need encryption.
It's because 127.*.*.* is logically a Class A address
It is. But why did they allocate a class A when a class C would have been enough. In that case localhost could have been 223.255.255.1 (and only 256 addresses would be allocated 223.255.255.0/24).
Also, I don't think it is morally correct to punish for distributing code they did not know about.
I agree with that. But even though SCO did not know about it, they had the possibility to check. Developers and users of Linux OTOH had no possibility to check, if the code originated from SCO's closed source product. So they should not be punished either.
If SCO's claims are true, somebody has done something illegaly and should be punished. But that somebody might be just one person, it is certainly not everybody in the Linux community who is responsible.
The worst part of what SCO is doing right now (assuming their claims are correct), is to knowingly forcing the Linux community to keep using the infriging code. If they had just pointed out what code was infriging their rights, that code could be removed. Afterwards SCO and possibly people from the Linux community could sue the responsible person.
If you can get an advantage in your case by letting something illegal continue that you could easilly have stoped, there is certainly something completely wrong with the legal system.
They did say a "fenced buffer", so presumably the buffer is immediately followed by an unmapped page that raises SIGSEGV.
An unmapped page would not be safe since it could later get allocated from a different place in the program. An allocated but write protected page works. And that will give you a SIGSEGV.
This, of course, is absurdly expensive compared to checking the return value
It is expensive in case of a long line. But it is cheaper in all the cases where the line is not too long. Sometimes programmers are willing to accept a huge penalty in the rare cases to get a minor improvement in the usual cases, because on average the code will be faster.
if you never ever want to run on any machine without virtual memory
Without virtual memory local security is nonexistent. So I certainly don't want anything running without virtual memory.
So why would you not use fgets in this case?
Because then I will not get a signal in case of long lines.
Just because you like doing things the hard way?
Nope, using fgets is the hard way. Setting up a safe buffer and using gets requires less programming if you do it often.
Slashdot Mirror
Lets forget about the jokes. And instead lets try to imagine, what Microsoft Linux would really be like, if it was ever released.
I'm pretty sure it would include patches to the kernel, and they might even play by the rules and release the source for those. But there might very well be some closed source kernel modules as well. In addition you will not be allowed to copy those kernel modules. We can start guessing about what modules there will be. But I'm pretty sure one of them would be an ntfs driver.
Microsoft could get their usual GUI to run on top of Linux. Since others have done most of it, Microsoft could do it as well. The exact details about how Microsoft would do it are not easy to guess. They could use parts of Wine, but maybe, Microsoft want to do it another way. If they are going to use Wine, they could either use the latest version, or the last non GPL version.
But Microsoft could take a completely different route and not use any Wine code at all, instead they could use as much of the existing Windows code as possible. I wonder if this would be best done in a library or a kernel module. Probably they would like a real binfmt_exe.o kernel module with its own personality. It is probably going to map some large DLLs into the process address space, and maybe even some shared memory.
I believe programs written for Windows when running on this Microsoft Linux will have access to some NTFS features, that are not easilly accesible by normal Linux programs. It could be done either by the closed source library knowing about some secret ioctl implemented by msntfs.o, or by cooperation between msntfs.o and binfmt_exe.o. Possibly a combination; an ioctl, which is not only secret, but also only allowed to programs running with the exe personality.
I wonder what graphics drivers are going to look like. I guess they will probably ship with closed source kernel modules implementing drivers for various graphics chips. But of course they are probably going to be incompatible with XFree86. And might even prevent the ones needed for XFree86 from being loaded at the same time.
Get 2 Pentium III 450MHz with 768MB of RAM
That is not the hardware Microsoft would choose to perform a comparision between Linux and Windows. Instead they would choose hardware they know works better with Windows than Linux. I remember a test some years ago, back in the days when Linux was designed for no more than 768MB RAM and couldn't possibly use more than 2GB. Personally I didn't have access to any computer with more than 64MB, but of course that was already a lot. However Microsoft choosed to perform the test with 4GB RAM because they did have some kernel that could utilize that amount.
Nothing prevents M$ from doing that already today. There are of course a few practical limitations:
- The code they want to use can have many different authors.
- They must find the authors for all the pieces of code.
- They must get permission from each of the authors.
It wouldn't get any easier by attacking the GPL. Do you really think authors of the GPL code would like to cooperate with M$ after they performed an attack on GPL. The real great part is, that people using GPL code as it was originally intended would be completely unaffected by the GPL being ruled unenforceable. You could simply keep using it just as you used to.Microsoft interoperability testing? Who would have thought that? OK some people probably think Microsoft only do that testing to ensure it doesn't work. If it does work something have to be changed.
Where do you think the one DOS uses came from?
I have found multiple documents stating that the first DOS version to support harddisks were MSDOS 3.0 from 1984. But the partition support in that version was so bad, that it might as well have been absent. It looks as it was something Microsoft added because they were somehow forced to, not because it was something they intended to use for anything reasonable.
I did a litle more search and found what apears to be the original assembler source code for the partition table and parsing code. Notice the comment that indicates this was written by IBM two years before a DOS version with harddisk support were released.
the format of the partition table itself is an MS-DOS partition table.
The partition table format is not OS specific. That particular format is supported by all OSes I know for the PC. (And for good reason). Linux does support other formats as well, but the "native" format when compiled for IA32 is the same as the one DOS uses.
nasty keyboard "spills"
Some keyboards can actually be disassembled and cleaned. Reassembling the keyboard is the tricky part. As soon as you have opened the keyboard, you will know if it is one of the easy or the difficult to reassemble. If there are more than 100 pieces scattered over the floor, it is going to be difficult. Trust me I have tried it. OTOH I actually have one keyboard where there were only five pieces inside. Easy to clean and reassemble. I have yet to find a shop, that will let me see how a keyboard looks inside before I buy it.
Well, it is not a tower model, and I don't try lots of internal cards as this computer have no expansion slots at all. I was just copying a 120GB harddisk (takes a long time with only a single ATA33 channel). The only good things to say about this computer is, that it was cheap, and it make very litle noise. (And the i810 graphics actually works quite well with Linux.)
A half sleeping government worker will enter the password that is written on the back of the keyboard
And once again the geek with something to hide won the batle. It was the password for activating the self destruct mechanism.
If this can be done in hardware, that's a good thing.
I agree. But this particular hardware solution looks very weak and incompatible with existing software solutions. That is not a good thing.
FAT16 and FAT32 are filesystems, not partitions.
/etc/fstab, on the command line, or autodetected by looking on the super block. But DOS and Windows do care about the type specified in the partition table. Did you ever try the l command in the Linux fdisk program. It will list a lot of those partition types. I could see 16 different types of FAT partitions. And only four types of Linux partitions, because Linux doesn't really care about those types. Some Linux install programs do however read the types.
You are wrong about that. Each entry in the partition table contains a one byte type field, that tells you which filesystem is on the partition. Not that Linux cares. Linux will use the filesystem specified in
I was there.
.mov file. Even looked like the camcorder was affected by some electrical interference when the computer was rebooted. But it was of course still a funny clip.
Whish I had been there. Unfortunately I have only seen it on a low quality
you would need a key of a size equal to the total storage of the hard drive itself for a true "one time pad" encryption of the HD.
:-)
You are wrong. That is simply not enough. It would be enough if you never changed any contents on the HD. But as soon as you change something, you would need more key bits.
I have seen a research document suggesting an algorithm to produce a pseudo one time pad from a key, and use that for encrypting the disk. For practical purposes it might be as secure as a one time pad. But since the one time pad is only secure as long as you never change anything on the disk, I don't consider that a good solution.
When I realized that might be state of the art in disk encryption, I decided to start researching it myself. Perhaps I should submit an article for slashdot when I have something interesting and new to tell the world about.
So you're saying an excess of ventilation causes your computer to overheat?
Nope. The ventilation in my computer only works as intended when the case is closed. I once had the computer running for an hour open. The CPU was at 75C when I turned it off.
A USB storage keychain holds 128MB, which we can assume is XOR'd against each 128MB block on the hard drive.
I have heard such claims too often by people not understanding just how easy such an encryption is broken. One of those people once put up a 147 byte challenge in a security newsgroup. He didn't tell us how long the key was. Half an hour later I could tell everybody that the key length was 13 bytes. A simple statistical analysis clearly revealed the key length. The percentage of identical pairs of bytes was three times higher than for any other tried key length in the range 1-25. And shortly thereafter I had guessed the key. I wrote a program to make simple guesses about each char based on statistics. The program guesed 12 out of 13 chars in the keyword correct. The last one was trivial to fix by hand. Keep in mind, that some of those chars were only used 11 times. Encrypting a 128GB harddisk with a 128MB key and XOR encryption would cause key bytes to be used a thousand times. Far more than enough to guess most of the key.
Do you really want your CPU factoring primes every time you read a sector of your hard drive?!
No problem. It is easy to factor primes. Not that you'd use that for disk encryption though. Most of that would be done with symetric ciphers. Symetric ciphers are much faster (and maybe more secure) than the algebraic encryptions. I have come up with a disk encryption that needs a single RSA encryption per sector written to the disk, but that was because I came up with some ridicolous security requirements, including that anybody who get a copy of my RAM may not be able to decrypt anythng I write to the disk in the future.
Possibly because software encryption kills performance?
AES ceratinly was designed with performance in mind. And it can be implemented efficiently on 8-bit and 32-bit general purpose architectures as well as dedicated hardware. What interests me even more is what mode of operation they are using. I'm researching in modes aimed at disk encryption. It certainly is more complicated than just using CBC and be done with that.
Now if all you wanted to do was ECB mode encryption of the disk, that could be done very efficient in hardware. With 512 byte sectors and 256 bit blocks, you would have 16 blocks per sector, which could be encrypted and decrypted in parallel by 16 independend AES circuits. But of course that is not particular secure.
I have designed a more secure encryption that uses a tree structure on the disk. And involves both hashing and symmetric and assymetric encryption. Obviously it does have a price in terms of disk space, memory requirements, and I/O efficiency. But you get impressive security properties.
I doubt ABIT have done any of that, because the customers probably only want encryption if they can get it for free. Besides it would be stupid anyway considering the ridiculously small key of just 40 bits as mentioned in the specification. They claim it is adequate for general users. I say it is adequate for anybody who doesn't need encryption.
how many cases aren't already open?
Mine is closed. The computer simply gets too hot if I leave it open.
It's because 127.*.*.* is logically a Class A address
It is. But why did they allocate a class A when a class C would have been enough. In that case localhost could have been 223.255.255.1 (and only 256 addresses would be allocated 223.255.255.0/24).
Also, I don't think it is morally correct to punish for distributing code they did not know about.
I agree with that. But even though SCO did not know about it, they had the possibility to check. Developers and users of Linux OTOH had no possibility to check, if the code originated from SCO's closed source product. So they should not be punished either.
If SCO's claims are true, somebody has done something illegaly and should be punished. But that somebody might be just one person, it is certainly not everybody in the Linux community who is responsible.
The worst part of what SCO is doing right now (assuming their claims are correct), is to knowingly forcing the Linux community to keep using the infriging code. If they had just pointed out what code was infriging their rights, that code could be removed. Afterwards SCO and possibly people from the Linux community could sue the responsible person.
If you can get an advantage in your case by letting something illegal continue that you could easilly have stoped, there is certainly something completely wrong with the legal system.
Torvalds admittedly makes no checks himself.
Because it is impossible to check. When somebody come with a piece of code, and say they wrote it, how would you check?
They did say a "fenced buffer", so presumably the buffer is immediately followed by an unmapped page that raises SIGSEGV.
An unmapped page would not be safe since it could later get allocated from a different place in the program. An allocated but write protected page works. And that will give you a SIGSEGV.
This, of course, is absurdly expensive compared to checking the return value
It is expensive in case of a long line. But it is cheaper in all the cases where the line is not too long. Sometimes programmers are willing to accept a huge penalty in the rare cases to get a minor improvement in the usual cases, because on average the code will be faster.
if you never ever want to run on any machine without virtual memory
Without virtual memory local security is nonexistent. So I certainly don't want anything running without virtual memory.
But remember, LSB refers to a single operating system, that OS being (as it's name states) Linux.
I don't know the details of LSB. Would it be any problem to make for example one of the BSDs compliant with LSB?
So why would you not use fgets in this case?
Because then I will not get a signal in case of long lines.
Just because you like doing things the hard way?
Nope, using fgets is the hard way. Setting up a safe buffer and using gets requires less programming if you do it often.
So it's better to be compliant with a single operating system than an open, published standard?
Is LSB not published? Is POSIX more open than LSB?
It takes years to add stuff to a standard
Some of the changes might actually be about removing stuff from the standard.