Four different forces, superstrings, antineutrinos, strange quarks, neutralinos, gluons, and 26 dimensions.
The laws of physics are clearly the result of a bureaucracy.
There's a basic frustration in physics today that things are just too complicated at the bottom. There's a classic comment by I. I. Rabi, "Who ordered that?", made when the muon was discovered. The muon is a "heavy electron", the first elementary particle discovered that doesn't appear in ordinary atoms. Muons didn't seem to be necessary to physics, but there they were. That was the end of simple subatomic physics, and nobody has been able to put the mess back in the box since.
Too many new applications have hard real time constraints. Copying movie-sized files around, no problem - TCP will throttle. Streaming HDTV without stuttering is much tougher. We're entering an era where the highest-traffic application needs a high quality of service. If resources are tight, there's good no place to throttle.
VoIP works because it's a small fraction of traffic. Streaming HDTV looks to be a much larger fraction of traffic.
We still don't have a good answer to managing backbone congestion in pure datagram networks. The Internet today works because the congestion is out near the edges.
If we get enough "last mile" bandwidth deployed that the backbone congests before the edges, packet loss rates will go way up. If we have about 2x excess capacity in the backbone, no problem. That's the solution we know.
Microsoft has proposed systems where "broadcast" video is multicast in real time with a high quality of service, while "video on demand" is heavily buffered and sent with a lower quality of service. That's an obvious solution; it's what multicast is for.
(Amusing thought: one solution to video buffering problems is commercials. When transport can't keep up and the player is getting close to running out of buffered content, play an extra locally-stored commercial or two. This lets the buffering refill. Download commercials in advance based on personalization info, then insert them as needed during playback. Don't put them in the main video streams at all.)
If you have the opportunity to look at query logs, you see how dumb most search engine queries are.
First, a big fraction of queries are simply navigational. Many are just URLs. The major search providers recognize these in the front end machines and send back canned answers, without even passing them to the real search engine. If you type "myspace" into Google, very little work is expended returning the canned reply.
After that, most queries are one word. Phrase queries are less common.
Few people seem to have noticed, but Google started returning results based on
synonyms and homonyms a few weeks ago. There have been some significant algorithm changes recently.
Less than 1% of queries use any operators, like '"" or '-'.
The real problem with natural language queries, though, is that "Ask Jeeves" was a flop. Remember Ask Jeeves? That was a system designed to process queries written as sentences. But it wasn't used that way, and didn't succeed commercially.
First of all, no language knows what data is locked at compile time. The problem of deciding what is locked and what is not is undecidable, just like everything else that submits to the halting problem. There is no compiler that can decide when something happens in a program and when it does not.
Oh, another "halting problem" bogus answer. There are languages where the compiler knows what's locked at compile time. The Ada "rendezvous" approach knows, for example.
Secondly, a keyword like 'synchronized' does not buy you anything:
...
Thirdly, it's very easy to make a Java program deadlock using the 'synchronized' keyword. For example, let's say we have two classes that recursively call each other from different threads...instant deadlock.
Yes. And that's a good thing. Deadlocks show up early in debugging; race conditions show up late. This is, in fact, a classic source of programming problems - lack of a clear understanding of when control is "inside" an object. Java has the problem that there's no way to say that control is temporarily leaving an object. The Microsoft Spec# team, which is doing proofs of correctness for C#, has addressed this, though.
The key to multithreading programming is to avoid locking altogether. It's possible to do it, using atomic functions at predefined places.
"Predefined places"? I know there's a cult of "lockless programming", but that approach is very difficult to debug.
Forthly, your solution on declaring items within a critical section does not work (see #1 for explanation). For example, what if you declare a pointer inside the critical section, and then deep in an algorithm, or worse, deep in a dll loaded at run-time, the pointer is assigned a value which points to a non-synchronized object?
That's why compilers need to know more about what locks what. Tracing dependency issues is better done by programs than by people.
#5, in databases, what is the most common approach is optimistic locking: you tell the database that you want to update X if Y's value is Z.
Oh, a "compare and swap" fan. Actually, most of the better databases accumulate a list of what objects have been touched by a transaction, and if there's an intersection between the lists for two transactions, one of them has to be backed out.
Even MySQL does this now. There's a proposal to provide similar transaction-like semantics for C++, and that might be a promising idea. It's more idiot-proof than most other approaches.
Finally, the question 'who owns what' in a programming language shouldn't exist: nobody should own anything, freeing the programmer from worrying about ownership. This can happen only with garbage collection.
The trouble with garbage collection is that it introduces indeterminism into otherwise deterministic programs. Garbage collection is OK if you can afford random stalls and don't use destructors. Destructors and GC do not play well together. Microsoft tried, in Managed C++, to make them play together, and it wasn't a happy marriage. There, destructors can be called more than once.
Reference counting does a good job of managing memory without disallowing destructors.
It's noteworthy that Perl and Python, both of which are reference counted, generally allow programmers to ignore memory allocation. But most reference counting systems are "naive"; the compiler implementing them doesn't known enough about reference counts to optimize them. This leads to performance problems. One can do better; the compiler should hoist reference count updates out of loops.
Critical sections are a high level future which must be in a library.
The problem is that a C++ compiler doesn't know what data is locked, and which data items are locked by which lock, because the language has no way to talk about that subject. OS-level primitives lock everything. The compiler has a hard time telling which data needs concurrency protection. Thus, the compiler can't diagnose race conditions.
If the language understood locking, one could do more checking at compile time.
One could take a hard-nosed approach. Every variable has to be locked by something.
Either it's locked by the object of which it is a member (like Java's "Synchronized"), or the thread to which it is local, or by some other object which owns the variable. This last is something for which a language needs descriptive syntax.
One approach would be syntax where the programmer declares a critical section, and lists everything that can be referenced within the critical section. But that might
not be necessary. A system more like the way an SQL database decides transaction locking issues might be easier on the programmer.
The big memory headache in C and C++ is always "who owns what", something with which the language provides no assistance. That's the cause of dangling pointers and memory leaks, but it's also the cause of much locking trouble.
I have little hope for the C++ standards committee. It's dominated by people who think really l33t templates are really cool. Everything has to be a template feature. They're fooling around with a proposal for declaring variables atomic through something like
atomic<int> n;
This allows really l33t programmers to write really l33t code using really l33t lockless programming. But without the proofs of correctness needed to make that actually work reliably.
It's also long been Strostrup's position that concurrency is a library problem. As long as the OS provides threads and locking, it's not a language problem. This isn't good enough.
The fundamental problem is that, as currently defined, a C++ compiler has no idea which variables are shared between threads, and which are never shared. The compiler has no notion of critical sections. Fixing this requires some fundamental changes to the language. It's known what to do; Modula, Ada, and Java all have synchronization and isolation built into the language. But there's nothing like that in C++, and the designers of C++ don't want to admit their mistakes.
It's not just a C++ problem. Python has a similar issue. Python as a language doesn't deal with concurrency adequately. The main implementation, CPython, has a "global interpreter lock" that slows the thing down to single-CPU speed.
I have for over 6 years been thinking..of a 3d-dimmension processor that cross communicates over a diagonal matrix instead of the traditional serial and parallel communication model.
Six years, and you haven't discovered all the machines built to try that? This was a hot idea in the 1980s. Hypercubes, connection machines, and even perfect shuffle machines work something like that. There's a long history of multidimensional interconnect schemes. Some of them even work.
> There are major sites on the web which lack even proper HTML/HEAD/BODY tags.
All three of those tags are optional in an HTML 4.01 document (see the DTD for HTML 4.01).
A more fundamental issue with hosted apps is that the app might go away.
It happens, even at Google. Remember Google Answers? One day, Google just turned it off.
Or the terms of service and pricing could change. If you're a Gmail user, you have no guarantee that Google won't start charging you tomorrow. Someday Google will have a down quarter, their stock will dive, and their management will be under pressure to find new revenue.
The first one is always free.
The current situation is awful.
on
HTML V5 and XHTML V2
·
· Score: 4, Insightful
The current situation is awful.
Major tools, like Dreamweaver, generate broken HTML/XHTML.. Try creating a page in Dreamweaver in XHTML or Strict HTML 4.1. It won't validate in Dreamweaver's own validator, let alone the W3C validator. The number of valid web pages out there is quite low. I'm not talking about subtle errors. There are major sites on the web which lack even proper HTML/HEAD/BODY tags.
The "div/float/clear" approach to layout was a terrible mistake. It's less powerful than tables, because it isn't a true 2D layout system. Absolute positioning made things even worse. And it got to be a religious issue. This dumb but heavily promoted article was largely responsible for the problem.
CSS layout is incompatible with WYSIWYG tools The fundamental problem with CSS is that it's all about defining named things and then using them. That's a programmer's concept. It's antithetical to graphic design. Click and drag layout and CSS do not play well together. Attempts to bash the two together usually result in many CSS definitions with arbitrary names. Tables mapped well to WYSIWYG tools. CSS didn't.
(Does anybody use Amaya? That was the W3C's attempt at a WYSIWYG editor for XHTML 1.0.)
The Linux/open source community gave up on web design tools. There used to be Netscape Composer and Nvu, but they're dead.
Cisco has been running QNX in their high end routers for several years now. They call it "IOS XR", but it's QNX. Classic IOS, unlike QNX, isn't a protected-mode OS. In classic IOS, everything runs in one address space. They need to get beyond that. So maybe this is just opening up classic IOS as an end of life measure.
Here's the Holosonics device that does it, if you care. It's a cute trick of nonlinear acoustics.
This thing has been around for about five years, used for niche applications like narration in musum displays. But usually at a range of about a meter or two. I'm amazed that they can make the thing work at 15-20m.
They haven't been successful in getting the cost down or the quality up. Otherwise, it would
have market share in hands-free phones and computer speakers, where such directionality would be really useful.
My guess is that it will be shut down as a public nuisance in NYC.
ISPs who register domains in their name on your behalf. Many "free domain with hosting" deals are like this. This is strictly for throwaway domains, not for anything serious.
Resellers of domain registration. These are "affiliates" of actual registrars. Don't use them.
Accredited ICANN registrars who are primarily domain speculators. There are hundreds of these, most of them false fronts. "enom1.com", "enom2.com",... "enom471.com" are examples.
Real registrars, consumer grade Go Daddy is at this level. Low rates, bad service, policies that give the registrar discretionary authority to delete the domain.
Real registrars, commercial grade A bit more upscale. Network Solutions is at this level. They're good enough for "ibm.com".
Real registrars, national brand grade MarkMonitor is in this business. They register domains like "google.com" and "ford.com". If anything goes wrong with your domain, alarms go off, and technicians and lawyers descend on the problem. If you have to ask, you can't afford it.
I don't want my LinkedIn profile on other sites. All I'll get is spam.
LinkedIn has a problem with "LinkedIn Open Networkers", i.e. spammers, who just use LinkedIn to troll for contacts. Since LinkedIn doesn't have forums, they troll by using the "LinkedIn Answers" feature to ask bogus "questions". Much more of that and the question-answering system will be useless.
Here's the actual paper from which came most of the material in the article:
"The Commercial Malware Industry", from the University of Auckland. More technical details.
New threats of interest:
Some viruses now use error correcting codes so that attempts to patch them out will be repaired.
Windows Genuine Advantage blackmail trojan. Pops up message requesting payment of money or will disable your computer. (p.39)
Location-aware malware - used to find location for credit card number, so phony transactions can be generated from a physically nearby node. (p. 41)
"The most popular brands of antivirus software have an 80% miss rate" - AusCERT (p. 46)
Malware that detects and removes anti-virus and anti-rootkit tools is available. Once one of these is loaded, it runs before anti-virus software, even in Safe Mode. (p. 48)
"eGold Siphoner" detects valid sessions connecting to eGold.com and transfers funds by hijacking the authenticated session. (p. 52)
Time worked on the employee's sixth (6th) workday of the workweek shall be paid at one and one-half (1 1/2) times the hourly rate provided herein for such employee's classification. Time worked on the employee's seventh (7th) workday of the workweek shall be paid at two (2) times the hourly rate provided herein for such employee's classification.
Minimum call for the sixth (6th) and seventh (7th) days shall be four (4) hours. In the event the actual time worked by such employee exceeds the four (4) hour minimum, s/he shall be paid for all time actually worked in 1/10th -hour increments.
All time worked in excess of fourteen (14) consecutive hours (including meal periods) from the time of reporting to work shall be Golden Hours and shall be paid at two (2) times the applicable hourly rate provided herein for such employee's classification.
Now that's the way it's supposed to work. There may be crunches when hours are long, but pay goes up, which discourages employers from overdoing it.
Note the "minimum call" provision. Calling someone at home to do work outside of normal hours triggers that, and costs the employer at least 4 hours pay. Again, emergencies are provided for, but they're billable, so employers don't overdo it.
Ask's parent company, IAC, is breaking up. They're a conglomerate; they own things like the Home Shopping Network, TicketMaster, Lending Tree, and CondoDirect. All those are being sold off. They're keeping all their "internet properties", like Excite (yes, that's where Excite ended up), CitySearch, Evite, Popular Screensavers (!), iWon, Match.com, and Zwinki. IAC collected many of the major losers from Web 1.0 under one corporate roof.
At this point, it hardly seems relevant what Ask does.
Maybe there is a legitimate purpose for this delay after uninstalling SP1? My best guess would be their Genuine disAdvantage thing is suspicious of closely-spaced registration events or something.
Probably something like that. Maybe you have to wait for propagation between Microsoft's servers as they track the state of your client. If you reconnect too soon, the server you happen to reach may not yet know the new state of your machine.
Oh, and remember that RC2 expires in June 2008. So you're installing a self-destruct on your system, and gambling that Microsoft will have a working final version out by then.
Let's take a look at the advertising from the company that actually sells the medical isotopes made at Chalk River:
MDS Nordion is the global leader in the supply and distribution of short-lived medical isotopes. It's what sets us apart.
Our world-renowned rapid, reliable and customizable distribution, and logistics system ensures shipments are where they're needed, when they're needed - anywhere in the world.
Our capacity to respond rapidly and effectively to routine orders as well as unexpected requests and emergencies is a hallmark of our operations.
Our four cyclotrons and access to two reactors located in North America and Europe guarantee an uninterrupted supply for research and manufacturing.
There's a
"Molybdenum-99 Shortage Resource Center" page which has more useful background on the subject. There are about five places in the world that make this stuff, and not much excess capacity.
The U.S. Department of Energy started a project in 1995 to convert a research reactor at Sandia to medical isotope production. This was done after the last US commercial producer, in Tuxedo, NY, shut down. The Sandia effort was canceled, after it was working and able to produce isotopes, on July 30, 1999, by the Office of Isotope Programs at DOE.
There's a startup that claims they will start making this stuff with a linear accelerator in early 2008, but they sound flakey.
We'll see more women in game leadership positions. Games today are about artwork, social dynamics, and world design. The underlying technology isn't the limiting factor any more.
Ten years ago, consumer-grade graphics hardware was weak, frame rates were slow, people were struggling to get physics engines to work at all, network gaming was flakey, and attempts to build big worlds were choking on scaling problems. Now, that stuff just works.
The concurrency model is lame and buggy. Open Google Maps in Firefox 2. Roll the mouse wheel rapidly to zoom in and out. Watch the maps break up as the browser gets out of sync with the server and doesn't properly repair the window damage. It's like a window system from 1990 or so.
Firewalls and AJAX still don't play well together. Rewriting JavaScript source in the firewall is not the answer.
The conflicts between cross-site scripting, mashups, and security illustrate that Javascript's security model is inadequate.
The JSON concept opens security holes. JavaScript has the wrong primitives. In LISP, there's the reader, which takes in a string and turns it into an S-expression, and there's "eval", which executes an S-expression. In JavaScript, there's only "eval", which takes a string and runs it. Oops. Not the right tool for marshalling.
JavaScript itself isn't that bad a language, though. It's the integration with browsers that's not good enough.
Most US nuclear weapons were designed using computers under 1 MIPS. Even the fusion bombs. About 40 years ago, I was visiting a UNIVAC 1105 installation (the biggest all-vacuum-tube computer ever built as a commercial product, designed when Gen. Leslie Groves was at UNIVAC), and they'd done some work on bomb design. It took about two days per run, and they'd run the program at the same time some other location was running it. Every three hours, the console typewriter would print out a checksum, and they'd phone the other location to see if it matched. If not, they had to back up to the last checkpoint tape and restart.
This huge machine was comparable in power to a PC/AT with an FPU chip; a good 1985 desktop.
The silly thing about export controls on computers is that the U.S. Government keeps increasing the control threshold for "supercomputers". The current threshold is 750 gigaflops, which is a few racks of servers. In 1995, it was 2 gigaflops, or about where a low-end PC is today. Back in 1987, there was a big flap when Iran tried to get hold of a VAX 8600, which is about 0.005 gigaflops. But bomb design isn't getting any more difficult.
Any modern laptop can do the calculations necessary for bomb design. Deal with it.
Slashdot Mirror
Because of the Bayh-Dole Act, which commercialized federally-funded research.
Four different forces, superstrings, antineutrinos, strange quarks, neutralinos, gluons, and 26 dimensions.
The laws of physics are clearly the result of a bureaucracy.
There's a basic frustration in physics today that things are just too complicated at the bottom. There's a classic comment by I. I. Rabi, "Who ordered that?", made when the muon was discovered. The muon is a "heavy electron", the first elementary particle discovered that doesn't appear in ordinary atoms. Muons didn't seem to be necessary to physics, but there they were. That was the end of simple subatomic physics, and nobody has been able to put the mess back in the box since.
Actually, there are things to worry about.
Too many new applications have hard real time constraints. Copying movie-sized files around, no problem - TCP will throttle. Streaming HDTV without stuttering is much tougher. We're entering an era where the highest-traffic application needs a high quality of service. If resources are tight, there's good no place to throttle. VoIP works because it's a small fraction of traffic. Streaming HDTV looks to be a much larger fraction of traffic.
We still don't have a good answer to managing backbone congestion in pure datagram networks. The Internet today works because the congestion is out near the edges. If we get enough "last mile" bandwidth deployed that the backbone congests before the edges, packet loss rates will go way up. If we have about 2x excess capacity in the backbone, no problem. That's the solution we know.
Microsoft has proposed systems where "broadcast" video is multicast in real time with a high quality of service, while "video on demand" is heavily buffered and sent with a lower quality of service. That's an obvious solution; it's what multicast is for.
(Amusing thought: one solution to video buffering problems is commercials. When transport can't keep up and the player is getting close to running out of buffered content, play an extra locally-stored commercial or two. This lets the buffering refill. Download commercials in advance based on personalization info, then insert them as needed during playback. Don't put them in the main video streams at all.)
If you have the opportunity to look at query logs, you see how dumb most search engine queries are.
First, a big fraction of queries are simply navigational. Many are just URLs. The major search providers recognize these in the front end machines and send back canned answers, without even passing them to the real search engine. If you type "myspace" into Google, very little work is expended returning the canned reply.
After that, most queries are one word. Phrase queries are less common.
Few people seem to have noticed, but Google started returning results based on synonyms and homonyms a few weeks ago. There have been some significant algorithm changes recently.
Less than 1% of queries use any operators, like '"" or '-'.
The real problem with natural language queries, though, is that "Ask Jeeves" was a flop. Remember Ask Jeeves? That was a system designed to process queries written as sentences. But it wasn't used that way, and didn't succeed commercially.
First of all, no language knows what data is locked at compile time. The problem of deciding what is locked and what is not is undecidable, just like everything else that submits to the halting problem. There is no compiler that can decide when something happens in a program and when it does not.
Oh, another "halting problem" bogus answer. There are languages where the compiler knows what's locked at compile time. The Ada "rendezvous" approach knows, for example.
Secondly, a keyword like 'synchronized' does not buy you anything:
...
Thirdly, it's very easy to make a Java program deadlock using the 'synchronized' keyword. For example, let's say we have two classes that recursively call each other from different threads...instant deadlock. Yes. And that's a good thing. Deadlocks show up early in debugging; race conditions show up late. This is, in fact, a classic source of programming problems - lack of a clear understanding of when control is "inside" an object. Java has the problem that there's no way to say that control is temporarily leaving an object. The Microsoft Spec# team, which is doing proofs of correctness for C#, has addressed this, though.
The key to multithreading programming is to avoid locking altogether. It's possible to do it, using atomic functions at predefined places.
"Predefined places"? I know there's a cult of "lockless programming", but that approach is very difficult to debug.
Forthly, your solution on declaring items within a critical section does not work (see #1 for explanation). For example, what if you declare a pointer inside the critical section, and then deep in an algorithm, or worse, deep in a dll loaded at run-time, the pointer is assigned a value which points to a non-synchronized object?
That's why compilers need to know more about what locks what. Tracing dependency issues is better done by programs than by people.
#5, in databases, what is the most common approach is optimistic locking: you tell the database that you want to update X if Y's value is Z.
Oh, a "compare and swap" fan. Actually, most of the better databases accumulate a list of what objects have been touched by a transaction, and if there's an intersection between the lists for two transactions, one of them has to be backed out. Even MySQL does this now. There's a proposal to provide similar transaction-like semantics for C++, and that might be a promising idea. It's more idiot-proof than most other approaches.
Finally, the question 'who owns what' in a programming language shouldn't exist: nobody should own anything, freeing the programmer from worrying about ownership. This can happen only with garbage collection.
The trouble with garbage collection is that it introduces indeterminism into otherwise deterministic programs. Garbage collection is OK if you can afford random stalls and don't use destructors. Destructors and GC do not play well together. Microsoft tried, in Managed C++, to make them play together, and it wasn't a happy marriage. There, destructors can be called more than once.
Reference counting does a good job of managing memory without disallowing destructors. It's noteworthy that Perl and Python, both of which are reference counted, generally allow programmers to ignore memory allocation. But most reference counting systems are "naive"; the compiler implementing them doesn't known enough about reference counts to optimize them. This leads to performance problems. One can do better; the compiler should hoist reference count updates out of loops.
Critical sections are a high level future which must be in a library.
The problem is that a C++ compiler doesn't know what data is locked, and which data items are locked by which lock, because the language has no way to talk about that subject. OS-level primitives lock everything. The compiler has a hard time telling which data needs concurrency protection. Thus, the compiler can't diagnose race conditions.
If the language understood locking, one could do more checking at compile time. One could take a hard-nosed approach. Every variable has to be locked by something. Either it's locked by the object of which it is a member (like Java's "Synchronized"), or the thread to which it is local, or by some other object which owns the variable. This last is something for which a language needs descriptive syntax.
One approach would be syntax where the programmer declares a critical section, and lists everything that can be referenced within the critical section. But that might not be necessary. A system more like the way an SQL database decides transaction locking issues might be easier on the programmer.
The big memory headache in C and C++ is always "who owns what", something with which the language provides no assistance. That's the cause of dangling pointers and memory leaks, but it's also the cause of much locking trouble.
I have little hope for the C++ standards committee. It's dominated by people who think really l33t templates are really cool. Everything has to be a template feature. They're fooling around with a proposal for declaring variables atomic through something like atomic<int> n; This allows really l33t programmers to write really l33t code using really l33t lockless programming. But without the proofs of correctness needed to make that actually work reliably.
It's also long been Strostrup's position that concurrency is a library problem. As long as the OS provides threads and locking, it's not a language problem. This isn't good enough.
The fundamental problem is that, as currently defined, a C++ compiler has no idea which variables are shared between threads, and which are never shared. The compiler has no notion of critical sections. Fixing this requires some fundamental changes to the language. It's known what to do; Modula, Ada, and Java all have synchronization and isolation built into the language. But there's nothing like that in C++, and the designers of C++ don't want to admit their mistakes.
It's not just a C++ problem. Python has a similar issue. Python as a language doesn't deal with concurrency adequately. The main implementation, CPython, has a "global interpreter lock" that slows the thing down to single-CPU speed.
I have for over 6 years been thinking..of a 3d-dimmension processor that cross communicates over a diagonal matrix instead of the traditional serial and parallel communication model.
Six years, and you haven't discovered all the machines built to try that? This was a hot idea in the 1980s. Hypercubes, connection machines, and even perfect shuffle machines work something like that. There's a long history of multidimensional interconnect schemes. Some of them even work.
Wikia's business is monetizing fancruft. They have the Star Wars/Trek/Gate/Craft wikis. They're the obvious buyer for this content.
> There are major sites on the web which lack even proper HTML/HEAD/BODY tags.
All three of those tags are optional in an HTML 4.01 document (see the DTD for HTML 4.01).
From the HTML 4.01 spec, section 7.4.2:
"Every HTML document must have a TITLE element in the HEAD section."
So HEAD is "optional", TITLE is mandatory, and TITLE can only appear in HEAD. Right. Somebody should submit a DR on this, I suppose.
A more fundamental issue with hosted apps is that the app might go away.
It happens, even at Google. Remember Google Answers? One day, Google just turned it off.
Or the terms of service and pricing could change. If you're a Gmail user, you have no guarantee that Google won't start charging you tomorrow. Someday Google will have a down quarter, their stock will dive, and their management will be under pressure to find new revenue.
The first one is always free.
The current situation is awful.
Cisco has been running QNX in their high end routers for several years now. They call it "IOS XR", but it's QNX. Classic IOS, unlike QNX, isn't a protected-mode OS. In classic IOS, everything runs in one address space. They need to get beyond that. So maybe this is just opening up classic IOS as an end of life measure.
Here's the Holosonics device that does it, if you care. It's a cute trick of nonlinear acoustics. This thing has been around for about five years, used for niche applications like narration in musum displays. But usually at a range of about a meter or two. I'm amazed that they can make the thing work at 15-20m.
They haven't been successful in getting the cost down or the quality up. Otherwise, it would have market share in hands-free phones and computer speakers, where such directionality would be really useful.
My guess is that it will be shut down as a public nuisance in NYC.
I don't want my LinkedIn profile on other sites. All I'll get is spam.
LinkedIn has a problem with "LinkedIn Open Networkers", i.e. spammers, who just use LinkedIn to troll for contacts. Since LinkedIn doesn't have forums, they troll by using the "LinkedIn Answers" feature to ask bogus "questions". Much more of that and the question-answering system will be useless.
Here's the actual paper from which came most of the material in the article: "The Commercial Malware Industry", from the University of Auckland. More technical details.
New threats of interest:
Here's how it's done in a union shop. This is an Animation Guild contract.
Time worked on the employee's sixth (6th) workday of the workweek shall be paid at one and one-half (1 1/2) times the hourly rate provided herein for such employee's classification. Time worked on the employee's seventh (7th) workday of the workweek shall be paid at two (2) times the hourly rate provided herein for such employee's classification.
Minimum call for the sixth (6th) and seventh (7th) days shall be four (4) hours. In the event the actual time worked by such employee exceeds the four (4) hour minimum, s/he shall be paid for all time actually worked in 1/10th -hour increments.
All time worked in excess of fourteen (14) consecutive hours (including meal periods) from the time of reporting to work shall be Golden Hours and shall be paid at two (2) times the applicable hourly rate provided herein for such employee's classification.
Now that's the way it's supposed to work. There may be crunches when hours are long, but pay goes up, which discourages employers from overdoing it.
Note the "minimum call" provision. Calling someone at home to do work outside of normal hours triggers that, and costs the employer at least 4 hours pay. Again, emergencies are provided for, but they're billable, so employers don't overdo it.
Ask's parent company, IAC, is breaking up. They're a conglomerate; they own things like the Home Shopping Network, TicketMaster, Lending Tree, and CondoDirect. All those are being sold off. They're keeping all their "internet properties", like Excite (yes, that's where Excite ended up), CitySearch, Evite, Popular Screensavers (!), iWon, Match.com, and Zwinki. IAC collected many of the major losers from Web 1.0 under one corporate roof.
At this point, it hardly seems relevant what Ask does.
Maybe there is a legitimate purpose for this delay after uninstalling SP1? My best guess would be their Genuine disAdvantage thing is suspicious of closely-spaced registration events or something.
Probably something like that. Maybe you have to wait for propagation between Microsoft's servers as they track the state of your client. If you reconnect too soon, the server you happen to reach may not yet know the new state of your machine.
Oh, and remember that RC2 expires in June 2008. So you're installing a self-destruct on your system, and gambling that Microsoft will have a working final version out by then.
Let's take a look at the advertising from the company that actually sells the medical isotopes made at Chalk River:
MDS Nordion is the global leader in the supply and distribution of short-lived medical isotopes. It's what sets us apart.
There's a "Molybdenum-99 Shortage Resource Center" page which has more useful background on the subject. There are about five places in the world that make this stuff, and not much excess capacity.
The U.S. Department of Energy started a project in 1995 to convert a research reactor at Sandia to medical isotope production. This was done after the last US commercial producer, in Tuxedo, NY, shut down. The Sandia effort was canceled, after it was working and able to produce isotopes, on July 30, 1999, by the Office of Isotope Programs at DOE.
There's a startup that claims they will start making this stuff with a linear accelerator in early 2008, but they sound flakey.
We'll see more women in game leadership positions. Games today are about artwork, social dynamics, and world design. The underlying technology isn't the limiting factor any more.
Ten years ago, consumer-grade graphics hardware was weak, frame rates were slow, people were struggling to get physics engines to work at all, network gaming was flakey, and attempts to build big worlds were choking on scaling problems. Now, that stuff just works.
-
The concurrency model is lame and buggy. Open Google Maps in Firefox 2. Roll the mouse wheel rapidly to zoom in and out. Watch the maps break up as the browser gets out of sync with the server and doesn't properly repair the window damage. It's like a window system from 1990 or so.
-
Firewalls and AJAX still don't play well together. Rewriting JavaScript source in the firewall is not the answer.
-
The conflicts between cross-site scripting, mashups, and security illustrate that Javascript's security model is inadequate.
-
The JSON concept opens security holes. JavaScript has the wrong primitives. In LISP, there's the reader, which takes in a string and turns it into an S-expression, and there's "eval", which executes an S-expression. In JavaScript, there's only "eval", which takes a string and runs it. Oops. Not the right tool for marshalling.
JavaScript itself isn't that bad a language, though. It's the integration with browsers that's not good enough.Most US nuclear weapons were designed using computers under 1 MIPS. Even the fusion bombs. About 40 years ago, I was visiting a UNIVAC 1105 installation (the biggest all-vacuum-tube computer ever built as a commercial product, designed when Gen. Leslie Groves was at UNIVAC), and they'd done some work on bomb design. It took about two days per run, and they'd run the program at the same time some other location was running it. Every three hours, the console typewriter would print out a checksum, and they'd phone the other location to see if it matched. If not, they had to back up to the last checkpoint tape and restart.
This huge machine was comparable in power to a PC/AT with an FPU chip; a good 1985 desktop.
The silly thing about export controls on computers is that the U.S. Government keeps increasing the control threshold for "supercomputers". The current threshold is 750 gigaflops, which is a few racks of servers. In 1995, it was 2 gigaflops, or about where a low-end PC is today. Back in 1987, there was a big flap when Iran tried to get hold of a VAX 8600, which is about 0.005 gigaflops. But bomb design isn't getting any more difficult.
Any modern laptop can do the calculations necessary for bomb design. Deal with it.
Pumped hydroelectric is great where it's available, sure, but what would, say, New York City do? Pump out New Your Harbor?
No, they pump out a lake in the Catskill Mountains.