I find the phrase "under consume and over save" to be hilarious. Obviously if you can make do with less, you can make do with less! Why consume when you don't really need to?
It's not about what one expects, but what's needed under treaties generally signed by most countries. Geneva convention is one such treaty. It affords no special treatment just because you're a civilian. As Kjella said, it's rather rudimentary stuff. They aren't supposed to starve you and such, otherwise it's fair game.
+1 insightful. Failure of communications between the machines, people in the cockpit, and people on the ground, has crashed more aerospace hardware than unsurvivable hardware faults.
There is no such thing as driving a floppy "directly somehow". All it can do is put bytes into a DMA buffer, and then put bytes into the command register area, and the the controller do its thing. 2M was written for DOS, it needs to directly talk to the floppy controller, that's why you need to run it under DOS, not Windows. I doubt it chews up CPU time for anything but polling, it has nothing better to do anyway as DOS is a single tasking OS. While you're formatting a floppy it wouldn't be very useful to let the command processor continue, of course the formatter could be a TSR, but then it'd need to have very extensive hooks into the OS to prevent any access to the floppy while it's being formatted.
It's fairly trivial to get the same effect on Linux, it has a flexible enough floppy driver IIRC. All you need is to set up the sector IDs in a certain order (for speed), and to use larger sectors and smaller gaps. All this is supported by the floppy controller, and the floppy controller does all the heavy lifting. You can get rid of sector gaps if you enforce rewriting of the entire track at once, that's reasonable anyway if you have a decent block buffers and elevator between the user and the device -- like you do on Linux!
Hand written state machines can be written more easily and legibly in C than in just about any other language.
If you think that doing explicit double dispatch by hand is somehow legible or OK performance wise, then I've got a couple bridges to sell. The best C-style hierarchical state machine code will have potentially crippling overheads due to runtime traversal of state handler hierarchy. By overheads I mean that the handler traversals may take an order of magnitude longer than whatever the state handler did.
Things are somewhat broken if you can write state machines with less syntax and runtime overhead and in a higher-level style in a decent macro assembler than in C. In good a macro assembler, you can exploit assembly-time computation to generate specific state traversals automagically and forgo any sort of runtime exploration of the hierarchy. In C, a supposedly higher-level language, you can't do squat for compile-time computation except for preprocessor metaprogramming (sigh). In C++, template metaprogramming is still such a resource hog on the available compilers that it's wholly impractical for anything but toy state machines, never mind that forcing functional programming for compile time computation in a fundamentally imperative language seems like an odd choice at best. Sane people give it a look and say: WTF?!
As for using frameworks: those are a.k.a. libraries. There's only so many times the humanity needs to reimplement and debug UML statechart semantics. I'd much rather reuse tested and optimized code than reinvent the wheel.
I'm not concerned at all with integration with anything -- only about making my own code look decent. I think I know every published way out there that producers/consumers ("yield") and state machines can be implemented in either C or C++, and it's not an amusing picture at all. Interestingly enough, it seems that out of "old" high-level languages still in common use only Lisp lets you implement both yielding generators and state machines such that there's no extra syntax overhead, no manual housekeeping, and no runtime overhead. C# and Python take care of generators, and both CLR and JVM will let you implement a library that rewrites code to generate precomputed state hierarchy traversals, but it's not fun to implement and I don't know of any decent open source implementations anyway. Forth lets you do what Lisp would let you do, but I'd be hard pressed to call it a high-level language.
Not when you are talking to PD765 or Intel 82072/7, like you would on PCs. Those run their own microcode. You prepare a DMA buffer with sector IDs for each sector in the track, then you fire off a command, and the controller does its thing in the background. It will interrupt when the track has been already formatted. When formatting, the fastest you can go is two revolutions: one for formatting, another one for the seek. Those floppy controllers don't allow you to start formatting mid-track IIRC, although feel free to give references stating otherwise if I'm wrong.
I have not thought about losing a companion, of course, but if you're right that a binary system is pretty much a prerequisite for any sort of a rogue capture, if that's what you mean.
I don't see how C is elegant. It's a horrible pain to write a lot of modern code from across many disciplines in C and even C++. Most software that deals with hardware or UIs needs to process asynchronous events and producers/consumers, so you need state machines and yield at the very least. Those are almost universally a royal pain to hack around. Just look at the statechart and msm libraries in boost -- and that's C++, not C! In plain C, look at Miro Samek's QP framework. Both C and C++ gets you to drown in irrelevant syntax for anything but old style procedural code, never mind that those languages artificially hide introspective data -- for example, there's no generic way in C nor C++ to add structural information about instances to enable non-conservative garbage collection. Go is a step in the right direction at least, even if it offers no compile-time computation (I consider that a must in any modern language).
I'm merely stating facts. FIFOs in UARTs and other I/O devices help with performance: you only pay one interrupt entry/exit overhead per FIFO access, not per every byte. A lot of software is poorly written, that's a fact, so just because with as-supplied MS-DOS and BIOS things wouldn't work right doesn't mean that hardware was entirely to blame.
...unless the serial data came in while the floppy interrupt handler was already in progress.
The interrupt handlers are supposed to do minimal amount of work, and relegate the rest to something called bottom half (using Linux parlance). When writing the code, you time it and model the worst case -- for example, a floppy interrupt being raised "right before" the serial input becomes available. If there are cases when it may not work, you absolutely have to have workarounds: either you can redo the floppy operation while losing some performance, or you suspend floppy access while data is coming in, etc. There's no handwaving allowed, in spite of a lot of software being designed just that way.
Floppy disk formatting requires very little CPU resources. You should have had no problem receiving bytes even at 57600 baudrate into a buffer using an 8250 UART (with one byte receive buffer) all the while formatting a floppy disk, even on the original IBM PC. You'd probably need to code it up yourself, of course. I don't recall BIOS having any buffering UART support, neither do I recall many BIOS implementations being any good at not disabling interrupts.
I wrote some 8250/16550 UART driver code, and everything worked fine as long as you didn't run stupid code that kept interrupts disabled, and as long as the interrupt priorities were set up right. In normal use, the only high-priority interrupts would be UART receive and floppy controller, and sound card if you had one. Everything else could wait with no ill effects.
Orbital dynamics and mr. Occam must be at odds today. Play with an N-body simulator and see how it goes. I don't think most people can claim any sort of common sense here unless they've been playing with one. It usually doesn't work the way one would expect. For example, one could naively think that gravity, as an attractive force, will cause eventual collapse if you start simulation with a random bunch of bodies having 0 relative velocity. To one's surprise, then, not only there will be no collapse, but a bunch of objects will get permanently ejected from such a system. Getting things cleanly orbiting one another in low-eccentricity orbits can be considered a lucky occurrence as well. That's what I remember from when I was in high school -- that's the first and last time I felt like coding up N-body (it's a pain -- naive algorithms don't work if you've not got a couple centuries to wait for the results), so feel free to correct me if I'm wrong.
If all you have is one star and one planet, and you simulate them as point masses (no tidal losses and no slowing down in star's outer atmosphere), capture seems impossible. The planets don't exactly have orbital insertion motors attached. I'd like to see a list of possible mechanisms that would make a capture possible in such a scenario. Remember: to have orbital insertion, you need to dissipate energy. Always.
Exactly. At both quantum and astronomical scales, plenty of everyday expressions become nonsensical -- just because one can say something, doesn't make it have a meaning in a particular context. It's easy to forget that.
Well said about the capture. It's very interesting to run an N-body gravitational simulation where the initial state is a bunch of things with random masses and velocity vectors. A whole lot of stuff will be ejected as things settle down. Gravitational capture appears to be hard. That's what I learned, to my initial amazement, when I started playing with N-body simulations. I thought the code had bugs. And then I'd input some solar system ephemeris for the planets and a couple other large objects, and voila, it didn't blow up, things were nicely orbiting:)
IIRC, the age of observable Universe does fluctuate by about 16 light minutes yearly (that's superimposed on other stuff, of course). The reference is wherever you happen to be. If you move a lot, the relative age of things shifts. All of the observable Universe always moves away from the observer. The Earth is a perfectly good reference point.
The deal is this: at the distance of 13 billion years, the only things we'll ever see are galaxies and perhaps some humongous supernovas. That's it. You can't see individual stars, never mind planets. The rule of thumb is, IIRC: if they find planets on it, it must be in our galaxy, and not on the far side of it either. More like in our backyard, and perhaps a bit further down the alley, too.
It's not bad perhaps, but I've tried very hard to use it a couple years ago, and quickly had to give up. Their whole operation has had a weird smell to it, as well: it seems perpetually borderline between a domain squatter and a real thing.
Slashdot Mirror
I find the phrase "under consume and over save" to be hilarious. Obviously if you can make do with less, you can make do with less! Why consume when you don't really need to?
It's not about what one expects, but what's needed under treaties generally signed by most countries. Geneva convention is one such treaty. It affords no special treatment just because you're a civilian. As Kjella said, it's rather rudimentary stuff. They aren't supposed to starve you and such, otherwise it's fair game.
+1 insightful. Failure of communications between the machines, people in the cockpit, and people on the ground, has crashed more aerospace hardware than unsurvivable hardware faults.
Makes perfect sense. +1.
There is no such thing as driving a floppy "directly somehow". All it can do is put bytes into a DMA buffer, and then put bytes into the command register area, and the the controller do its thing. 2M was written for DOS, it needs to directly talk to the floppy controller, that's why you need to run it under DOS, not Windows. I doubt it chews up CPU time for anything but polling, it has nothing better to do anyway as DOS is a single tasking OS. While you're formatting a floppy it wouldn't be very useful to let the command processor continue, of course the formatter could be a TSR, but then it'd need to have very extensive hooks into the OS to prevent any access to the floppy while it's being formatted.
It's fairly trivial to get the same effect on Linux, it has a flexible enough floppy driver IIRC. All you need is to set up the sector IDs in a certain order (for speed), and to use larger sectors and smaller gaps. All this is supported by the floppy controller, and the floppy controller does all the heavy lifting. You can get rid of sector gaps if you enforce rewriting of the entire track at once, that's reasonable anyway if you have a decent block buffers and elevator between the user and the device -- like you do on Linux!
+1 insightful. I've never thought of that!
Hand written state machines can be written more easily and legibly in C than in just about any other language.
If you think that doing explicit double dispatch by hand is somehow legible or OK performance wise, then I've got a couple bridges to sell. The best C-style hierarchical state machine code will have potentially crippling overheads due to runtime traversal of state handler hierarchy. By overheads I mean that the handler traversals may take an order of magnitude longer than whatever the state handler did.
Things are somewhat broken if you can write state machines with less syntax and runtime overhead and in a higher-level style in a decent macro assembler than in C. In good a macro assembler, you can exploit assembly-time computation to generate specific state traversals automagically and forgo any sort of runtime exploration of the hierarchy. In C, a supposedly higher-level language, you can't do squat for compile-time computation except for preprocessor metaprogramming (sigh). In C++, template metaprogramming is still such a resource hog on the available compilers that it's wholly impractical for anything but toy state machines, never mind that forcing functional programming for compile time computation in a fundamentally imperative language seems like an odd choice at best. Sane people give it a look and say: WTF?!
As for using frameworks: those are a.k.a. libraries. There's only so many times the humanity needs to reimplement and debug UML statechart semantics. I'd much rather reuse tested and optimized code than reinvent the wheel.
I'm not concerned at all with integration with anything -- only about making my own code look decent. I think I know every published way out there that producers/consumers ("yield") and state machines can be implemented in either C or C++, and it's not an amusing picture at all. Interestingly enough, it seems that out of "old" high-level languages still in common use only Lisp lets you implement both yielding generators and state machines such that there's no extra syntax overhead, no manual housekeeping, and no runtime overhead. C# and Python take care of generators, and both CLR and JVM will let you implement a library that rewrites code to generate precomputed state hierarchy traversals, but it's not fun to implement and I don't know of any decent open source implementations anyway. Forth lets you do what Lisp would let you do, but I'd be hard pressed to call it a high-level language.
Not when you are talking to PD765 or Intel 82072/7, like you would on PCs. Those run their own microcode. You prepare a DMA buffer with sector IDs for each sector in the track, then you fire off a command, and the controller does its thing in the background. It will interrupt when the track has been already formatted. When formatting, the fastest you can go is two revolutions: one for formatting, another one for the seek. Those floppy controllers don't allow you to start formatting mid-track IIRC, although feel free to give references stating otherwise if I'm wrong.
I have not thought about losing a companion, of course, but if you're right that a binary system is pretty much a prerequisite for any sort of a rogue capture, if that's what you mean.
I don't see how C is elegant. It's a horrible pain to write a lot of modern code from across many disciplines in C and even C++. Most software that deals with hardware or UIs needs to process asynchronous events and producers/consumers, so you need state machines and yield at the very least. Those are almost universally a royal pain to hack around. Just look at the statechart and msm libraries in boost -- and that's C++, not C! In plain C, look at Miro Samek's QP framework. Both C and C++ gets you to drown in irrelevant syntax for anything but old style procedural code, never mind that those languages artificially hide introspective data -- for example, there's no generic way in C nor C++ to add structural information about instances to enable non-conservative garbage collection. Go is a step in the right direction at least, even if it offers no compile-time computation (I consider that a must in any modern language).
Yep. Economies of scale and all that. A bottle of beer costs even less to make -- an order of magnitude less.
I'm merely stating facts. FIFOs in UARTs and other I/O devices help with performance: you only pay one interrupt entry/exit overhead per FIFO access, not per every byte. A lot of software is poorly written, that's a fact, so just because with as-supplied MS-DOS and BIOS things wouldn't work right doesn't mean that hardware was entirely to blame.
...unless the serial data came in while the floppy interrupt handler was already in progress.
The interrupt handlers are supposed to do minimal amount of work, and relegate the rest to something called bottom half (using Linux parlance). When writing the code, you time it and model the worst case -- for example, a floppy interrupt being raised "right before" the serial input becomes available. If there are cases when it may not work, you absolutely have to have workarounds: either you can redo the floppy operation while losing some performance, or you suspend floppy access while data is coming in, etc. There's no handwaving allowed, in spite of a lot of software being designed just that way.
Floppy disk formatting requires very little CPU resources. You should have had no problem receiving bytes even at 57600 baudrate into a buffer using an 8250 UART (with one byte receive buffer) all the while formatting a floppy disk, even on the original IBM PC. You'd probably need to code it up yourself, of course. I don't recall BIOS having any buffering UART support, neither do I recall many BIOS implementations being any good at not disabling interrupts.
I wrote some 8250/16550 UART driver code, and everything worked fine as long as you didn't run stupid code that kept interrupts disabled, and as long as the interrupt priorities were set up right. In normal use, the only high-priority interrupts would be UART receive and floppy controller, and sound card if you had one. Everything else could wait with no ill effects.
That's the weird thing about our Universe: it so happens that the center is always wherever you are.
IOW: give Apple a decade or two :)
Thank you. It just had to be said.
Orbital dynamics and mr. Occam must be at odds today. Play with an N-body simulator and see how it goes. I don't think most people can claim any sort of common sense here unless they've been playing with one. It usually doesn't work the way one would expect. For example, one could naively think that gravity, as an attractive force, will cause eventual collapse if you start simulation with a random bunch of bodies having 0 relative velocity. To one's surprise, then, not only there will be no collapse, but a bunch of objects will get permanently ejected from such a system. Getting things cleanly orbiting one another in low-eccentricity orbits can be considered a lucky occurrence as well. That's what I remember from when I was in high school -- that's the first and last time I felt like coding up N-body (it's a pain -- naive algorithms don't work if you've not got a couple centuries to wait for the results), so feel free to correct me if I'm wrong.
Seems like a copy-paste from youtube, if you ask me :)
If all you have is one star and one planet, and you simulate them as point masses (no tidal losses and no slowing down in star's outer atmosphere), capture seems impossible. The planets don't exactly have orbital insertion motors attached. I'd like to see a list of possible mechanisms that would make a capture possible in such a scenario. Remember: to have orbital insertion, you need to dissipate energy. Always.
Exactly. At both quantum and astronomical scales, plenty of everyday expressions become nonsensical -- just because one can say something, doesn't make it have a meaning in a particular context. It's easy to forget that.
Well said about the capture. It's very interesting to run an N-body gravitational simulation where the initial state is a bunch of things with random masses and velocity vectors. A whole lot of stuff will be ejected as things settle down. Gravitational capture appears to be hard. That's what I learned, to my initial amazement, when I started playing with N-body simulations. I thought the code had bugs. And then I'd input some solar system ephemeris for the planets and a couple other large objects, and voila, it didn't blow up, things were nicely orbiting :)
IIRC, the age of observable Universe does fluctuate by about 16 light minutes yearly (that's superimposed on other stuff, of course). The reference is wherever you happen to be. If you move a lot, the relative age of things shifts. All of the observable Universe always moves away from the observer. The Earth is a perfectly good reference point.
The deal is this: at the distance of 13 billion years, the only things we'll ever see are galaxies and perhaps some humongous supernovas. That's it. You can't see individual stars, never mind planets. The rule of thumb is, IIRC: if they find planets on it, it must be in our galaxy, and not on the far side of it either. More like in our backyard, and perhaps a bit further down the alley, too.
It's not bad perhaps, but I've tried very hard to use it a couple years ago, and quickly had to give up. Their whole operation has had a weird smell to it, as well: it seems perpetually borderline between a domain squatter and a real thing.