That's funny my computer has been turned off multiple times without the "proper" shutdown sequence and it has almost always worked perfectly.
"almost", hmm, "almost", thank you for proving my point. With every other Unix version (and Windows NT, since I am at it), I have never seen a drive consistancy check require manual intervention.
I theory eventually linux will surpass BSD in this area. Bigger user base and more competent developers with the source code and developers who will listen will always equal a better product.
This assumes that Linux's developers are more competent. But let's compare TCP/IP stacks of say, FreeBSD and Linux. Well, FreeBSD blows Linux out of the water. Let's compare virtual memory. FreeBSD virtual memory is simply incredible which why big sites run FreeBSD. NetBSD's new UVM is quite interesting and I wish I had time to look into it further. Linux's VM contains nothing insightful or even intelligent. Let's look at the file systems. Traditional Unix file systems included in the BSDs and SVR4s are rock solid. Are you using EXT2FS? I hope someone doesn't pull the plug on you, it probably won't come back.
Great example! TCP/IP from Berkeley was released under the BSD license and almost nobody rewrote. Everyone took the BSD TCP/IP code and incorprated it into their products. Well, everyone except Linux and the HURD. You see, Stallman's GPL wouldn't let them use BSD code. And this is why Linux's TCP/IP stack is still one of the weaker ones in the industry. Further proof that the GPL is only a partial solution.
I have recently run across something similar. I want to convert a a telnet-based bbs (called M-Net) to a multilingual site. The problem is there we are limited to merely what VT100 will let us output. In the end, we decided to translate the documents and use basic locale and i18n features already in the OS to help. It is not quite the same but I hope it helps.
Re:Why is hashing better than encrypting?
on
QNX Crypt Cracked
·
· Score: 3
This is a really weak analogy, but it will do for now. Imagine you have a number x. Now, let's "encrypt" x using a simple reversable function. So let's take y = 2x + 3. If we have y, we know that x = (y + 3) / 2. Okay, now let's "hash" x instead and make y = x * x. Now, given y, we know that x = sqrt(y) or x = -sqrt(y). Therefore, the pricise value of x is not known.
Yeah, I said it was not a great example and it has some other flaws (for instance, it doesn't matter which x you choose since they both work), but it should get the point across.
Darwin does have an x86 version. There are also persistant rumours that MacOS will compile on the x86, but Apple is not likely to release this any time soon.
Even if Minix were (in the past or right now) released under the four clause BSD license, the UCB announcement still does not affect Minix. UCB has no right to the Minix code and nothing UCB does will ever affect Minix.
It is really wonderful to see a major project released under the BSD license instead of the GPL or a home-rolled license. Publicitly like that will only help the BSD crowd and having more code under the BSD license is just grand. And of course, it is nice to see someone realizing that the BSD license is absolutely perfect for the majority of projects. The GPL only causes problems with minor projects.
Also, I think a reason (though I didn't see it listed) to use a BSD license is the fact a lot of the utilities in Minix have really old BSD copyrights in them. They probably were derived from some ancient BSD tapes and cannot be put under the GPL. (Yes, I am aware of UCB's pulling of the advertising clause but you would have to get every person who contributed to that code in Minix to agree to pulling the advertising clause from the forked Minix version. Even if one person said no, it can never be GPL'd.)
Ah, but look at what I presented above. There is no need to spoof the originating IP when you are hitting it from thousands of nodes across the net (and you don't own any of them)! No one can shut down thousands of machines at the same time.
It's FreeBSD that had a performace advantage over Linux on x86. I doubt NetBSD ever did, despite (I assume) sharing the same stack, because of the lack of emphasis on performance in that version of BSD. (A BSD expert might correct me here - is the Network performace of NetBSD & FreeBSD identical?)
While I have not tested it, I would be surprised if the top four positions were not held by the four BSDs. The exception to this might be OpenBSD since it does all sorts of secuirty sanity checking.
The 8088 had a 16-bit memory addressing unit but only an 8-bit bus. The 8086 was exactly like the 8088 except it ran on a 16-bit bus. But, there were really 20 bits of address space on both of them, they were just divided into a psychadelic 4 + 16 with some overlap.
Now, the 80286 was a 24-bit processor. Yes, you read that right, it could address up to 16M of RAM.
The 80386 and up were fully 32-bit. Except for the P6, which was 36 (it could address up to 64G of RAM).
Slashdot Mirror
Hmm I'd pay many adulations to then email privately :)
In that case, I have no trouble correcting your sig ;) It is "nickel" not "quarter." I have the Dilbert on my wall here. :)
(This is not flamebait, I am serious.)
Are you Cliff Stoll?
Cool, but where on the website are the ancient Unix versions?
That's funny my computer has been turned off multiple times without the "proper" shutdown sequence and it has almost always worked perfectly.
"almost", hmm, "almost", thank you for proving my point. With every other Unix version (and Windows NT, since I am at it), I have never seen a drive consistancy check require manual intervention.
I theory eventually linux will surpass BSD in this area. Bigger user base and more competent developers with the source code and developers who will listen will always equal a better product.
This assumes that Linux's developers are more competent. But let's compare TCP/IP stacks of say, FreeBSD and Linux. Well, FreeBSD blows Linux out of the water. Let's compare virtual memory. FreeBSD virtual memory is simply incredible which why big sites run FreeBSD. NetBSD's new UVM is quite interesting and I wish I had time to look into it further. Linux's VM contains nothing insightful or even intelligent. Let's look at the file systems. Traditional Unix file systems included in the BSDs and SVR4s are rock solid. Are you using EXT2FS? I hope someone doesn't pull the plug on you, it probably won't come back.
How many times have most protocols been re-coded?
Great example! TCP/IP from Berkeley was released under the BSD license and almost nobody rewrote. Everyone took the BSD TCP/IP code and incorprated it into their products. Well, everyone except Linux and the HURD. You see, Stallman's GPL wouldn't let them use BSD code. And this is why Linux's TCP/IP stack is still one of the weaker ones in the industry. Further proof that the GPL is only a partial solution.
I have recently run across something similar. I want to convert a a telnet-based bbs (called M-Net) to a multilingual site. The problem is there we are limited to merely what VT100 will let us output. In the end, we decided to translate the documents and use basic locale and i18n features already in the OS to help. It is not quite the same but I hope it helps.
This is a really weak analogy, but it will do for now. Imagine you have a number x. Now, let's "encrypt" x using a simple reversable function. So let's take y = 2x + 3. If we have y, we know that x = (y + 3) / 2. Okay, now let's "hash" x instead and make y = x * x. Now, given y, we know that x = sqrt(y) or x = -sqrt(y). Therefore, the pricise value of x is not known.
Yeah, I said it was not a great example and it has some other flaws (for instance, it doesn't matter which x you choose since they both work), but it should get the point across.
The lex clone was done by Lawrence Livermore Labratories, a group that works primarily with Berkeley.
On the other hand, it is easily argued that most laws are unethical (for instance, laws about drug use and prostitution).
By preventing closed-source modifications, all you do is limit the number of choices available on the markey.
If the original author had produced the program with a license resembling the X or BSD license, this would not be a problem now.
Darwin does have an x86 version. There are also persistant rumours that MacOS will compile on the x86, but Apple is not likely to release this any time soon.
Not even eleven years, dipshit. Star Trek debuted on September 9th, 1966. Star Wars first hit theaters May 25th, 1977.
Even if Minix were (in the past or right now) released under the four clause BSD license, the UCB announcement still does not affect Minix. UCB has no right to the Minix code and nothing UCB does will ever affect Minix.
Virtual memory was added by Kees J. Bot a long time ago.
It is not the 21st century yet. We still have eight months to go :)
It is really wonderful to see a major project released under the BSD license instead of the GPL or a home-rolled license. Publicitly like that will only help the BSD crowd and having more code under the BSD license is just grand. And of course, it is nice to see someone realizing that the BSD license is absolutely perfect for the majority of projects. The GPL only causes problems with minor projects.
Also, I think a reason (though I didn't see it listed) to use a BSD license is the fact a lot of the utilities in Minix have really old BSD copyrights in them. They probably were derived from some ancient BSD tapes and cannot be put under the GPL. (Yes, I am aware of UCB's pulling of the advertising clause but you would have to get every person who contributed to that code in Minix to agree to pulling the advertising clause from the forked Minix version. Even if one person said no, it can never be GPL'd.)
Actually, you cannot release BSD code under the GPL. The GPL specifically prohibits this.
Ah, but look at what I presented above. There is no need to spoof the originating IP when you are hitting it from thousands of nodes across the net (and you don't own any of them)! No one can shut down thousands of machines at the same time.
Robert Morris Jr. did it.
68k, PPC, 88k, Coldfire, StrongARM, i960, MIPS, SPARC, any of the above, but never an x86 for real time processing.
It's FreeBSD that had a performace advantage over Linux on x86. I doubt NetBSD ever did, despite (I assume) sharing the same stack, because of the lack of emphasis on performance in that version of BSD. (A BSD expert might correct me here - is the Network performace of NetBSD & FreeBSD identical?)
While I have not tested it, I would be surprised if the top four positions were not held by the four BSDs. The exception to this might be OpenBSD since it does all sorts of secuirty sanity checking.
That would be cool if it could generate pre-built kernels or custom installation floppies that way via the web :)
The 8088 had a 16-bit memory addressing unit but only an 8-bit bus. The 8086 was exactly like the 8088 except it ran on a 16-bit bus. But, there were really 20 bits of address space on both of them, they were just divided into a psychadelic 4 + 16 with some overlap.
Now, the 80286 was a 24-bit processor. Yes, you read that right, it could address up to 16M of RAM.
The 80386 and up were fully 32-bit. Except for the P6, which was 36 (it could address up to 64G of RAM).