Having multiple transactions active does not reduce the recursion. Recursive cloning of blocks is reduced by re-use, that is, by having large enough transactions that the same block may be updated many times, and not require branching at each update. Since having large transactions requires large flushes, the phasing is helpful, but not directly.
Recursion could also be reduced by maintaining allocation information near the data in the inode/file tree. Since a transaction only involves cloning blocks and saving the resultant allocation changes, it would be possible to localize an entire transaction at a node fairly far down the tree. The only reason that the metaroot has to be cloned and updated now is that the allocation table is linked there.
i.e.
The current tree structure:
metaroot
allocation table
subtable 1
subtable 2*
...
inodes
inodes 2
inodes 3
index block
...data
index 2
...data2*
Changing data2 above would require changing something in, say, subtable 2 above. Since changing = moving, we recurse up (from the nodes marked with "*" above), generating cloned blocks with new pointers, until we identify a common parent node which can be updated in *one* atomic operation. In the above picture, that one block is the metaroot.
The "*" nodes have a common parent at the inode1 block. We clone data1 into a new block listed in allocation1, and clone parent nodes until we find ourselves at inode1. At this point, we can flush the cloned blocks, and then overwrite inode1 with pointers to the new subtrees in one atomic operation.
The idea in doing this is that free space tracked at each node would be close to the data at the node, so that data locality would be maintained, or at least helped. I'm not sure how well space could be managed in such a framework, however.
I read about tux2 a few weeks ago, and noticed that it was implementing an algorithm I had read about a few weeks before, in a book on database architecture. Hopefully the discovery of some prior art will counter any patent claims.
Tux2's reliability algorithm essentially goes as follows:
1. At the beginning of a transaction, the "metablock" (including the block allocation table) at the root of the filesystem tree is copied into a buffer.
2. Whenever a block in a file is updated, the updated image of the block is written to a newly allocated block, and the "new" metablock is updated with the new allocation. Blocks pointing to the old block may also be updated, in recursive fashion, eventually copying and updating an entire subtree from the original. The blocks in the "old" subtree are marked as free in the new metablock. The newly allocated blocks can live in memory, but must be written to disk before commit.
3. At commit time, the new subtree replaces the old one. This operation simply involves overwriting the original metablock with a new one, which contains pointers to the new subtree as well as to the other subtrees which have not changed. If this operation does not complete, the complete picture of the old metablock, the old subtree linked to it, and free blocks where the new subtree was written, is maintained. If the operation does complete, the new image of the filesystem with the new, updated subtree, and free blocks where the old subtree used to be, is obtained.
This is a good algorithm, and it's the only way to achieve atomicity and reliability without any logging, but it does have a few tradeoffs. Each update necessitates allocating a new block, so, for instance, changing one byte in the middle of a 2G, contiguous file will require allocating a block at least 1G away (and putting a hole where the old block was). There is also a ripple effect as pointers are updated up the tree, so changing one byte of data may will mean cloning a block, then cloning the blocks that point to the block, and so on up to the root.
There's already a simple number to determine if memory bandwidth is a limiting factor: the percentage of memory accesses which are satisfied by the cache. Just about every database uses this statistic (for memory vs. disk accesses, not cache vs. RAM) as a measure of how well-tuned the installation is. For DDR, if 90% of the memory accesses are found in the cache, that leaves only 10% for the RAM to show its stuff on.
Given a sequence of memory accesses (e.g. in a memory benchmark), and the sizes of L2 and L1 caches, it's straightforward to calculate which will require main-memory reads, and which will not. For instance, if your cache size is 512kb, and you're getting a memory location that isn't among the 512k most recently accessed addresses, then you're going to incur a RAM hit (with slight alterations for associative caches, but the idea is the same).
Big scan or copy operations, where each address is only accessed once, will reduce the cache hit ratio to zero (and fill up the cache with useless data).
I suspect that these benchmarks are getting a cache hit ratio in the 80-90% range, which would explain the lack of dramatic improvement. But since the testers don't state this number, it's difficult to see if DDR is giving the improvement expected.
The benchmarks that I've seen for DDR on video cards have usually been able to highlight where DDR gives a big improvement, eg Quake at 1600x1200, and where it doesn't, such as 640x480 with 16-bit color.
The thing would fly perfectly well without an anchor; it's just a matter of putting it in a stable orbit with one end of the cable near the surface. It could be kept out of the lower atmosphere, and if needed a small difference from geosynchronous orbit would allow it to circle the equator slowly. One could also put aerodynamic forces to good use in adjusting the thing down or up.
Anchoring it to the earth would only be necessary if more downward force is needed, but it seems to me that down-force is to be avoided. Keeping the thing up with minimal additional tension in the cable would be better.
One should also look at what happens if the cable breaks. The greater the tension, the greater the energy released, and the larger the perturbation on the circular orbit. If the thing can be kept up without a lot of external force (i.e. yanking on the string), it's probably more stable.
Unfortunately one of the failings of slashdot (and the government) is that simplicity is moderated down. I think the question that most people are answering here is something like:
What big-government, over-engineered, deadly, polluting, land-wasting, oversubsidized mess can a bunch of technology-obsessed gadget freaks create to soak up tax money for the next 50 years?
Look up the "electric vehicle tax credit" to get an idea. ZEV's only count if they're not bicycles.
There was an article about the I-DNS method in several publications last week. Apparently the power-that-be (internic etc.) are considering adopting this standard. The idea is to use the usual 7 or 8 bit domain format, but lay unicode on top of it using a UTF-5 encoding. This encoding represents unicode characters using ascii [0-9A-Z], so zhongguo.com will map to an 8 bit string like G61H890.com in the DNS database.
This looks like a good idea, but it requires some work on the client end to generate UTF-5 lookup requests, and display urls correctly. I'm not sure what an anchor tag will look like in this system, i.e. whether the domain should be in the page's native encoding, or utf-5.
In any case. with a little bit of hex arithmetic (see the site for info) you can now domain squat in dozens of languages.
If perl were written like Japanese, it would have different forms depending on the computer's relationship to the coder. If the computer were older or higher in social status than the coder, the coder would have to use elaborate formal endings on all suggestions (commands would be forbidden). If the computer were younger or lower in social status, the coder would be able to use short, direct commands, and would not have to address the computer by title, or bow after each statement.
Men and women would also have different vocabularies. It would be considered improper for a male to use "Ladies' Perl" in most computer environments (except perhaps the Mac).
I've never understood working on a CRT in a darkened area. At best I end up with a whitish rectangle burned into my retinas at the end of the day.
It seems like most people don't like reflections of lighting fixtures or windows (the architectural kind), or glaring fixtures in the periphery of their vision. The reflection problem is easy to solve by tilting the monitor down slightly. The peripheral vision problem is solved by shielding lights so that they shine downward instead of to the sides. I'm not sure why people buy fixtures that produce a small amount of light downwards, and a huge amount of glare to the side and even upwards, but they do (especially outdoor lights, see www.darksky.org for examples). My office got partway to a solution by buying fluorescents with side shields, but the shields still allow a lot of light through in the 0-30 degrees-from-horizontal range. A little late-night work with tape or aluminum foil will fix these.
In any case, the lights directly above a monitor are not much of a problem. Darkening or tenting an entire cubicle just to avoid side glare seems like throwing out the baby with the bathwater. It puts the eyes into a highly dilated (i.e. poor depth of field) state, with dark adaptation taking 20-30 minutes to achieve maximum sensitivity. A few seconds of bright light will undue this adaptation. It also means tiny lights like LED's or light leaks will become glare sources themselves.
A while ago I posted some C code about the value of xor in swapping int's, etc., but some of the followups noted that most of it wouldn't compile. The reason is that ANSI C and C++ have moved away from K&R and made most type abuses illegal.
That got me to thinking about C in general, and the values that got me interested in it in the first place.
When I took up C I had already learned several high-level languages like BASIC, Pascal, and even APL and some Lisp. C immediately stood out, because it had tight integration with hardware, based on an abstract, but very accurate, Von-Neuman-type processor and memory model. The basic goal of C was to do everything that assembler did, with similar tightness of code and familiarity with registers, bit sizes, and machine addresses. Unfortunately, the prevailing trend was to take C and make it a higher-level and not a lower-level language.
However, these days, just about all processors are pipelined or multi-pipelined, and C code is hacked to pieces by the compiler or the on-chip optimizer. That's handy, but, in effect, C and even many assembly languages have become interpreted! The IA-64 will pull C code into separate, independent instruction streams, based on dependency and dataflow analysis. Crusoe will do speculative execution and even backtracking on unsuccessful branches, going so far as to do a rollback on memory locations, in cache.
That's all fine and dandy, but I wonder if there are features there that could be put under more programmer control. Maybe there are some new #pragma'sthat I don't know about, but still I see C as getting farther and farther behind the hardware model.
As a few naive suggestions, here are some ideas I have:
Tagging statements to designate which pipeline they go into. This is what IA-64 compilers do anyway, so why not us! (maybe we can, but I haven't checked).
adding cache control statements to variables - eg lock in cache, pageable, or page immediately (useful for scans, where,say, 2G of RAM is being scanned one byte at a time - there's no reuse). Oddly enough, I got this one from Oracle, which has this option for certain table operations.
More machine-level operators. I don't know what these would be, but anything bitwise would qualify.
I can't really see the big deal. I think it's meant to be sort of an extensible 5GL, i.e. a user-defined "intention" language combined with some user-defined heuristics to generate execution plans, and, presumably, a solution generator which applies rules and attempts to meet the goal or "intention" supplied by the user. This sounds a lot like just about every AI program ever written, which is why things like Scheme were developed.
For a mature example, look at Macsyma or Mathematica. These are extensible algebraic tools which have extensible rule sets, and "intentions" which are stated in mathematical expressions. A massive search engine powers the system by applying rules and attempting to construct a reduced or simplified expression from the original. These are handy (in fact I think calculators now use a simplified version), but not exactly a dream to program. For one thing, the algorithm to generate solutions meets the textbook definition of "intractable".
I think in the example of legacy code, the idea is to treat the FORTRAN or whatever as natural language and re-create all of the semantics of the compiler in some sort of rule base, and then go to town by adding to or modifying the ruleset to extend the domain. This seems like a hopeless endeavor.
As a kicker let me leave you with this quote, the result, apparently, of 4-5 years of intense IP research:
Many simple defines, such as #define foo 2, which would have been classified
as a constant definition by Notkin et al, instead turned out to be instances of parameter passing!
This is nothing new. I was arrested on Rodney King Day in SF while walking home from my job as a riot instigator at PG&E. The charge was apparently violating a 9pm emergency curfew; the only problem was that it was around 7-8 pm that I was rounded up, along with a bunch of Japanese tourists and a guy that had been using a pay phone on the street.
Everyone was held until 12:30 am, when we were cuffed and taken to a garage in the Mission, with a couple of porta-potties and a pool of water on the floor. We never received any water, food, warm clothing, or access to a telephone; we were cut off from the world entirely. Eventually around 6:30 I was fingerprinted and photographed and released onto the street to find my own way home.
A few years later a guy I worked with was beaten and arrested for "assaulting a police officer" because he had helped a photographer take pictures of police arresting people. The only problem was that this gentleman had polio, and couldn't really assault anyone.
Anyone who thinks that police have the resources or the ability to treat people fairly in a crowd-control situation is obviously deluded. Society works by hiring as few police as possible, and looking the other way when these police resort to mass round-ups, perjury, and excessive force to do their jobs and defend themselves.
PacBell offered me this a few weeks ago. They balked on my Linux box, but I adeptly changed my tune to get the Win98 "support".
The only problem is that they haven't delivered anything yet, and this is the second time we've ordered DSL at our current address (the first order evaporated, even though they're billing me for it).
Word to the wise: You may want to get the self-install option no matter what. The last PacBell guy to install DSL at our old apartment did the following:
failed to bring tools.
borrowed my wife's staple gun to run the wire all around the apartment, through doorways, around moldings, etc., using office staples.
miswired it, or apparently put a staple through the wire at some point, because it took 3 repair runs to stop the random carrier losses.
Things Korea has that the US doesn't: 1. cell phone coverage in the subway 2. a Starcraft TV show, with two players going at it, and commentators. 3. Scented business suits 4. Really small cell phones 5. A TV channel for Korean chess (Paduk). 6. The Turtle boat 7. The world's longest lava tube 8. Heated floors. Now that's technology.
napa cabbage salt red pepper garlic ginger sardine juice (sometimes)
The cabbage is diced and salted, then mixed with all the other stuff and placed in a cool, dry place for fermentation. Traditionally it's buried in a pot to keep the temperature in the right range.
There was an article in the WSJ a while back about the whole air cellular thing. It covered the FCC vs. FAA regulation, the lack of any evidence ever of a cell phone or computer interfering with a plane, etc.
One thing they mentioned is that those egregiously expensive AirFones are just cell phones with the base stations farther apart. For that we pay 10-20x higher fees.
However if there is some heretofore undiscovered interference found, then we logically should refuse to fly on airlines with AirFones, no?
Let's all stand by and watch while each airplane is grounded for re-testing. Until that happens I'll take this with a grain of salt.
That's another old-IBMism that I had completely forgotten about - an overemphasis on status by association. One thing I noticed right away when I started my job delivering mail at IBM in the 80's was that everyone there felt like their shit didn't stink, not due to their own merits, but due to the company's. It was thought that working at IBM was a kind of Nirvana, unlike any work experience anywhere (something I see in the MS recruiting ads all over downtown). Actually it was a lot like the post office.
That's a major part of what dragged IBM under. Success has an irresistable attraction for the mediocre, and they climbed aboard IBM in spades, and formed a company largely in their own image. It took a severe bludgeoning by the market to set them straight (and several rounds of layoffs).
Over on Salon there are some articles about the differences between the IBM case and the MS case, and, to summarize the last 10-20 years, I would say that MS was passed the baton by IBM, and became IBM in much less time than IBM took, but the DOJ also got through the antitrust part much faster than it did with IBM, due to its prior experience with the business model.
Looking at MS today, and dealing with some of the parts of the monolith, it's easy for me to see the resemblances to IBM in the 80's - dominant market position, booming profits, and top people, but also an overbearing, creeping internal stagnation that leaves people looking forward to the salad bar at lunch more than the workday.
The reasons for this sort of decline are easier to see in hindsight, but the basic fact is that a monopoly has no reason to innovate or grow beyond a certain point. It becomes a virtual reality - new products are only expected to work with other company products, deadlines are only vaguely necessary, and the external, chaotic world becomes less and less relevant. (For example, I took a trip up to MS a few months ago, and, judging from the posters on the walls, what was their major concern? Software piracy! As if a bunch of engineers in an ugly office park were going to do something about it.)
The tragic effect of this isolation, and one that IBM went through in the early 90's, is that the good tech gets shunned along with the bad stuff. A lot of the top people that IBM hired ended up watching great, enterprise-grade software and hardware go down the toilet, while shoddy, overhyped substitutes were pushed by dodgy competitors. Part of that was human nature (and lower prices), but the less-seen reason was the the marketing process had become disconnected from customers, and the tech wasn't able to make a difference to the consumer. It's one thing to have the best disk drive in the world, but another thing to have the best drive that people can plug into their PC's, Macs, or Sun workstations (or MP3 players).
Microsoft is pretty close to that stage now. Putting great tech into Word or NT is good, but selling the same stuff independently is better, and that's a scenario that most people being hired by MS today will never see. IBM learned its lesson late, but they now see that opening up interfaces isn't giving away the farm. People still buy all-IBM when they want tightly integrated systems with high reliability, but they also mix and match to get unique things that IBM does well.
The appeals court can do what it wants; the fact is that the people who need to know what MS has been doing, now know, and will apply this knowledge as appropriate in the future. I have no qualms about admitting that IBM was a monopoly (even though I have a lot of ties to the company), and I think that MS has some growing up to do before it can admit that it has some bad elements. The fact is, management let a lot of people down. I've often bashed MS in the past, but I hoped deep down that the charges were more illusion than fact. However purposeful sabotage of competitors just doesn't feel right, and one day MS will be a better place to work if these practices are stopped.
You need to remember that almost everything slashdot serves is user content, which is constantly being added-to by thousands of rambling geeks. All this has to be ingested, stored, and then threaded/sorted and filtered (by threshold) on the way out - that takes a lot of disk, memory, and cycles. Caching helps, but each additional post on a thread will invalidate the cache and necessitate regeneration.
Add to that the ad serving, graphics, and so on. I don't know how much tracking they do, but ads usually only pay for each unique user - loading the same ad on the same user's screen ten times only counts for one impression. So most sites have to set a cookie just to avoid double-billing, and check it on each pageload to rotate the ads correctly. That adds cpu and memory too.
There are several newsgroups for netwinder dev issues.
I was on the mailing lists that preceded these, and the main issue I can recall was struct alignments. A lot of code expects things like
struct { char a; char b; char c; char d }
to fit into four bytes, when 4-byte alignment may push it to 16.
Re:Experience with MySQL with Ciritcal Role
on
Why Not MySQL?
·
· Score: 2
I could go on and on about both sides here, but let it suffice to say that there are no absolutes in software, only tradeoffs. MySQL lacks certain features of other DBMS's, but in many cases it may be sufficient to implement these features, such as transactions, rollbacks, etc., in application software rather than spending 100k/yr. on Oracle. However, beyond a certain point, the cost of implementing and maintaining these safeguards may exceed the cost of a DBMS that already includes them.
Slashdot Mirror
X = { the root node } union { y: y is a child of some node in X }
This is perfectly well-defined; it's just a matter of getting SQL to handle it, as is done in SQL3.
Having multiple transactions active does not reduce the recursion. Recursive cloning of blocks is reduced by re-use, that is, by having large enough transactions that the same block may be updated many times, and not require branching at each update. Since having large transactions requires large flushes, the phasing is helpful, but not directly.
...
...data
...data2*
...etc.
Recursion could also be reduced by maintaining allocation information near the data in the inode/file tree. Since a transaction only involves cloning blocks and saving the resultant allocation changes, it would be possible to localize an entire transaction at a node fairly far down the tree. The only reason that the metaroot has to be cloned and updated now is that the allocation table is linked there.
i.e.
The current tree structure:
metaroot
allocation table
subtable 1
subtable 2*
inodes
inodes 2
inodes 3
index block
index 2
Changing data2 above would require changing something in, say, subtable 2 above. Since changing = moving, we recurse up (from the nodes marked with "*" above), generating cloned blocks with new pointers, until we identify a common parent node which can be updated in *one* atomic operation. In the above picture, that one block is the metaroot.
If instead we have something like this:
metaroot
inode1
allocation1*
index1
index2
data1*
inode2
The "*" nodes have a common parent at the inode1 block. We clone data1 into a new block listed in allocation1, and clone parent nodes until we find ourselves at inode1. At this point, we can flush the cloned blocks, and then overwrite inode1 with pointers to the new subtrees in one atomic operation.
The idea in doing this is that free space tracked at each node would be close to the data at the node, so that data locality would be maintained, or at least helped. I'm not sure how well space could be managed in such a framework, however.
I read about tux2 a few weeks ago, and noticed that it was implementing an algorithm I had read about a few weeks before, in a book on database architecture. Hopefully the discovery of some prior art will counter any patent claims.
Tux2's reliability algorithm essentially goes as follows:
1. At the beginning of a transaction, the "metablock" (including the block allocation table) at the root of the filesystem tree is copied into a buffer.
2. Whenever a block in a file is updated, the updated image of the block is written to a newly allocated block, and the "new" metablock is updated with the new allocation. Blocks pointing to the old block may also be updated, in recursive fashion, eventually copying and updating an entire subtree from the original. The blocks in the "old" subtree are marked as free in the new metablock. The newly allocated blocks can live in memory, but must be written to disk before commit.
3. At commit time, the new subtree replaces the old one. This operation simply involves overwriting the original metablock with a new one, which contains pointers to the new subtree as well as to the other subtrees which have not changed. If this operation does not complete, the complete picture of the old metablock, the old subtree linked to it, and free blocks where the new subtree was written, is maintained. If the operation does complete, the new image of the filesystem with the new, updated subtree, and free blocks where the old subtree used to be, is obtained.
This is a good algorithm, and it's the only way to achieve atomicity and reliability without any logging, but it does have a few tradeoffs. Each update necessitates allocating a new block, so, for instance, changing one byte in the middle of a 2G, contiguous file will require allocating a block at least 1G away (and putting a hole where the old block was). There is also a ripple effect as pointers are updated up the tree, so changing one byte of data may will mean cloning a block, then cloning the blocks that point to the block, and so on up to the root.
There's already a simple number to determine if memory bandwidth is a limiting factor: the percentage of memory accesses which are satisfied by the cache. Just about every database uses this statistic (for memory vs. disk accesses, not cache vs. RAM) as a measure of how well-tuned the installation is. For DDR, if 90% of the memory accesses are found in the cache, that leaves only 10% for the RAM to show its stuff on.
Given a sequence of memory accesses (e.g. in a memory benchmark), and the sizes of L2 and L1 caches, it's straightforward to calculate which will require main-memory reads, and which will not. For instance, if your cache size is 512kb, and you're getting a memory location that isn't among the 512k most recently accessed addresses, then you're going to incur a RAM hit (with slight alterations for associative caches, but the idea is the same).
Big scan or copy operations, where each address is only accessed once, will reduce the cache hit ratio to zero (and fill up the cache with useless data).
I suspect that these benchmarks are getting a cache hit ratio in the 80-90% range, which would explain the lack of dramatic improvement. But since the testers don't state this number, it's difficult to see if DDR is giving the improvement expected.
The benchmarks that I've seen for DDR on video cards have usually been able to highlight where DDR gives a big improvement, eg Quake at 1600x1200, and where it doesn't, such as 640x480 with 16-bit color.
The thing would fly perfectly well without an anchor; it's just a matter of putting it in a stable orbit with one end of the cable near the surface. It could be kept out of the lower atmosphere, and if needed a small difference from geosynchronous orbit would allow it to circle the equator slowly. One could also put aerodynamic forces to good use in adjusting the thing down or up.
Anchoring it to the earth would only be necessary if more downward force is needed, but it seems to me that down-force is to be avoided. Keeping the thing up with minimal additional tension in the cable would be better.
One should also look at what happens if the cable breaks. The greater the tension, the greater the energy released, and the larger the perturbation on the circular orbit. If the thing can be kept up without a lot of external force (i.e. yanking on the string), it's probably more stable.
A chance to chain-gun the filmmaker.
Unfortunately one of the failings of slashdot (and the government) is that simplicity is moderated down. I think the question that most people are answering here is something like:
What big-government, over-engineered, deadly, polluting, land-wasting, oversubsidized mess can a bunch of technology-obsessed gadget freaks create to soak up tax money for the next 50 years?
Look up the "electric vehicle tax credit" to get an idea. ZEV's only count if they're not bicycles.
There was an article about the I-DNS method in several publications last week. Apparently the power-that-be (internic etc.) are considering adopting this standard. The idea is to use the usual 7 or 8 bit domain format, but lay unicode on top of it using a UTF-5 encoding. This encoding represents unicode characters using ascii [0-9A-Z], so zhongguo.com will map to an 8 bit string like G61H890.com in the DNS database.
This looks like a good idea, but it requires some work on the client end to generate UTF-5 lookup requests, and display urls correctly. I'm not sure what an anchor tag will look like in this system, i.e. whether the domain should be in the page's native encoding, or utf-5.
In any case. with a little bit of hex arithmetic (see the site for info) you can now domain squat in dozens of languages.
If perl were written like Japanese, it would have different forms depending on the computer's relationship to the coder. If the computer were older or higher in social status than the coder, the coder would have to use elaborate formal endings on all suggestions (commands would be forbidden). If the computer were younger or lower in social status, the coder would be able to use short, direct commands, and would not have to address the computer by title, or bow after each statement.
Men and women would also have different vocabularies. It would be considered improper for a male to use "Ladies' Perl" in most computer environments (except perhaps the Mac).
I've never understood working on a CRT in a darkened area. At best I end up with a whitish rectangle burned into my retinas at the end of the day.
It seems like most people don't like reflections of lighting fixtures or windows (the architectural kind), or glaring fixtures in the periphery of their vision. The reflection problem is easy to solve by tilting the monitor down slightly. The peripheral vision problem is solved by shielding lights so that they shine downward instead of to the sides. I'm not sure why people buy fixtures that produce a small amount of light downwards, and a huge amount of glare to the side and even upwards, but they do (especially outdoor lights, see www.darksky.org for examples). My office got partway to a solution by buying fluorescents with side shields, but the shields still allow a lot of light through in the 0-30 degrees-from-horizontal range. A little late-night work with tape or aluminum foil will fix these.
In any case, the lights directly above a monitor are not much of a problem. Darkening or tenting an entire cubicle just to avoid side glare seems like throwing out the baby with the bathwater. It puts the eyes into a highly dilated (i.e. poor depth of field) state, with dark adaptation taking 20-30 minutes to achieve maximum sensitivity. A few seconds of bright light will undue this adaptation. It also means tiny lights like LED's or light leaks will become glare sources themselves.
A while ago I posted some C code about the value of xor in swapping int's, etc., but some of the followups noted that most of it wouldn't compile. The reason is that ANSI C and C++ have moved away from K&R and made most type abuses illegal.
That got me to thinking about C in general, and the values that got me interested in it in the first place.
When I took up C I had already learned several high-level languages like BASIC, Pascal, and even APL and some Lisp. C immediately stood out, because it had tight integration with hardware, based on an abstract, but very accurate, Von-Neuman-type processor and memory model. The basic goal of C was to do everything that assembler did, with similar tightness of code and familiarity with registers, bit sizes, and machine addresses. Unfortunately, the prevailing trend was to take C and make it a higher-level and not a lower-level language.
However, these days, just about all processors are pipelined or multi-pipelined, and C code is hacked to pieces by the compiler or the on-chip optimizer. That's handy, but, in effect, C and even many assembly languages have become interpreted! The IA-64 will pull C code into separate, independent instruction streams, based on dependency and dataflow analysis. Crusoe will do speculative execution and even backtracking on unsuccessful branches, going so far as to do a rollback on memory locations, in cache.
That's all fine and dandy, but I wonder if there are features there that could be put under more programmer control. Maybe there are some new #pragma'sthat I don't know about, but still I see C as getting farther and farther behind the hardware model.
As a few naive suggestions, here are some ideas I have:
Tagging statements to designate which pipeline they go into. This is what IA-64 compilers do anyway, so why not us! (maybe we can, but I haven't checked).
adding cache control statements to variables - eg lock in cache, pageable, or page immediately (useful for scans, where,say, 2G of RAM is being scanned one byte at a time - there's no reuse). Oddly enough, I got this one from Oracle, which has this option for certain table operations.
More machine-level operators. I don't know what these would be, but anything bitwise would qualify.
For a mature example, look at Macsyma or Mathematica. These are extensible algebraic tools which have extensible rule sets, and "intentions" which are stated in mathematical expressions. A massive search engine powers the system by applying rules and attempting to construct a reduced or simplified expression from the original. These are handy (in fact I think calculators now use a simplified version), but not exactly a dream to program. For one thing, the algorithm to generate solutions meets the textbook definition of "intractable".
I think in the example of legacy code, the idea is to treat the FORTRAN or whatever as natural language and re-create all of the semantics of the compiler in some sort of rule base, and then go to town by adding to or modifying the ruleset to extend the domain. This seems like a hopeless endeavor.
As a kicker let me leave you with this quote, the result, apparently, of 4-5 years of intense IP research:
This is nothing new. I was arrested on Rodney King Day in SF while walking home from my job as a riot instigator at PG&E. The charge was apparently violating a 9pm emergency curfew; the only problem was that it was around 7-8 pm that I was rounded up, along with a bunch of Japanese tourists and a guy that had been using a pay phone on the street.
Everyone was held until 12:30 am, when we were cuffed and taken to a garage in the Mission, with a couple of porta-potties and a pool of water on the floor. We never received any water, food, warm clothing, or access to a telephone; we were cut off from the world entirely. Eventually around 6:30 I was fingerprinted and photographed and released onto the street to find my own way home.
A few years later a guy I worked with was beaten and arrested for "assaulting a police officer" because he had helped a photographer take pictures of police arresting people. The only problem was that this gentleman had polio, and couldn't really assault anyone.
Anyone who thinks that police have the resources or the ability to treat people fairly in a crowd-control situation is obviously deluded. Society works by hiring as few police as possible, and looking the other way when these police resort to mass round-ups, perjury, and excessive force to do their jobs and defend themselves.
The problem is that any other house is $3 million.
The unfortunate fact of real estate profits is...they're only realizable if you're OK with being homeless (or moving away from wherever you grew up).
The only problem is that they haven't delivered anything yet, and this is the second time we've ordered DSL at our current address (the first order evaporated, even though they're billing me for it).
Word to the wise: You may want to get the self-install option no matter what. The last PacBell guy to install DSL at our old apartment did the following:
Things Korea has that the US doesn't:
1. cell phone coverage in the subway
2. a Starcraft TV show, with two players going at it, and commentators.
3. Scented business suits
4. Really small cell phones
5. A TV channel for Korean chess (Paduk).
6. The Turtle boat
7. The world's longest lava tube
8. Heated floors. Now that's technology.
The ingredients are:
napa cabbage
salt
red pepper
garlic
ginger
sardine juice (sometimes)
The cabbage is diced and salted, then mixed with all the other stuff and placed in a cool, dry place for fermentation. Traditionally it's buried in a pot to keep the temperature in the right range.
It's basically sauerkraut with a lot more flavor.
Kimchee is great. Try it on pizza, or on spaghetti with tomato sauce.
My favorite - soylent green kimchee.
There was an article in the WSJ a while back about the whole air cellular thing. It covered the FCC vs. FAA regulation, the lack of any evidence ever of a cell phone or computer interfering with a plane, etc.
One thing they mentioned is that those egregiously expensive AirFones are just cell phones with the base stations farther apart. For that we pay 10-20x higher fees.
However if there is some heretofore undiscovered interference found, then we logically should refuse to fly on airlines with AirFones, no?
Let's all stand by and watch while each airplane is grounded for re-testing. Until that happens I'll take this with a grain of salt.
15 Q. Do you know whether the Disney
16 search engine, for example, will do a search if you
17 put in DeCSS?
18 A. If Disney has a search engine, which
19 I will believe is true, I would presume it would.
20 Q. And do you know how many sites then
21 come up under the Disney search?
22 A. I have no knowledge.
23 Q. Is your answer "no knowledge," would
24 that be true with respect to any of the other
25 plaintiffs in this case?
INTERIM COURT REPORTING
136
1 Schumann
2 A. Yes, that's correct.
3 Q. Do you know if the Disney search
4 engine will take you to CSS.auth?
5 A. I have no knowledge.
6 Q. CSS.cat?
7 A. I have no knowledge.
8 Q. Do you have any knowledge of how
9 many people have downloaded or taken off --
10 (Telephone interruption.)
11 BY MR. GARBUS:
12 Q. -- downloaded DeCSS?
13 MR. GOLD: I object to the form.
14 MR. GARBUS: Pardon me?
15 MR. GOLD: I object to the form of
16 the question.
That's another old-IBMism that I had completely forgotten about - an overemphasis on status by association. One thing I noticed right away when I started my job delivering mail at IBM in the 80's was that everyone there felt like their shit didn't stink, not due to their own merits, but due to the company's. It was thought that working at IBM was a kind of Nirvana, unlike any work experience anywhere (something I see in the MS recruiting ads all over downtown). Actually it was a lot like the post office.
That's a major part of what dragged IBM under. Success has an irresistable attraction for the mediocre, and they climbed aboard IBM in spades, and formed a company largely in their own image. It took a severe bludgeoning by the market to set them straight (and several rounds of layoffs).
Over on Salon there are some articles about the differences between the IBM case and the MS case, and, to summarize the last 10-20 years, I would say that MS was passed the baton by IBM, and became IBM in much less time than IBM took, but the DOJ also got through the antitrust part much faster than it did with IBM, due to its prior experience with the business model.
Looking at MS today, and dealing with some of the parts of the monolith, it's easy for me to see the resemblances to IBM in the 80's - dominant market position, booming profits, and top people, but also an overbearing, creeping internal stagnation that leaves people looking forward to the salad bar at lunch more than the workday.
The reasons for this sort of decline are easier to see in hindsight, but the basic fact is that a monopoly has no reason to innovate or grow beyond a certain point. It becomes a virtual reality - new products are only expected to work with other company products, deadlines are only vaguely necessary, and the external, chaotic world becomes less and less relevant. (For example, I took a trip up to MS a few months ago, and, judging from the posters on the walls, what was their major concern? Software piracy! As if a bunch of engineers in an ugly office park were going to do something about it.)
The tragic effect of this isolation, and one that IBM went through in the early 90's, is that the good tech gets shunned along with the bad stuff. A lot of the top people that IBM hired ended up watching great, enterprise-grade software and hardware go down the toilet, while shoddy, overhyped substitutes were pushed by dodgy competitors. Part of that was human nature (and lower prices), but the less-seen reason was the the marketing process had become disconnected from customers, and the tech wasn't able to make a difference to the consumer. It's one thing to have the best disk drive in the world, but another thing to have the best drive that people can plug into their PC's, Macs, or Sun workstations (or MP3 players).
Microsoft is pretty close to that stage now. Putting great tech into Word or NT is good, but selling the same stuff independently is better, and that's a scenario that most people being hired by MS today will never see. IBM learned its lesson late, but they now see that opening up interfaces isn't giving away the farm. People still buy all-IBM when they want tightly integrated systems with high reliability, but they also mix and match to get unique things that IBM does well.
The appeals court can do what it wants; the fact is that the people who need to know what MS has been doing, now know, and will apply this knowledge as appropriate in the future. I have no qualms about admitting that IBM was a monopoly (even though I have a lot of ties to the company), and I think that MS has some growing up to do before it can admit that it has some bad elements. The fact is, management let a lot of people down. I've often bashed MS in the past, but I hoped deep down that the charges were more illusion than fact. However purposeful sabotage of competitors just doesn't feel right, and one day MS will be a better place to work if these practices are stopped.
You need to remember that almost everything slashdot serves is user content, which is constantly being added-to by thousands of rambling geeks. All this has to be ingested, stored, and then threaded/sorted and filtered (by threshold) on the way out - that takes a lot of disk, memory, and cycles. Caching helps, but each additional post on a thread will invalidate the cache and necessitate regeneration.
Add to that the ad serving, graphics, and so on. I don't know how much tracking they do, but ads usually only pay for each unique user - loading the same ad on the same user's screen ten times only counts for one impression. So most sites have to set a cookie just to avoid double-billing, and check it on each pageload to rotate the ads correctly. That adds cpu and memory too.
There are several newsgroups for netwinder dev issues.
I was on the mailing lists that preceded these, and the main issue I can recall was struct alignments. A lot of code expects things like
struct { char a; char b; char c; char d }
to fit into four bytes, when 4-byte alignment may push it to 16.
I could go on and on about both sides here, but let it suffice to say that there are no absolutes in software, only tradeoffs. MySQL lacks certain features of other DBMS's, but in many cases it may be sufficient to implement these features, such as transactions, rollbacks, etc., in application software rather than spending 100k/yr. on Oracle. However, beyond a certain point, the cost of implementing and maintaining these safeguards may exceed the cost of a DBMS that already includes them.