I sure hope that was a joke. Because otherwise it would be one of the most clueless comments I have seen.
Sure spliting data into a lot of smaller files is going to reduce the fragmentation slightly, but it is not going to improve your performance. Because the price of accessing different files is going to be higher than the price of the fragmentation.
In the next two arguments you managed to make two opposite statements both incorrect. That is actually quite impressive.
First you say large files increase the entropy of the data stored on the disk. Which is wrong as long as you compare to the same data stored in diffeerent files. Of course if the number of files on the disk is constant smaller files will lead to less entropy, but most people actually want to store some data on their disks.
Then you say large files are highly redundant, which is the opposite of having a large entropy as claimed in your previous argument. And in reality the redundancy does not tend to increase with filesize, but might of course depend on the format of the file.
All in all you are saying that people shouldn't store many data on their disks, and the little data they do store should be as compact as possible, while still allowing it to be compressed even further when doing backups. You might as well have said people shouldn't use their disks at all.
Finally claiming older Unix versions were faster is ridiculous, first of all they ran on different hardware. And surely on that hardware they were slower than todays systems. And even if you managed to port an ancient Unix version to modern hardware, I'm sure it wouldn't beat modern systems in todays tasks. Which DVD player would you suggest for K&R Unix?
The seek times alone withinr these files must be huge
Who moded that as Insightful? Sure, if you are using a filesystem designed for floppy disks, it might not work well with 2GB files. In the old days where the metadata could fit in 5KB a linked list of diskblocks could be acceptable. But any modern filesystem uses tree structures which makes a seek faster than it would be to open another file. Such a tree isn't complicated, even the minix filesystem has it.
If you are still using FAT... bad luck for you. AFAIK Microsoft was stupid enough to keep using linked lists in FAT32, which certainly did not improve the seek time.
The 286 does in fact have protection. It was however never used by DOS which might be the main reason few people know about it. In general the 286 protection was not too bad, but it had a few drawbacks.
Once turned on it could only be turned off again by reseting the CPU. This lead to clumsy workarounds in the BIOS to allow reseting the CPU without rebooting.
It was still only a 16 bit design at a point where other companies like Motorola already had 32 bit designs.
The 286 had a segmented protection model, the preffered protection model today is based on paging.
The 286 protected mode was not designed with enough thought for extensibility, leading to very clumsy segment descriptors on 386 and later architectures.
So in fact the major leftover from 286 protected mode is a mess in segment descriptors that we still suffer from today.
But does all the proxies do those lookups on different DNS servers? I doubt it. You could have a large number of proxies using just a single DNS server, although you would probably use two or three for redundancy. But the redundant servers could still query each other first and only outside if the result was missing or the other server was down. And then again you shouldn't need that many TLD lookups almost no matter how stupid you do it.
What makes you believe they haven't already done so? It could come in handy, if they suddenly realize they need such a thing in a hurry. Of course keeping it secret until then would be a major problem.
I could reboot OS/2 by clicking Ctrl-Alt-Del. Is not it the sign that it is just DOS?
I can reboot a PC without any OS by pressing C-A-D. In fact the C-A-D combination was originally implemented by the BIOS. It only worked in DOS because DOS was built on top of the BIOS. Later DOS got an optional keyboard driver of it's own with support for different keymaps but otherwise fully compatible with the BIOS driver. This driver did in fact reimplement the C-A-D combination. And most later OS running on the PC platform has some similar function bound to C-A-D.
If people aren't smart enough to secure their computer, deny them tools that would damage other people's computers.
Get serious. The ping command is definitely not a tool made to damage other people's computers. And though the article is a litle unclear on that issue, it sounds like this attack could in fact not have been done using the ping command.
The ping command is used to send legitimate ICMP ECHO REQUEST packets, which a computer according to the stanards MUST reply to with an ICMP ECHO REPLY packet.
What the attack did was to produce ICMP ECHO REQUEST packets with forged source address, so all the replies would be sent to the root DNS servers. This could not have been done by the use of the ping command.
You just shouldn't remove usefull tools and install firewalls to break the standards just to "improve" your security. Your efforts will be useless either because you are protecting against something that is not a problem, or you fail to defend against the actual problem because the attack could have been done in other ways as well.
In fact flooding is impossible to defend against, but a correctly configured system is going to be responsive again just a few seconds after the flooding has stopped.
the main difference in protected modes is the segment size.
In fact the segment descriptor is one of the more clumsy parts of the 386 design. In the 286 the segment descriptor had a 24 bit base field and a 16 bit size field. The descriptor was 64 bits in size, but most of the remaining 24 bits were reserved and was required for software to fill with zero bits. On the 386 it was wanted to make base and size field each 32 bits. But obviously there wasn't enough space for that. Instead the base was made 32 bits, and the size was made 21 bits consisting of a 20 bit value, and a single bit specifying the unit being either bytes or 4KB pages. So on the 386 segments can be any size up to 1MB, but larger segments has to have a size being a multiple of the page size. The most clumsy part is the layout of the bits, the new bits had to be placed in the reserved bits, and thus each field is scatered in three different locations in the selector.
AFAIR one 486 upcode is being used, otherwise it is 386 optimized.
Isn't that a bit silly? Why optimize for 386 if it cannot run on a 386? And why use one single 486 opcode? That better has to be a good one to justify the requirement for a newer CPU.
It would make more sense to me to stick with 386 opcodes, but otherwise optimize for PIII or something like that.
That makes sense since 286 protected mode and 386 protected mode would require completely different binaries for the kernel and all application software I think.
That is not the case. Of course you'd need a new kernel to take advantage of the 386, but in fact the new protected mode is backward compatible. You can run a 286 protected mode kernel without changes on a 386, and run 286 protected mode programs on that.
But even with a 386 kernel it would be possible to run 286 programs, and you could get a litle benefit from the 386 with only the kernel being changed but all user space programs being 286 code. Finally a kernel can support multitasking between 286 and 386 programs. I believe the later was the case for the first OS/2 versions to take advantage of 386.
The fact that 386 protected mode is backward compatible with 286 protected mode is perhaps litle known, but that is responsible for the 386 protected mode being designed a clumsy way in a few areas. It is however not as bad as you could have feared with the backward compatibility requirement.
OS/2 was originally designed to fully utilize the 286 architecture in particular the newly introduced protected mode. I have newer heard of any other OS supporting 286 protected mode. I know that later OS/2 has been improved to also utilize the 386 protected mode, now I wonder: Does OS/2 still run on a 286, or what is the minimum requirement?
I have often wondered, if it will be possible to find a formula calculating how likely something is given how sure people say they are about it. In the sense that if people say they are x% sure about something the probability of it being true is f(x)%. First of all to find the formula you would have to collect a lot of statements and the claimed percentage, and then find out which ones are true. Of course one problem remains. How sure do you have to be about the formula before you release it.
UDP will "just gimme the data", but you can't do that reliably.
For small pages I believe a UDP version of HTTP could be a good idea. Just send one packet with the request and wait for the response, retransmit if you got no response exactly like you would do with TCP. But as soon as the UDP packets grow larger than the MTU, this will no longer be a good idea. And it also makes the servers vulnurable to DoS attacks by flooding it with requests with spoofed source address.
But we can design protocols utilizing the network even better. The DoS attacks can be avoided by the use of cookies, which however does require an extra exchange of packets in the beginning, but the client can keep the cookie for a long time. The UDP packets larger than MTU problem can be solved by spliting the page into smaller packets before transmiting, and if a redundant coding is used, the server doesn't even have to know which packets were lost, before it can do retransmits. Just continue with the next redundant block and it will be usefull no matter what packet was actually lost.
There are however still problems. The redundant coding requires lots of CPU time. The server will not know at which rate to send packets to keep the packet loss as low as possible, and neither will it know when to stop sending more packets. So all in all I don't think we can come up with anything significantly better than persistent HTTP connections. Some servers do refuse persistent HTTP connections with IE, because the implementation in IE is broken.
Is that site slashdotted too? I cannot get to the page.
And BTW I think that security problem probably only applies to public accessible browsers. As long as you run the browser under your personal userID, I think there is no need to worry.
Slashdot Mirror
2^32 Bytes (aka 2GB).
Make that 2^31.
I sure hope that was a joke. Because otherwise it would be one of the most clueless comments I have seen.
Sure spliting data into a lot of smaller files is going to reduce the fragmentation slightly, but it is not going to improve your performance. Because the price of accessing different files is going to be higher than the price of the fragmentation.
In the next two arguments you managed to make two opposite statements both incorrect. That is actually quite impressive.
First you say large files increase the entropy of the data stored on the disk. Which is wrong as long as you compare to the same data stored in diffeerent files. Of course if the number of files on the disk is constant smaller files will lead to less entropy, but most people actually want to store some data on their disks.
Then you say large files are highly redundant, which is the opposite of having a large entropy as claimed in your previous argument. And in reality the redundancy does not tend to increase with filesize, but might of course depend on the format of the file.
All in all you are saying that people shouldn't store many data on their disks, and the little data they do store should be as compact as possible, while still allowing it to be compressed even further when doing backups. You might as well have said people shouldn't use their disks at all.
Finally claiming older Unix versions were faster is ridiculous, first of all they ran on different hardware. And surely on that hardware they were slower than todays systems. And even if you managed to port an ancient Unix version to modern hardware, I'm sure it wouldn't beat modern systems in todays tasks. Which DVD player would you suggest for K&R Unix?
The seek times alone withinr these files must be huge
Who moded that as Insightful? Sure, if you are using a filesystem designed for floppy disks, it might not work well with 2GB files. In the old days where the metadata could fit in 5KB a linked list of diskblocks could be acceptable. But any modern filesystem uses tree structures which makes a seek faster than it would be to open another file. Such a tree isn't complicated, even the minix filesystem has it.
If you are still using FAT... bad luck for you. AFAIK Microsoft was stupid enough to keep using linked lists in FAT32, which certainly did not improve the seek time.
they skipped from 2X to 4X and ignored 3X.
I see no reason why it even has to be an integer. Who wouldn't have wanted an eX or a ?X speed CD drive?
The 286 does in fact have protection. It was however never used by DOS which might be the main reason few people know about it. In general the 286 protection was not too bad, but it had a few drawbacks.
- Once turned on it could only be turned off again by reseting the CPU. This lead to clumsy workarounds in the BIOS to allow reseting the CPU without rebooting.
- It was still only a 16 bit design at a point where other companies like Motorola already had 32 bit designs.
- The 286 had a segmented protection model, the preffered protection model today is based on paging.
- The 286 protected mode was not designed with enough thought for extensibility, leading to very clumsy segment descriptors on 386 and later architectures.
So in fact the major leftover from 286 protected mode is a mess in segment descriptors that we still suffer from today.Each proxy then does its own lookup on the host.
But does all the proxies do those lookups on different DNS servers? I doubt it. You could have a large number of proxies using just a single DNS server, although you would probably use two or three for redundancy. But the redundant servers could still query each other first and only outside if the result was missing or the other server was down. And then again you shouldn't need that many TLD lookups almost no matter how stupid you do it.
Does talking about it circumvent any copy protection mechanisms on a copywrited work?
No.
Its completely unreadable.
True, but the PS version previously mentioned is in fact readable (except from the tables).
Maybe PDF has too much redundant code.
If it was only PDF the OS would not crash together with PDF. They are probably both buggy.
Did anybody look on the moderations of the parent?
Moderations: 20% Offtopic, 90% Informative
Oh, now people are probably just going to claim something about math being different on slashdot.
they could.
What makes you believe they haven't already done so? It could come in handy, if they suddenly realize they need such a thing in a hurry. Of course keeping it secret until then would be a major problem.
Will Linus accept the BSOD patch for the kernel?
Of course not, Linus never accepts anything for the kernel if it can be done just as good in user mode.
I could reboot OS/2 by clicking Ctrl-Alt-Del. Is not it the sign that it is just DOS?
I can reboot a PC without any OS by pressing C-A-D. In fact the C-A-D combination was originally implemented by the BIOS. It only worked in DOS because DOS was built on top of the BIOS. Later DOS got an optional keyboard driver of it's own with support for different keymaps but otherwise fully compatible with the BIOS driver. This driver did in fact reimplement the C-A-D combination. And most later OS running on the PC platform has some similar function bound to C-A-D.
How's the weather in egypt?
It is all mentioned in the article 20-25C in the winter up to 50C in the summer.
Wonder how it does in storms.
The housings are rain and wind-proof
If people aren't smart enough to secure their computer, deny them tools that would damage other people's computers.
Get serious. The ping command is definitely not a tool made to damage other people's computers. And though the article is a litle unclear on that issue, it sounds like this attack could in fact not have been done using the ping command.
The ping command is used to send legitimate ICMP ECHO REQUEST packets, which a computer according to the stanards MUST reply to with an ICMP ECHO REPLY packet.
What the attack did was to produce ICMP ECHO REQUEST packets with forged source address, so all the replies would be sent to the root DNS servers. This could not have been done by the use of the ping command.
You just shouldn't remove usefull tools and install firewalls to break the standards just to "improve" your security. Your efforts will be useless either because you are protecting against something that is not a problem, or you fail to defend against the actual problem because the attack could have been done in other ways as well.
In fact flooding is impossible to defend against, but a correctly configured system is going to be responsive again just a few seconds after the flooding has stopped.
the main difference in protected modes is the segment size.
In fact the segment descriptor is one of the more clumsy parts of the 386 design. In the 286 the segment descriptor had a 24 bit base field and a 16 bit size field. The descriptor was 64 bits in size, but most of the remaining 24 bits were reserved and was required for software to fill with zero bits. On the 386 it was wanted to make base and size field each 32 bits. But obviously there wasn't enough space for that. Instead the base was made 32 bits, and the size was made 21 bits consisting of a 20 bit value, and a single bit specifying the unit being either bytes or 4KB pages. So on the 386 segments can be any size up to 1MB, but larger segments has to have a size being a multiple of the page size. The most clumsy part is the layout of the bits, the new bits had to be placed in the reserved bits, and thus each field is scatered in three different locations in the selector.
AFAIR one 486 upcode is being used, otherwise it is 386 optimized.
Isn't that a bit silly? Why optimize for 386 if it cannot run on a 386? And why use one single 486 opcode? That better has to be a good one to justify the requirement for a newer CPU.
It would make more sense to me to stick with 386 opcodes, but otherwise optimize for PIII or something like that.
That makes sense since 286 protected mode and 386 protected mode would require completely different binaries for the kernel and all application software I think.
That is not the case. Of course you'd need a new kernel to take advantage of the 386, but in fact the new protected mode is backward compatible. You can run a 286 protected mode kernel without changes on a 386, and run 286 protected mode programs on that.
But even with a 386 kernel it would be possible to run 286 programs, and you could get a litle benefit from the 386 with only the kernel being changed but all user space programs being 286 code. Finally a kernel can support multitasking between 286 and 386 programs. I believe the later was the case for the first OS/2 versions to take advantage of 386.
The fact that 386 protected mode is backward compatible with 286 protected mode is perhaps litle known, but that is responsible for the 386 protected mode being designed a clumsy way in a few areas. It is however not as bad as you could have feared with the backward compatibility requirement.
OS/2 was originally designed to fully utilize the 286 architecture in particular the newly introduced protected mode. I have newer heard of any other OS supporting 286 protected mode. I know that later OS/2 has been improved to also utilize the 386 protected mode, now I wonder: Does OS/2 still run on a 286, or what is the minimum requirement?
Google could tell you "Our results are produced by 5,000 hamsters
They could tell you that, but they don't. Please notice the minor difference between hamsters and Pigeons.
There will be flying cars to take us to and from work.
It was predictions for 2003 not 2030.
and she was "100% sure" or her results.
I have often wondered, if it will be possible to find a formula calculating how likely something is given how sure people say they are about it. In the sense that if people say they are x% sure about something the probability of it being true is f(x)%. First of all to find the formula you would have to collect a lot of statements and the claimed percentage, and then find out which ones are true. Of course one problem remains. How sure do you have to be about the formula before you release it.
If I make an http client that sends "TEG index.html HTTP/0.9" instead of "GET index.html HTTP/0.9" can I bitch when IIS and Apache don't support it?
/" can you then bitch when IIS and sometimes Apache don't support it?
But if you then instead use simple requests just containing "GET
UDP will "just gimme the data", but you can't do that reliably.
For small pages I believe a UDP version of HTTP could be a good idea. Just send one packet with the request and wait for the response, retransmit if you got no response exactly like you would do with TCP. But as soon as the UDP packets grow larger than the MTU, this will no longer be a good idea. And it also makes the servers vulnurable to DoS attacks by flooding it with requests with spoofed source address.
But we can design protocols utilizing the network even better. The DoS attacks can be avoided by the use of cookies, which however does require an extra exchange of packets in the beginning, but the client can keep the cookie for a long time. The UDP packets larger than MTU problem can be solved by spliting the page into smaller packets before transmiting, and if a redundant coding is used, the server doesn't even have to know which packets were lost, before it can do retransmits. Just continue with the next redundant block and it will be usefull no matter what packet was actually lost.
There are however still problems. The redundant coding requires lots of CPU time. The server will not know at which rate to send packets to keep the packet loss as low as possible, and neither will it know when to stop sending more packets. So all in all I don't think we can come up with anything significantly better than persistent HTTP connections. Some servers do refuse persistent HTTP connections with IE, because the implementation in IE is broken.
(LinuxFromScratch) mozilla build howto:
Is that site slashdotted too? I cannot get to the page.
And BTW I think that security problem probably only applies to public accessible browsers. As long as you run the browser under your personal userID, I think there is no need to worry.