SCSI -- not sure now -- it's parallel, but are transfer rates specified in bits or bytes? Now that I think of it, I can't remember!:-)
Parallel ports also do bytes not bits, but again -- I can't recall ever seeing a transfer rate spec.
Reel to reel tape densities were in bits per inch, but they usually wrote a character at a time (7 track, 6 + parity).
I seem to remember some of the holographic storage specualations discussing bits not bytes, but then media densities usually are reported in bits per square hoojiwich.
SCSI and parallel ports aren't, but USB is, I think FireWire is, modems are, etc. Since comm is bit at a time, bit speeds make sense.
Storage is almost byte oriented. Actually, disk drives are sector / block oriented, but that differs from drive to drive, making byte the common denominator.
Since it's on a track, it's reasonably close to the ground, and I guess they don't want to go supersonic that close. Probably the energy required rises steeply there, not to mention strutural strengthening. I imagine sonic booms reflecting off the ground can make for some nasty buffeting.
I know all about/usr/local, or/opt, but that's only fine for programs which *aren't* already in the package system. I'm talking about wanting different compile options for programs which alreaady have packages installed.
--
Maybe I should have said 18 :-)
on
$200 Linux PCs
·
· Score: 1
That being hex 12...
--
Good read, but little mention of Magic / Purple
on
The Code Book
·
· Score: 2
I know he's got a Brit slant, and he never claims to cover everything, but I was a bit disappointed to find so little coverage of breaking the Pacific war codes, arguably a more difficult job than the Atlantic Enigma. It would be very interesting to know as much about the Japanese cipher machines as Enigma; he has written the clearest explanation of Enigma I have ever seen.
I don't like package systems because they are only valid if you never stray, and there are too many programs out there that offer compile options other than what the packages use. And as soon as you install a tarball, it's outside the package system, and unknown to the package system, and the rot sets in.
Now that would be something. Maybe a hacker's dozen? Buy 16, get the 17th for free.
O rbuy as many as you need, and another for a spare, so when one of them dies, you just quickly configure its net address (or use DHCP in the first place) and you're back on line.
Heck, get two for each room, that way you have some hot standbys!
Do the search, follow the links, read the making of the myths. Like the man says, it's learning to type that does the trick in a switchover, not the keyboard itself. The horse is dead, flesh is stripped, bones have been pulverized, all that's left is the urban legend.
Certainly the spy agencies and secret police (yes, I include DEA FBI etc:-) will get these first, but it won't be long after they are available to everyone, and cheap too. (As an aside, the recent news about the Canadian cell phone company kowtowing to the FBI wiretap rules just amused me; it won't be long before computers the size of buttons will be able to be phones under Linux control, and there's bugger all the FBI can do about it.)
So now choose your favorite target: reporters planting these all over city hall, civil rights activists planting them around the local police stations, and nationwide -- ah, imagine the juicy into to come out of the national level bureaucracies, Congress, the FBI and DEA themselves...
It's the same with The Diamon Age motes floating around, David Brin's ubiquitous cameras, and so on. The big guns will have their monopoly for a very short time, and then they will have the last surprise of their very snoopy life.
Life will be really interesting. This is definitely a multi edged sword!
And if this event doesn't prove that it's time for the U.S. to go 100% metric, I don't know what will.
Your analytical skills are sorely lacking. It could just as easily be argued that 100% English is the way to go.
The problem was not using English instead of metric. It was the mixture.
This is not a laughing point. This goes straight to the heart of analytical skills. You are using the "facts" to prove your opinion, not looking at the evidence to see what conclusions are warranted. Think about this the next time you debug a program or system. It's a real life skill, and you just failed the test.
which is that the TPC-D test involves massive updates and queries all intermingled together, yet M$'s test did not use a single machine, but several, and transactions were directed at specific machines, rather than parceled out by a central server. Also, they had preloaded the database, so there wer no updates and it could well have been optimized for readback only.
At least, that's what I remember. I almost certainly have some of the details wrong. But I do remember they weren't even close to duplicating the effort, only the statistic. Apples and oranges at least.
Not that I completely agree with eBay, but their complaint (at least, their *public* complaint:-) is that these spiders cache obsolete information and slow down the auction site.
I can believe it to some extent. General purpose search engines always cache stuff and a lot of the results are so out of date that the pages have gone, servers have gone, etc.
But these are auction-specific search engines, so they *know* that caching results more than a few hours old is worse than useless; in fact, it would give the auction search engines a bad rep.
Which brings up eBay's second complaint. To keep from showing obsolete results, the search engines trawl often enough that it ties up the auction site itself.
Now it seems to me that one solution would be for auction sites to have a compact data file they update once an hour or three times a day or sufficiently often, in a format meant to be machine readable, expressly for these auction search engines. That way, the auction site would get the benefit of the search engine with minimum fuss.
Your basic premise is correct, and Micro$hit is just going nyahh nyahh here. But the problem has nothing to do with non-empty directories; I would hope that's illegal even on NT, unless NT also recursively deletes the contents.
A better UNIX example would be a dir to which you have write permission, with a file in it owned by somebody else. Whether or not "you" in this instance is root (which apparently corresponds to NTFS Full Control permission), UNIX will let the directory owner delete the file, on the basis that it's the owner's directory. The only difference between being root and being a regular user is that root can pretty much go to any directory regardless of owner.
Why NTFS would allow somebody to create indestructible inaccessible files in somebody else's directory is beyond me. I have read other articles on problems with NTFS and it doesn't sound like a particularly logical file system to me, more like they purposely wanted to be different just for the sake of being different and making porting difficult.
BTW, POSIX generally means Unix. Or that subset common to all Unices, the intersection of them, something liek that:-)
I'll get to your relocatable code question , but as an aside, you might want to check out Ecos from Cygnus. I haven't dealt with rom based code for several years now, so I don't know much about ecos. But it comes from Cygnus, is free source (not GPL; their variation on the Mozilla license), and who knows, it may even be ported to your setup.
In general, processors have two kinds of addresses for data and instructions: absolute and relative. Absolute is faster since no airithmetic is involved. A.o file has the symbol name, a static link resolves it immediately, and a dynamic linker resolves it at load/run time.
Relative branches are slower because of the arithmetic, but on some machines the instructions can be quite a bit shorter because a full address is not necessary. Of course, this itself may make enough of a speed difference to cancel the arithmetic, and the code size reduction may be worthwhile too. The linker probably has to compute relative distances at link time.
None of this helps directly with your request for BIOS code, but if you want that just to figure out how it copies code, you may not need it. If your processor supports relative addressing, you probably don't. Make sure you can do everything you want with relative addressing. Some processors are troublesome this way, at least memory says so, but I spent 7 years on just m68k, so I'm a bit hazy on others now.
Of course, you may still need absolute addressing if system subroutines are at absolute locations in low or high memory, and if you have memory mapped I/O.
In the old days, when they were NACA, and did advanced research in aeronautics, they did a fantastic job of fundamental research while staying out of the way of the commercializers.
JFK threw money at them and gave them the Apollo mission. The mindset changed to the bureaucratic stay in power syndrome they have had ever since.
What they need to do is get out of all commercial launches, get out of the shuttle business, go back to basic aeronautics and space research. Not science research that coincidentally "requires" them to have their own space fleet and just happens to crowd out private launchers, but space research. Deep Space 1 was a great idea -- ion engine, self navigating, etc. Delta Clipper, which could have been a wonderful X series into Single Stage To Orbit, was dropped.
There are several private efforts to create cheap launch services, yet they are not attracing funding. I believe a large part of that is the fear that NASA will get in the way yet again.
NASA has got to get out of the way of commercialization of launch services, and get back to basic research.
RCA COSMAC 1802 (have I got that right?!?) had no stack; all subroutine calls were corouties really, and left their return address in a register.
CDC 6600/7600 had marvelous interacting registers. Set A1-5 with an 18 bit address and the corresponding 60 bit X register was loaded from that location; set A6-7 and the X was stored to that location; following instructions executed in parallel with the transfer. I have seen many references to them as the first RISC machines, and this was mid 60s. Wonderful wonderful machines. They also had the PPUs to handle I/O and system control. Up to a dozen or so 12 bit computers. Actually one PPU which rotated thru a "barrel" of the dozen or so registers sets and memory banks, looking like separate slow processors. A lot of fun.
Old drum machine spun at 17000 rpm; 200 bands of 25 words aiece I think, decimal, or should I say biquinary (quibinary? Univac had it one way, IBM the other) where the 4 bits were 5-4-2-1 not 8-4-2-1. One gate per circuit card, vacuum tubes power supply, took an hour to spin down. We rewired the instruction set to give us new capabilities!
1620, another decimal machine, with a CRT hooked up so you could toggle the sense switches to play space war.
What assembler (and machine language:-) teaches is that a line of code is not just a line of code; I know far too many so called programmers who haven't got a clue that some lines are fast and efficient, some are slow and inept.
You learn how operations break up into smaller pieces. You learn that timing varies all over the map. You learn the details of how instructions work, and how that affects programs, for speed, size, clarity, modularity, expandibility.
You gain new respect for compilers and compiler writers. You gain an insight into what makes computers tick that has nothing to do with counting cycles and bytes. You become a much better compiler language programmer without having to worry about counting cycles and bytes, because you have learned the gestalt of computers. Only assembler and machine language teach that.
Certainly some programmers become excellent without ever knowing assembler, but I have met far too many who simply have no understanding deeper than syntax limits of the language of the day. I seriously believe that assembler should be the second language learned, preferably on 8 bit micros where the instruction set, timing and size, can be memorized just by using it. (The first language should be something like Logo, or Python, or maybe the new Rebol, where the goal is to find out if analyzing and debugging is something the student likes.)
As for PICs, I looked them up for a job interview a few years back. Same reaction as when I first saw Sparc and Alpha specs. Yay! another assembler (ahh the Alpha is sweet, especially the atomic r/w). Several cute tricks, but once you have a dozen assemblers under your belt, there are no surprises. 68K, Yay and Thank You Motorola! VLIW, Yay! Merced, Yay! They all have their tricks, and they are all fun.
There is only one exception, and that is the x86. It has no redeeming features. Disgusting registers, disgusting opcodes, and nothing interesting. Wrote a virtual emmory system for 386. What a pig dog!
Like any other human activity, there are lazy people, there are doers, and there are controllers; actually people are a combination of all three. Some doers do things by controlling others, but always with the end goal of getting things done. These people don't scare me, altho sometimes they annoy me:-) Soem doers have no interest in controlling.
And then there's the controllers. They have no goals other than controlling. Nothing they want done, other than being in charge. And since they know they are non-productive, they have to make their bosses, who somewhere up the line are doers, think they are doers themselves, or at least have some use as paper pushing managers, because doers don't want to hassle with management any more than necessary.
So these controllers need to generate activity and reports. What better way than this kind of snooping software? Never mind that a good manager would judge by end results. That kind of judgement requires long term observation and reasoned judgement. Controllers are ultimately cowardly, paranoid, and have termendous inferioty complexes. They know they are ultimately uselsss, so they have to work like heck to hide that with ridiculous reports. They can afford no criticism from below and have to direct all criticism from above to those below. They must shift blame elsewhere, and hope to get away with it as long as possible, before the doers above them get wise and realize the cost benefit ratio of a particular paper pushing controller is less than unity.
I suppose that's why they take a subset of all entrants, and the 48 hours is in a secure setting. Bet they don't publish the changes! Still sounds like fun tho. I look forward to the results and hearing reports from the contestants.
Slashdot Mirror
SCSI -- not sure now -- it's parallel, but are transfer rates specified in bits or bytes? Now that I think of it, I can't remember! :-)
Parallel ports also do bytes not bits, but again -- I can't recall ever seeing a transfer rate spec.
Reel to reel tape densities were in bits per inch, but they usually wrote a character at a time (7 track, 6 + parity).
I seem to remember some of the holographic storage specualations discussing bits not bytes, but then media densities usually are reported in bits per square hoojiwich.
Bottom line is, I don't know.
--
SCSI and parallel ports aren't, but USB is, I think FireWire is, modems are, etc. Since comm is bit at a time, bit speeds make sense.
Storage is almost byte oriented. Actually, disk drives are sector / block oriented, but that differs from drive to drive, making byte the common denominator.
--
Since it's on a track, it's reasonably close to the ground, and I guess they don't want to go supersonic that close. Probably the energy required rises steeply there, not to mention strutural strengthening. I imagine sonic booms reflecting off the ground can make for some nasty buffeting.
--
Linux being representative of a new tech *is* the point of this article. The new tech is free source software, exemplified by Linux:
How have today's successful technology firms, then, fallen into the "innovator's dilemma" with respect to Linux?
--
I know all about /usr/local, or /opt, but that's only fine for programs which *aren't* already in the package system. I'm talking about wanting different compile options for programs which alreaady have packages installed.
--
That being hex 12...
--
I know he's got a Brit slant, and he never claims to cover everything, but I was a bit disappointed to find so little coverage of breaking the Pacific war codes, arguably a more difficult job than the Atlantic Enigma. It would be very interesting to know as much about the Japanese cipher machines as Enigma; he has written the clearest explanation of Enigma I have ever seen.
--
You *NEVER* need to circunvent the package system
I don't like package systems because they are only valid if you never stray, and there are too many programs out there that offer compile options other than what the packages use. And as soon as you install a tarball, it's outside the package system, and unknown to the package system, and the rot sets in.
--
Now that would be something. Maybe a hacker's dozen? Buy 16, get the 17th for free.
O rbuy as many as you need, and another for a spare, so when one of them dies, you just quickly configure its net address (or use DHCP in the first place) and you're back on line.
Heck, get two for each room, that way you have some hot standbys!
Yeh, I see some potential here.
--
A sampler, so to speak? Something representative of all his work, not just certain phases or the best of?
--
http://lwn.net/1999/1007/a/wwo_2.4.html
I have seen other versions of this; this is allegedly the "final" version.
--
Do the search, follow the links, read the making of the myths. Like the man says, it's learning to type that does the trick in a switchover, not the keyboard itself. The horse is dead, flesh is stripped, bones have been pulverized, all that's left is the urban legend.
--
I am now asdfg1140. Works like a champ. Power to the people!
--
Certainly the spy agencies and secret police (yes, I include DEA FBI etc :-) will get these first, but it won't be long after they are available to everyone, and cheap too. (As an aside, the recent news about the Canadian cell phone company kowtowing to the FBI wiretap rules just amused me; it won't be long before computers the size of buttons will be able to be phones under Linux control, and there's bugger all the FBI can do about it.)
So now choose your favorite target: reporters planting these all over city hall, civil rights activists planting them around the local police stations, and nationwide -- ah, imagine the juicy into to come out of the national level bureaucracies, Congress, the FBI and DEA themselves...
It's the same with The Diamon Age motes floating around, David Brin's ubiquitous cameras, and so on. The big guns will have their monopoly for a very short time, and then they will have the last surprise of their very snoopy life.
Life will be really interesting. This is definitely a multi edged sword!
--
And if this event doesn't prove that it's time for the U.S. to go 100% metric, I don't know what will.
Your analytical skills are sorely lacking. It could just as easily be argued that 100% English is the way to go.
The problem was not using English instead of metric. It was the mixture.
This is not a laughing point. This goes straight to the heart of analytical skills. You are using the "facts" to prove your opinion, not looking at the evidence to see what conclusions are warranted. Think about this the next time you debug a program or system. It's a real life skill, and you just failed the test.
--
which is that the TPC-D test involves massive updates and queries all intermingled together, yet M$'s test did not use a single machine, but several, and transactions were directed at specific machines, rather than parceled out by a central server. Also, they had preloaded the database, so there wer no updates and it could well have been optimized for readback only.
At least, that's what I remember. I almost certainly have some of the details wrong. But I do remember they weren't even close to duplicating the effort, only the statistic. Apples and oranges at least.
--
Not that I completely agree with eBay, but their complaint (at least, their *public* complaint :-) is that these spiders cache obsolete information and slow down the auction site.
I can believe it to some extent. General purpose search engines always cache stuff and a lot of the results are so out of date that the pages have gone, servers have gone, etc.
But these are auction-specific search engines, so they *know* that caching results more than a few hours old is worse than useless; in fact, it would give the auction search engines a bad rep.
Which brings up eBay's second complaint. To keep from showing obsolete results, the search engines trawl often enough that it ties up the auction site itself.
Now it seems to me that one solution would be for auction sites to have a compact data file they update once an hour or three times a day or sufficiently often, in a format meant to be machine readable, expressly for these auction search engines. That way, the auction site would get the benefit of the search engine with minimum fuss.
--
See subject
:-) :-) :-) :-) :-)
:-)
--
Your basic premise is correct, and Micro$hit is just going nyahh nyahh here. But the problem has nothing to do with non-empty directories; I would hope that's illegal even on NT, unless NT also recursively deletes the contents.
:-)
A better UNIX example would be a dir to which you have write permission, with a file in it owned by somebody else. Whether or not "you" in this instance is root (which apparently corresponds to NTFS Full Control permission), UNIX will let the directory owner delete the file, on the basis that it's the owner's directory. The only difference between being root and being a regular user is that root can pretty much go to any directory regardless of owner.
Why NTFS would allow somebody to create indestructible inaccessible files in somebody else's directory is beyond me. I have read other articles on problems with NTFS and it doesn't sound like a particularly logical file system to me, more like they purposely wanted to be different just for the sake of being different and making porting difficult.
BTW, POSIX generally means Unix. Or that subset common to all Unices, the intersection of them, something liek that
--
I'll get to your relocatable code question , but as an aside, you might want to check out Ecos from Cygnus. I haven't dealt with rom based code for several years now, so I don't know much about ecos. But it comes from Cygnus, is free source (not GPL; their variation on the Mozilla license), and who knows, it may even be ported to your setup.
.o file has the symbol name, a static link resolves it immediately, and a dynamic linker resolves it at load/run time.
In general, processors have two kinds of addresses for data and instructions: absolute and relative. Absolute is faster since no airithmetic is involved. A
Relative branches are slower because of the arithmetic, but on some machines the instructions can be quite a bit shorter because a full address is not necessary. Of course, this itself may make enough of a speed difference to cancel the arithmetic, and the code size reduction may be worthwhile too. The linker probably has to compute relative distances at link time.
None of this helps directly with your request for BIOS code, but if you want that just to figure out how it copies code, you may not need it. If your processor supports relative addressing, you probably don't. Make sure you can do everything you want with relative addressing. Some processors are troublesome this way, at least memory says so, but I spent 7 years on just m68k, so I'm a bit hazy on others now.
Of course, you may still need absolute addressing if system subroutines are at absolute locations in low or high memory, and if you have memory mapped I/O.
--
In the old days, when they were NACA, and did advanced research in aeronautics, they did a fantastic job of fundamental research while staying out of the way of the commercializers.
JFK threw money at them and gave them the Apollo mission. The mindset changed to the bureaucratic stay in power syndrome they have had ever since.
What they need to do is get out of all commercial launches, get out of the shuttle business, go back to basic aeronautics and space research. Not science research that coincidentally "requires" them to have their own space fleet and just happens to crowd out private launchers, but space research. Deep Space 1 was a great idea -- ion engine, self navigating, etc. Delta Clipper, which could have been a wonderful X series into Single Stage To Orbit, was dropped.
There are several private efforts to create cheap launch services, yet they are not attracing funding. I believe a large part of that is the fear that NASA will get in the way yet again.
NASA has got to get out of the way of commercialization of launch services, and get back to basic research.
--
RCA COSMAC 1802 (have I got that right?!?) had no stack; all subroutine calls were corouties really, and left their return address in a register.
CDC 6600/7600 had marvelous interacting registers. Set A1-5 with an 18 bit address and the corresponding 60 bit X register was loaded from that location; set A6-7 and the X was stored to that location; following instructions executed in parallel with the transfer. I have seen many references to them as the first RISC machines, and this was mid 60s. Wonderful wonderful machines. They also had the PPUs to handle I/O and system control. Up to a dozen or so 12 bit computers. Actually one PPU which rotated thru a "barrel" of the dozen or so registers sets and memory banks, looking like separate slow processors. A lot of fun.
Old drum machine spun at 17000 rpm; 200 bands of 25 words aiece I think, decimal, or should I say biquinary (quibinary? Univac had it one way, IBM the other) where the 4 bits were 5-4-2-1 not 8-4-2-1. One gate per circuit card, vacuum tubes power supply, took an hour to spin down. We rewired the instruction set to give us new capabilities!
1620, another decimal machine, with a CRT hooked up so you could toggle the sense switches to play space war.
Fond memories indeed.
--
What assembler (and machine language :-) teaches is that a line of code is not just a line of code; I know far too many so called programmers who haven't got a clue that some lines are fast and efficient, some are slow and inept.
You learn how operations break up into smaller pieces. You learn that timing varies all over the map. You learn the details of how instructions work, and how that affects programs, for speed, size, clarity, modularity, expandibility.
You gain new respect for compilers and compiler writers. You gain an insight into what makes computers tick that has nothing to do with counting cycles and bytes. You become a much better compiler language programmer without having to worry about counting cycles and bytes, because you have learned the gestalt of computers. Only assembler and machine language teach that.
Certainly some programmers become excellent without ever knowing assembler, but I have met far too many who simply have no understanding deeper than syntax limits of the language of the day. I seriously believe that assembler should be the second language learned, preferably on 8 bit micros where the instruction set, timing and size, can be memorized just by using it. (The first language should be something like Logo, or Python, or maybe the new Rebol, where the goal is to find out if analyzing and debugging is something the student likes.)
As for PICs, I looked them up for a job interview a few years back. Same reaction as when I first saw Sparc and Alpha specs. Yay! another assembler (ahh the Alpha is sweet, especially the atomic r/w). Several cute tricks, but once you have a dozen assemblers under your belt, there are no surprises. 68K, Yay and Thank You Motorola! VLIW, Yay! Merced, Yay! They all have their tricks, and they are all fun.
There is only one exception, and that is the x86. It has no redeeming features. Disgusting registers, disgusting opcodes, and nothing interesting. Wrote a virtual emmory system for 386. What a pig dog!
--
Like any other human activity, there are lazy people, there are doers, and there are controllers; actually people are a combination of all three. Some doers do things by controlling others, but always with the end goal of getting things done. These people don't scare me, altho sometimes they annoy me :-) Soem doers have no interest in controlling.
And then there's the controllers. They have no goals other than controlling. Nothing they want done, other than being in charge. And since they know they are non-productive, they have to make their bosses, who somewhere up the line are doers, think they are doers themselves, or at least have some use as paper pushing managers, because doers don't want to hassle with management any more than necessary.
So these controllers need to generate activity and reports. What better way than this kind of snooping software? Never mind that a good manager would judge by end results. That kind of judgement requires long term observation and reasoned judgement. Controllers are ultimately cowardly, paranoid, and have termendous inferioty complexes. They know they are ultimately uselsss, so they have to work like heck to hide that with ridiculous reports. They can afford no criticism from below and have to direct all criticism from above to those below. They must shift blame elsewhere, and hope to get away with it as long as possible, before the doers above them get wise and realize the cost benefit ratio of a particular paper pushing controller is less than unity.
--
I suppose that's why they take a subset of all entrants, and the 48 hours is in a secure setting. Bet they don't publish the changes! Still sounds like fun tho. I look forward to the results and hearing reports from the contestants.
--