Protocol latency is a big deal. If you have a large per-transaction overhead, then the overall throughput of a given medium will be very sensitive to the number of transactions it creates on the media, as opposed to the total number of bytes it needs to move.
That's part of the reason the HTTP sprouted request pipelining, since the round-trip-time between the endpoints of the connection figured largely in the startup latency of each connection.
It sounds like the typical PC implementation of USB relies heavily on the CPU to handle all but the lowest levels of the protocol. (I'm relying on hearsay here.) If this is indeed the case, then it'll be hard for USB to reach the max sustained speeds for storage devices, unless there's a mechanism for requesting large blocks of data (or large numbers of small blocks) in a single transaction.
For us old-school types, it's similar to the reason XMODEM didn't get much faster with faster modems over a certain speed. XMODEM didn't pipeline anything. It'd send a block, and then wait for an ACK. Since the latency of fancier modems was higher than the simple FSK 300 baud modems, the handshake turnaround time of the ACK swamped the gains made while sending the blocks. (Also, the tiny block size didn't help.) Thus, pipelined protocols like ZMODEM and large-block non-pipelined protocols (XMODEM-1K) came about to address this.
Indeed. The percentages seem designed to be vaguely comforting of one's suspicions of how things should turn out (Linux is slightly faster than Mac is slightly faster than Windows, but Windows is the heavy hitter so we'll talk most about it), with a safe "twist" (Win2K is the fastest of the real OSes) to give it a spritz of faux "interesting result" and a nod to "faded glory" (Win98 is fastest of all) to appease the die-hards that miss the DOS-extended games they grew up with. Oh, and of course, the "Don't worry, it'll all be better soon" bit (Windows 7 fixes everything wrong with all of these other OSes and gives you (or your daughter) a pony).
Agreed. And when looking at their numbers, I didn't see a single one that was bigger than a single-digit percentage. A change in methodology could produce much bigger changes. A change in SSD to one that has a different write to read bandwidth ratio could produce bigger changes. So regardless of what they were measuring, the measurements are probably in the noise margin anyway.
Ok, there's one exception to my "single digit percentage" comment, where they talked about raw access rates: "Winslow said benchmark testing on XP and Vista indicated that the less-efficient XP machines show a 10% improvement in random input/output operations per second using an SSD instead of a hard drive, while Vista showed a 25% improvement under the same conditions." That seemed to be an exception to the rule in the article, where they stated what the benchmark was, and provided a quantitative head to head result. The rest was vague apples vs. oranges hand waving.
This gives a hint as to their methodology: In that metric, they're measuring how much an OS improves when moving from spinning rust to an SSD. Well, if an OS already does really well with a normal hard drive (say, because it caches things effectively, schedules I/O well, and so on), then switching to an SSD will produce a smaller speedup. If you're already doing well, then there's less room for improvement. So, these numbers should be viewed with suspicion. The fact that Win98 fared best probably has more to say about its lackluster I/O scheduling and caching than it does about its suitability to SSDs.
If Linux improved more than Windows did going to an SSD, that isn't necessary a glowing endorsement for Linux. It could mean that we're better able to take advantage of SSDs, or it could mean that we're not utilizing hard drives effectively enough.
In other words, there isn't much in the way of actionable data in this article. There's just a sound and fury of numbers, signifying nothing.
Seriously, though, I don't think the language matters so much as long as there are basic tools available to get started. Heck, even Excel could be a starting point to get a handle on building up equations and conditionals.
The main thing is to have some "getting started" type of documentation, maybe a couple of examples, and offer some encouragement to "see what you can make it do." At least, that's how I started. My folks didn't know a thing about computers. I had a manual that had examples and reference material, and I figured it out from there. The single greatest encouragement was "Don't worry, you can't break it just by typing at the keyboard." (Not quite so true today with viruses and malware and all, but still true of basic programming.)
Once you break the mindset of "the computer is an appliance", and start thinking in terms of "the computer is something I can shape and mold to do whatever I like", the rest flows from there. That's probably the most important part.
There was a bunch of "Don't Copy That Floppy" type of propaganda around our schools back when I was still in public school. Teachers were being inoculated against allowing software piracy in their midst, since kids loved to swap floppies and pirate games and so on back in the day. Unsurprisingly, Microsoft and the BSA funded a lot of that.
These kinds of programs drum simple rules into people's minds in order to be effective. Simple rules and simple policies for simple minds. It's the same kind of thinking that goes into zero tolerance policies. There's no room for context or flexibility.
Unfortunately, this sort of "This is how it is; this is how it must be" type of thinking is rampant throughout our educational system. Not everyone in education is like this, but too many people are.
As I mentioned elsewhere, the company has a slow moving approval process. They stay on a given release for a very long period of time to minimize issues with the wide array of software that we use for design. They don't care so much about web browsers since that's not a core part of what we do.
I believe they shoot for a 4-5 year operating window for an OS version they approve. I've had the OS updated 3 times on my Linux box at work, the most recent being a month ago to bring it to the RHEL WS 4 image that's on there today. It is "up to date" by our standards.
We still haven't moved to Vista even for our Windows machines. All our shiny new Windows boxes come with the corporate load of XP on them. I heard we're scheduled to move to Vista (or another OS) in ~2010.
Part of this is so that the same versions of a wide range of applications work on everybody's machine. This prevents widespread interoperability issues (and therefore license churn with a sort of "rolling upgrade"). Thus, we all run the same version of Office, for example, even though it's 5 years old. On the UNIX side, it's more a matter of using a small number of versions of various fiddly (and expensive) design tools.
I don't care about the phishing filter. I would like to move to Firefox 3. I don't really have control over what IT snapshots to for our design flows. They move very conservatively between OS and infrastructure releases to minimize breakage.
I'm not the administrator (nor would I want to be). Corporate IT goes through a long process of approving OS builds and package sets for the workstations, and they have, in their infinite wisdom, chosen to not include RH's Firefox RPM.
I suppose I could try finding that RPM and installing it in an alternate location.
That wasn't really my point though. My point is that I haven't bothered to upgrade because Firefox 2 works for me, and it's frustrating to upgrade to Firefox 3. Having been spoiled by easy upgrades in the past, I've decided it's not worth my time to jump through hoops to install an update if the installation doesn't "just work."
I imagine it's not just one library. The GTK / GNOME libraries have a number of interdependencies such that I probably would need to make a parallel installation of the full set to make it work. I ran into similar problems with GIMP, which is why I haven't tried to rebuild that in years.
Well, I don't have any control over the Linux that runs on my corporate workstation. Firefox 3 isn't installed, and we're encouraged to run Firefox 2. I can't just go install RPMs on this machine.
I can, however, download the Firefox build from the website and run it myself. Except, of course, it doesn't run because of this library dependency. I suppose I could download the source and try to build Firefox, but honestly, I've got work to do and Firefox 2 already works.
I still use Firefox 2 at work because the Firefox 3 downloads won't run on Red Hat Enterprise Linux Workstation 4. Seems to want libpangocairo, as I recall. Also, a couple plugins I like haven't been updated for Firefox 3 (FLST and Open Link In... come to mind).
I wonder how many of the 25% are in similar situations to mine?
Not exactly, on a couple counts. Word has it (and I don't know if it's true or computer folklore) that Woz assembled Integer BASIC by hand. That is, it's written in assembly code, but the wasn't assembled by a computer.
What we have available to us are the Apple I and Apple II Integer BASIC program images. (Cassette dump for the Apple I, ROM dump for the Apple II.) These are the machine code images for the two programs. They can be disassembled to show us the instructions, but that doesn't tell us anything about the intent of those instructions. Any additional comments, labels, etc. are lost in the assembly process. One would have to reverse engineer the code to determine its intent and function.
Here's an example of assembly source code with all its comments intact. In contrast, here's an example of assembly code that's been reverse engineered (only partially, though) from a disassembly. As you can see, there's lots of question marks and half-explanations. Variables and functions don't have names--there are only raw location addresses. Much harder to work with and understand.
If he were to post source code, I wouldn't be at all surprised if it were scans of old notebooks. I also wouldn't be surprised if the source is lost to the sands of time. I'd hope that later versions (such as the Apple II version) did benefit from machine assembly, and so the source might be found in electronic form somewhere, or maybe a printout.
*shrug* When I'm debugging my own code, the readability matters most to me. When I check in the debugged code, I'll have removed my temporary debugging statements. That's the whole point of temporary debug statements that are easy to remove.
If some debug code is more permanent, then yes, I indent it with everything else for precisely the reason you mention. Go take a look in that same file I posted above for instances of calls to "dprintf".
The temporary debug statements (the ones that were in column 0) in that file are a fluke. I had hacked in a feature (saving voice samples) and accidentally checked in some debug statements that should have been deleted or turned into actual status messages. (That's why I don't have more examples to show, since they don't persist. I have plenty more examples of "permanent debug" statments indented with the code.) The fact these temporary statements are in column 0 makes them stick out similarly to "// XXX: FIXME" or "// XXX: DEBUG", but it's clearer that they're meant to be deleted on sight.
The new sense, "assumed responsibility for a published text", is not the sense being used here, though. The traditional sense, "wrote", is what's being used.
Have you ever considered publishing the Integer BASIC source code? I remember reading the system ROM source code in my old Apple ][ manuals, but I don't recall seeing Integer BASIC.
I count myself among those who don't like Python's syntactically significant whitespace. In my particular case, I use a particular programming idiom that I use when debugging code. I put temporary debug statements in column 0 of my code, purposefully, so that they stick out like a sore thumb and are easily found and removed later. They're "out of band" over there.
You can see some examples in this code. I had left in some "jzp_printf" calls in some code I added for saving voice samples to disk. You can see those near the top.
That idiom works in multiple languages, but it doesn't work in Python. Of course, it shouldn't be hard to write a translator that translates { } style blocks into Python translation as a preprocessing step.
Note: It is still possible to experience a hibernation problem after you install this fix if the memory becomes highly fragmented. The speed at which this problem manifests is dependent on the software that you run and your particular usage model.
Slashdot Mirror
Protocol latency is a big deal. If you have a large per-transaction overhead, then the overall throughput of a given medium will be very sensitive to the number of transactions it creates on the media, as opposed to the total number of bytes it needs to move.
That's part of the reason the HTTP sprouted request pipelining, since the round-trip-time between the endpoints of the connection figured largely in the startup latency of each connection.
It sounds like the typical PC implementation of USB relies heavily on the CPU to handle all but the lowest levels of the protocol. (I'm relying on hearsay here.) If this is indeed the case, then it'll be hard for USB to reach the max sustained speeds for storage devices, unless there's a mechanism for requesting large blocks of data (or large numbers of small blocks) in a single transaction.
For us old-school types, it's similar to the reason XMODEM didn't get much faster with faster modems over a certain speed. XMODEM didn't pipeline anything. It'd send a block, and then wait for an ACK. Since the latency of fancier modems was higher than the simple FSK 300 baud modems, the handshake turnaround time of the ACK swamped the gains made while sending the blocks. (Also, the tiny block size didn't help.) Thus, pipelined protocols like ZMODEM and large-block non-pipelined protocols (XMODEM-1K) came about to address this.
I was being deliberately obtuse, which seems to have been the point of the followups on this thread. :-)
A not-so-small country near Greenland?
I suppose that's more or less true.
So is the whole greater than the sum of its parts?
Indeed. The percentages seem designed to be vaguely comforting of one's suspicions of how things should turn out (Linux is slightly faster than Mac is slightly faster than Windows, but Windows is the heavy hitter so we'll talk most about it), with a safe "twist" (Win2K is the fastest of the real OSes) to give it a spritz of faux "interesting result" and a nod to "faded glory" (Win98 is fastest of all) to appease the die-hards that miss the DOS-extended games they grew up with. Oh, and of course, the "Don't worry, it'll all be better soon" bit (Windows 7 fixes everything wrong with all of these other OSes and gives you (or your daughter) a pony).
Agreed. And when looking at their numbers, I didn't see a single one that was bigger than a single-digit percentage. A change in methodology could produce much bigger changes. A change in SSD to one that has a different write to read bandwidth ratio could produce bigger changes. So regardless of what they were measuring, the measurements are probably in the noise margin anyway.
Ok, there's one exception to my "single digit percentage" comment, where they talked about raw access rates: "Winslow said benchmark testing on XP and Vista indicated that the less-efficient XP machines show a 10% improvement in random input/output operations per second using an SSD instead of a hard drive, while Vista showed a 25% improvement under the same conditions." That seemed to be an exception to the rule in the article, where they stated what the benchmark was, and provided a quantitative head to head result. The rest was vague apples vs. oranges hand waving.
This gives a hint as to their methodology: In that metric, they're measuring how much an OS improves when moving from spinning rust to an SSD. Well, if an OS already does really well with a normal hard drive (say, because it caches things effectively, schedules I/O well, and so on), then switching to an SSD will produce a smaller speedup. If you're already doing well, then there's less room for improvement. So, these numbers should be viewed with suspicion. The fact that Win98 fared best probably has more to say about its lackluster I/O scheduling and caching than it does about its suitability to SSDs.
If Linux improved more than Windows did going to an SSD, that isn't necessary a glowing endorsement for Linux. It could mean that we're better able to take advantage of SSDs, or it could mean that we're not utilizing hard drives effectively enough.
In other words, there isn't much in the way of actionable data in this article. There's just a sound and fury of numbers, signifying nothing.
INTERCAL, naturally.
CORRECT SOURCE AND RESUBNIT
Seriously, though, I don't think the language matters so much as long as there are basic tools available to get started. Heck, even Excel could be a starting point to get a handle on building up equations and conditionals.
The main thing is to have some "getting started" type of documentation, maybe a couple of examples, and offer some encouragement to "see what you can make it do." At least, that's how I started. My folks didn't know a thing about computers. I had a manual that had examples and reference material, and I figured it out from there. The single greatest encouragement was "Don't worry, you can't break it just by typing at the keyboard." (Not quite so true today with viruses and malware and all, but still true of basic programming.)
Once you break the mindset of "the computer is an appliance", and start thinking in terms of "the computer is something I can shape and mold to do whatever I like", the rest flows from there. That's probably the most important part.
There was a bunch of "Don't Copy That Floppy" type of propaganda around our schools back when I was still in public school. Teachers were being inoculated against allowing software piracy in their midst, since kids loved to swap floppies and pirate games and so on back in the day. Unsurprisingly, Microsoft and the BSA funded a lot of that.
These kinds of programs drum simple rules into people's minds in order to be effective. Simple rules and simple policies for simple minds. It's the same kind of thinking that goes into zero tolerance policies. There's no room for context or flexibility.
Unfortunately, this sort of "This is how it is; this is how it must be" type of thinking is rampant throughout our educational system. Not everyone in education is like this, but too many people are.
Wow! The 40th anniversary was a year ago? Holy time travel, Batman! When'd I get in 2009?
As I mentioned elsewhere, the company has a slow moving approval process. They stay on a given release for a very long period of time to minimize issues with the wide array of software that we use for design. They don't care so much about web browsers since that's not a core part of what we do.
I believe they shoot for a 4-5 year operating window for an OS version they approve. I've had the OS updated 3 times on my Linux box at work, the most recent being a month ago to bring it to the RHEL WS 4 image that's on there today. It is "up to date" by our standards.
We still haven't moved to Vista even for our Windows machines. All our shiny new Windows boxes come with the corporate load of XP on them. I heard we're scheduled to move to Vista (or another OS) in ~2010.
Part of this is so that the same versions of a wide range of applications work on everybody's machine. This prevents widespread interoperability issues (and therefore license churn with a sort of "rolling upgrade"). Thus, we all run the same version of Office, for example, even though it's 5 years old. On the UNIX side, it's more a matter of using a small number of versions of various fiddly (and expensive) design tools.
I don't care about the phishing filter. I would like to move to Firefox 3. I don't really have control over what IT snapshots to for our design flows. They move very conservatively between OS and infrastructure releases to minimize breakage.
I'm not the administrator (nor would I want to be). Corporate IT goes through a long process of approving OS builds and package sets for the workstations, and they have, in their infinite wisdom, chosen to not include RH's Firefox RPM.
I suppose I could try finding that RPM and installing it in an alternate location.
That wasn't really my point though. My point is that I haven't bothered to upgrade because Firefox 2 works for me, and it's frustrating to upgrade to Firefox 3. Having been spoiled by easy upgrades in the past, I've decided it's not worth my time to jump through hoops to install an update if the installation doesn't "just work."
I imagine it's not just one library. The GTK / GNOME libraries have a number of interdependencies such that I probably would need to make a parallel installation of the full set to make it work. I ran into similar problems with GIMP, which is why I haven't tried to rebuild that in years.
Well, I don't have any control over the Linux that runs on my corporate workstation. Firefox 3 isn't installed, and we're encouraged to run Firefox 2. I can't just go install RPMs on this machine.
I can, however, download the Firefox build from the website and run it myself. Except, of course, it doesn't run because of this library dependency. I suppose I could download the source and try to build Firefox, but honestly, I've got work to do and Firefox 2 already works.
How about that periodically appearing "Upgrade now to Firefox 3" dialog that keeps coming up in Firefox 2?
I still use Firefox 2 at work because the Firefox 3 downloads won't run on Red Hat Enterprise Linux Workstation 4. Seems to want libpangocairo, as I recall. Also, a couple plugins I like haven't been updated for Firefox 3 (FLST and Open Link In... come to mind).
I wonder how many of the 25% are in similar situations to mine?
Not exactly, on a couple counts. Word has it (and I don't know if it's true or computer folklore) that Woz assembled Integer BASIC by hand. That is, it's written in assembly code, but the wasn't assembled by a computer.
What we have available to us are the Apple I and Apple II Integer BASIC program images. (Cassette dump for the Apple I, ROM dump for the Apple II.) These are the machine code images for the two programs. They can be disassembled to show us the instructions, but that doesn't tell us anything about the intent of those instructions. Any additional comments, labels, etc. are lost in the assembly process. One would have to reverse engineer the code to determine its intent and function.
Here's an example of assembly source code with all its comments intact. In contrast, here's an example of assembly code that's been reverse engineered (only partially, though) from a disassembly. As you can see, there's lots of question marks and half-explanations. Variables and functions don't have names--there are only raw location addresses. Much harder to work with and understand.
If he were to post source code, I wouldn't be at all surprised if it were scans of old notebooks. I also wouldn't be surprised if the source is lost to the sands of time. I'd hope that later versions (such as the Apple II version) did benefit from machine assembly, and so the source might be found in electronic form somewhere, or maybe a printout.
*shrug* When I'm debugging my own code, the readability matters most to me. When I check in the debugged code, I'll have removed my temporary debugging statements. That's the whole point of temporary debug statements that are easy to remove.
If some debug code is more permanent, then yes, I indent it with everything else for precisely the reason you mention. Go take a look in that same file I posted above for instances of calls to "dprintf".
The temporary debug statements (the ones that were in column 0) in that file are a fluke. I had hacked in a feature (saving voice samples) and accidentally checked in some debug statements that should have been deleted or turned into actual status messages. (That's why I don't have more examples to show, since they don't persist. I have plenty more examples of "permanent debug" statments indented with the code.) The fact these temporary statements are in column 0 makes them stick out similarly to "// XXX: FIXME" or "// XXX: DEBUG", but it's clearer that they're meant to be deleted on sight.
The new sense, "assumed responsibility for a published text", is not the sense being used here, though. The traditional sense, "wrote", is what's being used.
Have you ever considered publishing the Integer BASIC source code? I remember reading the system ROM source code in my old Apple ][ manuals, but I don't recall seeing Integer BASIC.
I count myself among those who don't like Python's syntactically significant whitespace. In my particular case, I use a particular programming idiom that I use when debugging code. I put temporary debug statements in column 0 of my code, purposefully, so that they stick out like a sore thumb and are easily found and removed later. They're "out of band" over there.
You can see some examples in this code. I had left in some "jzp_printf" calls in some code I added for saving voice samples to disk. You can see those near the top.
That idiom works in multiple languages, but it doesn't work in Python. Of course, it shouldn't be hard to write a translator that translates { } style blocks into Python translation as a preprocessing step.
Manually? You've never used "unexpand"?
I know you're joking, but coding in assembler is good for learning the machine. Heck, I wrote my game entirely in assembler.
Murrrh?
Perhaps you missed this text:
Sounds like there is a RAM fragmentation problem.