For the inside mirror, a convex surface would cause more confusion than the extra viewing area is worth. Espcially given that most of the extra area will be blocked by the door frames/pillars and people's heads.
"That turns out not to be the case". I have been driving for 20 years now. One of the first things I did when I got my first car was buy one HUGE convex inside mirror. I keep moving it from each car to the new one. Combined with the largest convex side mirrors I can make fit.
The system works like a charm. There are absolutely no blind spots. The scale in all the mirrors is almost the same. Most importantly, there's huge overlap between the field of view of the inside and each of the side mirrors. This means that when you shift your gaze from one mirror to another, you immediately know how the views fit together.
It is non-convex mirrors, outside or inside, are a crime. Whenever I drive a car that's not my own I feel like I'm seeing the world through three separate sets of blinders. I'm painfully aware of my blind spots. You need to literally "invent" what's in them to get a complete surround image of the car in your head. The frustration is similar to the feeling I get if I'm forced to script something in DOS instead of bash:-)
For the life of me I can't see why equipting cars with such inferior mirrors doesn't result in lawsuits. It is just like equipting a car with underpowered brakes IMVHO. People are dying because of it. The only down side to using convex mirrors is you have to get use to the scale. Of course, if all cars had large, convex mirrors everywhere, this wouldn't be a problem; you'd get used to the scale when you learn to drive. And anyway, adjusting to convex mirrors only takes several days.
Besides, if you are dead-set on adding a radar to each car, PLEASE put it in the front, connect it to the speedometer, and have a nice large red light flash on the driver's dashboard when he is too close to the car AHEAD of him. Inappropriate distance from the car ahead is a leading cause of accidents (if not the leading cause). Placing a radar on the back of the car is, literaly, an ass-backwards notion.
what's next? software that composes the game in real time with "unpredictable but recognizable content"?
You mean like Nethack? Inevitably, someone will add something like their software to the game... Throw in some sound effects, and maybe specific tunes for special levels, and you get:
... both explosive and propulsion power is provided by simple anti-matter.
Can't get any simpler than that, I guess:-) It combines well with:
Williams makes one of the races both supreme tacticians and incapable of anything more than 2G. OK, that's different).
I can see how using such a wimpy explosive and propulsion power, missiles wouldn't be able to pull more than 2G and would do little damage, so the "supreme tacticians" will actually have a chance of surviving a battle.
Re:Sick of XML? Try YAML.
on
Effective XML
·
· Score: 2, Interesting
XML and YAML have different "sweet spot" domains, though you can apply both technologies outside their intended domain.
XML is great for "documents" - text documents, that is. XML does an admirable job seperating "content" from "markup" which can be used to drive "presentation". It really is a big improvement over SGML. Things like DocBook, and CSS stylesheets, make XML the choice for writing documents.
YAML is great for "data" - data structures, that is. YAML directly maps to common application data structures, so the result is more readable for both humans and computer programs. It is still very new, but is gaining acceptance, and IMVHO is the way to serialize data.
Sure you can use XML for data (lots of people do) and YAML for documents (the YAML spec is written as a YAML document, just as a test of how far this can be pushed). But in both cases you are using the technologies outside their intended domain and suffer the consequences. It is all about using the right tool for the job.
XML was never designed for data, it is an "Extensible Mark Up Language" for crying out loud. Promoting it as the end-all be-all solution for serializing data is strange - it is like promoting the use of the C++ programming language for writing scripts (it is all "programs", right?).
In contrast, YAML Ain't Markup Language - it was designed specifically for data, and is very good at what it does. Just as the world has mostly come to accept that "system languages" and "scripting languages" are different animals, it will discover that "document formats" and "data formats" are different animals - hence the need for both XML and YAML.
(I'm one of the YAML spec authors, so the above reflects about 33% of the "official YAML position":-)
Re:Sick of XML? Try YAML.
on
Effective XML
·
· Score: 1
YAML is nice, I use it for a couple things, but I find it harder to edit by hand. Why? It's very picky about punctuation and spacing. For instance, if your data has a "special" character in it, you must remember to put single quotes around it. then if you have single quotes in it too, you have to deal with those, etc.
If you use single quotes, all you have to worry about is quoting single quotes - no other character. If you don't want to bother quoting any character, use a literal:
At the chance that I'll be slashdotting my hosting service... Here's my "Practical Guide" for solving the cube. It has the following advantages:
- It is simple. There's even an ASCII version that fits on a single page. Honest! It makes it easy to carry it with the cube (or in your PDA, or whatever).
- It is "practical"; it focuses on solving the cube using a small number of basic moves that are "natural" and easy to perform. They become "muscle memory" in no time.
- It is easy to memorize because the combinations of the basic moves (mostly) make (some) sense. So you have a fighting chance of remembering them a month (or a year) later.
Of course, this means you'll never win a speed competition using it. If you are into that, there are much better guides (which are much, much more complicated).
"Sure they say it's impossible to spill (radioactive material) for it to get out. But nothing in this world is impossible," he said.
Except, of course, for the public to rationally consider anything at all with "nuclear" in its name. That is really impossible.
What is it with people and "nuclear"? This reactor is suggested by the Japanese of all people. They were nuked. Twice. If anyone should automatically shut down his brain and cringe at the sound "nuclear", it should be them. Yet they seem to be thinking rationally about it. In the meanwhile, it is the Americans who nuked them who black out when hearing the word. What is this, some sort of guilt trip?
Wait, I got it. These Japanese are also scared of nuclear power. But they hell-bent on revenge! They'll install these miniature nuclear plants all over the USA, and at a predetermined time will cause them all to explode, killing everyone in the continent! Notice they don't suggest it be used in Japan? Launch a pre-emptive strike now!
It is 2AM after a week of 3/4-hour sleep nights. "The crunch". The demo version must be ready in 48 hours to show the investors, or the company is tanked. You know, the good old days...
We were so zonked we were pair programing, to keep each other from making dumb mistakes. This was before XP was a gleam in Beck's eyes - around 85. But we were that desperate....
At any rate, I'm in this directory with a zillion files we don't need. And one file we *really* need. Just finished a few hours of very delicate work on. Crown jewels sort of thing.
You guessed it... I type "rm *".
It took me a milisecond to understand what I've just done. Simultaneously the girl next to me (yes, we actually had some female programmers back then, imagine) shrieks "Noooooooo!".
I hit Control-C faster than a blink. And then, with trembling fingers, "ls".
And there it was. One file, out of the multitude that were in this directory. Our crown jewels.
I turn around and tell here "What? We only needed this one anyway!"
The look on her face was worth my heart stopping a second before.
BTW, we did beat the deadline, presented a demo, got the money, and then spent a month recovering the code from the results of this one-week massacre. I was a green rookie at the time, and this has taught me the value of "40 hours weeks" in a way you never forget.
And that every once in a while, Lady Luck _does_ smile on you...
If LCDs could be stacked side by side without any bezel, it should allow creating very large screen. It might also reduce costs of existing screens since I believe the cost of creating an LCD is worse than linear in its size.
So - exactly why do LCD displays require a surrounding bezel? I'd expect that for for both strength and connections it should be possible to attach to the LCD from behind. Or at least reduce the width of the bezel to something much lower (say, 1mm).
Would have been the Monty Python gang. Terry Gilliams as Zaphold (and as a director, of course!), Eric Idle as Ford, and John Cleese as Arthur.
Alas, it is too late for that... A pity. We take comfort in that, at the time, there was a finite (im)probability for this movie to exist, so we you need to do to obtain a copy it is a time machine and hot cup of tea.
"Just sitting there" is what all URNs are for. I don't see it as a down side. As for usefulness - I'm co-author of the YAML spec, and it exactly fits our needs. It seems to me the ability to mint persistant URIs is universally useful. Making them easy to work with (e.g., compare), and doing it without a new registrar is great.
I don't see why the draft can't be adopted as is. Then again, I have zero knowledge of the IETF processes involved. Is there a way the YAML community can promote the approval?
Quick, without peeking at the answer, what's the difference between a URI, a URL, and a URN? OK, now that we are all on the same page:-), what is "info:"? you'd expect it to be a URN. It isn't (from the RFC):
7.2 Why Not Use a URN Namespace ID for Identifiers from Public Namespaces?
RFC 2396 [RFC2396] states that a "URN differs from a URL in that it's primary purpose is persistent labeling of a resource with an identifier". An "info" URI on the other hand does not assert persistence of resource names or of the resource itself, but rather declares namespaces of identifiers managed according to the policies and business models of the Namespace Authorities. Some of these namespaces will not have persistence of identifiers as a primary purpose, while others will have locator semantics as well as name semantics. It would therefore be inappropriate to employ a URN Namespace ID for such namespaces.
Which I read to mean that an info: URI may, or may not, be a URL (i.e., useful for actually accessing the resource); may, or may not, be a URN (i.e., provides some semblence of a chance that it means the same thing today as it did yesterday). Oh, did I mention that it may, or may not, be case sensitive, and may or may not be subject to scheme-specific normalization rules?
It seems that someone (say "Perfection") got fed up holding the fort agains a hoard of requests for top-level URI schemes - or someone (say "Kludge") got fed up with the demand that these schemes actually have some well defined semantics. Or both. Either way, they had this brilliant notion... why don't we have a junk^H^H^H^Hinfo: URI scheme with as little control over semantics as we can get away with? If some top-level URI scheme sucks, we'll just put it there. We'll spin off a company to be the registrar so "Perfection" will be able to pretend not to see it, and "Kludge" will be able to register all the junk^H^H^H^Hinformation URIs he wants!
I guess it does make some sort of twisted sense... In the meanwhile, proposals like the taguri proposal languish. Here's a years-old proposal that attempts to define coherent semantics for time-persistant identifiers, without requiring a (new) registration agency. We can't have that, can we?
Sigh. Insert mandatory "I for one welcome the arrival of our new info:disposable:gjyr4784ghf89yf4h URI masters" post here...
This is a good thing because it hurts Microsoft financially.
No, this is a bad thing because it promotes harmful software patents and their use to sue anybody in sight with deep enough pockets.
No, this is a good thing because it will make HTML more secure for most people (no more harmful ActiveX plug-ins).
No, this is bad because it will hurt client side Java (what's left of it, anyway).
No, this is good because it will promote standards such as SVG, making content more portable and turning the browser into a viable application platform.
No, this is bad because it will bury the notion of turning the browser into an alternative to the OS by running 3rd party code.
ARRGGHH!!!
This is just an indication of the mess we have gotten ourselves into during the last twenty years (yeah, I know, this dates me). Can somebody please repoot the world from a snapshot taken in 1983, before breaking up Bell killed any chance of wide-spread adoption of UNIX on PCs? Anyone? PLEASE?
Base 3 is the only truly beautiful base. Not only is it optimal in a theoretical sense, it would dramatically improve the quality of life of geeks everywhere. True, they would still not get any, but at least instead of working with boring bits and bytes they would switch to thrilling tits and tights. I say, go for it!
Once, when negotating an investment deal, we got a Word document with the investment bank's comments on our proposed contract.
They tracked changes. All we needed to do was display them... and we got juicy stuff like "if they accept either our fix for clause X or for clause Y we can still s---w them royally in scenario Z".
Made for a very effective negotiation. For us.
Oh, wait, the article was about the problems this raises for the document's _author_.
Don't evaluate patents at all. Just pay a fixed fee for stamping any piece of junk you want as "accepted at YYYY-MM-DD HH:MM:SS". Your junk becomes immediately available for the public, for free. Allow submission in electronic form through the web, using digital signatures. In short - bye bye USPTO, hellow stupid PHP web server.
Then, if/when someone want to sue another for infringement, let the court sort it out. The big point is that the court will NOT assume that just because the USPTO has stamped some document, it means the claims are truly innovative. The burden of proof will no long rest on the defendent. This makes a BIG difference.
Also, if someone tries to enforce a junk patent, well... the immediate course of action is to whip up another junk patent of your own and counter-sue. "See, judge, if that piece of junk is innovative, by the same standard so is ours". It would only take a few cases where a busy judge would force a big company to pay legal fees and harassment damages for trying to enforce an obviously junk patent to cool off the industry's lust for such things. And they can still register them for their heart's content and for the glory of their balance sheet - our product is covered by 10^6 patents! - so everybody wins.
Of course the USPTO will scream bloody murder about the loss of jobs - sorry, about how important a function they are providing. Well, if their function is that important and they are any good at it, they can all hire out as expert witnesses for patent infringement cases. Probably make more money, too.
Yeah, I know, the chances of this happening are the same as the pay-a-penny for copyright extension after 15 years scheme (solving Disney's Micky problem without shafting the rest of the world), the chances that the courts will actually do anything about Microsoft, and the chances that the fact that the total food production in the world is enough to make everyone overweight will solve the hunger problem in Africa:-(
Larry Niven had this great short story where Elephant looks for the most unusual piece of real estate in the known space... nicknamed "Cannonball", it is a solar system zooming *very fast* through our galaxy. While that is unusual by itself, it isn't the *most* unusual thing about it, as you can guess.
Luckily for him his pilot is a coward, so they don't land:-)
Seriously, the existrance of large amount of anti matter (whole galaxies of it) isn't _that_ far fetched. Consider that the original big-bang universe is made out of hot plasma. A blob of matter pressed against a blob of anti matter will create a terribly violent reaction in the interface zone; this would act as a "wall" repelling both matter and anti-matter away from it, preserving them as seperate regions. Also, any electrical current flowing through the plasma will tend to separate matter and anti-matter. Given the whole universe is expanding madly in the duration it is possible that ant-matter "islands" survived.
AFAIK (IANAP) anti-matter galaxies/stars would be indistinguishible from normal-matter ones. Photons don;t care whether they are created by matter fusion or anti-matter fusion, etc.
I wrote a path-finder program using Dijkstra's algorithm (and then A*, etc.). At any rate, it dynamically displayed its results showing a red path over a green graph (you can see where this is going...).
It was working very nicely and the animation was very fun to watch. I was proudly demonstrating it to a co-worker - "See how it just sniffs this dead-end and back-tracks left here?". He looked bewildered: "I don't see anything". Exasperated, I pointed to the bright red line of the path: "Here, *this*! - what are you, color blind?".
Him: "Yes".
Oops.
I spent the next 5 minutes apologizing and then another half hour adding user control over the animation colors so he could see the results. And never took this for granted again.
There are so many of these... And this isn't going to change.
The nice thing about SCons is that you code the "makefile" in Python instead of some build-tool specific language. Of course, that's also its main disadvantage. Build tool languages are typically nicer for this specific problem domain. Not to mention you need to install the Python run-time environment first. Well, not everybody wants to install it just for the sake of a build script.
As for its other claims to fame, there's nothing new about them. All modern build tools (and there are many) do away with "recursive make", "make depend" etc. This has been the case for more than a decade now. Comparing a new build tool with this crude method is the equivalent of a car maker coming out with a new model whose claim to fame is having airbags and ABS. Yawn.
The only reason that (reasonable) people use make is portability; like/bin/sh, you *know* it will exist on your target platform. I wouldn't hold my brath waiting for either makefiles or shell scripts to disappear any time soon.
I doubt SCons is better than cake, jam or cook (to name a few example). There was also the original Cons which had the same idea as SCons but was based on Perl instead of Python; Ant that does the same thing with XML and Java. None have even made a dent in plain old make.
We are stuck with makefiles for almost anything that needs to be delivered as an open source project, regardless of size. I'd probably use GNU make for the larger projects. While GNU make isn't quite up to the task, it is common enough to be acceptable and advanced enough that the pain is tolerable. That is, as long as you do *NOT* use it recursively. Recursive make is an abomination.
For serious in-house projects I personally prefer to use cook, since I'd want to use Aegis as well and cook is the best match for it. Cook is really a great build tool independently from Aegis. It is just that their combination is such an amazingly useful development framework that if you hit on one you usually end up sucked into using the other as well:-)
Of course, most people couldn't care less; in fact, most people use the Visual Studio build system. It makes recursive make look advanced!
Planet earth: closed system Human race: growing exponentially Inevitably: not for long!
This leaves us three options:
- We grow exponentially until there's a collapse, then do it all over again (if we survive). This option sucks.
- We make the transition to a stable, zero growth society. This transition seems politically impossible. Also, a stable, zero growth society sucks (e.g., prepare to give up basic freedoms, etc.). Admittedly it sucks less than a collapse, but it still sucks.
- We expand out of earth, and maintain a growing, open, free society. This is possible, but is expensive.
Some say the last option will never be practical, by doing a simple economical feasability study of mass migration out of earth. There are two answers to this:
- If someone did the same sort of study on the 15th century, it would be obvious mass migration to the Americas isn't economically feasible, either.
- If we don't try, we are certainly doomed to one of the first two options.
So yes, we don't need humans in space for pure scientific exploration. We merely need them for our long-range survival as an open, free society.
(As long as the collected data is only statistical, etc. - I'd hate to get a "you have been watching too few commercials and we are therefore forced to increase your subscription fee" letter:-)
At any rate, measuring skips will have a positive self-regulating effect on ads. Obviously ads would become more "interesting" and "relevant". But I expect that there will also be fewer ads as a result. IMVHO the amount of ads being broadcasted today is ludicrous - way above any cost-effectiveness.
In Israel we finally caught up with the rest of the civilized world and have zillion of channels, but there are remnants of our pre-hiostoric past - channels that have no ads. Amazingly, the same show is broadcast in several channels, some with and some without ads. Not always, and not the same seasons, but it really drives the point home when you see that on channel A "Buffy" takes only 45 minutes, including a few minutes of promotions between episodes, while on channel B it takes a full hour. I'll watch a few interesting/relevant ads, fine. But watching ads 33% - 25% of my time? They have got to be kidding.
I really don't understand how you people in the USA endure this. When I'm there (one or twice a year) I'm in hotel rooms, so I don't get any ad-free channels (do you even have such things?). If I bother and am lucky I catch a show that I follow in Israel and is a season ahead in the USA, so I watch about one or two hours on average per trip, all the ads are new for me (for the first half-hour, anyway) - and I can still only barely take it. I guess it is true that one gets used to everything... but UGH!
I assume that the way you survive is by simply tuning these ads out, somehow. Which means that they aren't really working, right? Measuring ad-skipping will drive this point home to advertisers so that the percentage will reduce to something more sane. Wouldn't that be great?
Slashdot Mirror
``I assume that many Slashdot readers must serve as the IT staff for their parents.''
:-)
`Many of us are the IT staff for our kids!'
My kids are the IT staff for my parents. Problem solved.
For the inside mirror, a convex surface would cause more confusion than the extra viewing area is worth. Espcially given that most of the extra area will be blocked by the door frames/pillars and people's heads.
:-)
"That turns out not to be the case". I have been driving for 20 years now. One of the first things I did when I got my first car was buy one HUGE convex inside mirror. I keep moving it from each car to the new one. Combined with the largest convex side mirrors I can make fit.
The system works like a charm. There are absolutely no blind spots. The scale in all the mirrors is almost the same. Most importantly, there's huge overlap between the field of view of the inside and each of the side mirrors. This means that when you shift your gaze from one mirror to another, you immediately know how the views fit together.
It is non-convex mirrors, outside or inside, are a crime. Whenever I drive a car that's not my own I feel like I'm seeing the world through three separate sets of blinders. I'm painfully aware of my blind spots. You need to literally "invent" what's in them to get a complete surround image of the car in your head. The frustration is similar to the feeling I get if I'm forced to script something in DOS instead of bash
For the life of me I can't see why equipting cars with such inferior mirrors doesn't result in lawsuits. It is just like equipting a car with underpowered brakes IMVHO. People are dying because of it. The only down side to using convex mirrors is you have to get use to the scale. Of course, if all cars had large, convex mirrors everywhere, this wouldn't be a problem; you'd get used to the scale when you learn to drive. And anyway, adjusting to convex mirrors only takes several days.
Besides, if you are dead-set on adding a radar to each car, PLEASE put it in the front, connect it to the speedometer, and have a nice large red light flash on the driver's dashboard when he is too close to the car AHEAD of him. Inappropriate distance from the car ahead is a leading cause of accidents (if not the leading cause). Placing a radar on the back of the car is, literaly, an ass-backwards notion.
what's next? software that composes the game in real time with "unpredictable but recognizable content"?
You mean like Nethack? Inevitably, someone will add something like their software to the game... Throw in some sound effects, and maybe specific tunes for special levels, and you get:
MuseHack!
... both explosive and propulsion power is provided by simple anti-matter.
:-) It combines well with:
Can't get any simpler than that, I guess
Williams makes one of the races both supreme tacticians and incapable of anything more than 2G. OK, that's different).
I can see how using such a wimpy explosive and propulsion power, missiles wouldn't be able to pull more than 2G and would do little damage, so the "supreme tacticians" will actually have a chance of surviving a battle.
XML and YAML have different "sweet spot" domains, though you can apply both technologies outside their intended domain.
:-)
XML is great for "documents" - text documents, that is. XML does an admirable job seperating "content" from "markup" which can be used to drive "presentation". It really is a big improvement over SGML. Things like DocBook, and CSS stylesheets, make XML the choice for writing documents.
YAML is great for "data" - data structures, that is. YAML directly maps to common application data structures, so the result is more readable for both humans and computer programs. It is still very new, but is gaining acceptance, and IMVHO is the way to serialize data.
Sure you can use XML for data (lots of people do) and YAML for documents (the YAML spec is written as a YAML document, just as a test of how far this can be pushed). But in both cases you are using the technologies outside their intended domain and suffer the consequences. It is all about using the right tool for the job.
XML was never designed for data, it is an "Extensible Mark Up Language" for crying out loud. Promoting it as the end-all be-all solution for serializing data is strange - it is like promoting the use of the C++ programming language for writing scripts (it is all "programs", right?).
In contrast, YAML Ain't Markup Language - it was designed specifically for data, and is very good at what it does. Just as the world has mostly come to accept that "system languages" and "scripting languages" are different animals, it will discover that "document formats" and "data formats" are different animals - hence the need for both XML and YAML.
(I'm one of the YAML spec authors, so the above reflects about 33% of the "official YAML position"
YAML is nice, I use it for a couple things, but I find it harder to edit by hand. Why? It's very picky about punctuation and spacing. For instance, if your data has a "special" character in it, you must remember to put single quotes around it. then if you have single quotes in it too, you have to deal with those, etc.
If you use single quotes, all you have to worry about is quoting single quotes - no other character. If you don't want to bother quoting any character, use a literal:
literal: |
It's nice, anything goes*&%^$%#$@!
Warning: Self promotion here.
At the chance that I'll be slashdotting my hosting service... Here's my "Practical Guide" for solving the cube. It has the following advantages:
- It is simple. There's even an ASCII version that fits on a single page. Honest! It makes it easy to carry it with the cube (or in your PDA, or whatever).
- It is "practical"; it focuses on solving the cube using a small number of basic moves that are "natural" and easy to perform. They become "muscle memory" in no time.
- It is easy to memorize because the combinations of the basic moves (mostly) make (some) sense. So you have a fighting chance of remembering them a month (or a year) later.
Of course, this means you'll never win a speed competition using it. If you are into that, there are much better guides (which are much, much more complicated).
The guide is in http://www.ben-kiki.org/oren/rubik/rubik.html and the compact version is in
http://www.ben-kiki.org/oren/rubik/rubik.txt.
Share & Enjoy!
We could make H1000 pencils that would write on *anything*. All we need now is for someone to create an eraser to match :-)
"Sure they say it's impossible to spill (radioactive material) for it to get out. But nothing in this world is impossible," he said.
Except, of course, for the public to rationally consider anything at all with "nuclear" in its name. That is really impossible.
What is it with people and "nuclear"? This reactor is suggested by the Japanese of all people. They were nuked. Twice. If anyone should automatically shut down his brain and cringe at the sound "nuclear", it should be them. Yet they seem to be thinking rationally about it. In the meanwhile, it is the Americans who nuked them who black out when hearing the word. What is this, some sort of guilt trip?
Wait, I got it. These Japanese are also scared of nuclear power. But they hell-bent on revenge! They'll install these miniature nuclear plants all over the USA, and at a predetermined time will cause them all to explode, killing everyone in the continent! Notice they don't suggest it be used in Japan? Launch a pre-emptive strike now!
It is 2AM after a week of 3/4-hour sleep nights. "The crunch". The demo version must be ready in 48 hours to show the investors, or the company is tanked. You know, the good old days...
We were so zonked we were pair programing, to keep each other from making dumb mistakes. This was before XP was a gleam in Beck's eyes - around 85. But we were that desperate....
At any rate, I'm in this directory with a zillion files we don't need. And one file we *really* need. Just finished a few hours of very delicate work on. Crown jewels sort of thing.
You guessed it... I type "rm *".
It took me a milisecond to understand what I've just done. Simultaneously the girl next to me (yes, we actually had some female programmers back then, imagine) shrieks "Noooooooo!".
I hit Control-C faster than a blink. And then, with trembling fingers, "ls".
And there it was. One file, out of the multitude that were in this directory. Our crown jewels.
I turn around and tell here "What? We only needed this one anyway!"
The look on her face was worth my heart stopping a second before.
BTW, we did beat the deadline, presented a demo, got the money, and then spent a month recovering the code from the results of this one-week massacre. I was a green rookie at the time, and this has taught me the value of "40 hours weeks" in a way you never forget.
And that every once in a while, Lady Luck _does_ smile on you...
If LCDs could be stacked side by side without any bezel, it should allow creating very large screen. It might also reduce costs of existing screens since I believe the cost of creating an LCD is worse than linear in its size.
So - exactly why do LCD displays require a surrounding bezel? I'd expect that for for both strength and connections it should be possible to attach to the LCD from behind. Or at least reduce the width of the bezel to something much lower (say, 1mm).
That Bellwether by Connie Willis was fiction. It turns out that there _are_ fairy godmothers after all!
Would have been the Monty Python gang. Terry Gilliams as Zaphold (and as a director, of course!), Eric Idle as Ford, and John Cleese as Arthur.
Alas, it is too late for that... A pity. We take comfort in that, at the time, there was a finite (im)probability for this movie to exist, so we you need to do to obtain a copy it is a time machine and hot cup of tea.
"Just sitting there" is what all URNs are for. I don't see it as a down side. As for usefulness - I'm co-author of the YAML spec, and it exactly fits our needs. It seems to me the ability to mint persistant URIs is universally useful. Making them easy to work with (e.g., compare), and doing it without a new registrar is great.
I don't see why the draft can't be adopted as is. Then again, I have zero knowledge of the IETF processes involved. Is there a way the YAML community can promote the approval?
Quick, without peeking at the answer, what's the difference between a URI, a URL, and a URN? OK, now that we are all on the same page :-), what is "info:"? you'd expect it to be a URN. It isn't (from the RFC):
7.2 Why Not Use a URN Namespace ID for Identifiers from Public Namespaces?
RFC 2396 [RFC2396] states that a "URN differs from a URL in that it's primary purpose is persistent labeling of a resource with an identifier". An "info" URI on the other hand does not assert persistence of resource names or of the resource itself, but rather declares namespaces of identifiers managed according to the policies and business models of the Namespace Authorities. Some of these namespaces will not have persistence of identifiers as a primary purpose, while others will have locator semantics as well as name semantics. It would therefore be inappropriate to employ a URN Namespace ID for such namespaces.
Which I read to mean that an info: URI may, or may not, be a URL (i.e., useful for actually accessing the resource); may, or may not, be a URN (i.e., provides some semblence of a chance that it means the same thing today as it did yesterday). Oh, did I mention that it may, or may not, be case sensitive, and may or may not be subject to scheme-specific normalization rules?
It seems that someone (say "Perfection") got fed up holding the fort agains a hoard of requests for top-level URI schemes - or someone (say "Kludge") got fed up with the demand that these schemes actually have some well defined semantics. Or both. Either way, they had this brilliant notion... why don't we have a junk^H^H^H^Hinfo: URI scheme with as little control over semantics as we can get away with? If some top-level URI scheme sucks, we'll just put it there. We'll spin off a company to be the registrar so "Perfection" will be able to pretend not to see it, and "Kludge" will be able to register all the junk^H^H^H^Hinformation URIs he wants!
I guess it does make some sort of twisted sense... In the meanwhile, proposals like the taguri proposal languish. Here's a years-old proposal that attempts to define coherent semantics for time-persistant identifiers, without requiring a (new) registration agency. We can't have that, can we?
Sigh. Insert mandatory "I for one welcome the arrival of our new info:disposable:gjyr4784ghf89yf4h URI masters" post here...
This is a good thing because it hurts Microsoft financially.
No, this is a bad thing because it promotes harmful software patents and their use to sue anybody in sight with deep enough pockets.
No, this is a good thing because it will make HTML more secure for most people (no more harmful ActiveX plug-ins).
No, this is bad because it will hurt client side Java (what's left of it, anyway).
No, this is good because it will promote standards such as SVG, making content more portable and turning the browser into a viable application platform.
No, this is bad because it will bury the notion of turning the browser into an alternative to the OS by running 3rd party code.
ARRGGHH!!!
This is just an indication of the mess we have gotten ourselves into during the last twenty years (yeah, I know, this dates me). Can somebody please repoot the world from a snapshot taken in 1983, before breaking up Bell killed any chance of wide-spread adoption of UNIX on PCs? Anyone? PLEASE?
Base 3 is the only truly beautiful base. Not only is it optimal in a theoretical sense, it would dramatically improve the quality of life of geeks everywhere. True, they would still not get any, but at least instead of working with boring bits and bytes they would switch to thrilling tits and tights. I say, go for it!
Once, when negotating an investment deal, we got a Word document with the investment bank's comments on our proposed contract.
:-)
They tracked changes. All we needed to do was display them... and we got juicy stuff like "if they accept either our fix for clause X or for clause Y we can still s---w them royally in scenario Z".
Made for a very effective negotiation. For us.
Oh, wait, the article was about the problems this raises for the document's _author_.
Never mind
Because the copyright on Mickey will never expire! Remember, copyright duration is for the life of the author, plus seventy years.
Don't evaluate patents at all. Just pay a fixed fee for stamping any piece of junk you want as "accepted at YYYY-MM-DD HH:MM:SS". Your junk becomes immediately available for the public, for free. Allow submission in electronic form through the web, using digital signatures. In short - bye bye USPTO, hellow stupid PHP web server.
:-(
Then, if/when someone want to sue another for infringement, let the court sort it out. The big point is that the court will NOT assume that just because the USPTO has stamped some document, it means the claims are truly innovative. The burden of proof will no long rest on the defendent. This makes a BIG difference.
Also, if someone tries to enforce a junk patent, well... the immediate course of action is to whip up another junk patent of your own and counter-sue. "See, judge, if that piece of junk is innovative, by the same standard so is ours". It would only take a few cases where a busy judge would force a big company to pay legal fees and harassment damages for trying to enforce an obviously junk patent to cool off the industry's lust for such things. And they can still register them for their heart's content and for the glory of their balance sheet - our product is covered by 10^6 patents! - so everybody wins.
Of course the USPTO will scream bloody murder about the loss of jobs - sorry, about how important a function they are providing. Well, if their function is that important and they are any good at it, they can all hire out as expert witnesses for patent infringement cases. Probably make more money, too.
Yeah, I know, the chances of this happening are the same as the pay-a-penny for copyright extension after 15 years scheme (solving Disney's Micky problem without shafting the rest of the world), the chances that the courts will actually do anything about Microsoft, and the chances that the fact that the total food production in the world is enough to make everyone overweight will solve the hunger problem in Africa
Larry Niven had this great short story where Elephant looks for the most unusual piece of real estate in the known space... nicknamed "Cannonball", it is a solar system zooming *very fast* through our galaxy. While that is unusual by itself, it isn't the *most* unusual thing about it, as you can guess.
:-)
Luckily for him his pilot is a coward, so they don't land
Seriously, the existrance of large amount of anti matter (whole galaxies of it) isn't _that_ far fetched. Consider that the original big-bang universe is made out of hot plasma. A blob of matter pressed against a blob of anti matter will create a terribly violent reaction in the interface zone; this would act as a "wall" repelling both matter and anti-matter away from it, preserving them as seperate regions. Also, any electrical current flowing through the plasma will tend to separate matter and anti-matter. Given the whole universe is expanding madly in the duration it is possible that ant-matter "islands" survived.
AFAIK (IANAP) anti-matter galaxies/stars would be indistinguishible from normal-matter ones. Photons don;t care whether they are created by matter fusion or anti-matter fusion, etc.
I wrote a path-finder program using Dijkstra's algorithm (and then A*, etc.). At any rate, it dynamically displayed its results showing a red path over a green graph (you can see where this is going...).
It was working very nicely and the animation was very fun to watch. I was proudly demonstrating it to a co-worker - "See how it just sniffs this dead-end and back-tracks left here?". He looked bewildered: "I don't see anything". Exasperated, I pointed to the bright red line of the path: "Here, *this*! - what are you, color blind?".
Him: "Yes".
Oops.
I spent the next 5 minutes apologizing and then another half hour adding user control over the animation colors so he could see the results. And never took this for granted again.
There are so many of these... And this isn't going to change.
/bin/sh, you *know* it will exist on your target platform. I wouldn't hold my brath waiting for either makefiles or shell scripts to disappear any time soon.
:-)
The nice thing about SCons is that you code the "makefile" in Python instead of some build-tool specific language. Of course, that's also its main disadvantage. Build tool languages are typically nicer for this specific problem domain. Not to mention you need to install the Python run-time environment first. Well, not everybody wants to install it just for the sake of a build script.
As for its other claims to fame, there's nothing new about them. All modern build tools (and there are many) do away with "recursive make", "make depend" etc. This has been the case for more than a decade now. Comparing a new build tool with this crude method is the equivalent of a car maker coming out with a new model whose claim to fame is having airbags and ABS. Yawn.
The only reason that (reasonable) people use make is portability; like
I doubt SCons is better than cake, jam or cook (to name a few example). There was also the original Cons which had the same idea as SCons but was based on Perl instead of Python; Ant that does the same thing with XML and Java. None have even made a dent in plain old make.
We are stuck with makefiles for almost anything that needs to be delivered as an open source project, regardless of size. I'd probably use GNU make for the larger projects. While GNU make isn't quite up to the task, it is common enough to be acceptable and advanced enough that the pain is tolerable. That is, as long as you do *NOT* use it recursively. Recursive make is an abomination.
For serious in-house projects I personally prefer to use cook, since I'd want to use Aegis as well and cook is the best match for it. Cook is really a great build tool independently from Aegis. It is just that their combination is such an amazingly useful development framework that if you hit on one you usually end up sucked into using the other as well
Of course, most people couldn't care less; in fact, most people use the Visual Studio build system. It makes recursive make look advanced!
Planet earth: closed system
Human race: growing exponentially
Inevitably: not for long!
This leaves us three options:
- We grow exponentially until there's a collapse, then do it all over again (if we survive). This option sucks.
- We make the transition to a stable, zero growth society. This transition seems politically impossible. Also, a stable, zero growth society sucks (e.g., prepare to give up basic freedoms, etc.). Admittedly it sucks less than a collapse, but it still sucks.
- We expand out of earth, and maintain a growing, open, free society. This is possible, but is expensive.
Some say the last option will never be practical, by doing a simple economical feasability study of mass migration out of earth. There are two answers to this:
- If someone did the same sort of study on the 15th century, it would be obvious mass migration to the Americas isn't economically feasible, either.
- If we don't try, we are certainly doomed to one of the first two options.
So yes, we don't need humans in space for pure scientific exploration. We merely need them for our long-range survival as an open, free society.
(As long as the collected data is only statistical, etc. - I'd hate to get a "you have been watching too few commercials and we are therefore forced to increase your subscription fee" letter :-)
At any rate, measuring skips will have a positive self-regulating effect on ads. Obviously ads would become more "interesting" and "relevant". But I expect that there will also be fewer ads as a result. IMVHO the amount of ads being broadcasted today is ludicrous - way above any cost-effectiveness.
In Israel we finally caught up with the rest of the civilized world and have zillion of channels, but there are remnants of our pre-hiostoric past - channels that have no ads. Amazingly, the same show is broadcast in several channels, some with and some without ads. Not always, and not the same seasons, but it really drives the point home when you see that on channel A "Buffy" takes only 45 minutes, including a few minutes of promotions between episodes, while on channel B it takes a full hour. I'll watch a few interesting/relevant ads, fine. But watching ads 33% - 25% of my time? They have got to be kidding.
I really don't understand how you people in the USA endure this. When I'm there (one or twice a year) I'm in hotel rooms, so I don't get any ad-free channels (do you even have such things?). If I bother and am lucky I catch a show that I follow in Israel and is a season ahead in the USA, so I watch about one or two hours on average per trip, all the ads are new for me (for the first half-hour, anyway) - and I can still only barely take it. I guess it is true that one gets used to everything... but UGH!
I assume that the way you survive is by simply tuning these ads out, somehow. Which means that they aren't really working, right? Measuring ad-skipping will drive this point home to advertisers so that the percentage will reduce to something more sane. Wouldn't that be great?