Just as an FYI and future reference, "disc" is reserved for optical media while "disk" is for magnetic (hard or soft media). Bollocks. The two spellings have been used interchangeably for years. Whilst it might be true to say that the trademark "Compact disc" requires the "C" spelling, extrapolating from this to your general rule is purely wishful thinking.
It is true that "disk" is more common in the USA, whilst "disc" is (or was) more common in English English, but all these things are becoming very blurred.
In its way, rather similar to what happened with the 3" floppy disc drive. For a while the two battled it out, then it became clear that 3.5" had won out, but then Alan Sugar made use of the fact that the price of 3" drives had dropped to practically nothing and put them in the Amstrad PCW256. Unfortunately, production of the media had pretty much stopped so for a while the drives were quite a lot cheaper than a box of 10 discs (which was more surprising then than it would be now).
The Amstrad box was so popular that production of 3" discs had to be restarted and 3" drives got a whole new lease of life. Still died in the end though.
Wouldn't it be cool if one could reset the device simply by flipping it over (hourglass style), rather than having to use some mechanism to reset the weight to the top of the device? Even better would be to arrange the flipping mechanism so that the unit rotated around the current position of the heavy weight. You'd thus avoid most of the energy input requirement and make it even more efficient!
Sad, but I do remember when I finally registered here (after months of lurking, I'd say), I felt like my UID was _really_ late compared to a lot of the 4-digits that were posting.
Wonder where they all went. If you get here really early in the morning and keep very, very quiet then you may just spot one.
The script suggested above seems to miss the point - once you set the "allow_restart" parameter it means the drive can be (and is) restarted whenever needed. You don't need to run it every 10 minutes to stop the drive going to sleep. I use the following in/etc/rc.local. The only relevant drive I have is the FreeAgent one - add the device test from the script above if you have a mixture.
for file in/sys/class/scsi_disk/*/allow_restart; do
echo 1 >$file done
The script needs to run just once - at system boot - and it does all that is necessary.
The only down side is that if the drive has gone to sleep it takes 2 or 3 seconds to wake up again the next time you access it. I've never actually tested to see whether it comes back in USB1 or USB2 mode, but given that I use it to store multi-gigabyte files I think I'd have noticed if it was running at USB1 speeds.
Why give email addresses to students at all now? So that staff can reliably communicate with students?
If you set up an in-house e-mail system (even if it's hosted on Google) then staff can make use of predictable e-mail addresses to communicate with students. If I want to communicate with John Doe in year 10 then I know immediately that his e-mail address is 06jdoe@... (06 because he would have started in 2006). Trying to keep a list of students' external e-mail addresses up to date would be a nightmare, and staff would still have to go and consult it every time they wanted to communicate. I have e-mail address lists set up for each of my classes - I wouldn't want to have to check them every time I used them.
You can (and I would argue, should) of course provide the means for the student then to forward his or her e-mail to a preferred server. This if John Doe prefers to use Hotmail he can arrange that everything sent to 06jdoe@... is forwarded appropriately.
You don't incidentally need to take away the addresses after the student leaves. My college (which I left in 1980) still has an e-mail address for me and stuff sent to it will be forwarded to my current address. Again, it uses a predictable naming system so someone who I was at college with and wanted to contact me could work it out without needing any more information.
uhhh, no, a good friend of mine last week had his PSU crap out, and not only it took down the motherboard, it also completely fried both of his HDs and since he was not a believer of offsite backups he's now SOL and has lost 5+ years of photos and other irreplaceable things. You mean it burnt the building down too?
Or was he not a believer in any kind of backup, offsite or otherwise?
Apparently, it was sent via normal post, without recorded delivery. Not quite - it was sent by an internal courier service, provided by TNT. It seems however that the service did not include step-by-step tracing of the package's progress and TNT don't know what they've done with it.
Had it been sent by normal post, it would make absolutely no difference whether it had been sent by Recorded Delivery or not. Recorded Delivery just gets you a signature at the point of delivery, so that if there's a dispute at a later date you can prove (up to a point) that the item arrived. It's intended for items of no intrinsic value which are easily be replaced, but for which it is important to know that they got there - e.g. contract documents, solicitors' letters etc. If the Post Office loses a recorded delivery item then they will have no idea where they lost it - it isn't traced as it passes through the system - and the compensation you can get is only the same as if you'd used first class post.
For an item of value sent through the post you would historically have used Registered Post, but that has been discontinued quite a few years ago. The only thing available now is Special Delivery, which combines speed (next day delivery) with tracking. I still wouldn't trust it with an item like this though - motorbike courier would seem more appropriate.
and everything that came before was going away; all the stuff, a year ago they were saying was the future. I wonder if it's even possible to count how many times Microsoft have iterated through that cycle. I stopped developing on Microsoft platforms about 9 years ago and this is one of the main reasons.
1: it is a pain to voltage convert. Voltage conversion is pretty vital to our modern use of electricity, you don't want 11KV in your home but you don't want to be transmitting 240/415 three phase or worse 120/240 split phase any significant distance. The idea of three phase DC is a bit difficult to get your head around.
Bill Gates funded the construction of the display model on the condition that afterwards, they build him one too. Which I presume they did. I don't know about Bill Gates, but when I was last there (about a year ago) the second one was at an advanced stage of construction. I got talking to a man who was oiling the big steam engine and said I'd noticed they were building a second one. His response was, "Actually, I'm building a second one". His explanation was that when they'd built the first one, enough parts had been machined for two and now they were putting together the second one to go to an American museum.
400-600 people on Linux use bbc.co.uk It's clearly either a made up figure or a case of very creative use of statistics. He would have been better off with a figure like 50,000 - it's surprisingly small but it's not so easy to prove that it's just plain wrong.
It would be interesting to do a survey of Linux users to see how many regularly use bbc.co.uk. I suspect the figure would be well up in the hundreds of thousands. 400-600 is just beyond belief.
I used to fly around small airports in Europe quite a lot (places like Salzburg) and I habitually used a very odd-shaped bag. This seemed to work very well, and I more than once saw it travelling to or from the plane perched on top of the baggage trolley and it usually seemed to come out first on the carousel.
My theory to explain its early arrival was that its odd shape caused handlers to put it to one side each time they were stacking something and then pop it on top of the trolley at the end. Worked for me anyway.
No. That was not the problem. Yes, it was the problem.
The problem was that DOS programs were 16-bit real mode programs. This means that they used 16-bit pointers to refer to memory locations. This is what limits a DOS program to 1 megabyte of memory, not any deficiency in MS-DOS (which it had many of, admittedly). You have clearly failed to understand what the problem is. It's *not* that programs running on an 8086 can't access more than 1M of RAM, which is what you're talking about above.
The problem is that even when the hardware limitations were removed in later revisions, the deficiencies of the operating system meant that existing programs couldn't make use of the new facilities.
1) Methods to drive the screen purely by system calls, without having to be aware of the hardware at all. We are talking about unaccelerated graphics card here. The fastest way to use them was to write directly to memory. Going through a system call would not only have been slower, meaning no one would had used it, Bollocks. Any program worth considering implemented its screen access routines as a library, and it was perfectly possible to produce library code which would access the screen 20 to 50 times faster than the pitiful facilities provided by the OS. The point is this library code should have been in the OS - it would have been just as fast and the 640K limit (*not* as you suggest in your attempt to obfuscate, a 1M limit) would have been avoided.
And, frankly, I doubt anyone at either IBM nor Microsoft realized that the IBM PC would still be in use, extended beyond nearly all recognition, 26 years later. Ah yes - another obfuscation technique - "It's perfectly all right for me to push out crap code because I don't think it will be in use for very long."
I get really, really tired of people trying to make excuses for what was simple plain incompetence on the part of the original programmers. They weren't trying to do anything new and they just couldn't be bothered to study any contemporary solutions to discover how to do the job properly. The amount of time which has been wasted because of their incompetence boggles the mind.
It is actually a limit, not of the software, in any way, shape, or form I don't know who is reponsible for the quote, but this chunk is pure drivel.
It is true to say that the *value* of the limit was dictated by the hardware, but the fact that it was a hard limit was purely the fault of the software. The problem was that the operating system's facilities for addressing the hardware - in particular the screen - were so piss-poor that programmer's had to address the hardware directly in order to achieve reasonable results. There weren't even system calls to allow the software to discover dynamically where the hardware was - the locations had to be hard coded. As a result it then became impossible to move on to a new generation of hardware (with a different limit) because the old software then wouldn't run any more.
A well written operating system would have provided:
1) Methods to drive the screen purely by system calls, without having to be aware of the hardware at all. 2) Hooks to extend the facilities for screen referencing. 3) System calls to discover the location of the hardware if it was necessary to completely circumvent the OS.
It's not as if all this wasn't known at the time. Other earlier offerings provided all this and more, but MS-DOS really didn't deserve the title of "Operating System" at all. It was a filing system and process loader with a few extra bits cobbled onto it to avoid being prosecuted under trades description laws.
In summary - the *value* of the 640K limit was dictated by hardware, the fact that it was a limit at all was purely down to the crappy software.
As an example, 3 days after 9/11 a major ISP lost their connection between France and Germany, as it turned out that they were routing that traffic through a New York telco hotel, which went down when the generators ran out of diesel fuel. I was told that there was no institutional memory in the ISP that this was being done, and it made no sense from a fiber topology standpoint, but there it was. This things often happen purely as a result of expediency.
I recall many years ago when I was working in Melbourne we needed some terminals on the 3rd floor of the building (it was a telephone exchange) connected to a computer on the 2nd floor. Alas, there was no spare electric string between the two, but a simple solution to the problem was found - just put a stat mux in each room and route the connections via Tasmania! It worked - don't knock it.
Slashdot Mirror
I think you mean "effective", not "efficient". Using the QM2 to cool your CPU would be incredibly inefficient.
It is true that "disk" is more common in the USA, whilst "disc" is (or was) more common in English English, but all these things are becoming very blurred.
In its way, rather similar to what happened with the 3" floppy disc drive. For a while the two battled it out, then it became clear that 3.5" had won out, but then Alan Sugar made use of the fact that the price of 3" drives had dropped to practically nothing and put them in the Amstrad PCW256. Unfortunately, production of the media had pretty much stopped so for a while the drives were quite a lot cheaper than a box of 10 discs (which was more surprising then than it would be now).
The Amstrad box was so popular that production of 3" discs had to be restarted and 3" drives got a whole new lease of life. Still died in the end though.
Surely all you need to do is measure the force required to move mountains and then divide by the number of atoms in a mountain?
...clearly the remaining component which he needs to make it complete is a flux capacitor (and perhaps a deLorean).
Odd geography. ITYM
"Fog in the channel - continent isolated".
Anything lower than 6413.
Wonder where they all went. If you get here really early in the morning and keep very, very quiet then you may just spot one.
HTH
John
Or maybe your servers run Debian Etch (which would give you precisely Squirrelmail 1.4.9a) and so only gets security fixes and not functional updates.
The script suggested above seems to miss the point - once you set the "allow_restart" parameter it means the drive can be (and is) restarted whenever needed. You don't need to run it every 10 minutes to stop the drive going to sleep. I use the following in /etc/rc.local. The only relevant drive I have is the FreeAgent one - add the device test from the script above if you have a mixture.
/sys/class/scsi_disk/*/allow_restart; do
for file in
echo 1 >$file
done
The script needs to run just once - at system boot - and it does all that is necessary.
The only down side is that if the drive has gone to sleep it takes 2 or 3 seconds to wake up again the next time you access it. I've never actually tested to see whether it comes back in USB1 or USB2 mode, but given that I use it to store multi-gigabyte files I think I'd have noticed if it was running at USB1 speeds.
John
If you set up an in-house e-mail system (even if it's hosted on Google) then staff can make use of predictable e-mail addresses to communicate with students. If I want to communicate with John Doe in year 10 then I know immediately that his e-mail address is 06jdoe@... (06 because he would have started in 2006). Trying to keep a list of students' external e-mail addresses up to date would be a nightmare, and staff would still have to go and consult it every time they wanted to communicate. I have e-mail address lists set up for each of my classes - I wouldn't want to have to check them every time I used them.
You can (and I would argue, should) of course provide the means for the student then to forward his or her e-mail to a preferred server. This if John Doe prefers to use Hotmail he can arrange that everything sent to 06jdoe@... is forwarded appropriately.
You don't incidentally need to take away the addresses after the student leaves. My college (which I left in 1980) still has an e-mail address for me and stuff sent to it will be forwarded to my current address. Again, it uses a predictable naming system so someone who I was at college with and wanted to contact me could work it out without needing any more information.
Or was he not a believer in any kind of backup, offsite or otherwise?
Had it been sent by normal post, it would make absolutely no difference whether it had been sent by Recorded Delivery or not. Recorded Delivery just gets you a signature at the point of delivery, so that if there's a dispute at a later date you can prove (up to a point) that the item arrived. It's intended for items of no intrinsic value which are easily be replaced, but for which it is important to know that they got there - e.g. contract documents, solicitors' letters etc. If the Post Office loses a recorded delivery item then they will have no idea where they lost it - it isn't traced as it passes through the system - and the compensation you can get is only the same as if you'd used first class post.
For an item of value sent through the post you would historically have used Registered Post, but that has been discontinued quite a few years ago. The only thing available now is Special Delivery, which combines speed (next day delivery) with tracking. I still wouldn't trust it with an item like this though - motorbike courier would seem more appropriate.
1: it is a pain to voltage convert. Voltage conversion is pretty vital to our modern use of electricity, you don't want 11KV in your home but you don't want to be transmitting 240/415 three phase or worse 120/240 split phase any significant distance. The idea of three phase DC is a bit difficult to get your head around.
It would be interesting to do a survey of Linux users to see how many regularly use bbc.co.uk. I suspect the figure would be well up in the hundreds of thousands. 400-600 is just beyond belief.
...does it run Linux? Surely what he's proved is that it does?I used to fly around small airports in Europe quite a lot (places like Salzburg) and I habitually used a very odd-shaped bag. This seemed to work very well, and I more than once saw it travelling to or from the plane perched on top of the baggage trolley and it usually seemed to come out first on the carousel.
My theory to explain its early arrival was that its odd shape caused handlers to put it to one side each time they were stacking something and then pop it on top of the trolley at the end. Worked for me anyway.
No, no, no - the cut off is at 4000.
The problem is that even when the hardware limitations were removed in later revisions, the deficiencies of the operating system meant that existing programs couldn't make use of the new facilities. 1) Methods to drive the screen purely by system calls, without having to be aware of the hardware at all. We are talking about unaccelerated graphics card here. The fastest way to use them was to write directly to memory. Going through a system call would not only have been slower, meaning no one would had used it, Bollocks. Any program worth considering implemented its screen access routines as a library, and it was perfectly possible to produce library code which would access the screen 20 to 50 times faster than the pitiful facilities provided by the OS. The point is this library code should have been in the OS - it would have been just as fast and the 640K limit (*not* as you suggest in your attempt to obfuscate, a 1M limit) would have been avoided. And, frankly, I doubt anyone at either IBM nor Microsoft realized that the IBM PC would still be in use, extended beyond nearly all recognition, 26 years later. Ah yes - another obfuscation technique - "It's perfectly all right for me to push out crap code because I don't think it will be in use for very long."
I get really, really tired of people trying to make excuses for what was simple plain incompetence on the part of the original programmers. They weren't trying to do anything new and they just couldn't be bothered to study any contemporary solutions to discover how to do the job properly. The amount of time which has been wasted because of their incompetence boggles the mind.
It is true to say that the *value* of the limit was dictated by the hardware, but the fact that it was a hard limit was purely the fault of the software. The problem was that the operating system's facilities for addressing the hardware - in particular the screen - were so piss-poor that programmer's had to address the hardware directly in order to achieve reasonable results. There weren't even system calls to allow the software to discover dynamically where the hardware was - the locations had to be hard coded. As a result it then became impossible to move on to a new generation of hardware (with a different limit) because the old software then wouldn't run any more.
A well written operating system would have provided:
1) Methods to drive the screen purely by system calls, without having to be aware of the hardware at all.
2) Hooks to extend the facilities for screen referencing.
3) System calls to discover the location of the hardware if it was necessary to completely circumvent the OS.
It's not as if all this wasn't known at the time. Other earlier offerings provided all this and more, but MS-DOS really didn't deserve the title of "Operating System" at all. It was a filing system and process loader with a few extra bits cobbled onto it to avoid being prosecuted under trades description laws.
In summary - the *value* of the 640K limit was dictated by hardware, the fact that it was a limit at all was purely down to the crappy software.
I recall many years ago when I was working in Melbourne we needed some terminals on the 3rd floor of the building (it was a telephone exchange) connected to a computer on the 2nd floor. Alas, there was no spare electric string between the two, but a simple solution to the problem was found - just put a stat mux in each room and route the connections via Tasmania! It worked - don't knock it.