This has got to be one of the dumber things I have read recently...
No matter how 'bad' the first write is, as long as it can be read correctly, the second write starts perfectly and then is affected only be the variables in the second write (burner, media, etc)
The first read does not retain the 'bad' aspects of the first write such as rough pits through to the second write.
I never understood the unix line wraps comments people make until someone posted something sufficiently annoying that I actually went and did the research. (I just looked for it , can't find it, don't ask for it, sorry)
The results were as follows:
Windows line wraps are 'right' at least according to the original standards which were based on the following problems with original teletype(?) machines.
The characters came to the machine at a specific rate based on the ability of the machine to print the character and move the head to the next position (fixed width fonts of course) the main problem was that the head could not return from the end of the line to the beginning (to start the next) in one time slice. Thus the solution was fixed by breaking up the 'go to start of next line' character/signal into 'return the head(carriage) to the start of the line' and 'feed the paper one line further into the machine': CR and LF.
Since the CR needed two time slices to finish the LF provided the needed 'next line' and the necessary time for the CR to complete.
everyone can pick their favorite, but since i don't need to save 7/8/16 bits and so I'll stick with my CR and LF, thank you very much.
*ducks*
General Failure reading drive C.
on
MS DOS: A Eulogy
·
· Score: 1
Who's General Failure, and how did he get access to my hard drive?
Only the 'broke ass' (as one of my friends would call them) Win32 programs use CLI to manipulate one another. There are far better ways, and if one put in even a little effort they are convenient.
I'd love to here a hardcore Win32 programmer on this topic as opposed to MS haters who read the first chapter of some o'reilly book and burned it in disgust.
Hopefully this will continue to happen, but the production run of this IBM thing is not large enough to justify a slashdot piece on this. (no offense intended) If the linux-router-thing (above) takes off, that would be big.
Seems to me like the best way to do this would be to have the next-gen routing protocols be able to propogate 'blocks' in addition to routes.
Yes, I know this would be massively memory intensive on the routing tables, but how cool would it be if you could set a block on an ip on your border/edge/first router and that block would propogate to the border/edge/first router in front of the offending ip.
Again, yes,I know there are all sorts of security problems with this, but shouldn't this be the direction of the majority of effort in this regard?
Oh yeah, they just want to make money, not actually fix things... Sorry.
Slashdot Mirror
This has got to be one of the dumber things I have read recently...
No matter how 'bad' the first write is, as long as it can be read correctly, the second write starts perfectly and then is affected only be the variables in the second write (burner, media, etc)
The first read does not retain the 'bad' aspects of the first write such as rough pits through to the second write.
That would be analog....
I never understood the unix line wraps comments people make until someone posted something sufficiently annoying that I actually went and did the research. (I just looked for it , can't find it, don't ask for it, sorry)
The results were as follows:
Windows line wraps are 'right' at least according to the original standards which were based on the following problems with original teletype(?) machines.
The characters came to the machine at a specific rate based on the ability of the machine to print the character and move the head to the next position (fixed width fonts of course) the main problem was that the head could not return from the end of the line to the beginning (to start the next) in one time slice. Thus the solution was fixed by breaking up the 'go to start of next line' character/signal into 'return the head(carriage) to the start of the line' and 'feed the paper one line further into the machine': CR and LF.
Since the CR needed two time slices to finish the LF provided the needed 'next line' and the necessary time for the CR to complete.
everyone can pick their favorite, but since i don't need to save 7/8/16 bits and so I'll stick with my CR and LF, thank you very much.
*ducks*
Who's General Failure, and how did he get access to my hard drive?
Only the 'broke ass' (as one of my friends would call them) Win32 programs use CLI to manipulate one another. There are far better ways, and if one put in even a little effort they are convenient.
I'd love to here a hardcore Win32 programmer on this topic as opposed to MS haters who read the first chapter of some o'reilly book and burned it in disgust.
Anyone?
This is simply a continuation of an established progression, i.e. open source the traditionally proprietary internal workings of specialized devices.
Check out http://www.networkrobots.com/ for a functionally similar development on the router side of things.
Hopefully this will continue to happen, but the production run of this IBM thing is not large enough to justify a slashdot piece on this. (no offense intended) If the linux-router-thing (above) takes off, that would be big.
Microsoft is shipping not one thing on time, but TWO! and GameCube slips endangering the most successful console enterprise ever.
What's next MSDonald's?
Seems to me like the best way to do this would be to have the next-gen routing protocols be able to propogate 'blocks' in addition to routes.
Yes, I know this would be massively memory intensive on the routing tables, but how cool would it be if you could set a block on an ip on your border/edge/first router and that block would propogate to the border/edge/first router in front of the offending ip.
Again, yes,I know there are all sorts of security problems with this, but shouldn't this be the direction of the majority of effort in this regard?
Oh yeah, they just want to make money, not actually fix things... Sorry.