You just don't get it. Think. Fuzzing can find errors, if they're simple. But people are exponentially better at finding (and exploiting) complex combinatorial errors of the type I described. Fuzzing is never going to find, even in 2^32 passes, those kinds of errors.
Remember the very obvious maxim of Dykstra: testing can only tell you there ARE errors, it can't tell you there AREN'T errors.
Randomly poking at data only find you the very dumbest errors. It takes some real thinking and mulling to realize, hey, if a xml field crosses this buffer boundary, and the last 4-byte Unicode code was cached, it's going to get bashed by the next 3-byte escape code. Or 255 bytes of code-page Yen symbol (255) followed by a 254 will lead to sign-extension and access to an address in the kernel trampoline DLL. Those kind of combinatorial errors are not going to be discovered by random poking at the data.
So they're going to (and have) given everybody a false sense of security, when the basic method can do nothing of the sort. it can only fin errors of the most trivial sort. It can't find errors that thousands of unemployed Russian hackers can dream up of testing for, and it can only FIND errors, not tell you there aren't an unlimited number of remaining errors.
If you read closely, Microsoft admits that the reason Vista came out late is that they *tried* rewriting large parts of Windows in.NET, and cringed at the results.
So Microsoft has about $4 billion and 2.5 years of lessons in why.NET is not the shining city on a hill of programming.
So it's no surprise that they're quietly burying it, as they have so many names and hot technologies du-jour. Take a quick mental trip through the half-dozen Microsoft database connection technologies of yore.
>So what's different if the computer needs to hibernate?
Good point, if the OS has a hibernate capability, it must have all the right hooks to tell every driver and every piece of hardware to stop generating interrupts and somehow save their state.
But that's no help to this virus detector-- malware that hides as a device driver can pretend to hibernate too.
The basic flaw is the assumption that the detector can know what belongs in RAM, and that everything else is malware. Neither assumption is even remotely accurate to begin with, and both are circumventable in the next malware release.
I tried reading TFA a few times. First time, utter confusion. Second, third times, no better. I can't make any sense out of these points:
>1) There are absolutely only three things malware can do when you scan for it. One: be active in RAM, maybe trying to interfere with the detection algorithm. Two: not be active in RAM, but store itself in secondary storage. It cannot interfere with the detection algorithm then, quite obviously. And option number three: erase itself.
Absolutely, not. There are many other things malware could be doing. Inactive in RAM, compressed and inactive in RAM, encoded as plausible-looking entries in the File Name Table or the Virtual Memory map.
>2) Any program -- good or bad -- that wants to be active in RAM has no choice but to take up some space in RAM. At least one byte, right?
No, it could be sleeping, existing only as an entry in the swapped-out process table. Or in unused space below a thread stack.
>Assume now that we have a detection algorithm that runs in kernel mode, and that swaps out everything in RAM. Everything except itself.
Whoah there fella. Everything? Are you going to turn off all timers and interrupt enables so their service routines don't get called? Hard to do without mucking up all the device drivers. Are you going to swap out the kernel too, as malware is quite capable of infesting kernel space. And what about device drivers? They're constantly mucking with their internal tables and I/O buffers. And if you turn off all device drivers, you lose, as there's nothing stopping malware from masquerading as a device driver. Many do.
>>But if we know how big RAM is, we know how much space should be free.
Whoa there again, big guy. There are plenty of machines with RAM at places not generally known to the OS, such as video RAM, graphics polygon RAM, network card RAM buffers, and kernel stacks.
>> Assume we write pseudo-random bits over all this supposedly free space. Again, a malware agent could refuse to be overwritten.
You don't need a checksum test to do this-- each page of virtual memory has R/W control bits. And you're foiled here again, as there are plenty of system areas that are write-protected, such as pre code areas and the VM tables themselves.
>>Then, let us compute a keyed hash of the entire memory contents -- both our detection program and all the random bits. Here is what could happen: If there is no malware in RAM, the results will be the expected result. An external verifier checks this, and tells us that the scanned device is clean.
Nooo, that just tells you that either you overwrote the malware, so you'll never find it, or the malware during your two sweeps did not change any RAM contents. Quite possible as most malware just sits around most of the time.
>> Or there could be malware in RAM, and the checksum will be wrong.
Well, no, unless you disabled all interrupts and stopped all kernel tasks, there will still be system timers and interrupts and device drivers changing their state in RAM.
>> The external verifier would notice and conclude that the device must be infected.
Or some part of the system or some device driver is still running. Huge chance of false positives.
This essay seems to have been written by someone with only a glancing familiarity with hardware and system software.
uh, no. The one-way efficiency of this tiny hydropower system is about 80%, but the only number that matters is the round-trip, which is 64%, theoretical and 63% as actually measured on-site.
It's mighty silly to spend that kind of money up front to get such miserly returns.
Much more so bad to even think of pumped air storage, which has to be less efficient.
Getting the straight poop from "Wired" is like expecting it from Fox News.
Air--pumped storage is dead from the get-go. You compress air and a goodly percentage of the energy ends up as heat, which has to be removed from the compressor cylinder heads and is lost. Then the hot compressed air loses heat to the walls of the cavern. Then when you let the air expand, it cools off and you lose pressure from that effect too.
A rough guess-- you lose 50% of the wind energy coming and going.
You can do better by pumping water uphill, where you don't have the compressive losses.
Go to Google books and look up a book "Internal combustion", circa 1910.
In there you'll find the basic equations of IC engine efficiency.
Clue: They haven't changed a bit since then.
It all depends on the Carnot cycle, which is basically immutable. A proper gas-air mixture burns at a certain well-defined temperature, and then with expansion, generates a certain amount of work. There's nothing you can do in the way of injection that makes any difference.
You can come up with minor tweaks, like stratified charge, external mixing, heating, cooling, intercooling, ( all well explored in the 1910 book ).
NO, they did not find a glitch in the algorithm, they happened to find an implementation which was amenable to their attack method.
All the chip makers have to do is take any one of several measures:
(1) Regulate the CPU voltage on-chip. (2) or just detect that it's below spec and force a reset. (3) or do the calculation two times, or in two different ways, or both, and reset if the results don't match. (4) or add a few gates of carry-lookahead to the multiplier so it's not so speed-sensitive. (5) or detect the tampering and send out the tamperer's IP address encrypted in the message.
First of all, you don't write "ones" and "zeroes" on a surface. The only thing you can write are flux transitions, changes from north to south magnetic polarity and back. In order to be able to write and then read them back you also have to add clocking transitions and DC-restoration transitions. It takes a fair amount of sophisticated analog and digital electronics to do the writing and reading. The digital parts are semi-programmable, but the analog parts are not-- you're stuck with writing and reading the type of flux transitions that the analog electronics is optimized for.
I can't imagine why you think you *have to* be able to write a particular pattern. Unless you're going to use the platter to test out some kind of magnetic imaging camera.
Slashdot, please think of the children that will be disappointed by this article.
Us grownups can see through the PR-speak, but kids can't.
We can see that this loose talk of high efficiencies is just that-- only part of the story.
It's swell that these gizmos have a 97% absorption efficiency, but that's only the front end.
The actual cell, which converts the light to electricity, is no different-- about 16% efficient, due to the many mismatches in energy levels and the unavoidable phonon products.
Plus the business about needing less silicon is not spreadsheet-worthy. The actual bulk silicon is not a large part of the cost. Even if they got the silicon usage down to 0%, the cost would not come down very much if at all.
Also the economic predictions are unrealistic. Nothing that's better has ever sold for less than 5% under the price of the competition. No company can afford to leave money on the table.
Very simple. Get a coding wiz to write a background app that hooks into the OS and whenever it sees a error dialog box pop up, it either captures the text or does a screen dump to a file.
(1) At least 100 times stronger, in incident watts.
(2) Has a million times more punch per photon.
(3) Couples to your body at least 10 times more.... so as a rough estimate, the cell phone signals affect your body about a billion times less than standing in the sunlight.
(Actually, much less than that, as photons below infrared cannot, no way, dislodge any electrons, so there cannot be any chemical changes in your body as a result. )
No, what you'd get for a billion Euros is that many lines of code. No idea if the code would be any good. But usually when managers are fixated on the LOC, you get lots of LOC, not necessarily GOOD or FAST code. Just lots of it. Been there, seen it, upchucked, many times.
We have perfectly good physical random-number generators -- your basic Boltzmann (Johnson) thermal noise is just the ticket. Hook any resistor above absolute zero to a A/D converter and you have a few microvlots of random noise-- after an A/D converter, a nice stream of random numbers. Well, not quite, A/D converters are less than perfect, so you'll just get semi-random numbers with a slight bias towards the A/D converter's nonlinearities. But pretty darn good.
If that's too weal a signal, you can avalanche a diode and get VOLTS of noise.... or you could metastable some flip/flops.... but if you do you'll get HORRIBLE random numbers, as the metastable state amplifies and unbalances in the flip/flops. i.e. if one flip flop has one microvolt of unbalance towards the "1" state, the unbalance increases exponentially in just a few nanoseconds, making it most likely it will go into the "1" state solidly a very high percent of the time..
Stick to Johnson (resistor) noise, avalanche diodes, or even beta emitters. Forgit the metastable flippers.
On the one hand it's potentially a good idea to use "unneeded" RAM to pre-fetch possibly useful in the future disk data.
But a whole lot of apps were written without that "feature", so a lot of them already pre-fetch data. Now you have twice the amount of RAM tied up, for no benefit.
And nobody can predict the future, so the pre-fetching is speculative at best, and has no way to compensate for other tasks the user may double-click into competion with ones being pre-fetched.
Worse yet, a lot of apps look at the amount of free RAM when they decide whether to prune their working set or make other cache/purge decisions.
If all of a sudden the OS reports less free RAM, all those apps are going to make the wrong decision.
> (I still have a pair) AFAIK, they cost much, much more than $100 each. They were core modules that had 48k by 1 bit and had been assembled by hand.
Yes, I meant to say, more than $1000 in 1972 dollars.
And yes, there were many ways to get passwords-- the simplest being to run the password changing program from one terminal and dump out memory from another. At first when you requested memory the OS did not zero it out! Easy password pickins.
For a long while the password file was passed form system to system through ECS. A simple "DUMPECS" command would often dump out lots of passwords.
I don't see how you come up with that analogy at all.
The amount of energy stored in an inductor or capacitor is a scalar quantity.
In a capacitor, the energy is proportional to the capacitance times the applied voltage. In an inductor, it's the inductance times the current. Nothing vectorial about it.
AC versus DC has nothing to do with it. A capacitor and inductor respond to AC in equivalent but opposite ways.
I never knew of a -press- command variant that allowed you to press keys on someone else's terminal, although that would be a logical way for the screen-sharing term-whatever that was to work.
The -ext- command was particularly hilarious if the terminal had that rube-goldberg microfiche slide projector. It was literally steam-powered through a pneumatic line. Well, air, not steam, but awfully close. You could step the 8x8 michrofiche and make the terminal wobble.
In 1972, I was a college student with more time on my hands than sense. Here's a few things I did to a $4 million CDC 6600 time-sharing system:
(1) Hells bells: This machine had ten PP's (Peripheral Processors) that offloaded I/O tasks. The PP's had for-the-time screaming I/O speeds-- all of 2MBPS. User disk space consisted of two washing-machine sized disk drives, 88MB total. A little metal arithmetic suggested that you could fill the disks in no time. so a 2-line FORTRAN program: 1 WRITE(1) 76437643764376437643B; GOTO 1... it filled up the disks in under a minute, bringing the system to a standstill. (7643B was the display code for ^G, bell) ( The system programmers quickly implemented disk space quotas after that ).
(2) There was a fixed-size open file table in the kernel memory area, usually configured for 400 files. There were no open file quotas. So a 2-line SNOBOL program could very quickly open up an number of empty temp files, bringing the system to a halt. ( FORTRAN programs could only work with files declared in the program header line ). ( The system programmers again very quickly implemented a limit on number of files per user ).
(3) On early core RAM modules, the modules were interleaved 8-wise, so each module only got accessed every 8-th word fetch.. But if you knew this, and wrote a program that jumped forward 8 words several dozen times, then jumped back to the start, one module would get accessed at the maximum possible rate and within a minute the module would melt down. I did not try this ( the 4K modules must have cost $100 or so ), but I heard of someone that did.
(4) The card punch was designed for punching text data, which had at most two out of every 12 rows punched per column. If one punched a few hundred cards of -0 (all ones on a one's complement machine), and did a DISPOSE(OUTPUT=PUNCHB), the card punch would overheat and melt down all the punch electromagnets. My boss at the time admitted to doing this.
(5) The line printers were amazing machines, extremely speedy, BUT if you write out a few hundred lines of "-------------------", the first column was carriage control, and the default cc tape would map "-" to mean "no line feed". A few dozen lines of that and the paper would cut through, bringing that printer to a halt. ] (6) Same thing as (5), but with a "1" in column 1 would eject pages at the maximum rate, which was much faster than the paper stacker could collect the pages. There were page limits in place, but the poor operators would still be confronted by a printer covered with 100 pages of ejected paper.
(7) At first you could make system calls with bit 20 set, which meant asyncronously. You could issue these requests much faster than the OS or PP's could finish them, so you could easily tie up all the free PP's and that would instantly bring the system to a very slow crawl. Very soon thereafter, a limit of 2 PP's per user task was implemented.
There were more, but the statute of limitations may not be up for them.
At $5,600 for the printer, just the interest alone is $300 a year. For that you can buy 100,000 sheets of copy paper a year. If you expect the printer to last 5 years, that's another $1,100 that could go towards buying almost 400,000 sheets of paper.
And I doubt if the plastic sheets can be reused more than 10 times in a typical office situation. They're going to get wrinkled, bent, curled, and soiled after just ten cycles. Most printers balk at feeding paper that is even slightly curled. Let's assume 10 uses is a practical limit. So this 33 cent sheet of plastic is now costing you 3 cents a page, ten times more than the equivalent piece of paper.
Ah, no, a flywheel is analogous to a capacitor, where applied force (current) is stored as RPM (voltage). A mechanical inductor would be more like a spring, storing energy as pressure and releasing it over a distance.
Slashdot Mirror
You just don't get it. Think. Fuzzing can find errors, if they're simple. But people are exponentially better at finding (and exploiting) complex combinatorial errors of the type I described. Fuzzing is never going to find, even in 2^32 passes, those kinds of errors.
It's a losing game, for losers.
Remember the very obvious maxim of Dykstra: testing can only tell you there ARE errors, it can't tell you there AREN'T errors.
Randomly poking at data only find you the very dumbest errors. It takes some real thinking and mulling to realize, hey, if a xml field crosses this buffer boundary, and the last 4-byte Unicode code was cached, it's going to get bashed by the next 3-byte escape code. Or 255 bytes of code-page Yen symbol (255) followed by a 254 will lead to sign-extension and access to an address in the kernel trampoline DLL. Those kind of combinatorial errors are not going to be discovered by random poking at the data.
So they're going to (and have) given everybody a false sense of security, when the basic method can do nothing of the sort. it can only fin errors of the most trivial sort. It can't find errors that thousands of unemployed Russian hackers can dream up of testing for, and it can only FIND errors, not tell you there aren't an unlimited number of remaining errors.
Let's try to think clearly here.
Microsoft seems to be saying that you have more privacy when you type a URL into their address bar.
But that just means that your DNS server is now the "evil" thing that knows every place you've visited.
And of course your ISP can trap every URL you access.
So if you use Microsoft's model, you've just hidden from Google, but still exposed to your perhaps Ma and Pa ISP and DNS providers.
another web page.
If you read closely, Microsoft admits that the reason Vista came out late is that they *tried* rewriting large parts of Windows in .NET, and cringed at the results.
So Microsoft has about $4 billion and 2.5 years of lessons in why .NET is not the shining city on a hill of programming.
So it's no surprise that they're quietly burying it, as they have so many names and hot technologies du-jour. Take a quick mental trip through the half-dozen Microsoft database connection technologies of yore.
Ahem, what about the cruise missiles the USA built in the 1950's?
Over a billion big fat 1950's dollars spent on those.
Just off the top of my head, the Hound Dog, the Snark, The Navaho, the BOMARC, the Boojum, the Triton, and the Mace.
>So what's different if the computer needs to hibernate?
Good point, if the OS has a hibernate capability, it must have all the right hooks to tell every driver and every piece of hardware to stop generating interrupts and somehow save their state.
But that's no help to this virus detector-- malware that hides as a device driver can pretend to hibernate too.
The basic flaw is the assumption that the detector can know what belongs in RAM, and that everything else is malware. Neither assumption is even remotely accurate to begin with, and both are circumventable in the next malware release.
I tried reading TFA a few times. First time, utter confusion. Second, third times, no better. I can't make any sense out of these points:
>1) There are absolutely only three things malware can do when you scan for it. One: be active in RAM, maybe trying to interfere with the detection algorithm. Two: not be active in RAM, but store itself in secondary storage. It cannot interfere with the detection algorithm then, quite obviously. And option number three: erase itself.
Absolutely, not. There are many other things malware could be doing. Inactive in RAM, compressed and inactive in RAM, encoded as plausible-looking entries in the File Name Table or the Virtual Memory map.
>2) Any program -- good or bad -- that wants to be active in RAM has no choice but to take up some space in RAM. At least one byte, right?
No, it could be sleeping, existing only as an entry in the swapped-out process table. Or in unused space below a thread stack.
>Assume now that we have a detection algorithm that runs in kernel mode, and that swaps out everything in RAM. Everything except itself.
Whoah there fella. Everything? Are you going to turn off all timers and interrupt enables so their service routines don't get called?
Hard to do without mucking up all the device drivers. Are you going to swap out the kernel too, as malware is quite capable of infesting kernel space. And what about device drivers? They're constantly mucking with their internal tables and I/O buffers.
And if you turn off all device drivers, you lose, as there's nothing stopping malware from masquerading as a device driver. Many do.
>>But if we know how big RAM is, we know how much space should be free.
Whoa there again, big guy. There are plenty of machines with RAM at places not generally known to the OS, such as video RAM, graphics polygon RAM, network card RAM buffers, and kernel stacks.
>> Assume we write pseudo-random bits over all this supposedly free space. Again, a malware agent could refuse to be overwritten.
You don't need a checksum test to do this-- each page of virtual memory has R/W control bits.
And you're foiled here again, as there are plenty of system areas that are write-protected, such as pre code areas and the VM tables themselves.
>>Then, let us compute a keyed hash of the entire memory contents -- both our detection program and all the random bits. Here is what could happen: If there is no malware in RAM, the results will be the expected result. An external verifier checks this, and tells us that the scanned device is clean.
Nooo, that just tells you that either you overwrote the malware, so you'll never find it, or the malware during your two sweeps did not change any RAM contents. Quite possible as most malware just sits around most of the time.
>> Or there could be malware in RAM, and the checksum will be wrong.
Well, no, unless you disabled all interrupts and stopped all kernel tasks, there will still be system timers and interrupts and device drivers changing their state in RAM.
>> The external verifier would notice and conclude that the device must be infected.
Or some part of the system or some device driver is still running. Huge chance of false positives.
This essay seems to have been written by someone with only a glancing familiarity with hardware and system software.
uh, no. The one-way efficiency of this tiny hydropower system is about 80%, but the only number that matters is the round-trip, which is 64%, theoretical and 63% as actually measured on-site.
It's mighty silly to spend that kind of money up front to get such miserly returns.
Much more so bad to even think of pumped air storage, which has to be less efficient.
Getting the straight poop from "Wired" is like expecting it from Fox News.
Air--pumped storage is dead from the get-go. You compress air and a goodly percentage of the energy ends up as heat, which has to be removed from the compressor cylinder heads and is lost. Then the hot compressed air loses heat to the walls of the cavern. Then when you let the air expand, it cools off and you lose pressure from that effect too.
A rough guess-- you lose 50% of the wind energy coming and going.
You can do better by pumping water uphill, where you don't have the compressive losses.
Go to Google books and look up a book "Internal combustion", circa 1910.
In there you'll find the basic equations of IC engine efficiency.
Clue: They haven't changed a bit since then.
It all depends on the Carnot cycle, which is basically immutable. A proper gas-air mixture burns at a certain well-defined temperature, and then with expansion, generates a certain amount of work. There's nothing you can do in the way of injection that makes any difference.
You can come up with minor tweaks, like stratified charge, external mixing, heating, cooling, intercooling, ( all well explored in the 1910 book ).
NO, they did not find a glitch in the algorithm, they happened to find an implementation which was amenable to their attack method.
All the chip makers have to do is take any one of several measures:
(1) Regulate the CPU voltage on-chip.
(2) or just detect that it's below spec and force a reset.
(3) or do the calculation two times, or in two different ways, or both, and reset if the results don't match.
(4) or add a few gates of carry-lookahead to the multiplier so it's not so speed-sensitive.
(5) or detect the tampering and send out the tamperer's IP address encrypted in the message.
First of all, you don't write "ones" and "zeroes" on a surface. The only thing you can write are flux transitions, changes from north to south magnetic polarity and back. In order to be able to write and then read them back you also have to add clocking transitions and DC-restoration transitions. It takes a fair amount of sophisticated analog and digital electronics to do the writing and reading. The digital parts are semi-programmable, but the analog parts are not-- you're stuck with writing and reading the type of flux transitions that the analog electronics is optimized for.
I can't imagine why you think you *have to* be able to write a particular pattern. Unless you're going to use the platter to test out some kind of magnetic imaging camera.
Slashdot, please think of the children that will be disappointed by this article.
Us grownups can see through the PR-speak, but kids can't.
We can see that this loose talk of high efficiencies is just that-- only part of the story.
It's swell that these gizmos have a 97% absorption efficiency, but that's only the front end.
The actual cell, which converts the light to electricity, is no different-- about 16% efficient, due
to the many mismatches in energy levels and the unavoidable phonon products.
Plus the business about needing less silicon is not spreadsheet-worthy. The actual bulk silicon is not a large part of the cost.
Even if they got the silicon usage down to 0%, the cost would not come down very much if at all.
Also the economic predictions are unrealistic. Nothing that's better has ever sold for less than 5% under the price of the competition. No company can afford to leave money on the table.
Very simple. Get a coding wiz to write a background app that hooks into the OS and whenever it sees a error dialog box pop up, it either captures the text or does a screen dump to a file.
Did you ever consider that maybe the headaches could have been caused by the noxious fumes from all the police cars?
Police radios are like 100 watts, intermittent.
I lived for 15 years in the shadow of a 50,000-watt radio station tower. On 24/7. No headaches.
The basic physics say you're more than okay.
The sunlight streaming in thru your windows is:
(1) At least 100 times stronger, in incident watts.
(2) Has a million times more punch per photon.
(3) Couples to your body at least 10 times more. ... so as a rough estimate, the cell phone signals affect your body about a billion times less than standing in the sunlight.
(Actually, much less than that, as photons below infrared cannot, no way, dislodge any electrons, so there cannot be any chemical changes
in your body as a result. )
No, what you'd get for a billion Euros is that many lines of code. No idea if the code would be any good. But usually when managers are fixated on the LOC, you get lots of LOC, not necessarily GOOD or FAST code. Just lots of it. Been there, seen it, upchucked, many times.
We have perfectly good physical random-number generators -- your basic Boltzmann (Johnson) thermal noise is just the ticket. Hook any resistor above absolute zero to a A/D converter and you have a few microvlots of random noise-- after an A/D converter, a nice stream of random numbers. Well, not quite, A/D converters are less than perfect, so you'll just get semi-random numbers with a slight bias towards the A/D converter's nonlinearities. But pretty darn good.
If that's too weal a signal, you can avalanche a diode and get VOLTS of noise. ... or you could metastable some flip/flops.... but if you do you'll get HORRIBLE random numbers, as the metastable state amplifies and unbalances in the flip/flops. i.e. if one flip flop has one microvolt of unbalance towards the "1" state, the unbalance increases exponentially in just a few nanoseconds, making it most likely it will go into the "1" state solidly a very high percent of the time..
Stick to Johnson (resistor) noise, avalanche diodes, or even beta emitters. Forgit the metastable flippers.
The issue is not a simple one.
On the one hand it's potentially a good idea to use "unneeded" RAM to pre-fetch possibly useful in the future disk data.
But a whole lot of apps were written without that "feature", so a lot of them already pre-fetch data. Now you have twice the amount of RAM tied up, for no benefit.
And nobody can predict the future, so the pre-fetching is speculative at best, and has no way to compensate for other tasks the user may double-click into competion with ones being pre-fetched.
Worse yet, a lot of apps look at the amount of free RAM when they decide whether to prune their working set or make other cache/purge decisions.
If all of a sudden the OS reports less free RAM, all those apps are going to make the wrong decision.
> (I still have a pair) AFAIK, they cost much, much more than $100 each. They were core modules that had 48k by 1 bit and had been assembled by hand.
Yes, I meant to say, more than $1000 in 1972 dollars.
And yes, there were many ways to get passwords-- the simplest being to run the password changing program from one terminal and dump out memory from another. At first when you requested memory the OS did not zero it out! Easy password pickins.
For a long while the password file was passed form system to system through ECS. A simple "DUMPECS" command would often dump out lots of passwords.
I don't see how you come up with that analogy at all.
The amount of energy stored in an inductor or capacitor is a scalar quantity.
In a capacitor, the energy is proportional to the capacitance times the applied voltage. In an inductor, it's the inductance times the current. Nothing vectorial about it.
AC versus DC has nothing to do with it. A capacitor and inductor respond to AC in equivalent but opposite ways.
I never knew of a -press- command variant that allowed you to press keys on someone else's terminal, although that would be a logical way for the screen-sharing term-whatever that was to work.
The -ext- command was particularly hilarious if the terminal had that rube-goldberg microfiche slide projector. It was literally steam-powered through a pneumatic line. Well, air, not steam, but awfully close. You could step the 8x8 michrofiche and make the terminal wobble.
In 1972, I was a college student with more time on my hands than sense. Here's a few things I did to a $4 million CDC 6600 time-sharing system:
(1) Hells bells: This machine had ten PP's (Peripheral Processors) that offloaded I/O tasks. The PP's had for-the-time screaming I/O speeds-- all of 2MBPS. User disk space consisted of two washing-machine sized disk drives, 88MB total. A little metal arithmetic suggested that you could fill the disks in no time. so a 2-line FORTRAN program: 1 WRITE(1) 76437643764376437643B; GOTO 1 ... it filled up the disks in under a minute, bringing the system to a standstill. (7643B was the display code for ^G, bell) ( The system programmers quickly implemented disk space quotas after that ).
(2) There was a fixed-size open file table in the kernel memory area, usually configured for 400 files. There were no open file quotas. So a 2-line SNOBOL program could very quickly open up an number of empty temp files, bringing the system to a halt. ( FORTRAN programs could only work with files declared in the program header line ). ( The system programmers again very quickly implemented a limit on number of files per user ).
(3) On early core RAM modules, the modules were interleaved 8-wise, so each module only got accessed every 8-th word fetch.. But if you knew this, and wrote a program that jumped forward 8 words several dozen times, then jumped back to the start, one module would get accessed at the maximum possible rate and within a minute the module would melt down. I did not try this ( the 4K modules must have cost $100 or so ), but I heard of someone that did.
(4) The card punch was designed for punching text data, which had at most two out of every 12 rows punched per column. If one punched a few hundred cards of -0 (all ones on a one's complement machine), and did a DISPOSE(OUTPUT=PUNCHB), the card punch would overheat and melt down all the punch electromagnets. My boss at the time admitted to doing this.
(5) The line printers were amazing machines, extremely speedy, BUT if you write out a few hundred lines of "-------------------", the first column was carriage control, and the default cc tape would map "-" to mean "no line feed". A few dozen lines of that and the paper would cut through, bringing that printer to a halt.
]
(6) Same thing as (5), but with a "1" in column 1 would eject pages at the maximum rate, which was much faster than the paper stacker could collect the pages. There were page limits in place, but the poor operators would still be confronted by a printer covered with 100 pages of ejected paper.
(7) At first you could make system calls with bit 20 set, which meant asyncronously. You could issue these requests much faster than the OS or PP's could finish them, so you could easily tie up all the free PP's and that would instantly bring the system to a very slow crawl. Very soon thereafter, a limit of 2 PP's per user task was implemented.
There were more, but the statute of limitations may not be up for them.
The math just does not work out.
At $5,600 for the printer, just the interest alone is $300 a year. For that you can buy 100,000 sheets of copy paper a year. If you expect the printer to last 5 years, that's another $1,100 that could go towards buying almost 400,000 sheets of paper.
And I doubt if the plastic sheets can be reused more than 10 times in a typical office situation. They're going to get wrinkled, bent, curled, and soiled after just ten cycles. Most printers balk at feeding paper that is even slightly curled. Let's assume 10 uses is a practical limit. So this 33 cent sheet of plastic is now costing you 3 cents a page, ten times more than the equivalent piece of paper.
Now a good deal.
Ah, no, a flywheel is analogous to a capacitor, where applied force (current) is stored as RPM (voltage). A mechanical inductor would be more like a spring, storing energy as pressure and releasing it over a distance.