Don't worry, I missed the typo too, and I made it. I hade to read through the comments five times before I figured out that I was an idiot. I think I'll write that discovery down on a postit note for future reference.
Except of course the fact their method of verification worked at all invalidated it. After all, two separate, unattached pieces of tissue, even if taken the same creature, can hardly be considered to be the same organism. They may be genetically identical copies of each other, but they have the opportunity to develop separately. What verification is their that the giant fungus is not really a couple of dozen, slowly having developed and broken off from the original growth?
This may be a weird answer, but I learned with FutureBasic (version 3, I think) on a macintosh. First, let's get one thing out of the way: It's not basic. It's procedural, but it allows well-structured code. It allows really quick really powerful application development, but it's entirely coding, no silly point-and-build stuff. And I learned when I was eight; I had looked at C++, but I just wasn't ready for that yet. The editor is great (it's handling of tabs is still the best of any editor I've ever seen) and the usability is real. I really really really recommend it as the language for teaching children up to age 15 or so; beyond that I recommend Lisp, as the math (well, not math, perhaps formal logic) facilities are up for the task of Lisp, the learning is a bit more valuable, but creating usable apps is a bit harder.
Right, but I don't want it to run every couple of minutes. I want it to run every time that a write occurs to the file system, and I want a read to occur from all sources every time I make a request, and at least get a consistent response for a majority before data is considered read. And yes, connectivity is flaky, but if you have five data sources, and one of them is the local host, you only need to be able to access two out of four remote sites to have workable data. How often do you lose more than half the 'net? Also keep in mind that I'm not proposing this be done for applications or anything which needs rapid access, just for small but valuable data files.
Heh. Yes, I know you're joking, but a bit more info for you: I'm pretty sure that Columbia was the only one with a data recorder, or at least a data recorder of this type. It was a 'leftover' from the testing process, and not standard equipment on later shuttles.
Tar is good for preserving some data for a very long time. A good example is dinosaurs, although the technique has also been applied to various small mammals. The problem with using tar for something like the space shuttle missions is that the write bandwidth and latency are both very low. While the write bandwidth scales linear with the surface of the tar (and with the cube root of the volume of the tar), space missions are mass-limited and could carry only a very little tar. Also, the latency is a real issue, as most of the data stored during the mission would not have time to be fully written before the accident occured.
All I've really wanted for a while is a distributed raid system. When working on things like source code and documentation, I couldn't care less about disk speed... 10kb/s is more than enough most of the time. So why not have some server that I can run on about five computers around the world that automatically does raid mirroring of my document directories? Even with the overhead of five reads / five writes per operation, speed should still be an easy 100kb/s over a fast internet connection, and you could recover from a nuclear war without much difficulty. The only downside is the inability to do offline work (or rather, offline work would not be backed up immediately), but that's what ubiquitous wireless is for.
No, in the worst case you get arrested a local cop for something that the NCIC said you did. You go to jail for a few days, then the court assigns you a public defendent because you can't afford your own lawyer. The public defendent is convinced of your inherent worthlessness because your of Arab decent and makes only enough effort to defend you to avoid a mistrial, so you're sent to prison. Nah, not so bad.
I'd have to say that Wiki is much more suited to a collaborative environment than slash or k5. It allows not just addition of new ideas, but modification of existing ones.
Ram slots are expensive, though. Not only are they a lot of traces, but if you put a lot of them together it seriously screws up your signal quality on faster memory (reflections, etc). Really, 4 DIMM slots per memory channel is about all you can hope for on an affordable machine; my fancy 8-way server does 16 per channel, at the cost of additional latency. Now, Hammer is fun, in that a multiprocessor box has one memory channel per processor, rather than the constant one or two channels of current x86 machines. But for you and I, we're unlikely to get more than a 2-processor box, which means 4 dimm slots (2 per channel) for high-end DDR, or 8 dimm slots (4 per channel) if we're willing to go slower. Now, what AMD really needs, but AFAIK hasn't yet discussed, is two interleaved memory channels per processor... not only does that give you four channels in a two way box, and eight channels in a four way box, but it lets you get away with slightly slower memory without much of a performance hit. My ideal box would be four-way Hammer, two DDR266 or so channels per processor, 3 dimm slots per channel (reasonable for DDR266, pushing it for DDR333)... for a total of 24 slots. That compares favorably with the 32 slots in my current server. On the other hand, as I mentioned, I don't think that's too likely. A current four-way box is probably 8 dimm slots; two-way is either going to be four dimm slots, or maybe eight with slightly slower memory. On the other hand, 4GB dimm sticks were just announced a few days ago... so even four slots gives you 16GB of memory, enough for most current tasks. I really think that most PC's up to workstation class will stick with 4 dimm slots, 16GB memory max, for two processors.
Keep in mind that Apple is in a different situation than, say, Microsoft or Linux, when it comes to 64 bit chips. Ya see, Apple's 32 bit chips (well, Motorolla's, currently), suck rocks. I love 'em, but let's face it, they do. And nobody's going to come along and slap down a 32-bit PPC chip that can compete with anything decent, ever. So if Apply wants to outgrow the G4 (and I'm sure they do), their choices are complete platform change to something like MIPS or x86 and stay 32 bits, but lose all backwards compatibility, or go 970 (or motorolla G5, should it ever exist) and go 64 bits, but keep backwards compatibility through 32 bit mode. So for Apple, the compatibility reason turns out to be in favor of 64 bits, unlike with Windows. And the G4 has earned its retirement by now.
Best part is I was born in '82. But I still play with the old stuff... there's a lot you can learn from it. And it's surprisingly easy to make mercury delay line memory these days... anyone with access to basic glass working, a liter of mercury, and a good microphone / speaker combo can easily get 1-5 bits per centimeter; not professional level, but more than enough to learn the ideas. Do a base 1 adder, whatever. Good stuff.
An array of card punchers. A very wide array. Or just a piezo speaker, and store it in a mercury delay line until you have time to write it to disk. Hmm... then again, room temperature would give far too much brownian motion for coherence at that bandwidth in mercury. Metallic hydrogen delay line, then.
More nitpicking, yay! (a) If we assume base 10, it's actually ~0.9031 (log[10](8)) orders of magnitude off, as this is a logarithmic measure; (b) why are we assuming base 10? Base 2, which makes a lot more sense for this thing, gives us an even three orders of magnitude off; as a comment below mentioned, octal gives exactly one.
The computer science textbook I've learned most from was published in 1959, I think. The technology may be obsolete, but until the physical nature of the universe and the human mind changes, the concepts are still valid and valuable.
Yeah, my ImageWriter II finally died about a year ago (the feed belt for the ribbon cartridge snapped). Fortunately, my ImageWriter I is a tougher beast... no color, but absolutely wonderful for rough-drafting my thesis, printing from my iBook. The noise gives you a feeling of accomplishment.
No, he was asking why we were at war, not what the government said. If you believe what the government says (whether you support the war or not), you have more serious problems.
Well, yes. And that's the kind of dependency that makes some of us use colorforth. But I do find less weirdness, certainly not none, with OS X than XP.
Can you use a bluetooth headset with the powermac? I'd buy both a powermac and a bluetooth phone this week if I could switch a sound stream source from one to the other easily.
I suspect the head-scratching was not over how to disable font smoothing, but rather why the hell that would influence video capture and editing in the first place. This is the kind of unexpected, undesirable dependency that makes some of us use macs.
Slashdot Mirror
Don't worry, I missed the typo too, and I made it. I hade to read through the comments five times before I figured out that I was an idiot. I think I'll write that discovery down on a postit note for future reference.
printf allocates money. Use fprintf directed to stderr, which doesn't buffer output. :-)
Except of course the fact their method of verification worked at all invalidated it. After all, two separate, unattached pieces of tissue, even if taken the same creature, can hardly be considered to be the same organism. They may be genetically identical copies of each other, but they have the opportunity to develop separately. What verification is their that the giant fungus is not really a couple of dozen, slowly having developed and broken off from the original growth?
This may be a weird answer, but I learned with FutureBasic (version 3, I think) on a macintosh. First, let's get one thing out of the way: It's not basic. It's procedural, but it allows well-structured code. It allows really quick really powerful application development, but it's entirely coding, no silly point-and-build stuff. And I learned when I was eight; I had looked at C++, but I just wasn't ready for that yet. The editor is great (it's handling of tabs is still the best of any editor I've ever seen) and the usability is real. I really really really recommend it as the language for teaching children up to age 15 or so; beyond that I recommend Lisp, as the math (well, not math, perhaps formal logic) facilities are up for the task of Lisp, the learning is a bit more valuable, but creating usable apps is a bit harder.
Right, but I don't want it to run every couple of minutes. I want it to run every time that a write occurs to the file system, and I want a read to occur from all sources every time I make a request, and at least get a consistent response for a majority before data is considered read. And yes, connectivity is flaky, but if you have five data sources, and one of them is the local host, you only need to be able to access two out of four remote sites to have workable data. How often do you lose more than half the 'net? Also keep in mind that I'm not proposing this be done for applications or anything which needs rapid access, just for small but valuable data files.
Heh. Yes, I know you're joking, but a bit more info for you: I'm pretty sure that Columbia was the only one with a data recorder, or at least a data recorder of this type. It was a 'leftover' from the testing process, and not standard equipment on later shuttles.
Tar is good for preserving some data for a very long time. A good example is dinosaurs, although the technique has also been applied to various small mammals. The problem with using tar for something like the space shuttle missions is that the write bandwidth and latency are both very low. While the write bandwidth scales linear with the surface of the tar (and with the cube root of the volume of the tar), space missions are mass-limited and could carry only a very little tar. Also, the latency is a real issue, as most of the data stored during the mission would not have time to be fully written before the accident occured.
All I've really wanted for a while is a distributed raid system. When working on things like source code and documentation, I couldn't care less about disk speed... 10kb/s is more than enough most of the time. So why not have some server that I can run on about five computers around the world that automatically does raid mirroring of my document directories? Even with the overhead of five reads / five writes per operation, speed should still be an easy 100kb/s over a fast internet connection, and you could recover from a nuclear war without much difficulty. The only downside is the inability to do offline work (or rather, offline work would not be backed up immediately), but that's what ubiquitous wireless is for.
Is zero a vowel?
At least whitehouse.com doesn't have to worry!
No, in the worst case you get arrested a local cop for something that the NCIC said you did. You go to jail for a few days, then the court assigns you a public defendent because you can't afford your own lawyer. The public defendent is convinced of your inherent worthlessness because your of Arab decent and makes only enough effort to defend you to avoid a mistrial, so you're sent to prison. Nah, not so bad.
I'd have to say that Wiki is much more suited to a collaborative environment than slash or k5. It allows not just addition of new ideas, but modification of existing ones.
Hm. We use WebCT here and I've always rather liked it. Safari works for all features, and lynx works with everything but the fanciest.
Ram slots are expensive, though. Not only are they a lot of traces, but if you put a lot of them together it seriously screws up your signal quality on faster memory (reflections, etc). Really, 4 DIMM slots per memory channel is about all you can hope for on an affordable machine; my fancy 8-way server does 16 per channel, at the cost of additional latency. Now, Hammer is fun, in that a multiprocessor box has one memory channel per processor, rather than the constant one or two channels of current x86 machines. But for you and I, we're unlikely to get more than a 2-processor box, which means 4 dimm slots (2 per channel) for high-end DDR, or 8 dimm slots (4 per channel) if we're willing to go slower. Now, what AMD really needs, but AFAIK hasn't yet discussed, is two interleaved memory channels per processor... not only does that give you four channels in a two way box, and eight channels in a four way box, but it lets you get away with slightly slower memory without much of a performance hit. My ideal box would be four-way Hammer, two DDR266 or so channels per processor, 3 dimm slots per channel (reasonable for DDR266, pushing it for DDR333)... for a total of 24 slots. That compares favorably with the 32 slots in my current server. On the other hand, as I mentioned, I don't think that's too likely. A current four-way box is probably 8 dimm slots; two-way is either going to be four dimm slots, or maybe eight with slightly slower memory. On the other hand, 4GB dimm sticks were just announced a few days ago... so even four slots gives you 16GB of memory, enough for most current tasks. I really think that most PC's up to workstation class will stick with 4 dimm slots, 16GB memory max, for two processors.
Keep in mind that Apple is in a different situation than, say, Microsoft or Linux, when it comes to 64 bit chips. Ya see, Apple's 32 bit chips (well, Motorolla's, currently), suck rocks. I love 'em, but let's face it, they do. And nobody's going to come along and slap down a 32-bit PPC chip that can compete with anything decent, ever. So if Apply wants to outgrow the G4 (and I'm sure they do), their choices are complete platform change to something like MIPS or x86 and stay 32 bits, but lose all backwards compatibility, or go 970 (or motorolla G5, should it ever exist) and go 64 bits, but keep backwards compatibility through 32 bit mode. So for Apple, the compatibility reason turns out to be in favor of 64 bits, unlike with Windows. And the G4 has earned its retirement by now.
Best part is I was born in '82. But I still play with the old stuff... there's a lot you can learn from it. And it's surprisingly easy to make mercury delay line memory these days... anyone with access to basic glass working, a liter of mercury, and a good microphone / speaker combo can easily get 1-5 bits per centimeter; not professional level, but more than enough to learn the ideas. Do a base 1 adder, whatever. Good stuff.
An array of card punchers. A very wide array. Or just a piezo speaker, and store it in a mercury delay line until you have time to write it to disk. Hmm... then again, room temperature would give far too much brownian motion for coherence at that bandwidth in mercury. Metallic hydrogen delay line, then.
More nitpicking, yay! (a) If we assume base 10, it's actually ~0.9031 (log[10](8)) orders of magnitude off, as this is a logarithmic measure; (b) why are we assuming base 10? Base 2, which makes a lot more sense for this thing, gives us an even three orders of magnitude off; as a comment below mentioned, octal gives exactly one.
I have a dream. Some day the editors will learn the difference between a bit and a byte. Or I'll byte a bit of their heads off. [grumble]
The computer science textbook I've learned most from was published in 1959, I think. The technology may be obsolete, but until the physical nature of the universe and the human mind changes, the concepts are still valid and valuable.
Yeah, my ImageWriter II finally died about a year ago (the feed belt for the ribbon cartridge snapped). Fortunately, my ImageWriter I is a tougher beast... no color, but absolutely wonderful for rough-drafting my thesis, printing from my iBook. The noise gives you a feeling of accomplishment.
No, he was asking why we were at war, not what the government said. If you believe what the government says (whether you support the war or not), you have more serious problems.
Well, yes. And that's the kind of dependency that makes some of us use colorforth. But I do find less weirdness, certainly not none, with OS X than XP.
Can you use a bluetooth headset with the powermac? I'd buy both a powermac and a bluetooth phone this week if I could switch a sound stream source from one to the other easily.
I suspect the head-scratching was not over how to disable font smoothing, but rather why the hell that would influence video capture and editing in the first place. This is the kind of unexpected, undesirable dependency that makes some of us use macs.