The QEMU Accelerator is free to use, but it is a closed source proprietary product.
... so perhaps not the best example of an open source virtualisation app. (The QEMU accelerator is needed to true virtualisation like the other examples being discussed—without that, QEMU is just a processor simulator, and so runs 5–10 times slower—at least, according to its own web page!)
[OT: Apologies for the boldface—the new style doesn’t allow italics inside <blockquote>—WTF?]
Yes, that's right—even tcpdump compiles code at runtime,
While I agree with most of your post, that's not actually true—tcpdump compiles to bytecode, which it then interprets much like a non-optimised JVM. To see this, run the same commands on the same version of tcpdump on different CPU architectures (I tried SPARC and i386): you’ll see the same instructions being generated (you can even check that the compiled bytes are the same, if you use the -dd option).
That won't work, as the "su" executable, in order to work, has to be installed setuid-to-root, which you can't do unless you're already root. And I'd guess that they're detecting the "su" usage by examining the syslog output, which will show up your attempt in either case...
Yes—I didn’t mean to suggest that WinXP product keys were tied to a particular copy—just that WinXP has measures that are a bit more effective than having to type a number that isn’t even unique:-)
Anything that came with a certificate of authenticity had its own unique number.
That might be what Microsoft wants you to think, but it’s not actually true—in the sense that you can use the “unique” number from any Win95/NT/98 etc CD to install any other CD of the same OS—there’s no real protection involved.
The description in the patent sounds much more like the (more effective) protection that came in with Windows XP. Which was released, IIRC, in late 2001. Which is still plenty before 2003...
Linux must have some process that reaps them automatically. I've kill-9'd plenty of parent processes and forked without waiting, and I haven't seen a zombie in years.
Killing the parent doesn't create a zombie—the orphaned process becomes a child of its parent’s parent (ie its grandparent process), which is often a shell or init (both of which are good at cleaning up after their children).
Zombies are an artifact of bad system design. If I didn't express an interest in process accounting when I created the child, I damn sure don't need it hanging around for process accounting when it exits.
It's not really bad system design, more a poor choice of defaults in the API—the default should probably be not to create zombies. But it’s arguable: often (if you’re writing software for more than throwaway purposes) you’ll want to know the exit status of your children... But you can disable the creation of zombies—just call sigignore(SIGCHLD) in your parent process, and you’ll never see a zombie again.
when you roll your head away from the horizontal your stereo vision doesnt go all overlappy
Why would it do that? Surely your eyes would still be at the same distance/angle from each other, so they'd still be giving stereographic information that was just as valid?
Using a hash table with a "biased" hash function is a nice idea. You could exploit subtle differences in the platform, such as whether certain C types are signed/unsigned, or big/little-endianness:
// Trivial (and fairly useless) hash function int calculate_hash(const void *data, size_t length) { int total = 0; const unsigned char *bytes = data; for (int i = 0; i < length; i++) { total += bytes[i]; } return (total % NUM_BUCKETS); }
// Calculate the hash value for a record. Base it on the // employee id since that's unique per employee int calculate_employee_hash(const employee *emp) { return (calculate_hash(&employee->id, 2)); }
On a little-endian system, assuming a relatively even distribution of [32 bit] employee IDs, this will perform well; on a big-endian system (high-byte-first) it will store the first 65536 employees in the same hash bucket - which, if you're searching the buckets linearly is going to get pretty slow:-)
So... of your three references, the first can't spell genitive, the first and second don't mention "its" vs "it's", and the third agrees with the poster you're criticising... perhaps not very convincing;-)
You're right, he's talking rubbish: CEF can be used on UDP packets just like any other IP packets—indeed, it generally won't even look deep enough into the packet to discover whether the packet is UDP, TCP or something else... perhaps he meant RED rather than CEF—that's a load-managing strategy that only works for TCP...
It's true that lots of small packets will stress any software-forwarding platform, but that's true whether the packets are TCP, UDP, ICMP, SCTP etc... although it's fair to say that most broken protocols that do send storms of such packets are probably based on UDP!
But putting more stuff into interrupt handlers slows down everything else.
Why do you assume that this is the case? Leaving aside the many other arguments against putting more work into interrupt handlers: the interrupt has to occur either way (to get the packet from the network), and the protocol processing has to take place either way (because we want to support the protocol!), but if you do the work inside the interrupt handler, there's no need to take the time to notify another process/kernel thread/whatever—so fewer CPU cycles are used in total. So everything else goes faster. (As well as being less modular, more prone to crash, etc, etc...)
Not necessarily: the code could, for example, be generated (by a cryptographically secure hash) from the PIN and the current time/date—that way it is constantly changing but easily resynchronised...
Would you like to knock approximately 360 times every time you open your door, and more importantly, regularly having to remember sequences of that length for one-time-use?
Erm, no... that's why I'd use a little device, into which I'd enter a PIN, causing it to generate and tap out the long authentication sequence for me—and much more rapidly than I could ever tap it out myself!
It's funny, they even mention such a device in the article;-)
And what, exactly, would a rootkit or virus want with the BIOS?
A very insightful question—and one with a scary answer. Currently, if I have a machine that's infected with a rootkit/virus/other malware, I can boot Knoppix or other favourite live CD of choice, and be sure that the malware isn't running (and thus can't prevent me detecting/removing it, log my keystrokes, wipe my HD, or any other things I'd rather it didn't do). Once malware starts overwriting the BIOS, I can't even be sure of that: as soon as I apply power to the machine, it's already compromised...
So... how will the virus survive after a format? It bootstraps code on the hard drive.. which... just got formatted... excellent plan!
Most computers these days are networked. So it just downloads the rest of the code from rootkits-r-us.com...
Plus, what's the virus gonna do, turn off my PC?
Yeah... or steal all your data... and passwords... and delete your files... and download kiddie porn to your hard drive. In short, all the usual malware tricks!
Of, except that one of the regions of said secular country will "explode" if he does.
Northern Ireland, though part of the UK, is not part of Britain. So the claim stands.
(And of course, the tensions in NI have more to do with how different sectors of society have been treated historically, than to do with religion. The disturbances that arise from time to time are not arguing over transubstantiation vs consubstantiation...)
The energy is surplus and going to waste regardless of whether you use it or not.
That's not actually true—the more power you take out, the more gas you'll use. The bigger the electrical load it has to power, the more strain the alternator will place on the engine.
If you don't believe me, try this experiment: take a DC motor (which converts electricity to rotational motion, but functions just as well in reverse as a generator) and don't connect it to anything—so there's no load—and observe how easy it is to turn the spindle. Now short-circuit it (so that there's effectively a huge load on it, which will draw as much current as the poor motor can produce). You'll find that turning the spindle becomes much harder!
Or did it poll them all when a * command was issued until one responded? You shouldn't have to page in EPROMs to issue * commands.
Yes, it polled all the ROMs when a * command it didn't recognise was issued.
In answer to the original question, if it's the Master that comes up with network selected by default, you should be able to type *ROMS to get a list of the EPROMs present, then *CONFIGURE FILE <n> (where <n> is the ROM with the disc filing system (DFS)—typically 9). If it's the BBC B you may have to move the ROMs around internally, or solder/unsolder one of the "keyboard links" to persuade it to come up with DFS by default.
Slashdot Mirror
From the site you linked to:
... so perhaps not the best example of an open source virtualisation app. (The QEMU accelerator is needed to true virtualisation like the other examples being discussed—without that, QEMU is just a processor simulator, and so runs 5–10 times slower—at least, according to its own web page!)
[OT: Apologies for the boldface—the new style doesn’t allow italics inside <blockquote>—WTF?]
Correct. It's the First Amendment that gives him *that* right ;-)
While I agree with most of your post, that's not actually true—tcpdump compiles to bytecode, which it then interprets much like a non-optimised JVM. To see this, run the same commands on the same version of tcpdump on different CPU architectures (I tried SPARC and i386): you’ll see the same instructions being generated (you can even check that the compiled bytes are the same, if you use the -dd option).
That won't work, as the "su" executable, in order to work, has to be installed setuid-to-root, which you can't do unless you're already root. And I'd guess that they're detecting the "su" usage by examining the syslog output, which will show up your attempt in either case...
OK, I did, and here's what it says...
Yes—I didn’t mean to suggest that WinXP product keys were tied to a particular copy—just that WinXP has measures that are a bit more effective than having to type a number that isn’t even unique :-)
That might be what Microsoft wants you to think, but it’s not actually true—in the sense that you can use the “unique” number from any Win95/NT/98 etc CD to install any other CD of the same OS—there’s no real protection involved.
The description in the patent sounds much more like the (more effective) protection that came in with Windows XP. Which was released, IIRC, in late 2001. Which is still plenty before 2003...
Killing the parent doesn't create a zombie—the orphaned process becomes a child of its parent’s parent (ie its grandparent process), which is often a shell or init (both of which are good at cleaning up after their children).
Zombies are an artifact of bad system design. If I didn't express an interest in process accounting when I created the child, I damn sure don't need it hanging around for process accounting when it exits.
It's not really bad system design, more a poor choice of defaults in the API—the default should probably be not to create zombies. But it’s arguable: often (if you’re writing software for more than throwaway purposes) you’ll want to know the exit status of your children... But you can disable the creation of zombies—just call sigignore(SIGCHLD) in your parent process, and you’ll never see a zombie again.
Why would it do that? Surely your eyes would still be at the same distance/angle from each other, so they'd still be giving stereographic information that was just as valid?
Using a hash table with a "biased" hash function is a nice idea. You could exploit subtle differences in the platform, such as whether certain C types are signed/unsigned, or big/little-endianness:
On a little-endian system, assuming a relatively even distribution of [32 bit] employee IDs, this will perform well; on a big-endian system (high-byte-first) it will store the first 65536 employees in the same hash bucket - which, if you're searching the buckets linearly is going to get pretty slowSo... of your three references, the first can't spell genitive, the first and second don't mention "its" vs "it's", and the third agrees with the poster you're criticising... perhaps not very convincing ;-)
Don't be silly. Fir trees are evergreen, not deciduous...
*ducks*
It's true that lots of small packets will stress any software-forwarding platform, but that's true whether the packets are TCP, UDP, ICMP, SCTP etc... although it's fair to say that most broken protocols that do send storms of such packets are probably based on UDP!
Why do you assume that this is the case? Leaving aside the many other arguments against putting more work into interrupt handlers: the interrupt has to occur either way (to get the packet from the network), and the protocol processing has to take place either way (because we want to support the protocol!), but if you do the work inside the interrupt handler, there's no need to take the time to notify another process/kernel thread/whatever—so fewer CPU cycles are used in total. So everything else goes faster. (As well as being less modular, more prone to crash, etc, etc...)
Ah, now you've identified the real flaw in this plan :-)
Not necessarily: the code could, for example, be generated (by a cryptographically secure hash) from the PIN and the current time/date—that way it is constantly changing but easily resynchronised...
Erm, no... that's why I'd use a little device, into which I'd enter a PIN, causing it to generate and tap out the long authentication sequence for me—and much more rapidly than I could ever tap it out myself!
It's funny, they even mention such a device in the article ;-)
And what, exactly, would a rootkit or virus want with the BIOS?
A very insightful question—and one with a scary answer. Currently, if I have a machine that's infected with a rootkit/virus/other malware, I can boot Knoppix or other favourite live CD of choice, and be sure that the malware isn't running (and thus can't prevent me detecting/removing it, log my keystrokes, wipe my HD, or any other things I'd rather it didn't do). Once malware starts overwriting the BIOS, I can't even be sure of that: as soon as I apply power to the machine, it's already compromised...
So... how will the virus survive after a format? It bootstraps code on the hard drive.. which... just got formatted... excellent plan!
Most computers these days are networked. So it just downloads the rest of the code from rootkits-r-us.com...
Plus, what's the virus gonna do, turn off my PC?
Yeah... or steal all your data... and passwords... and delete your files... and download kiddie porn to your hard drive. In short, all the usual malware tricks!
-P
Northern Ireland, though part of the UK, is not part of Britain. So the claim stands.
(And of course, the tensions in NI have more to do with how different sectors of society have been treated historically, than to do with religion. The disturbances that arise from time to time are not arguing over transubstantiation vs consubstantiation...)
The energy is surplus and going to waste regardless of whether you use it or not.
That's not actually true—the more power you take out, the more gas you'll use. The bigger the electrical load it has to power, the more strain the alternator will place on the engine.
If you don't believe me, try this experiment: take a DC motor (which converts electricity to rotational motion, but functions just as well in reverse as a generator) and don't connect it to anything—so there's no load—and observe how easy it is to turn the spindle. Now short-circuit it (so that there's effectively a huge load on it, which will draw as much current as the poor motor can produce). You'll find that turning the spindle becomes much harder!
They're doing it by using a design-description method that prevents unambiguity
Now that's a method I'd like to see—one which makes it impossible to say anything without a double meaning ;-)
See his FAQ for an explanation and a .wav file!
Yes, it polled all the ROMs when a * command it didn't recognise was issued.
In answer to the original question, if it's the Master that comes up with network selected by default, you should be able to type *ROMS to get a list of the EPROMs present, then *CONFIGURE FILE <n> (where <n> is the ROM with the disc filing system (DFS)—typically 9). If it's the BBC B you may have to move the ROMs around internally, or solder/unsolder one of the "keyboard links" to persuade it to come up with DFS by default.