I did something like that back in my school days on a dual-CPU Burroughs B6700, but with a twist: Each process forked itself twice, then waited. When it received a signal about a child process being killed, it spawned two more. I had a sleep of a few seconds or so in there so it didn't grow too fast.
The fun part of that was when the system operators saw the processes replicating like crazy and started to kill them, that made it worse.
Another fun trick with that machine was to set up a circularly-linked list and invoke the LLLU (linked list lookup) instruction on it...
(Yeah, stupid things to do. At least I only did them during relatively quiet times.)
turned off in the NASA sense doesn't mean completely turned off.
In this case it probably does. In the mid/late 1970s, when the ALSEPs were turned off, NASA was doing a very thorough job of nuking anything that had anything to do with Apollo to ensure that all funds went to Shuttle. I'm sure I've read that they were turned off in such a way that they couldn't be turned on. I could be wrong, but I suspect there's about as much chance of switching the ALSEPs back on as there is of erecting and launching the Saturn V lawn ornament at KSC.
a meteorite struck the basin about 2 billion years ago.
And they don't seem to think this might have had something to do with it too? The Sudbury Basin around Sudbury, Ontario was formed by meteor impact (about 1.85 billion years ago), and is one of the world's largest sources of nickel and other metals like copper, silver, platinum group and gold. Coincidence? What other metals are found at the South Africa site?
If Kernighan and Ritchie had suggested Hungarian notation, you'd find lots of evangelists for it on Slashdot.
And if Bill Gates wore a dress, he'd be Mother Teresa. GMAFB, Kernighan and Ritchie wouldn't have suggested Hungarian notation, they're not that stupid.
(Besides which, the first C compilers only distinguished identifiers in their first 8 characters (and the loader reduced that to 7). They certainly wouldn't waste the space.)
Which is exactly what's wrong with it, unless you're programming in assembler. Programming in higher level languages (yeah, some would debate that C qualifies here) is all about abstraction.
Besides which, "iAge" doesn't tell you anything useful about how that age is represented -- is that number in years? months? days? hours? centuries? Depending on the underlying application (are we talking about adults, infants, bacterial cultures, archaeological relics?) it could be any of the above. That's the danger of Hungarian notation -- it gives the illusion of conveying information when it doesn't really.
Anyway, for all you know, a month ago somebody decided they needed to redeclare "iAge" to "unsigned short" and was too lazy to rename the variable in 32,178 lines of code. The compiler sure doesn't enforce it.
You're confusing the two shafts. The "door" is at the top of the south shaft. The north shaft has a length of wood at the 45-degree corner, one end of which was presumably broken off by Wayman Dixon's probing in 1872 (the piece he brought back with the couple of artifacts that are now in the British Museum).
A more reasonable (if less "interesting") theory is that after the rough surfaces of two stones were abutted, the gap was sawn/planed with a metal tool to smooth the surfaces between them, and then they were shoved the last 1/4 inch or so together. The fact that saw-grooves from such a process can be found on stones underlying the joints is an additional niggling detail that isn't really "interesting".
IIRC, feature freeze date for 2.5 is October 31. Figure a few more months of shakeouts and bugfixes after that, we might see 2.6 sometime in first quarter of 2003.
There is a list around of the desired features for 2.6 that was put together at the Linux Kernel Summit. A very hasty web search turns up this list, which doesn't seem to mention things already merged like the block-IO stuff.
Flexibility, performance, optimization of whatever characteristics you want to optimize.
There may be no compelling reason for you to change from the default (which, presumably, were chosen as defaults becaused they'd satisfy most people). But for someone looking to optimize for a particular application, it's one more variable they can tweak (different filesystems each having their own strengths and weaknesses.)
For example, someone doing desktop video editing (really big contiguous files, high sustained data rate needed, etc) might want a different filesystem than someone running a highly active database server (lots of small table changes scattered across the filesystem).
That would depend on a few other factors -- your total experience, the exact position I was trying to fill, etc. If all I was looking for was a C or C++ programmer, it wouldn't be as big a deal, of course. I worked for a few years at a company whose product (large, expensive GIS systems) included a couple of proprietary scripting languages, so obviously in that case a knack for learning new languages was a plus.
The first two languages I learned were Algol and APL. I've been paid to write programs in (in roughly chronological order, ignoring repeats): Fortran, Basic-Plus, Cobol (although I don't admit that on my resume;-), APL, Pascal, C, sh, C++, SQL, csh, GML (a proprietary GIS scripting language), Perl and Java. In addition, I've used on the job (written short one-offs, or modified an existing program): PL/I, Tcl/Tk, and a handful of other scripting or job control languages. On my own time (or for class assignments) I've written programs (bigger than "Hello world") in Algol, GPSS, Simula67, PDP-11 assembler, 6502 machine language, Snobol, Python, Lisp and Forth.
The above isn't to brag so much as to give you an idea where I'm coming from. And yes, I'd agree with you that C and C++ programming are (if done right) different skill sets.
Yep, and the speed of light in all those media is a lot less than 186,000 miles/second. (Well, possibly except in air, I don't recall the refractive index of air WRT vacuum off hand.)
That would be a hell of a lot funnier (read, still not very funny) if you used the correct speed: 186,282.4 miles per second. Your number is a mere 99.85% of lightspeed.
On the other hand, when I read a CV if I don't see at least three languages with at least two of them being radically different (ie C, C++ and Java won't cut it for "radically different"(*) -- throw a Lisp or APL or some such in there and you're getting closer), then I'll know the guy either has no imagination/curiosity or has problems learning new things.
(*) Although Fortran IV, Fortan 77 and Fortran 95 might;-)
I suppose things could have changed, but the startup I worked for in the late 80s hired computer people from two places, UW and Queen's -- and the company was founded by UW grads.
I completely agree (see my earlier post). The Lex Luthor character is great too -- he brings complexity to the role that was missing from the Superman movies. (In the original comics, Lex had been a boyhood friend of Superboy (don't recall about Kent), until Lex lost his hair which he blamed Superboy for. (It was a lab accident, in the process of putting out the fire, Superboy causes a chemical spill that affects Luthor. -- The modified backstory in Smallville is superior, IMHO.)
As for the show being geared for teenagers -- maybe so, but some of us old fogeys like it too. Good story lines (although for a while the "human is exposed to kryptonite, gets wierd powers, goes berserk" was being overdone) and good filmmaking go a long way. (And you gotta love all those foreshadowing jokes.)
..a few more years until the current cast of Smallville is old enough to be convincing in the parts. (Which shouldn't be long, they're a little old for the parts now -- but it's still an enjoyable show.)
Although I'm curious about how and when Chloe Sullivan changes her name to Lois Lane.;)
a 35mm frame is 36x24mm (strange, but true) That's roughly 7200x4800 pixels, or 34.56 MPixels
And 35mm is small-format. Photographers going for higher quality go with "medium format" (70mm film, 60x60mm image size - think Hasselblad) or larger, roughly 12000x12000 pixels -- 144 megapixels. Digital still has a ways to go to catch up at the high end.
Since these interrupts are generated by events external to the computer (mouse movement, network events, etc.) the distribution is truly random.
Actually there was some discussion on the kernel mailing list recently about this. On, say, a rackmounted server you don't have mouse and keyboard interrupts, the only source of entropy is the timing of network events -- which in theory can be controlled by an outside entity (some other machine on the network). This leads to a theoretical non-randomness of/dev/random if some attacker is carefully controlling the timing of network packets.
There was a patch offered for this but the side effects (taking much longer to generate an entropy pool) versus a practical assessment of the risk, were deemed not worth it.
Slashdot Mirror
I did something like that back in my school days on a dual-CPU Burroughs B6700, but with a twist: Each process forked itself twice, then waited. When it received a signal about a child process being killed, it spawned two more. I had a sleep of a few seconds or so in there so it didn't grow too fast.
The fun part of that was when the system operators saw the processes replicating like crazy and started to kill them, that made it worse.
Another fun trick with that machine was to set up a circularly-linked list and invoke the LLLU (linked list lookup) instruction on it...
(Yeah, stupid things to do. At least I only did them during relatively quiet times.)
turned off in the NASA sense doesn't mean completely turned off.
In this case it probably does. In the mid/late 1970s, when the ALSEPs were turned off, NASA was doing a very thorough job of nuking anything that had anything to do with Apollo to ensure that all funds went to Shuttle. I'm sure I've read that they were turned off in such a way that they couldn't be turned on. I could be wrong, but I suspect there's about as much chance of switching the ALSEPs back on as there is of erecting and launching the Saturn V lawn ornament at KSC.
They were turned off in the late 70's, but there's some hope that they can be reactivated for this event.
Reactivated how? They gonna send up someone (or a robot) to toggle the on-off switch? The receivers are turned off, too.
a meteorite struck the basin about 2 billion years ago.
And they don't seem to think this might have had something to do with it too? The Sudbury Basin around Sudbury, Ontario was formed by meteor impact (about 1.85 billion years ago), and is one of the world's largest sources of nickel and other metals like copper, silver, platinum group and gold. Coincidence? What other metals are found at the South Africa site?
If Kernighan and Ritchie had suggested Hungarian notation, you'd find lots of evangelists for it on Slashdot.
And if Bill Gates wore a dress, he'd be Mother Teresa. GMAFB, Kernighan and Ritchie wouldn't have suggested Hungarian notation, they're not that stupid.
(Besides which, the first C compilers only distinguished identifiers in their first 8 characters (and the loader reduced that to 7). They certainly wouldn't waste the space.)
Call me a 'troll' a million times, but you *still* lack decent evidence OOP is objectively better
;)
Nonsense. Of course OOP is objectively better. What, you think FP is functionally superior?
The "with" statement goes back to Pascal (maybe even earlier, but that's 25 years right there):
with foo.bar.yuckims do
begin
glock(a, 1);
glock(a, 2);
{ etc.. }
end
Not quite as terse, and original Pascal didn't have procedure/function members of structures, so the above wouldn't quite work.
Would you settle for
#define x(n) foo.bar.yukims.glock(a, n)
x(1);
x(2);
x(8);
x(13);
x(19);
#undef x
Hmm?
(Note, I am not advocating this practise!)
iAge tells you how that age is represented.
Which is exactly what's wrong with it, unless you're programming in assembler. Programming in higher level languages (yeah, some would debate that C qualifies here) is all about abstraction.
Besides which, "iAge" doesn't tell you anything useful about how that age is represented -- is that number in years? months? days? hours? centuries? Depending on the underlying application (are we talking about adults, infants, bacterial cultures, archaeological relics?) it could be any of the above. That's the danger of Hungarian notation -- it gives the illusion of conveying information when it doesn't really.
Anyway, for all you know, a month ago somebody decided they needed to redeclare "iAge" to "unsigned short" and was too lazy to rename the variable in 32,178 lines of code. The compiler sure doesn't enforce it.
You're confusing the two shafts. The "door" is at the top of the south shaft. The north shaft has a length of wood at the 45-degree corner, one end of which was presumably broken off by Wayman Dixon's probing in 1872 (the piece he brought back with the couple of artifacts that are now in the British Museum).
A more reasonable (if less "interesting") theory is that after the rough surfaces of two stones were abutted, the gap was sawn/planed with a metal tool to smooth the surfaces between them, and then they were shoved the last 1/4 inch or so together. The fact that saw-grooves from such a process can be found on stones underlying the joints is an additional niggling detail that isn't really "interesting".
IIRC, feature freeze date for 2.5 is October 31. Figure a few more months of shakeouts and bugfixes after that, we might see 2.6 sometime in first quarter of 2003.
There is a list around of the desired features for 2.6 that was put together at the Linux Kernel Summit. A very hasty web search turns up this list, which doesn't seem to mention things already merged like the block-IO stuff.
Flexibility, performance, optimization of whatever characteristics you want to optimize.
There may be no compelling reason for you to change from the default (which, presumably, were chosen as defaults becaused they'd satisfy most people). But for someone looking to optimize for a particular application, it's one more variable they can tweak (different filesystems each having their own strengths and weaknesses.)
For example, someone doing desktop video editing (really big contiguous files, high sustained data rate needed, etc) might want a different filesystem than someone running a highly active database server (lots of small table changes scattered across the filesystem).
In Tux's name, why?
(Actually, I'm assuming that was a joke. I do like Linux's HFS support, since I run a mixed platform household.)
Would you file my CV in the circular cabinet
;-), APL, Pascal, C, sh, C++, SQL, csh, GML (a proprietary GIS scripting language), Perl and Java. In addition, I've used on the job (written short one-offs, or modified an existing program): PL/I, Tcl/Tk, and a handful of other scripting or job control languages. On my own time (or for class assignments) I've written programs (bigger than "Hello world") in Algol, GPSS, Simula67, PDP-11 assembler, 6502 machine language, Snobol, Python, Lisp and Forth.
That would depend on a few other factors -- your total experience, the exact position I was trying to fill, etc. If all I was looking for was a C or C++ programmer, it wouldn't be as big a deal, of course. I worked for a few years at a company whose product (large, expensive GIS systems) included a couple of proprietary scripting languages, so obviously in that case a knack for learning new languages was a plus.
The first two languages I learned were Algol and APL. I've been paid to write programs in (in roughly chronological order, ignoring repeats): Fortran, Basic-Plus, Cobol (although I don't admit that on my resume
The above isn't to brag so much as to give you an idea where I'm coming from. And yes, I'd agree with you that C and C++ programming are (if done right) different skill sets.
Five nines beats a pair of nines any time ;-)
Yep, and the speed of light in all those media is a lot less than 186,000 miles/second. (Well, possibly except in air, I don't recall the refractive index of air WRT vacuum off hand.)
That would be a hell of a lot funnier (read, still not very funny) if you used the correct speed: 186,282.4 miles per second. Your number is a mere 99.85% of lightspeed.
Sure, Perl is close enough to APL, in readability anyway ;-)
On the other hand, when I read a CV if I don't see at least three languages with at least two of them being radically different (ie C, C++ and Java won't cut it for "radically different"(*) -- throw a Lisp or APL or some such in there and you're getting closer), then I'll know the guy either has no imagination/curiosity or has problems learning new things.
;-)
(*) Although Fortran IV, Fortan 77 and Fortran 95 might
Queen's.
I suppose things could have changed, but the startup I worked for in the late 80s hired computer people from two places, UW and Queen's -- and the company was founded by UW grads.
I completely agree (see my earlier post). The Lex Luthor character is great too -- he brings complexity to the role that was missing from the Superman movies. (In the original comics, Lex had been a boyhood friend of Superboy (don't recall about Kent), until Lex lost his hair which he blamed Superboy for. (It was a lab accident, in the process of putting out the fire, Superboy causes a chemical spill that affects Luthor. -- The modified backstory in Smallville is superior, IMHO.)
As for the show being geared for teenagers -- maybe so, but some of us old fogeys like it too. Good story lines (although for a while the "human is exposed to kryptonite, gets wierd powers, goes berserk" was being overdone) and good filmmaking go a long way. (And you gotta love all those foreshadowing jokes.)
..a few more years until the current cast of Smallville is old enough to be convincing in the parts. (Which shouldn't be long, they're a little old for the parts now -- but it's still an enjoyable show.)
;)
Although I'm curious about how and when Chloe Sullivan changes her name to Lois Lane.
a 35mm frame is 36x24mm (strange, but true) That's roughly 7200x4800 pixels, or 34.56 MPixels
And 35mm is small-format. Photographers going for higher quality go with "medium format" (70mm film, 60x60mm image size - think Hasselblad) or larger, roughly 12000x12000 pixels -- 144 megapixels. Digital still has a ways to go to catch up at the high end.
Since these interrupts are generated by events external to the computer (mouse movement, network events, etc.) the distribution is truly random.
/dev/random if some attacker is carefully controlling the timing of network packets.
Actually there was some discussion on the kernel mailing list recently about this. On, say, a rackmounted server you don't have mouse and keyboard interrupts, the only source of entropy is the timing of network events -- which in theory can be controlled by an outside entity (some other machine on the network). This leads to a theoretical non-randomness of
There was a patch offered for this but the side effects (taking much longer to generate an entropy pool) versus a practical assessment of the risk, were deemed not worth it.