I don't know how they calculated it, but for a family of four with a mortgage and an equivalent of one good job, the residual federal tax rate would be around 1-2%.
Of course I'm feeding the troll, but heck, I was a grad student with a newborn, and we were on WIC, and I don't think I'm not contributing anything back. No, we don't buy 10 liters of soda at Walmart every other weekday. So shut the fuck up idiot.
Thank you, this was quite informative. I have known about O2 causing blindness in infants, but did not appreciate that it has risks that continue throughout one's life.
I think that, given the number of imitators, what he did was in fact technology-world changing in a way. Not new-science world-changing of way, but design- and usability-changing. Whatever you may say about something as "simple" as Time Machine, even that is probably the first time ever you had such functionality available, in a user-accessible way. With all the backups indexed, no less. I'm no stranger to setting up backups on various breeds of machines, and of course know about rsync --link-dest, but Time Machine presents it in such a way that I don't have to cringe when using it. Not having to worry about the most mundane things has its pluses, you know.
That includes my pet peeve: sleep-on-lid-close on laptops. Every year around Christmas I do a survey of a nearby MicroCenter and Best-Buy, and it's not very reassuring to say the least. The trend points upwards -- more and more machines are doing the right thing by default, but it's still not what you would expect: that every damn laptop out there goes to sleep and resumes without you having endure beeps, having to press something (what?), etc.
There is something to be said for attention to detail in usability, and I think that Apple has been doing more than OK in that department while Jobs was in charge. It's still not an everyday thing, you know, even though it SHOULD BE.
I think this is selling him short a bit. His contribution was entirely in what to sell, his insight was about why the products should be designed in a certain way. Yes, Apple got ideas from Xerox about basics of the GUI, but Xerox did not manage to fully realize the potential of the technology they had. Xerox's products were a flop, because they didn't understand what was it about them that could make them good, and thus never took advantage of their own innovation. It's no good if you have figured out something cool if you have no clue how to actually use it in a product.
Never mind that Apple pretty much reimplemented all of Xerox's ideas from scratch. It's not like they went to Xerox, ripped some code, then tweaked it and sold it on. The original Mac and Apple II were quite revolutionary products. There was nothing quite like them on the market. Of course there were other "similar" products, but nothing that was designed with similar attention to detail and usability. Even "silly" stuff like Apple II's switching power supply was quite a breakthrough in an age where most computers had a transfomer, rectifier, and a linear regulator that ran pretty hot.
Of course both Tek and HP sold oscilloscopes with such power supplies at the time, and probably some workstations and mainframes had switching supplies, but no consumer/hobbyist products at the time had that. Look, for example, at ABC-80, circa 1978. See the black radiator in the back? That's what the linear regulators were bolted to. It added to the cost and made for an unwieldy-looking thing. Perhaps in Swedish climate it made sense, though:)
All those "little" things count, and that's why "quite like it" doesn't count.
Does anyone NOT receive their television from cable these days?
I'm considering dropping the cable TV part of my cable package since all that I watch is either available online on the network sites (with a slight delay), or it's on the channels that are available over-the-air, in HD no less. I have to get my behind up into the attic and install two antennas, though: there are two masts downtown that do OTA broadcasts, and they are separated enough that you need two antennas.
Mandatory attendance? Gee whiz, when I went to grad school there wasn't a single course where attendance counted for anything. There were a couple courses where I skipped most of lectures, and there were some where lectures were so good that I didn't have to do any extra learning at home besides solving assignments.
He probably doesn't use those trig identities each day anyway. It's basic stuff, you'd think a math professor will be doing research that's slightly more involved than that! Heck, if your research involves lots of trig identities (somehow), you are dumb if you do it by hand, as you'd be wasting time with inevitable mistakes. If you need lots of trig identities done, you use a symbolic math package to do it for you. I'd think there's plenty of profs out there who do quite high level research and would pretty much suck at some of the undergraduate level stuff. I don't remember the trig identities, even if I could prove or derive every one of them in a couple of minutes.
This is a reverse ad-hominem FTW. Someone else "attacked" her behavior (and not her as a person!), and she turns it into a personal attack on the attacker. I guess it's a start of a slipper slope. Legion d'honneur, my ass.
There is nothing fundamentally wrong about using a samba share, sorry. That problem with KDE 4 persists no matter what sort of a share you're using: if it's not visible in the filesystem, there is usually no streaming. It sucks.
Agreed. When doing embedded stuff, I audit all compiler output. Sometimes a simple tweak can save (or waste!) substantial amount of execution time and code space. The bootloader would probably fit into 1.5kb if I had a need to fit it in such small space. Right now it's mostly written in C, with only the startup code, CRC routines and a state machine dispatcher written in assembly. It has to run on devices with less-than-maximum clock, while still processing all the incoming bytes in real time (up to 10kbytes/s). Thus, for example, the 16- and 32-bit CRC is unrolled and uses immediate loads for all the constants. In many places the C compiler's output is close to optimal, and any further size optimizations would only be had by going to a more table-driven system that trades a bit of speed for lots of space savings.
I can easily see a 10x reduction in code size if one doesn't look at the output, or doesn't understand how the compiler arrives at the output. Probably the starting point is a choice of ABI (memory model, parameter passing, dynamic vs. static frames). Plenty of embedded firmware has non-reentrant functions so there's no need at all to use stack for anything but return addresses. In many architectures accessing stack variables is either slower or results in larger code than accessing fixed memory locations, especially if the latter are available in some sort of shortened-addressing windows (page 0 on 6502, register window on Z8/eZ8, etc).
If you have a quirky compiler, sometimes simple things like reordering variables in a comparison can save 50%+ in generated code size, sigh.
Ha, that made me go down a memory lane. I pulled up my 8250 library that I wrote in Pascal back in the 90s. I think that the issue you refer to is that setting IER_THRI bit generates an interrupt independently of whether THR (transmit holding register) is empty. Thus in the transmit interrupt handler you have to check if the THR is actually empty. This isn't a big amount of gymnastics, though. When you account for handshaking and other intricacies, though, it's a good couple of pages just for the interrupt handler, and that's in a high-level language.
Well, I'm a bit more lazy, because I can afford 128 bytes of RAM and about 3.5kb of code just for a bootloader. But it's a networked one, with CRCs, topology discovery, and other goodies;)
If you want a lot of effort with a lot more bang, then perhaps making your own transistors would be a thing to consider, from there you can make gates and stuff:)
If I were to attack this, I'd think of installing gradient coils on some sort of electrostrictive material and issue pulses to both to provide opposite loads on the coil structure.
That said, it is highly unlikely you would have the power and cooling (just to name a few requirements) in your garage to build a better MRI.
For that matter most people would probably dim the lights in their neighborhood if they brought an MRI to full power in their garage.
MRI is inherently scalable -- that is, you can develop imaging algorithms on an imager for chipmunks then scale up. I have seen essentially desktop-sized NMR imagers used for studies of small archeozoological artifacts, for veterinary imaging of small animals, an for research on NMR/MRI algorithms. So if I were to start doing something like that, I would not be encumbered by anything you mentioned. With groundwork laid, I'd look for VC or buyout to scale it up.
Relays do not exclude toggle switches, but with the paperclip computer you had to execute everything by hand, there was no automation of any sort.
I think that you'd want something that's designed to visualize and allow manual overriding of any function block inside the CPU. Say you can be a manual accumulator while instruction decode and sequencing and memory is automated. Or you can be the instruction decoder. Or you can do every single thing.
Unless you really want a lot of clickety-clack, you could cheat a bit and design the UI on pc-boards, but have all the logic running on a small microcontroller. I'd think that memory and CPU state should be visible, so that there would be plenty of LEDs. The LEDs and switches and required large PC-boards will already cost a good bundle by themselves. Even if you don't want PCBs and wish to do point-to-point wiring, it'll take quite a lot of time to do it. And you better learn how to lace those wire bundles:)
There are cheap electromechanical relays (less than 1 USD each) but you'd still need quite a few of them. A fairly basic machine with, say, 256 bits of data memory/registers and most basic instruction set would still require about 1000 relays, and this still doesn't cover any code memory. Probably 512 bits of data+code storage is enough to cover the basics... It's not going to be cheap.
The paperclip version is, IMHO, a total waste of time. It'd be better, IMHO, to start with paper-based version, and code up something simple like drawing a bitmapped circle. Executing the code to draw a small circle that way (say 16 pixels across) by hand should take about an hour if you're good at mental math and can avoid mistakes. To make life easy, you can design it to have bit-addressable memory with row address and column address in separate registers.
That's just silly, every single article you link to. The specs for the code were such that there would be no year-end-crossing missions, that's all there is to it. This has nothing to do with when was the flight software designed in. It simply wasn't in the specs back then, and there was no funding to change it any time earlier than when they did actually change the specs and implemented it. You're providing a straw man for an argument. Space Shuttle's flight software was probably the best engineered piece of software there ever was. See here. Or we can cite Feynman, who had quite low bullshit threshold and would not be impressed if there was nothing to be impressed about:
The software is checked very carefully in a bottom-up fashion. First, each new line of code is checked, then sections of code or modules with special functions are verified. The scope is increased step by step until the new changes are incorporated into a complete system and checked. This complete output is considered the final product, newly released. But completely independently there is an independent verification group, that takes an adversary attitude to the software development group, and tests and verifies the software as if it were a customer of the delivered product. There is additional verification in using the new programs in simulators, etc. A discovery of an error during verification testing is considered very serious, and its origin studied very carefully to avoid such mistakes in the future. Such unexpected errors have been found only about six times in all the programming and program changing (for new or altered payloads) that has been done. The principle that is followed is that all the verification is not an aspect of program safety, it is merely a test of that safety, in a non-catastrophic verification. Flight safety is to be judged solely on how well the programs do in the verification tests. A failure here generates considerable concern.
To summarize then, the computer software checking system and attitude is of the highest quality. There appears to be no process of gradually fooling oneself while degrading standards so characteristic of the Solid Rocket Booster or Space Shuttle Main Engine safety systems. To be sure, there have been recent suggestions by management to curtail such elaborate and expensive tests as being unnecessary at this late date in Shuttle history. This must be resisted for it does not appreciate the mutual subtle influences, and sources of error generated by even small changes of one part of a program on another. There are perpetual requests for changes as new payloads and new demands and modifications are suggested by the users. Changes are expensive because they require extensive testing. The proper way to save money is to curtail the number of requested changes, not the quality of testing for each.
One might add that the elaborate system could be very much improved by more modern hardware and programming techniques. Any outside competition would have all the advantages of starting over, and whether that is a good idea for NASA now should be carefully considered.
Internationalization, done properly, only takes up disk space, it should have NO runtime overheads of any sort other than a fixed overhead that's unrelated to the number of translatable strings. IOW, internationalization should have O(1) runtime space cost.
Slashdot Mirror
I don't know how they calculated it, but for a family of four with a mortgage and an equivalent of one good job, the residual federal tax rate would be around 1-2%.
Of course I'm feeding the troll, but heck, I was a grad student with a newborn, and we were on WIC, and I don't think I'm not contributing anything back. No, we don't buy 10 liters of soda at Walmart every other weekday. So shut the fuck up idiot.
One small post for martian, one big win for sarcasm. This made my day!
Thank you, this was quite informative. I have known about O2 causing blindness in infants, but did not appreciate that it has risks that continue throughout one's life.
I think that, given the number of imitators, what he did was in fact technology-world changing in a way. Not new-science world-changing of way, but design- and usability-changing. Whatever you may say about something as "simple" as Time Machine, even that is probably the first time ever you had such functionality available, in a user-accessible way. With all the backups indexed, no less. I'm no stranger to setting up backups on various breeds of machines, and of course know about rsync --link-dest, but Time Machine presents it in such a way that I don't have to cringe when using it. Not having to worry about the most mundane things has its pluses, you know.
That includes my pet peeve: sleep-on-lid-close on laptops. Every year around Christmas I do a survey of a nearby MicroCenter and Best-Buy, and it's not very reassuring to say the least. The trend points upwards -- more and more machines are doing the right thing by default, but it's still not what you would expect: that every damn laptop out there goes to sleep and resumes without you having endure beeps, having to press something (what?), etc.
There is something to be said for attention to detail in usability, and I think that Apple has been doing more than OK in that department while Jobs was in charge. It's still not an everyday thing, you know, even though it SHOULD BE.
I think this is selling him short a bit. His contribution was entirely in what to sell, his insight was about why the products should be designed in a certain way. Yes, Apple got ideas from Xerox about basics of the GUI, but Xerox did not manage to fully realize the potential of the technology they had. Xerox's products were a flop, because they didn't understand what was it about them that could make them good, and thus never took advantage of their own innovation. It's no good if you have figured out something cool if you have no clue how to actually use it in a product.
Never mind that Apple pretty much reimplemented all of Xerox's ideas from scratch. It's not like they went to Xerox, ripped some code, then tweaked it and sold it on. The original Mac and Apple II were quite revolutionary products. There was nothing quite like them on the market. Of course there were other "similar" products, but nothing that was designed with similar attention to detail and usability. Even "silly" stuff like Apple II's switching power supply was quite a breakthrough in an age where most computers had a transfomer, rectifier, and a linear regulator that ran pretty hot.
Of course both Tek and HP sold oscilloscopes with such power supplies at the time, and probably some workstations and mainframes had switching supplies, but no consumer/hobbyist products at the time had that. Look, for example, at ABC-80, circa 1978. See the black radiator in the back? That's what the linear regulators were bolted to. It added to the cost and made for an unwieldy-looking thing. Perhaps in Swedish climate it made sense, though :)
All those "little" things count, and that's why "quite like it" doesn't count.
Does anyone NOT receive their television from cable these days?
I'm considering dropping the cable TV part of my cable package since all that I watch is either available online on the network sites (with a slight delay), or it's on the channels that are available over-the-air, in HD no less. I have to get my behind up into the attic and install two antennas, though: there are two masts downtown that do OTA broadcasts, and they are separated enough that you need two antennas.
Mandatory attendance? Gee whiz, when I went to grad school there wasn't a single course where attendance counted for anything. There were a couple courses where I skipped most of lectures, and there were some where lectures were so good that I didn't have to do any extra learning at home besides solving assignments.
Huh? Quantum mechanics are quite practical and demonstrable, it's just that you need to know a lot of theory to begin applying them at all.
He probably doesn't use those trig identities each day anyway. It's basic stuff, you'd think a math professor will be doing research that's slightly more involved than that! Heck, if your research involves lots of trig identities (somehow), you are dumb if you do it by hand, as you'd be wasting time with inevitable mistakes. If you need lots of trig identities done, you use a symbolic math package to do it for you. I'd think there's plenty of profs out there who do quite high level research and would pretty much suck at some of the undergraduate level stuff. I don't remember the trig identities, even if I could prove or derive every one of them in a couple of minutes.
This is a reverse ad-hominem FTW. Someone else "attacked" her behavior (and not her as a person!), and she turns it into a personal attack on the attacker. I guess it's a start of a slipper slope. Legion d'honneur, my ass.
Offtopic I agree with, but Troll? Or overrated? Oh joys of moderation :)
You can mount samba shares directly into the filesystem :)
There is nothing fundamentally wrong about using a samba share, sorry. That problem with KDE 4 persists no matter what sort of a share you're using: if it's not visible in the filesystem, there is usually no streaming. It sucks.
Agreed. When doing embedded stuff, I audit all compiler output. Sometimes a simple tweak can save (or waste!) substantial amount of execution time and code space. The bootloader would probably fit into 1.5kb if I had a need to fit it in such small space. Right now it's mostly written in C, with only the startup code, CRC routines and a state machine dispatcher written in assembly. It has to run on devices with less-than-maximum clock, while still processing all the incoming bytes in real time (up to 10kbytes/s). Thus, for example, the 16- and 32-bit CRC is unrolled and uses immediate loads for all the constants. In many places the C compiler's output is close to optimal, and any further size optimizations would only be had by going to a more table-driven system that trades a bit of speed for lots of space savings.
I can easily see a 10x reduction in code size if one doesn't look at the output, or doesn't understand how the compiler arrives at the output. Probably the starting point is a choice of ABI (memory model, parameter passing, dynamic vs. static frames). Plenty of embedded firmware has non-reentrant functions so there's no need at all to use stack for anything but return addresses. In many architectures accessing stack variables is either slower or results in larger code than accessing fixed memory locations, especially if the latter are available in some sort of shortened-addressing windows (page 0 on 6502, register window on Z8/eZ8, etc).
If you have a quirky compiler, sometimes simple things like reordering variables in a comparison can save 50%+ in generated code size, sigh.
BTW, I'm serious, look for Jeri Ellsworth's videos on youtube.
Ha, that made me go down a memory lane. I pulled up my 8250 library that I wrote in Pascal back in the 90s. I think that the issue you refer to is that setting IER_THRI bit generates an interrupt independently of whether THR (transmit holding register) is empty. Thus in the transmit interrupt handler you have to check if the THR is actually empty. This isn't a big amount of gymnastics, though. When you account for handshaking and other intricacies, though, it's a good couple of pages just for the interrupt handler, and that's in a high-level language.
Well, I'm a bit more lazy, because I can afford 128 bytes of RAM and about 3.5kb of code just for a bootloader. But it's a networked one, with CRCs, topology discovery, and other goodies ;)
If you want a lot of effort with a lot more bang, then perhaps making your own transistors would be a thing to consider, from there you can make gates and stuff :)
+1 insightful. or informative.
If I were to attack this, I'd think of installing gradient coils on some sort of electrostrictive material and issue pulses to both to provide opposite loads on the coil structure.
That said, it is highly unlikely you would have the power and cooling (just to name a few requirements) in your garage to build a better MRI.
For that matter most people would probably dim the lights in their neighborhood if they brought an MRI to full power in their garage.
MRI is inherently scalable -- that is, you can develop imaging algorithms on an imager for chipmunks then scale up. I have seen essentially desktop-sized NMR imagers used for studies of small archeozoological artifacts, for veterinary imaging of small animals, an for research on NMR/MRI algorithms. So if I were to start doing something like that, I would not be encumbered by anything you mentioned. With groundwork laid, I'd look for VC or buyout to scale it up.
Relays do not exclude toggle switches, but with the paperclip computer you had to execute everything by hand, there was no automation of any sort.
I think that you'd want something that's designed to visualize and allow manual overriding of any function block inside the CPU. Say you can be a manual accumulator while instruction decode and sequencing and memory is automated. Or you can be the instruction decoder. Or you can do every single thing.
Unless you really want a lot of clickety-clack, you could cheat a bit and design the UI on pc-boards, but have all the logic running on a small microcontroller. I'd think that memory and CPU state should be visible, so that there would be plenty of LEDs. The LEDs and switches and required large PC-boards will already cost a good bundle by themselves. Even if you don't want PCBs and wish to do point-to-point wiring, it'll take quite a lot of time to do it. And you better learn how to lace those wire bundles :)
There are cheap electromechanical relays (less than 1 USD each) but you'd still need quite a few of them. A fairly basic machine with, say, 256 bits of data memory/registers and most basic instruction set would still require about 1000 relays, and this still doesn't cover any code memory. Probably 512 bits of data+code storage is enough to cover the basics... It's not going to be cheap.
The paperclip version is, IMHO, a total waste of time. It'd be better, IMHO, to start with paper-based version, and code up something simple like drawing a bitmapped circle. Executing the code to draw a small circle that way (say 16 pixels across) by hand should take about an hour if you're good at mental math and can avoid mistakes. To make life easy, you can design it to have bit-addressable memory with row address and column address in separate registers.
That's just silly, every single article you link to. The specs for the code were such that there would be no year-end-crossing missions, that's all there is to it. This has nothing to do with when was the flight software designed in. It simply wasn't in the specs back then, and there was no funding to change it any time earlier than when they did actually change the specs and implemented it. You're providing a straw man for an argument. Space Shuttle's flight software was probably the best engineered piece of software there ever was. See here. Or we can cite Feynman, who had quite low bullshit threshold and would not be impressed if there was nothing to be impressed about:
The software is checked very carefully in a bottom-up fashion. First, each new line of code is checked, then sections of code or modules with special functions are verified. The scope is increased step by step until the new changes are incorporated into a complete system and checked. This complete output is considered the final product, newly released. But completely independently there is an independent verification group, that takes an adversary attitude to the software development group, and tests and verifies the software as if it were a customer of the delivered product. There is additional verification in using the new programs in simulators, etc. A discovery of an error during verification testing is considered very serious, and its origin studied very carefully to avoid such mistakes in the future. Such unexpected errors have been found only about six times in all the programming and program changing (for new or altered payloads) that has been done. The principle that is followed is that all the verification is not an aspect of program safety, it is merely a test of that safety, in a non-catastrophic verification. Flight safety is to be judged solely on how well the programs do in the verification tests. A failure here generates considerable concern.
To summarize then, the computer software checking system and attitude is of the highest quality. There appears to be no process of gradually fooling oneself while degrading standards so characteristic of the Solid Rocket Booster or Space Shuttle Main Engine safety systems. To be sure, there have been recent suggestions by management to curtail such elaborate and expensive tests as being unnecessary at this late date in Shuttle history. This must be resisted for it does not appreciate the mutual subtle influences, and sources of error generated by even small changes of one part of a program on another. There are perpetual requests for changes as new payloads and new demands and modifications are suggested by the users. Changes are expensive because they require extensive testing. The proper way to save money is to curtail the number of requested changes, not the quality of testing for each.
One might add that the elaborate system could be very much improved by more modern hardware and programming techniques. Any outside competition would have all the advantages of starting over, and whether that is a good idea for NASA now should be carefully considered.
(emphasis mine)
Internationalization, done properly, only takes up disk space, it should have NO runtime overheads of any sort other than a fixed overhead that's unrelated to the number of translatable strings. IOW, internationalization should have O(1) runtime space cost.