Sorry. I didn't mean DSNs, I meant the SMTP reply 550 Requested action not taken: mailbox unavailable. For a mistyped address, the sender's MTA generally drops a bounce message in their inbox. Spamware generally just ignores the reply. In no case does the rejecting MTA generate an email message.
My opinion is that Linux on a 1024-way is a spectacularly stupid idea, introduced more for the sexiness of having a 1024-way machine than for any practical benefits. Linux is simply not designed for scaling that large.
Not necessarily true. The NCSA's workload will probably be large 3D physics simulations. To scale well for that, you need
A scheduler that runs out of local data structures as much as possible.
A memory manager that stores the thread's page tables locally.
Forcible processor affinity for threads.
Forcible processor affinity for memory allocation.
Competent use of communication hardware, esp. semaphores.
All of these problems are either solved or trivially solvable. Not surprising, as the OS's biggest job for this sort of workload is to get the hell out of the way.
Argh. They're talking about SMTP replies, such as 550 Requested action not taken: mailbox unavailable. Those failure codes can have a message that is shown to the sender in the process of trying to send. The rejecting mail server does not generate an email of any kind.
Don't use an autoreply and turn your problem into my problem.
They're talking about sending it out as part of the SMTP delivery failure notification, not as an email message. Spammers will ignore it. Legit senders will get an email generated by their own mail server.
In this case the physical security layer was compromised - this is why encryption would have helped.
If you can freely walk around inside the building, you own the data.
As far as redundancy, there are password managers, etc.
The redundancy I mentioned was in regard to data corruption. With many encryption schemes, there's no such thing as corrupting one bit. Look up the bit error rates for commodity RAM sometime: it's scary.
And if the info is really that sensitive, wouldn't data loss be the lesser evil compared to sensitive info ending up in unfriendly hands?
Depends. Nuke data tends to be rather expensive and slow to recreate.
Remind me again of what form of strong encryption they were using for said data? Oh wait a minute...
Repeat after me: Encryption is not magic pixie dust.
Sprinkling it around at random does not necessarily improve security. Encryption can actually reduce security by distracting people from higher-risk threats. It also increases the probability of irrecoverable data loss unless unusual redundancy measures are taken.
Before everything was stored electronically somehow I doubt people obtained sensitive info just because someone forgot to lock a vault door...
Read Richard Feynman's accounts of the operational security of LANL. Their security has leaked like a sieve since the Manhattan Project days.
I doubt supercaps will ever be practical for giant-scale energy storage. The best current ones only store around 40 kJ of energy per kg of capacitor. By comparison, launching an Apollo-style mission takes on the order of 10^12 J. Even if we charitably assumed supercaps could be made that can store 400 kJ/kg, we'd need 2500 tonnes of supercap. That would seem to be rather expensive, and the cost scales linearly with increased capacity. I'd also expect supercaps to wear out quicker than an SMES system.
The problem of nuclear power is merely one of "waste"...
BZZT! Wrong! The really troublesome waste can be recycled (and very profitably I might add).
And there lies the real problem: it's not a big step from reprocessing waste to separation of bomb isotopes. The people against nukes have a political agenda all right, just not the one you think.
The power storage problem might be overcome using ultracapacitors. You can get 2600 farad capacitors (not ufd, farads) at 2.5V today,...
Capacitor energy density is pathetic: cost and energy both scale as physical size.
Superconductive coils are better: Cost scales a little less than radius, but energy scales as radius squared. On the other hand there may be problems getting the energy out fast enough. (Problems like radially pumping ground water that rips open the coil container.)
Another possibility is gas dynamic lasers. They scale all the way up, and fuel/oxygen tanks are cheap.
The X-prize guys get all the press, but Orbital actually puts stuff in orbit.
Orbital's approach is insanely expensive and logistically apalling. It's fine for launching must-not-fail satellites serving lucrative markets, but worthless for the human conquest of space. What I want is the flying equivalent of Conestoga wagons.
Heh. I saved an ancient 286 motherboard as a sort of perverse work of art. It has a dozen or two change wires, an added capacitor hanging over other components, and so forth. Texas Instruments left the PC business for a reason.
Hmm... Gold and indium. I'll have to keep that combo in mind.
Simple acids would be just awful. No matter where you put it, it would vaporize and etch everything: connectors, switches, component leads up inside the plastic IC packages, you name it.
I'm talking about ordinary production rework. For example, a solder bridge on a PCI connector. Such problems do happen, and are fairly easy to diagnose. What with cheap Asian labor it might even be worthwhile to fix, but the cost equation changes if lots of scraping is needed.
You also occassionally get a bad batch of, say, capacitors but don't find out until too late. Or maybe a reel of mislabeled resistors. Salvaging the production lot would be nice, but doing so when a coating was used would be way expensive.
In my experience
coating leads with gold works fine, why all this
tin, lead, nickel crap when gold on copper works
well already?
A bit of the gold dissolves in the solder, forming an intermetallic compound that is brittle, making the soldered junction weak. Solderable coatings are chosen so that they either form ductile alloys with the solder (e.g., tin plating), or only dissolve to a negligible extent (e.g., nickel).
Likewise, why use lead-based solders when indium is so nice to use: it wets metals easily, it wets itself and it is soft so solder joints would actually heal themselves at room temperature if cracks appeared for some reason?
1. Solderable metals oxidize over time, which has to be handled using a flux to chemically suck up the oxygen. At low temperatures it takes an aggressive flux to get the job done, and the flux remains aggressive at normal operating temperatures. Ergo extensive cleaning is required. By working at higher temperatures, a less agressive flux can be used. You can get fluxes for lead-tin soldering that don't even have to be cleaned off the board.
2. Strength. Indium solders are fairly weak, especially at elevated operating temperatures. You may think this isn't an issue, but I've accidentally peeled components off of lead-tin soldered circuit boards. I shudder to think how squishy indium would be. Fatigue failures from vibration would be a worry.
Yup. Tiny metal wires can carry surprisingly high currents without burning out.
It's even worse when the defect is on a printed circuit board, as even the plastic board material makes a pretty good heat sink for the tiny bridge. I've seen microscopic bridges on PCBs carry hundreds of milliamps. Finding failures like that is incredibly annoying.
1. Make rework much harder. The plastic coating has to be carefully scraped away to fix a soldering error. Even with cheap Chinese labor it would be expensive.
2. Affect impedances. Commodity motherboards already have low (let's be honest: negative) timing margin. Random-thickness plastic coating over those long squiggly traces would make a bad situation worse. OTOH, it might not be so bad for the self-timed serial links that are becoming popular.
3. Have a higher failure rate. The spray will sometimes get onto connector and jumper terminals, and that sort of flakiness is way expensive.
Hmm, we always use business data as primary key. I don't see the point of using artificial keys except for very few cases (to optimize away a composite key that would get too many elements and be too cumbersome to use).
Example: Transactions outside the database engine. Typical case would be using an abstract SKU for an e-commerce system, so things don't fall apart when the marketing fools decide to "improve" the model number. SQL CASCADE can't help you there.
If your properly define a domain that has a specific, meaningfull "NULL" value, you should also provide operators to deal with it, in particular '=' (comparison).
And that gets you to the "what the hell does this operator do given these data types?" problem seen everywhere that operator overloading is allowed. The permutations can rapidly become overwhelming.
Ah ha! Accrual. That answers my main question. The option is basically held in trust for the recipient, so they don't have any tax issues at the time of granting. Granting and expiration only affect the company's position. I knew it couldn't be as stupid as I was making it out, but I just didn't see how.
...the SQL language retrieves information from SQL databases, not relational ones (the former, Chamberlin's own contribution) due to failure to understand the latter....
Makes me wish I understood a bit more, for it's all a bit confusing.
Fabian Pascal is smart and well-informed, but a zealot. Like all zealots he is willing to sacrifice anything and everything for his vision of technical purity.
One of his specific complaints is about SQL NULL values being "unrelational". As an example, a real-world designer might use the following table in a genealogy DB:
CREATE TABLE people (
person_id INTEGER NOT NULL,
name VARCHAR(100) NOT NULL,
birth DATE NOT NULL,
death DATE
)
If a person hasn't died yet, then people.death would be NULL. Well that just isn't relational enough for our friend Pascal. Since relations can be used to express optional values, then by God they have to be:
CREATE TABLE people (
person_id INTEGER PRIMARY KEY,
name VARCHAR(100) NOT NULL,
birth DATE NOT NULL
)
CREATE TABLE deaths (
person_id UNIQUE INTEGER REFERENCES people,
death_date DATE NOT NULL
)
It's pure, correctly formed, and worse than useless. It causes a profusion of tables: one for every optional value. It turns every simple query ("tell me useful stuff about this person") into a join ("find matching rows from several tables about this person"). The database server has to waste time enforcing deaths.person_id's pointless UNIQUE constraint. Cascading deletion has to be used to clean up deaths when a row is deleted in people.
The simple fact is that the world is full of optional, single-valued data. NULL-allowed columns express that data efficiently, without confusion, and without breakage. Community college database designers have no trouble using the convention productively. It may be a little inelegant, but it is pragmatic and balanced engineering. The only whining you hear is from zealots like Pascal who heap fire and fury on others, but never seem to deliver the mythic PerfectoRDBMS.
Except that the guy in your example doesn't have a job, he has welfare.
When robots can provide nearly everything, idleness is acceptable as a matter of policy. Until then a stable, free society must keep the free rider problem in check.
Creating work for work's sake is economically harmful.
The natural state of the human animal is work. Hard work, and lots of it. Enforced idleness is torture--the primary torture used in modern "civilized" prisons. It is a direct economic cost, and idle hands being the devil's tools is an indirect economic cost.
At least I live in a highly-developed country, where we're leading the world in outsourcing everything. It's the less-developed countries where life will really suck. They'll be gung ho moving their economy over to export capitalism when the exponential automation curve slams them into a brick wall.
But I presume an unexercised option would be considered a liability.
Nope. The whole point of "expensing" is to realize the option as an expense up-front. The stock value of the company takes it on the chin the instant the option is granted. That's arguably a good idea. But treating the transaction as cash-equivalent may have other implications...
Aside from the fact that expensing options makes for more accurate financial statements, it reduces a company's tax burden, thus making them more profitable in reality (rather than just on paper).
I'm not clear on the accounting. What happens when an option expires without being exercised? Does the company treat it as income? Taxable income? At the market value at grant? At the strike price? At the market price? If the expiration value is different than the original granting expense, does the employee pay income tax on the "value" they received? Or is it a loss for the employee? Or is it both, and therefore a wash?
And if the company is paying an expense, then the recipient is receiving equivalent income. Does that mean employees have to pay income tax on stock options at the time they are granted?
Slashdot Mirror
Sorry. I didn't mean DSNs, I meant the SMTP reply 550 Requested action not taken: mailbox unavailable. For a mistyped address, the sender's MTA generally drops a bounce message in their inbox. Spamware generally just ignores the reply. In no case does the rejecting MTA generate an email message.
- A scheduler that runs out of local data structures as much as possible.
- A memory manager that stores the thread's page tables locally.
- Forcible processor affinity for threads.
- Forcible processor affinity for memory allocation.
- Competent use of communication hardware, esp. semaphores.
All of these problems are either solved or trivially solvable. Not surprising, as the OS's biggest job for this sort of workload is to get the hell out of the way."Cluttering" their inbox when they mistype an address, that is. 99.99% of users want that to happen.
Argh. They're talking about SMTP replies, such as 550 Requested action not taken: mailbox unavailable. Those failure codes can have a message that is shown to the sender in the process of trying to send. The rejecting mail server does not generate an email of any kind.
Sprinkling it around at random does not necessarily improve security. Encryption can actually reduce security by distracting people from higher-risk threats. It also increases the probability of irrecoverable data loss unless unusual redundancy measures are taken.
Read Richard Feynman's accounts of the operational security of LANL. Their security has leaked like a sieve since the Manhattan Project days.You cannot tell it to not follow URIs for embedded images and such.
I doubt supercaps will ever be practical for giant-scale energy storage. The best current ones only store around 40 kJ of energy per kg of capacitor. By comparison, launching an Apollo-style mission takes on the order of 10^12 J. Even if we charitably assumed supercaps could be made that can store 400 kJ/kg, we'd need 2500 tonnes of supercap. That would seem to be rather expensive, and the cost scales linearly with increased capacity. I'd also expect supercaps to wear out quicker than an SMES system.
And there lies the real problem: it's not a big step from reprocessing waste to separation of bomb isotopes. The people against nukes have a political agenda all right, just not the one you think.
Superconductive coils are better: Cost scales a little less than radius, but energy scales as radius squared. On the other hand there may be problems getting the energy out fast enough. (Problems like radially pumping ground water that rips open the coil container.)
Another possibility is gas dynamic lasers. They scale all the way up, and fuel/oxygen tanks are cheap.
Orbital's approach is insanely expensive and logistically apalling. It's fine for launching must-not-fail satellites serving lucrative markets, but worthless for the human conquest of space. What I want is the flying equivalent of Conestoga wagons.Heh. I saved an ancient 286 motherboard as a sort of perverse work of art. It has a dozen or two change wires, an added capacitor hanging over other components, and so forth. Texas Instruments left the PC business for a reason.
Simple acids would be just awful. No matter where you put it, it would vaporize and etch everything: connectors, switches, component leads up inside the plastic IC packages, you name it.
You also occassionally get a bad batch of, say, capacitors but don't find out until too late. Or maybe a reel of mislabeled resistors. Salvaging the production lot would be nice, but doing so when a coating was used would be way expensive.
2. Strength. Indium solders are fairly weak, especially at elevated operating temperatures. You may think this isn't an issue, but I've accidentally peeled components off of lead-tin soldered circuit boards. I shudder to think how squishy indium would be. Fatigue failures from vibration would be a worry.
It's even worse when the defect is on a printed circuit board, as even the plastic board material makes a pretty good heat sink for the tiny bridge. I've seen microscopic bridges on PCBs carry hundreds of milliamps. Finding failures like that is incredibly annoying.
1. Make rework much harder. The plastic coating has to be carefully scraped away to fix a soldering error. Even with cheap Chinese labor it would be expensive.
2. Affect impedances. Commodity motherboards already have low (let's be honest: negative) timing margin. Random-thickness plastic coating over those long squiggly traces would make a bad situation worse. OTOH, it might not be so bad for the self-timed serial links that are becoming popular.
3. Have a higher failure rate. The spray will sometimes get onto connector and jumper terminals, and that sort of flakiness is way expensive.
Ah ha! Accrual. That answers my main question. The option is basically held in trust for the recipient, so they don't have any tax issues at the time of granting. Granting and expiration only affect the company's position. I knew it couldn't be as stupid as I was making it out, but I just didn't see how.
One of his specific complaints is about SQL NULL values being "unrelational". As an example, a real-world designer might use the following table in a genealogy DB:
If a person hasn't died yet, then people.death would be NULL. Well that just isn't relational enough for our friend Pascal. Since relations can be used to express optional values, then by God they have to be: It's pure, correctly formed, and worse than useless. It causes a profusion of tables: one for every optional value. It turns every simple query ("tell me useful stuff about this person") into a join ("find matching rows from several tables about this person"). The database server has to waste time enforcing deaths.person_id's pointless UNIQUE constraint. Cascading deletion has to be used to clean up deaths when a row is deleted in people.The simple fact is that the world is full of optional, single-valued data. NULL-allowed columns express that data efficiently, without confusion, and without breakage. Community college database designers have no trouble using the convention productively. It may be a little inelegant, but it is pragmatic and balanced engineering. The only whining you hear is from zealots like Pascal who heap fire and fury on others, but never seem to deliver the mythic PerfectoRDBMS.
At least I live in a highly-developed country, where we're leading the world in outsourcing everything. It's the less-developed countries where life will really suck. They'll be gung ho moving their economy over to export capitalism when the exponential automation curve slams them into a brick wall.
And if the company is paying an expense, then the recipient is receiving equivalent income. Does that mean employees have to pay income tax on stock options at the time they are granted?