It's called following the spirit of the law instead of the letter.
More accurately, this is called "judicial activism". Also known as, "when the judge substitutes his or her idea of what the law ought to do for what the text of the law really does."
I don't want to be at trial and have the judge decide, "you know, Mr. Hansen, the law as written in the books doesn't work the way I think it should work. So instead of applying the law, I'm going to apply what I think ought to be instead. Deal with it."
That, Zath, is called judicial tyranny. Some very sharp people wrote some essays warning against allowing this to happen. You can find these essays collected into convenient book form and sold as the Federalist Papers.I strongly suggest you read them.
Let me give you a couple of scholarly references here, too--this one comes courtesy of Justice Antonin Scalia's monograph, A Matter Of Interpretation, which argues compellingly against judicial activism:
"It is the law that governs, not the intent of the lawgiver. That seems to be the essence of the famous American ideal set forth in the Massachusetts constitution: A government of laws, not of men. Men may intend what they will; but it is only the laws that they enact which bind us."
Or, as Dean James M. Landis of Harvard Law School wrote in Harvard's 1930 law review,
"The gravest sins are perpetrated in the name of the intent of the legislature.... To condone in these instances the practice of talking in terms of the intent of the legislature, as if the legislature had attributed a particular meaning to certain words, when it is apparent that the intent is that of the judge, is to condone atavistic practices too reminiscent of the medicine man."
Moving again to Scalia:
"Of all the criticisms leveled against [strict interpretation of laws], the most mindless is that it is `formalistic'. The answer to that is, of course it's formalistic! The rule of law is about form. If, for example, a citizen performs an act--let us say the sale of a certain technology to a foreign country--which is prohibited by a widely publicized bill proposed by the Administration and passed by both houses of Congress, but not yet signed by the President, that sale is lawful. It is of no consequence that everyone knows both houses of Congress and the President wish to prevent that sale. Before the wish becomes a binding law, it must be embodied in a bill that passes both houses and is signed by the President. Is that not formalism? A murderer has been caught with blood on his hands, bending over the body of the victim; a neighbor with a video camera has filmed the crime; and the murderer has confessed in writing and on videotape. We nonetheless insist that before the state can punish this miscreant, it must conduct a full-dress criminal trial that results in a verdict of guilty. Is that not formalism? Long live formalism! It is what makes a government a government of laws and not of men."
(All emphasis is as found in the original documents.)
Of course, his position is nothing to sneeze at either, but it worries me to have such a strict justice in that position.
Only those appointed to the Supreme Court are called "justices". Everyone else is just called "judge".
It's not illegal to be in possession of burglary tools. If that was the case, you'd be breaking the law just by keeping a crowbar in the trunk of your car.
It's illegal to be in possession of burglary tools while committing a burglary, under the theory that bringing burglary tools to a burglary shows that you approached the burglary with premeditation and planning. Premeditated, thought-out-in-advance crimes are almost always punished more severely than "amateur night" or heat-of-the-moment crimes.
E.g.., if I use a rock to break a car window, reach inside and pull out the stereo... maybe I'm a career criminal, or maybe I'm just someone who made a really stupid choice.
But if I've picked the lock on the door with a SlimJim, brought open specialized tools to crack the dash and remove the radio in 15 seconds flat, then it's a pretty good bet I've done this crime before and I'll continue to do it in the future--both of which make me a more serious criminal in the eyes of the law.
While a language like C# may be nothing really new under the sun, there is still "value" in learning it
I never said there wasn't. I said it was neither interesting nor useful--that's all. Are there jobs out there which require proficiency in.NET/C#/VB.NET/pick-your-CLRed-language? Sure. There are rather a lot of them in comparison to other older languages. If you're looking for employment, there's a lot worse you can do than adding C#, VB.NET and Java to your resume.
But that said... there's a difference between "what will increase my income" and "what is interesting or useful".
Although, with benefit of a few days' hindsight, "useful" may not be precisely the word I'm looking for--English is often admirably precise in its vocabulary, and other times maddeningly vague. I don't mean "useful" in the sense of utility. It's beyond question in my mind that C#/VB.NET/.NET possesses utility, in that it's an effective tool for solving certain problems.
I mean "useful" in the sense of "advancing the state of the art, and/or making hackers' lives significantly easier". As I've said before, I see very little difference between.NET and Java, save for.NET was designed from the get-go to be targetable by multiple languages (within the same paradigm--not to harp on it, just to make clear that I still think it's not multi-language in any interesting or useful sense), while the JVM was always closely tied to Java and other languages grew to target it more by necessity than design.
So how does.NET make programmers' lives easier? If your programmers are married to Microsoft and unwilling to broaden their horizons by learning new (non-MS) languages, then yes, I imagine it makes their lives easier. But speaking personally, I don't quite feel comfortable saying that making life easier for the lowest common denominator equates to being "useful".
By that logic, Terminator 3 is a more "useful" movie than Seven Samurai, because it more successfully catered to the lowest common denominator of moviegoers.
So--after yet another longwinded post, I fear--my position is basically this:
C# and.NET are meant to leverage the skills of the lowest common denominator of programmers, at the cost of the skills of the hackers. If a hacker sees that a Scheme continuation would solve a problem elegantly and quickly, s/he can't do that in.NET; the CLR is specifically designed to cater to a totally different sort of programmer than the hacker.
If you're in an environment where you're surrounded by lowest common denominator programmers, then yes,.NET makes a lot of sense. So does Java, if you can get them to learn a non-MS language.
But if you're a hacker, look elsewhere. Because there's nothing interesting or useful to you in.NET. It's stuff you've seen before. Learn C# and.NET, if only to put it on your resume and increase your marketability. But don't drink Microsoft's Kool-Aid and think that it's better than sliced bread. It's just another VM which targets a specific paradigm of languages.
You'll see a dropdown box saying "Comment Reply". Select "Email", then save your changes and you're done.
That said, I hope you enjoyed that act of friendliness, because I see nothing but disagreements in the near future.:)
What I really wanted to point out was the fallacy of the "language worth learning" quote, in that it only uses "worth" in once sense of value, when in fact the majority of people in the world who deal with technology use a completely different set of criteria on which to place the "value" of learning a language - and this usually comes down to $ in the end.
I'm utterly unconvinced that the software industry has any sensible valuation of worth, particularly in the management field. Paul Graham has a great essay on why this is--what it boils down to is management's knowledge of the field and languages is primarily imparted by marketing glossies and marketing departments (either Sun's or Microsoft's, it appears). Hackers' knowledge of the field is primarily imparted by catastrophic disasters.
As an example of this, Java is being used in a lot of places today where it really shouldn't be. In 2000 during the height of the Java hype, a friend of mine who worked for a major United States bank was driven up the wall by a management decision to migrate all their COBOL apps to Java. "After all," Management said, "COBOL is a dead language and these are fifty-year-old legacy programs."
To a hacker, COBOL may well be a dead language, but a program that has a fifty-year record of reliability basically swaggers around the RAID array menacing newer programs with <DenisLeary>"yeah, I may be written in COBOL, but I haven't crashed in fifty fucking years, guy, okay?"</DenisLeary>
So was this major U.S. bank wise in their decision to migrate all their legacy COBOL apps to Java? By your logic, yes, because industry knows the value of software and can properly evaluate things in a dollars-and-cents manner. I'm certain there was a great business case made for this mass migration. I can't imagine what else could make a bank decide to undertake something that risky.
And after about 150 man-years of work--optimistically, about $15 million of development--the program was abruptly cancelled due to the fabled dollars and cents failing to materialize.
Wherever you look in the industry there are all sorts of examples like this. In the commercial software industry, I've seen far more projects fail than succeed. How does the industry respond to this? By declaring any software project that comes in at under 500% cost overrun and a year late to be a "qualified success".
The thing is, we all know this. We've all read The Mythical Man-Month. Most of us--I imagine you do, I know I do--have horror stories about death marches and the Project That Would Not Die And Yet Never Truly Lived, Either.
Given the spectacularly poor state of software management nowadays, I'm deeply skeptical of any claims that the software industry is in a position to make accurate estimations of value, whether that value be in a financial or a technical sense.
I'm a hacker. I don't know about how to value software in a financial sense. (I'm heartened by the fact that nobody else does, either.) On the other hand, I do know how to value software in a technical and artistic sense. My estimations will differ from the next hacker's, but in general we can make certain agreements--that COBOL is crufty but COBOL legacy apps that run for fifty years rock, that LISP is woefully underused, that people keep on using C when they really want to be using something else, etc.
if they had the same skillset level and also the same level of mathema
First, I'll ask you to please see my comments in the other response to you...
Done.
In fact, even his "brilliant" graph algorithms may have been top-class during his time.
As far as I can see, remember, or am concerned, Dijkstra's contributions to computational graph theory are fundamental to the field. If you think they're brilliant-in-quotation-marks, all I can ask is what you've discovered that's comparable.
That's not meant as an insult or a challenge, incidentally. It's meant to say that in hindsight many things become obvious which required real genius to see them in the first place. Dijkstra's graph algorithms are simple and straightforward, and in hindsight they're obvious--but let's not forget that the only reason they're obvious to us is because Dijkstra had the insight to see, in foresight, what's obvious in hindsight.
If in your academic mind you truly believe this,
You keep on calling me that, an "academic". The reality is I'm nothing of the sort except in the sense that I'm a graduate student. I'm a hacker, not an ivory-tower academic. I believe in solving problems and sharing those solutions with the world.
It's axiomatic that if you're faced with a problem, one of the worst things you can do is stubbornly insist that it be solved with X technique. You have to show some flexibility. You have to be able to approach the problem from different angles. For GUIs, I've found object orientation is almost always best. For scientific programming, I've found template metaprogramming best. For using computers in math theory courses, I use LISP or ML. For writing system-level software, I use C++. Etcetera.
My insistence on multiple paradigms is unequivocally not born out of "academia", a word which it seems you're using as an insult. My insistence on multiple paradigms is born out of my demand that I use the right tool for the job..NET claims it will support all programming languages. It doesn't. It doesn't even come close. Once you realize.NET is just another VM that can be more easily targeted by compilers, you realize that "hey, this is... really... not all that interesting or useful," as I said in the post which kicked all this off.
Why is it not all that interesting or useful? Because we already have that with Java. We've got a virtual machine which provides managed services and is targeted by over 60 different languages, all of which can use all the facilities of the other languages once their code has been reduced down to bytecodes. We've got a VM which allows you to interface with the native hardware to get a massive speed boost.
Am I talking about.NET or am I talking about Java? In this case, Java. (I can't confirm the 60+ languages bit, but that's the number I see. Last I heard, Java supported more languages than.NET, but this gap was rapidly closing and the numbers are a couple of months old.)
So where is.NET interesting? It was interesting the first time Sun did it with Java. (Or, for us dinosaurs, it was interesting the first time I saw UCSD Pascal do it with their VM.) It's not interesting this second time around.
Where is.NET useful? If you're married to the Microsoft platform, then I guess it's useful. But really, where's the huge win for.NET over Java? There isn't one. It's an alternative to Java, not really something new and innovative, not something which allows you to solve more problems than Java or even allows you to solve them all that much differently.
That said, is it useful for Company A, which prefers VB, and Company B, which uses Java, to be able to collaborate on software, each using their preferred language, with their results able to be executed on a shared VM?
Sure it is. That's not what I mean when I say ".NET is neither useful nor intere
The parent post is only ill-informed about Lisp macros. Those are done at compile time, and there's nothing about the CLR that would preclude them.
Just to clarify what I said--
I didn't mean it to be interpreted as "LISP macros cannot be called from C# or VB.NET". As you said, LISP macros are just compile-time entities, and they'd reduce down to CLR just fine (modulo other LISPisms which wouldn't reduce--CLOS is mostly macro calls, IIRC, and CLOS doesn't reduce).
What I meant was, you can't use LISP macros from non-LISP.NET languages. For instance, if I write an object Foo with method Bar in C#, I can export it trivially to VB.NET. Great. Whee. This is surprisingly useful and very limited all at the same time. What would be really impressive is if I could do something like
I.e., if.NET was really as crossplatform and multilanguage as it claims, there should be some way to export a LISP macro. I'm unaware of any way a LISP macro could be sensibly exported to another.NET language.
Take a look at my original formulation again--
Show me how to... export a C++ template, or a LISP macro.
Hopefully that makes it clear as to what I was talking about--not whether LISP-style macros could be supported in the CLR (they can be), but whether or not they could be exported to other languages (I'm deeply skeptical).
Strange. I know Java pretty well. Learning Java pretty well, coming from a C++ background, took me a few weeks. I was productive inside of two days, but it took me a fair bit of time to start thinking in Java as opposed to thinking in C++. I.e., I was trying to apply C++ solutions to Java problems, and was having real troubles.
Once I had Java thoroughly in hand, I picked up the O'Reilly book on C#. I figured if I'd drunk Sun's Kool-Aid, I should really take a gulp of Microsoft's, too. It took me four hours to reach the same level of proficiency in C# that I have in Java. Yeah. Four hours. I still had to look up things in C# in a Nutshell, but I thoroughly understood everything from interfaces to inheritance to events to I/O to basic Winforms in four hours flat.
Any language where you can become proficient in four hours is not a "different language". It's the same language, just with a different syntax.
As Dijkstra famously said, "Any language which does not change the way you think about programming is not worth learning."
C# is not worth learning. Hasn't changed the way I think about programming. LISP did (two years to become proficient). C++ did (eight years). Scheme did. Modula-3 did. PROLOG did. Smalltalk did.
C# did not. As such, I don't think "VB + C# == `multiple languages'". I think at best you can call them the same language, highly derivative of Java which is in turn highly derivative of Smalltalk with C++ syntax, with a slightly more flexible VM than the JVM and better support for foreign syntaxes.
Re:quote: "the CLR integrates all prog. languages"
on
Does C# Measure Up?
·
· Score: 1
"all languages" is clearly meant to imply all languages in the domain of ".NET-enabled programming languages".
Sorry, but I call bullshit on this one.
All languages equals all languages. To say "all languages" and then subtly change the meaning of "all" to "object-oriented languages only" (when OO languages are a small part of the programming language world, and often not the optimal choice) is to engage in sophistries that not even lawyers would use.
All means all. And when Microsoft says the CLR supports all languages, they can only mean it in the very tenuous manner by which they'd say "... well, it is Turing-complete, you know."
CLR supports C# and subsets of the C# functionality. That's it--bam--period--end of sentence. While technically you can get away with non-C# subsets in some languages, you do so at the price of throwing away everything that's good about the CLR. For that reason, I stand by my original statement (long since forgotten in this thread, I'm sure):
CLR and.NET are not multilanguage in any useful or interesting sense. In order to be multilanguage in a useful and/or interesting sense, it would have to support a wide variety of programming paradigms. It doesn't. It doesn't support such wonderfully cool things as LISP object-orientation, Scheme continuations, PROLOG declarative logic... it supports the OO paradigm, which is today's Buzzword Bingo word. If it's going to be useful tomorrow, it needs to support a lot more than that.
Look at LISP. It's going on sixty years old and it's still being used. Why? Because it supports lambda calculus and functional programming--it supports OOP--it supports procedural programming--it supports logic-based programming--name the paradigm; LISP supports it.
C++ is much the same way. It supports procedural, OO and templatized programming out-of-the-box, and you can do functional programming in C++ without too much unpleasantness if you're willing to use the STL and do template metaprogramming.
I expect LISP and C++ will still be used in 30 years. No, I'm not kidding. I don't think they'll still be used in their present forms, but I do expect they'll still be around.
I'll be very surprised if Java and.NET survive that long.
LISP was designed by McCarthy not for natural language processing--that wasn't even a field of study back in the '50s when he invented LISP--but purely for academic research. Here's the thing: while the Universal Turing Machine is a complete model of computation, it sucks for anything outside of toy theoretical problems. The UTM is simply too awkward and kludgy a model. Is it complete? Yes. Is it accurate? Yes. Is it unspeakably gross? Yes.
Alonzo Church developed a competing computational theory called the lambda calculus. The lambda calculus is a complete computational model, and it's breathtakingly simple and elegant. Really; going from the UTM to the lambda calculus is like going from darkness into light.
So in the '50s, the lambda calculus was still reasonably new. McCarthy decided to make a totally theoretical language--one which was never intended to be implemented--to allow algorithms to be expressed in lambda form, the better to analyze them for correctness, runtime analysis, etc.
Not long after McCarthy wrote the language description, an enterprising graduate student actually figured out a way to implement LISP on real hardware. And thus, McCarthy's LISP was born (aka LISP 1.5).
Natural language processing came along much later, in the '80s. AI researchers used LISP extensively not because LISP was designed for AI, but because LISP had the greatest flexibility and power of any language of the day.
In fact, I'd be hard-pressed to name any languages today which can beat LISP in power and flexibility. There are a few worthy contenders, but almost all of the worthy contenders build on LISP's heritage instead of representing entirely new directions in computer science.
Before you go about slamming a language, you may wish to learn the language's history.
If I understand the.NET framework correctly, there is no way to support either multiple inheritance or templates--in which case C++ cannot be accurately modeled in.NET. Nor will Java be.NETtable after 1.5, which will introduce pale imitations of templates (but imitation enough to give the CLR a hissyfit).
The.NET CLR does not support multiple languages. It supports one language--C#. Its "multiple language support" comes from being able to compile down many functionally-identical languages with different syntaxes down to the same bytecodes.
But truly different languages are not representable in the CLR. Show me how to do a Scheme continuation in the CLR, please, or export a C++ template, or a LISP macro.
The only languages.NET supports are those which are subsets of C#. And once you realize that,.NET becomes much less interesting.
(Warning: haven't used.NET much in the last few months. Last I checked these things were true, but after being very unimpressed with.NET I haven't kept up with things.)
We already HAVE the different language.
on
Secure Programming
·
· Score: 1
It's called LISP.
(And before anyone says "... but you can't write a kernel in LISP!", there are several LISP Machines out there which beg to disagree with you.)
The information in question was gathered with the authority of a writ issued by a court clerk. No judge was involved. THIS is the most illegal, unconstitutional part of the DMCA. The Constitution quite clearly says that only THE JUDICIARY (ie: JUDGES) can issue these kinds of orders.
Are you high?
The information was retrieved under subpoena, not under search warrant. The Fourth Amendment doesn't talk about civil litigation, only about criminal litigation... not only that, the Fourth Amendment nowhere mentions the necessity of it being a judicial warrant. The Fourth Amendment, in its entirety, reads
"The right of the people to be secure in their persons, houses, papers, and effects, against unreasonable searches and seizures, shall not be violated, and no warrants shall issue, but upon probable cause, supported by oath or affirmation, and particularly describing the place to be searched, and the persons or things to be seized."
No mention of a judge anywhere.
So in the first place, you're on crack because you think the Fourth Amendment includes words it very clearly doesn't; and in the second place, you're on crack because you think the Fourth Amendment covers writs of subpoena.
Writs of subpoena come to us from the English Common Law, and have never been repudiated by any court. Heck, they're even mentioned in the Bill of Rights (indirectly, where it specifies criminal defendants will have the right to "compulsory processes" to procure evidence).
If you're going to rant about the law, you should probably learn what the law is and what it is not.
Read my other post in this thread. If you can refute that, along with references to back up your refutations, then I'll consider what you're saying. Otherwise, you're arguing against FAS, and I trust them and their analysis a hell of a lot more than anything I read from J. Random Physics Wannabe on Slashdot.
they decay much too quickly (half-life ~ 1.56 microseconds) to catalyze many reactions
They're up to one muon catalyzing 150 D-D fuses in a laboratory environment. Depending on your definition of "many", this is either "nowhere near enough" or "surprisingly a lot, all things considered". Both are, IMO, defensible viewpoints.
Theoretical break-even was reached in the early '80s, where muon-catalyzed fusion produced as much energy (in fuses) as it took to create the muons. It's still a long, long way from (a) scalable break-even (i.e., works for more than just proof-of-concept) or (b) practical break-even (i.e., produces enough energy to pay for the energy cost of the muons, plus the operating costs of the people and personnel required to run the reactor).
in a nuclear reaction (not chemical), U-238 + H --> Np + 2 neutrons
If you're using "H" to denote a proton, be advised that's not what's happening here. The U-238 is hit by a very energetic fusion-originated neutron and undergoes fission, at the end of which it's split into two halves of an average electrostatic charge of +46.
Please see my other posts in this thread. H-bombs do not work anything like what you're talking about here.
Of course, it's possible that IHBT. In which case, have a nice day.:)
Check FAS. Quoting liberally from that document, and with minor editing for clarity:
=====
The quest for the H-bomb was based in part on a false premise: that there is an inherent limitation on the size and power of a uranium fission bomb, namely the limitation imposed by critical mass considerations. When a sphere of uranium-235 any larger than a softball is assembled, a nuclear chain reaction will start prematurely. This must, of course, be avoided until the moment of detonation. If only one critical mass (one softball) is used, the size of the explosion is limited to a few tens of kilotons. This was the supposed limitation.
[After some discussion of ways to get around the limitation...] Another technique was to use uranium-238, which has no critical mass limitation and which, by the way, is dirt cheap. The bomb can have as much uranium-238 as the designer wants, in any shape, but the neutrons for fission must come from an outside source, namely fusion.
Despite the public hype about the hydrogen bomb contest, there was a serious problem with any weapon based mostly on fusion energy. It doesn't produce a very satisfactory explosion. In uranium fission, 90% of the energy is released as the kinetic energy of highly-charged, fully-ionized fission fragments. With a high electrostatic charge, these fission fragments convert their energy to heat quickly and within inches, producing an intense point source of heat. The resulting blast and fire is the whole point of a nuclear explosion.
In fusion, on the other hand, only 20% of the energy is released as the kinetic energy of charged fusion products, and their electrostatic charge is only a plus two. Because of the lower charge, the Bremsstrahlung Effect, which produces the heat, is much less powerful with fusion products than with fission products. More importantly, the bulk of the fusion energy (80%) is carried off by neutrally-charged neutrons which can travel hundreds of yards before colliding with something and giving up their energy. By themselves, neutrons are very inefficient producers of blast and fire. But an H-bomb which is designed so that every fusion-produced neutron results in a uranium fission event is very efficient. It not only converts relatively useless neutron energy into blast and fire energy, it also multiplies the total energy release by a factor of ten or more. The neutron, with an energy value of 14 MeV, produces a fission event worth 180 MeV.
In a weapon optimized for fission-fusion symbiosis, fission actually dominates the explosion, providing 90% of the total energy and virtually all of the energy that contributes to blast and fire.
=====
Read the entire article if you have time, BTW. It's absolutely excellent.
Here's a scary thought: do you think some lines of fusion research have been suppressed because they could lead to "pure" fusion bombs (H-bombs without an A-bomb trigger)?
No. Hydrogen bombs are horribly misnamed; they're really just very, very large fission bombs. The initial fission core goes off; the heat and pressure creates a very brief fusion reaction; as a consequence of this fusion reaction a huge amount of very energetic neutrons are produced; and the neutrons from the fusion reaction are then used to induce a critical reaction in a thick jacket of U-238 which surrounds the nuclear core.
U-238 normally has no critical mass, so you can put as much of it around the core as you like. But when there's a fusion reaction going on inside the U-238 jacket, and it's bathed in a sea of energetic neutrons, U-238 goes nuclear.
The only purpose of the hydrogen step is to create the neutrons required for an extremely large fissile step. In the '60s we did some experiments (the Bassoon Tests) with true fusion H-bombs and the results were generally not as impressive as with fusion-boosted A-bombs.
Muon-catalyzed fusion is real and comes within a factor of 15 of being commercially viable--muon-catalyzed reactions became self-sustaining in a theoretical sense in the 1980s (generating more energy out than was put in), but there's a long way between theoretical and practical self-sufficiency.
They hit the theoretical; they're within a factor of 15 of practical. This makes muon-catalyzed fusion the closest to viability of any fusion method so far. On the other hand, people have been throwing themselves at it for 20 years now trying to close that factor-of-15 gap and haven't gotten anywhere. Nowadays it's thought that there are some physical limitations on muon fusion which will prevent it from closing that factor-of-15 gap, and muon catalysis is no longer considered to be the most promising light on the horizon.
Muons are not 300,000 times the mass of an electron; they're 207 times the mass of an electron (or appreciably close to the mass of a proton).
Not true--cold fusion is possible, just not like Pons and Fleischmann described. (Nothing like it, in fact.) The quantum mechanical description of the energy states of a hydrogen atom are identical whether you use electrons or muons; use either, the hydrogen atom doesn't care. (Now, when you ask the very important question "yeah, genius, now how do you create quintillions of muon-replaced hydrogen atoms?", I'll resort to the classic physicist's dodge: "that's an engineering issue; go ask an engineer.")
QMech says that if you've got hydrogens with muon shells instead of electron shells, you'll see spontaneous fusion reactions at very low temperatures. The reasons why are hard to explain without going into a lot of math, but it's quite possible according to the Standard Model.
Of course, there's a world of difference between possible and feasible. But physicists are only concerned with the possible. Feasible is for engineers.:)
This is the case in a small town (like the one in which I'm currently living). Try living in a city like San Francisco and see how many of the employees know you by sight. Practically none of them will. It has nothing to do with their competency and everything to do with the sheer quantities of their customers, the rapidly-revolving nature of bank jobs (you're working at the front one week, the back the next), etc., etc.
With Citibank, I closed my account when I was moving away from San Jose. An hour later I was back with a jarful of change that I'd forgotten to cash out for bills. Not only did I not find anyone there who knew me--I didn't find anyone there who remembered me from an hour before.
That's just the nature of the beast for large banks nowadays.
Another professional security geek: I disagree.
on
Users feel Password Rage
·
· Score: 2, Informative
I agree with you in part, but I think it's premature to dismiss biometric security entirely. There are instances and occasions where it makes good sense. For instance, let's say that you're a bank teller. Every day you deal with a steady stream of customers, the vast majority who don't know their account number.
No problem. Do what Citibank's been doing for the last few years; put ATM keypads at each teller window. To authenticate yourself, swipe your ATM card and enter your PIN. Poof. While this isn't the best system around it's not too bad, especially since there's a teller standing right beside it to make sure you don't do anything obviously hinky with it.
But then there are going to be lots of people who don't have their ATM card with them for whatever reason--let's say they accidentally left it at home. Okay, the system still works, but instead of swiping your ATM card and punching your PIN you show the teller your driver's license. The teller looks you up in their database, makes sure you match your photograph, etcetera.
What happens if your wallet's been stolen and you have no identification? Let's say you're mugged and you lose your wallet, and you're forced at gunpoint to give up your PIN. As soon as you get away you run to your bank and talk to the teller. You have no ATM card. You have no driver's license. There's no way they can authenticate you.
But you still have your thumbprint.
So now you authenticate yourself via a thumbprint scanner. The teller takes the thumbprint scanner out of a locked drawer (where it's been stored precisely to limit the amount of access people can have to it, and thus, their opportunities for malfeasance with it) and sets it out in front of you.
Presto, you're logged in, and the teller can have some degree of confidence that you're a customer and need to have your credit cards and ATM access cancelled.
Yes, there are significant problems with biometrics over the Net. Most of these problems can be alleviated by adding a trusted human being to the equasion, someone to stand by the biometric reader and make sure nobody does anything obviously hinky with it. (In this case, the teller serves that function.)
I certainly agree that biometrics aren't a panacea and they aren't a replacement for a real security policy. But I think you go a little too far to say that security people think biometrics ought never be used for over-the-Net transactions.
Re:Adjust your tinfoil hat, guy.
on
Cracking GSM
·
· Score: 1
Using an elite hidden network for industrial spying is clearly against the law in both countries.
Cite me the law which says this, please? It's clearly illegal for a private citizen to do it; but the law allows intelligence agencies a great deal of flexibility to execute their duties, as directed by the Executive Branch of the government. Want to change this? Change the law or change the executive members of government who are giving these orders.
Does Echelon exist? Yes. Does Echelon exist to eavesdrop on electronic communications? Yes. Does Echelon exist to eavesdrop on United States communications? Well... that's a thornier question. The NSA is allowed to do it, at the explicit request of the FBI, after being presented with a judicial warrant, and with a couple of oversight committees being informed, but they're not allowed to do it of their own accord.
And you haven't presented one shred of evidence to suggest that it's being used illegally. Only that it exists, and since it exists it must be being used illegally--a cause-and-effect relation which I don't buy.
Do the US/UK signals intelligence services enjoy an extremely close relationship? Yes. Is this relationship formalized in classified agreements? Yes. Is the purpose of this relationship to evade the laws forbidding both governments from spying on their own citizens in violation of their laws? You seem to be claiming that "since the relationship exists, it must be being used for nefarious purposes."
Prove it.
I'm not asking you to prove Echelon exists, nor that a US/UK relationship exists, or that the NSA (in accordance with US law and at the order of executive officials in government) has spied on European industry to counter industrial espionage from the French DGSE. All of this is true.
I'm just asking you to prove your accusations that they are breaking the law. Which you haven't done, and which you seem incapable of realizing that the law might be very different from what you think it is.
Slashdot Mirror
A Justice of the Peace is a state-level position. At the Federal level, the only justices are those which sit on the Supreme Court.
It's called following the spirit of the law instead of the letter.
... To condone in these instances the practice of talking in terms of the intent of the legislature, as if the legislature had attributed a particular meaning to certain words, when it is apparent that the intent is that of the judge, is to condone atavistic practices too reminiscent of the medicine man."
More accurately, this is called "judicial activism". Also known as, "when the judge substitutes his or her idea of what the law ought to do for what the text of the law really does."
I don't want to be at trial and have the judge decide, "you know, Mr. Hansen, the law as written in the books doesn't work the way I think it should work. So instead of applying the law, I'm going to apply what I think ought to be instead. Deal with it."
That, Zath, is called judicial tyranny. Some very sharp people wrote some essays warning against allowing this to happen. You can find these essays collected into convenient book form and sold as the Federalist Papers. I strongly suggest you read them.
Let me give you a couple of scholarly references here, too--this one comes courtesy of Justice Antonin Scalia's monograph, A Matter Of Interpretation, which argues compellingly against judicial activism:
"It is the law that governs, not the intent of the lawgiver. That seems to be the essence of the famous American ideal set forth in the Massachusetts constitution: A government of laws, not of men. Men may intend what they will; but it is only the laws that they enact which bind us."
Or, as Dean James M. Landis of Harvard Law School wrote in Harvard's 1930 law review,
"The gravest sins are perpetrated in the name of the intent of the legislature.
Moving again to Scalia:
"Of all the criticisms leveled against [strict interpretation of laws], the most mindless is that it is `formalistic'. The answer to that is, of course it's formalistic! The rule of law is about form. If, for example, a citizen performs an act--let us say the sale of a certain technology to a foreign country--which is prohibited by a widely publicized bill proposed by the Administration and passed by both houses of Congress, but not yet signed by the President, that sale is lawful. It is of no consequence that everyone knows both houses of Congress and the President wish to prevent that sale. Before the wish becomes a binding law, it must be embodied in a bill that passes both houses and is signed by the President. Is that not formalism? A murderer has been caught with blood on his hands, bending over the body of the victim; a neighbor with a video camera has filmed the crime; and the murderer has confessed in writing and on videotape. We nonetheless insist that before the state can punish this miscreant, it must conduct a full-dress criminal trial that results in a verdict of guilty. Is that not formalism? Long live formalism! It is what makes a government a government of laws and not of men."
(All emphasis is as found in the original documents.)
Of course, his position is nothing to sneeze at either, but it worries me to have such a strict justice in that position.
Only those appointed to the Supreme Court are called "justices". Everyone else is just called "judge".
It's not illegal to be in possession of burglary tools. If that was the case, you'd be breaking the law just by keeping a crowbar in the trunk of your car.
It's illegal to be in possession of burglary tools while committing a burglary, under the theory that bringing burglary tools to a burglary shows that you approached the burglary with premeditation and planning. Premeditated, thought-out-in-advance crimes are almost always punished more severely than "amateur night" or heat-of-the-moment crimes.
E.g.., if I use a rock to break a car window, reach inside and pull out the stereo... maybe I'm a career criminal, or maybe I'm just someone who made a really stupid choice.
But if I've picked the lock on the door with a SlimJim, brought open specialized tools to crack the dash and remove the radio in 15 seconds flat, then it's a pretty good bet I've done this crime before and I'll continue to do it in the future--both of which make me a more serious criminal in the eyes of the law.
While a language like C# may be nothing really new under the sun, there is still "value" in learning it
.NET/C#/VB.NET/pick-your-CLRed-language? Sure. There are rather a lot of them in comparison to other older languages. If you're looking for employment, there's a lot worse you can do than adding C#, VB.NET and Java to your resume.
.NET and Java, save for .NET was designed from the get-go to be targetable by multiple languages (within the same paradigm--not to harp on it, just to make clear that I still think it's not multi-language in any interesting or useful sense), while the JVM was always closely tied to Java and other languages grew to target it more by necessity than design.
.NET make programmers' lives easier? If your programmers are married to Microsoft and unwilling to broaden their horizons by learning new (non-MS) languages, then yes, I imagine it makes their lives easier. But speaking personally, I don't quite feel comfortable saying that making life easier for the lowest common denominator equates to being "useful".
.NET are meant to leverage the skills of the lowest common denominator of programmers, at the cost of the skills of the hackers. If a hacker sees that a Scheme continuation would solve a problem elegantly and quickly, s/he can't do that in .NET; the CLR is specifically designed to cater to a totally different sort of programmer than the hacker.
.NET makes a lot of sense. So does Java, if you can get them to learn a non-MS language.
.NET. It's stuff you've seen before. Learn C# and .NET, if only to put it on your resume and increase your marketability. But don't drink Microsoft's Kool-Aid and think that it's better than sliced bread. It's just another VM which targets a specific paradigm of languages.
I never said there wasn't. I said it was neither interesting nor useful--that's all. Are there jobs out there which require proficiency in
But that said... there's a difference between "what will increase my income" and "what is interesting or useful".
Although, with benefit of a few days' hindsight, "useful" may not be precisely the word I'm looking for--English is often admirably precise in its vocabulary, and other times maddeningly vague. I don't mean "useful" in the sense of utility. It's beyond question in my mind that C#/VB.NET/.NET possesses utility, in that it's an effective tool for solving certain problems.
I mean "useful" in the sense of "advancing the state of the art, and/or making hackers' lives significantly easier". As I've said before, I see very little difference between
So how does
By that logic, Terminator 3 is a more "useful" movie than Seven Samurai, because it more successfully catered to the lowest common denominator of moviegoers.
So--after yet another longwinded post, I fear--my position is basically this:
C# and
If you're in an environment where you're surrounded by lowest common denominator programmers, then yes,
But if you're a hacker, look elsewhere. Because there's nothing interesting or useful to you in
if you have some kind of auto-email thing turned on let me know, because I'm a relative /. newbie and have no idea how to set that up if it exists...
:)
Check your User Page.
You'll see a dropdown box saying "Comment Reply". Select "Email", then save your changes and you're done.
That said, I hope you enjoyed that act of friendliness, because I see nothing but disagreements in the near future.
What I really wanted to point out was the fallacy of the "language worth learning" quote, in that it only uses "worth" in once sense of value, when in fact the majority of people in the world who deal with technology use a completely different set of criteria on which to place the "value" of learning a language - and this usually comes down to $ in the end.
I'm utterly unconvinced that the software industry has any sensible valuation of worth, particularly in the management field. Paul Graham has a great essay on why this is--what it boils down to is management's knowledge of the field and languages is primarily imparted by marketing glossies and marketing departments (either Sun's or Microsoft's, it appears). Hackers' knowledge of the field is primarily imparted by catastrophic disasters.
As an example of this, Java is being used in a lot of places today where it really shouldn't be. In 2000 during the height of the Java hype, a friend of mine who worked for a major United States bank was driven up the wall by a management decision to migrate all their COBOL apps to Java. "After all," Management said, "COBOL is a dead language and these are fifty-year-old legacy programs."
To a hacker, COBOL may well be a dead language, but a program that has a fifty-year record of reliability basically swaggers around the RAID array menacing newer programs with <DenisLeary>"yeah, I may be written in COBOL, but I haven't crashed in fifty fucking years, guy, okay?"</DenisLeary>
So was this major U.S. bank wise in their decision to migrate all their legacy COBOL apps to Java? By your logic, yes, because industry knows the value of software and can properly evaluate things in a dollars-and-cents manner. I'm certain there was a great business case made for this mass migration. I can't imagine what else could make a bank decide to undertake something that risky.
And after about 150 man-years of work--optimistically, about $15 million of development--the program was abruptly cancelled due to the fabled dollars and cents failing to materialize.
Wherever you look in the industry there are all sorts of examples like this. In the commercial software industry, I've seen far more projects fail than succeed. How does the industry respond to this? By declaring any software project that comes in at under 500% cost overrun and a year late to be a "qualified success".
The thing is, we all know this. We've all read The Mythical Man-Month. Most of us--I imagine you do, I know I do--have horror stories about death marches and the Project That Would Not Die And Yet Never Truly Lived, Either.
Given the spectacularly poor state of software management nowadays, I'm deeply skeptical of any claims that the software industry is in a position to make accurate estimations of value, whether that value be in a financial or a technical sense.
I'm a hacker. I don't know about how to value software in a financial sense. (I'm heartened by the fact that nobody else does, either.) On the other hand, I do know how to value software in a technical and artistic sense. My estimations will differ from the next hacker's, but in general we can make certain agreements--that COBOL is crufty but COBOL legacy apps that run for fifty years rock, that LISP is woefully underused, that people keep on using C when they really want to be using something else, etc.
if they had the same skillset level and also the same level of mathema
First, I'll ask you to please see my comments in the other response to you...
.NET claims it will support all programming languages. It doesn't. It doesn't even come close. Once you realize .NET is just another VM that can be more easily targeted by compilers, you realize that "hey, this is ... really ... not all that interesting or useful," as I said in the post which kicked all this off.
.NET or am I talking about Java? In this case, Java. (I can't confirm the 60+ languages bit, but that's the number I see. Last I heard, Java supported more languages than .NET, but this gap was rapidly closing and the numbers are a couple of months old.)
.NET interesting? It was interesting the first time Sun did it with Java. (Or, for us dinosaurs, it was interesting the first time I saw UCSD Pascal do it with their VM.) It's not interesting this second time around.
.NET useful? If you're married to the Microsoft platform, then I guess it's useful. But really, where's the huge win for .NET over Java? There isn't one. It's an alternative to Java, not really something new and innovative, not something which allows you to solve more problems than Java or even allows you to solve them all that much differently.
Done.
In fact, even his "brilliant" graph algorithms may have been top-class during his time.
As far as I can see, remember, or am concerned, Dijkstra's contributions to computational graph theory are fundamental to the field. If you think they're brilliant-in-quotation-marks, all I can ask is what you've discovered that's comparable.
That's not meant as an insult or a challenge, incidentally. It's meant to say that in hindsight many things become obvious which required real genius to see them in the first place. Dijkstra's graph algorithms are simple and straightforward, and in hindsight they're obvious--but let's not forget that the only reason they're obvious to us is because Dijkstra had the insight to see, in foresight, what's obvious in hindsight.
If in your academic mind you truly believe this,
You keep on calling me that, an "academic". The reality is I'm nothing of the sort except in the sense that I'm a graduate student. I'm a hacker, not an ivory-tower academic. I believe in solving problems and sharing those solutions with the world.
It's axiomatic that if you're faced with a problem, one of the worst things you can do is stubbornly insist that it be solved with X technique. You have to show some flexibility. You have to be able to approach the problem from different angles. For GUIs, I've found object orientation is almost always best. For scientific programming, I've found template metaprogramming best. For using computers in math theory courses, I use LISP or ML. For writing system-level software, I use C++. Etcetera.
My insistence on multiple paradigms is unequivocally not born out of "academia", a word which it seems you're using as an insult. My insistence on multiple paradigms is born out of my demand that I use the right tool for the job.
Why is it not all that interesting or useful? Because we already have that with Java. We've got a virtual machine which provides managed services and is targeted by over 60 different languages, all of which can use all the facilities of the other languages once their code has been reduced down to bytecodes. We've got a VM which allows you to interface with the native hardware to get a massive speed boost.
Am I talking about
So where is
Where is
That said, is it useful for Company A, which prefers VB, and Company B, which uses Java, to be able to collaborate on software, each using their preferred language, with their results able to be executed on a shared VM?
Sure it is. That's not what I mean when I say ".NET is neither useful nor intere
Just to clarify what I said--
I didn't mean it to be interpreted as "LISP macros cannot be called from C# or VB.NET". As you said, LISP macros are just compile-time entities, and they'd reduce down to CLR just fine (modulo other LISPisms which wouldn't reduce--CLOS is mostly macro calls, IIRC, and CLOS doesn't reduce).
What I meant was, you can't use LISP macros from non-LISP
Take a look at my original formulation again--
Show me how to
Hopefully that makes it clear as to what I was talking about--not whether LISP-style macros could be supported in the CLR (they can be), but whether or not they could be exported to other languages (I'm deeply skeptical).
But VB+C#=="multiple languages".
Strange. I know Java pretty well. Learning Java pretty well, coming from a C++ background, took me a few weeks. I was productive inside of two days, but it took me a fair bit of time to start thinking in Java as opposed to thinking in C++. I.e., I was trying to apply C++ solutions to Java problems, and was having real troubles.
Once I had Java thoroughly in hand, I picked up the O'Reilly book on C#. I figured if I'd drunk Sun's Kool-Aid, I should really take a gulp of Microsoft's, too. It took me four hours to reach the same level of proficiency in C# that I have in Java. Yeah. Four hours. I still had to look up things in C# in a Nutshell, but I thoroughly understood everything from interfaces to inheritance to events to I/O to basic Winforms in four hours flat.
Any language where you can become proficient in four hours is not a "different language". It's the same language, just with a different syntax.
As Dijkstra famously said, "Any language which does not change the way you think about programming is not worth learning."
C# is not worth learning. Hasn't changed the way I think about programming. LISP did (two years to become proficient). C++ did (eight years). Scheme did. Modula-3 did. PROLOG did. Smalltalk did.
C# did not. As such, I don't think "VB + C# == `multiple languages'". I think at best you can call them the same language, highly derivative of Java which is in turn highly derivative of Smalltalk with C++ syntax, with a slightly more flexible VM than the JVM and better support for foreign syntaxes.
"all languages" is clearly meant to imply all languages in the domain of ".NET-enabled programming languages".
.NET are not multilanguage in any useful or interesting sense. In order to be multilanguage in a useful and/or interesting sense, it would have to support a wide variety of programming paradigms. It doesn't. It doesn't support such wonderfully cool things as LISP object-orientation, Scheme continuations, PROLOG declarative logic... it supports the OO paradigm, which is today's Buzzword Bingo word. If it's going to be useful tomorrow, it needs to support a lot more than that.
.NET survive that long.
Sorry, but I call bullshit on this one.
All languages equals all languages. To say "all languages" and then subtly change the meaning of "all" to "object-oriented languages only" (when OO languages are a small part of the programming language world, and often not the optimal choice) is to engage in sophistries that not even lawyers would use.
All means all. And when Microsoft says the CLR supports all languages, they can only mean it in the very tenuous manner by which they'd say "... well, it is Turing-complete, you know."
CLR supports C# and subsets of the C# functionality. That's it--bam--period--end of sentence. While technically you can get away with non-C# subsets in some languages, you do so at the price of throwing away everything that's good about the CLR. For that reason, I stand by my original statement (long since forgotten in this thread, I'm sure):
CLR and
Look at LISP. It's going on sixty years old and it's still being used. Why? Because it supports lambda calculus and functional programming--it supports OOP--it supports procedural programming--it supports logic-based programming--name the paradigm; LISP supports it.
C++ is much the same way. It supports procedural, OO and templatized programming out-of-the-box, and you can do functional programming in C++ without too much unpleasantness if you're willing to use the STL and do template metaprogramming.
I expect LISP and C++ will still be used in 30 years. No, I'm not kidding. I don't think they'll still be used in their present forms, but I do expect they'll still be around.
I'll be very surprised if Java and
LISP was designed by McCarthy not for natural language processing--that wasn't even a field of study back in the '50s when he invented LISP--but purely for academic research. Here's the thing: while the Universal Turing Machine is a complete model of computation, it sucks for anything outside of toy theoretical problems. The UTM is simply too awkward and kludgy a model. Is it complete? Yes. Is it accurate? Yes. Is it unspeakably gross? Yes.
Alonzo Church developed a competing computational theory called the lambda calculus. The lambda calculus is a complete computational model, and it's breathtakingly simple and elegant. Really; going from the UTM to the lambda calculus is like going from darkness into light.
So in the '50s, the lambda calculus was still reasonably new. McCarthy decided to make a totally theoretical language--one which was never intended to be implemented--to allow algorithms to be expressed in lambda form, the better to analyze them for correctness, runtime analysis, etc.
Not long after McCarthy wrote the language description, an enterprising graduate student actually figured out a way to implement LISP on real hardware. And thus, McCarthy's LISP was born (aka LISP 1.5).
Natural language processing came along much later, in the '80s. AI researchers used LISP extensively not because LISP was designed for AI, but because LISP had the greatest flexibility and power of any language of the day.
In fact, I'd be hard-pressed to name any languages today which can beat LISP in power and flexibility. There are a few worthy contenders, but almost all of the worthy contenders build on LISP's heritage instead of representing entirely new directions in computer science.
Before you go about slamming a language, you may wish to learn the language's history.
Currently there are C#, C++, VB, and even Java
.NET framework correctly, there is no way to support either multiple inheritance or templates--in which case C++ cannot be accurately modeled in .NET. Nor will Java be .NETtable after 1.5, which will introduce pale imitations of templates (but imitation enough to give the CLR a hissyfit).
.NET CLR does not support multiple languages. It supports one language--C#. Its "multiple language support" comes from being able to compile down many functionally-identical languages with different syntaxes down to the same bytecodes.
.NET supports are those which are subsets of C#. And once you realize that, .NET becomes much less interesting.
.NET much in the last few months. Last I checked these things were true, but after being very unimpressed with .NET I haven't kept up with things.)
If I understand the
The
But truly different languages are not representable in the CLR. Show me how to do a Scheme continuation in the CLR, please, or export a C++ template, or a LISP macro.
The only languages
(Warning: haven't used
It's called LISP.
(And before anyone says "... but you can't write a kernel in LISP!", there are several LISP Machines out there which beg to disagree with you.)
"Epiphany" refers to either a flash of insight, or the day of the year in which the three magi are alleged to have visited the Christ child.
Of course, an even more accurate term for "Epiphany" would be "January 6".
And the most accurate term for "Epiphany" is "my birthday".
The information in question was gathered with the authority of a writ issued by a court clerk. No judge was involved. THIS is the most illegal, unconstitutional part of the DMCA. The Constitution quite clearly says that only THE JUDICIARY (ie: JUDGES) can issue these kinds of orders.
Are you high?
The information was retrieved under subpoena, not under search warrant. The Fourth Amendment doesn't talk about civil litigation, only about criminal litigation... not only that, the Fourth Amendment nowhere mentions the necessity of it being a judicial warrant. The Fourth Amendment, in its entirety, reads
"The right of the people to be secure in their persons, houses, papers, and effects, against unreasonable searches and seizures, shall not be violated, and no warrants shall issue, but upon probable cause, supported by oath or affirmation, and particularly describing the place to be searched, and the persons or things to be seized."
No mention of a judge anywhere.
So in the first place, you're on crack because you think the Fourth Amendment includes words it very clearly doesn't; and in the second place, you're on crack because you think the Fourth Amendment covers writs of subpoena.
Writs of subpoena come to us from the English Common Law, and have never been repudiated by any court. Heck, they're even mentioned in the Bill of Rights (indirectly, where it specifies criminal defendants will have the right to "compulsory processes" to procure evidence).
If you're going to rant about the law, you should probably learn what the law is and what it is not.
Read my other post in this thread. If you can refute that, along with references to back up your refutations, then I'll consider what you're saying. Otherwise, you're arguing against FAS, and I trust them and their analysis a hell of a lot more than anything I read from J. Random Physics Wannabe on Slashdot.
they decay much too quickly (half-life ~ 1.56 microseconds) to catalyze many reactions
They're up to one muon catalyzing 150 D-D fuses in a laboratory environment. Depending on your definition of "many", this is either "nowhere near enough" or "surprisingly a lot, all things considered". Both are, IMO, defensible viewpoints.
Theoretical break-even was reached in the early '80s, where muon-catalyzed fusion produced as much energy (in fuses) as it took to create the muons. It's still a long, long way from (a) scalable break-even (i.e., works for more than just proof-of-concept) or (b) practical break-even (i.e., produces enough energy to pay for the energy cost of the muons, plus the operating costs of the people and personnel required to run the reactor).
in a nuclear reaction (not chemical), U-238 + H --> Np + 2 neutrons
:)
If you're using "H" to denote a proton, be advised that's not what's happening here. The U-238 is hit by a very energetic fusion-originated neutron and undergoes fission, at the end of which it's split into two halves of an average electrostatic charge of +46.
Please see my other posts in this thread. H-bombs do not work anything like what you're talking about here.
Of course, it's possible that IHBT. In which case, have a nice day.
It is possible that the Hydrogen bomb does not create a fusion reaction
All modern H-bombs fuse hydrogen as their secondary stage, immediately preceding the very large fission stage.
Check FAS. Quoting liberally from that document, and with minor editing for clarity:
=====
The quest for the H-bomb was based in part on a false premise: that there is an inherent limitation on the size and power of a uranium fission bomb, namely the limitation imposed by critical mass considerations. When a sphere of uranium-235 any larger than a softball is assembled, a nuclear chain reaction will start prematurely. This must, of course, be avoided until the moment of detonation. If only one critical mass (one softball) is used, the size of the explosion is limited to a few tens of kilotons. This was the supposed limitation.
[After some discussion of ways to get around the limitation...] Another technique was to use uranium-238, which has no critical mass limitation and which, by the way, is dirt cheap. The bomb can have as much uranium-238 as the designer wants, in any shape, but the neutrons for fission must come from an outside source, namely fusion.
Despite the public hype about the hydrogen bomb contest, there was a serious problem with any weapon based mostly on fusion energy. It doesn't produce a very satisfactory explosion. In uranium fission, 90% of the energy is released as the kinetic energy of highly-charged, fully-ionized fission fragments. With a high electrostatic charge, these fission fragments convert their energy to heat quickly and within inches, producing an intense point source of heat. The resulting blast and fire is the whole point of a nuclear explosion.
In fusion, on the other hand, only 20% of the energy is released as the kinetic energy of charged fusion products, and their electrostatic charge is only a plus two. Because of the lower charge, the Bremsstrahlung Effect, which produces the heat, is much less powerful with fusion products than with fission products. More importantly, the bulk of the fusion energy (80%) is carried off by neutrally-charged neutrons which can travel hundreds of yards before colliding with something and giving up their energy. By themselves, neutrons are very inefficient producers of blast and fire. But an H-bomb which is designed so that every fusion-produced neutron results in a uranium fission event is very efficient. It not only converts relatively useless neutron energy into blast and fire energy, it also multiplies the total energy release by a factor of ten or more. The neutron, with an energy value of 14 MeV, produces a fission event worth 180 MeV.
In a weapon optimized for fission-fusion symbiosis, fission actually dominates the explosion, providing 90% of the total energy and virtually all of the energy that contributes to blast and fire.
=====
Read the entire article if you have time, BTW. It's absolutely excellent.
Here's a scary thought: do you think some lines of fusion research have been suppressed because they could lead to "pure" fusion bombs (H-bombs without an A-bomb trigger)?
No. Hydrogen bombs are horribly misnamed; they're really just very, very large fission bombs. The initial fission core goes off; the heat and pressure creates a very brief fusion reaction; as a consequence of this fusion reaction a huge amount of very energetic neutrons are produced; and the neutrons from the fusion reaction are then used to induce a critical reaction in a thick jacket of U-238 which surrounds the nuclear core.
U-238 normally has no critical mass, so you can put as much of it around the core as you like. But when there's a fusion reaction going on inside the U-238 jacket, and it's bathed in a sea of energetic neutrons, U-238 goes nuclear.
The only purpose of the hydrogen step is to create the neutrons required for an extremely large fissile step. In the '60s we did some experiments (the Bassoon Tests) with true fusion H-bombs and the results were generally not as impressive as with fusion-boosted A-bombs.
Muon-catalyzed fusion is real and comes within a factor of 15 of being commercially viable--muon-catalyzed reactions became self-sustaining in a theoretical sense in the 1980s (generating more energy out than was put in), but there's a long way between theoretical and practical self-sufficiency.
They hit the theoretical; they're within a factor of 15 of practical. This makes muon-catalyzed fusion the closest to viability of any fusion method so far. On the other hand, people have been throwing themselves at it for 20 years now trying to close that factor-of-15 gap and haven't gotten anywhere. Nowadays it's thought that there are some physical limitations on muon fusion which will prevent it from closing that factor-of-15 gap, and muon catalysis is no longer considered to be the most promising light on the horizon.
Muons are not 300,000 times the mass of an electron; they're 207 times the mass of an electron (or appreciably close to the mass of a proton).
Not true--cold fusion is possible, just not like Pons and Fleischmann described. (Nothing like it, in fact.) The quantum mechanical description of the energy states of a hydrogen atom are identical whether you use electrons or muons; use either, the hydrogen atom doesn't care. (Now, when you ask the very important question "yeah, genius, now how do you create quintillions of muon-replaced hydrogen atoms?", I'll resort to the classic physicist's dodge: "that's an engineering issue; go ask an engineer.")
:)
QMech says that if you've got hydrogens with muon shells instead of electron shells, you'll see spontaneous fusion reactions at very low temperatures. The reasons why are hard to explain without going into a lot of math, but it's quite possible according to the Standard Model.
Of course, there's a world of difference between possible and feasible. But physicists are only concerned with the possible. Feasible is for engineers.
This is the case in a small town (like the one in which I'm currently living). Try living in a city like San Francisco and see how many of the employees know you by sight. Practically none of them will. It has nothing to do with their competency and everything to do with the sheer quantities of their customers, the rapidly-revolving nature of bank jobs (you're working at the front one week, the back the next), etc., etc.
With Citibank, I closed my account when I was moving away from San Jose. An hour later I was back with a jarful of change that I'd forgotten to cash out for bills. Not only did I not find anyone there who knew me--I didn't find anyone there who remembered me from an hour before.
That's just the nature of the beast for large banks nowadays.
I agree with you in part, but I think it's premature to dismiss biometric security entirely. There are instances and occasions where it makes good sense. For instance, let's say that you're a bank teller. Every day you deal with a steady stream of customers, the vast majority who don't know their account number.
No problem. Do what Citibank's been doing for the last few years; put ATM keypads at each teller window. To authenticate yourself, swipe your ATM card and enter your PIN. Poof. While this isn't the best system around it's not too bad, especially since there's a teller standing right beside it to make sure you don't do anything obviously hinky with it.
But then there are going to be lots of people who don't have their ATM card with them for whatever reason--let's say they accidentally left it at home. Okay, the system still works, but instead of swiping your ATM card and punching your PIN you show the teller your driver's license. The teller looks you up in their database, makes sure you match your photograph, etcetera.
What happens if your wallet's been stolen and you have no identification? Let's say you're mugged and you lose your wallet, and you're forced at gunpoint to give up your PIN. As soon as you get away you run to your bank and talk to the teller. You have no ATM card. You have no driver's license. There's no way they can authenticate you.
But you still have your thumbprint.
So now you authenticate yourself via a thumbprint scanner. The teller takes the thumbprint scanner out of a locked drawer (where it's been stored precisely to limit the amount of access people can have to it, and thus, their opportunities for malfeasance with it) and sets it out in front of you.
Presto, you're logged in, and the teller can have some degree of confidence that you're a customer and need to have your credit cards and ATM access cancelled.
Yes, there are significant problems with biometrics over the Net. Most of these problems can be alleviated by adding a trusted human being to the equasion, someone to stand by the biometric reader and make sure nobody does anything obviously hinky with it. (In this case, the teller serves that function.)
I certainly agree that biometrics aren't a panacea and they aren't a replacement for a real security policy. But I think you go a little too far to say that security people think biometrics ought never be used for over-the-Net transactions.
Using an elite hidden network for industrial spying is clearly against the law in both countries.
Cite me the law which says this, please? It's clearly illegal for a private citizen to do it; but the law allows intelligence agencies a great deal of flexibility to execute their duties, as directed by the Executive Branch of the government. Want to change this? Change the law or change the executive members of government who are giving these orders.
Does Echelon exist? Yes. Does Echelon exist to eavesdrop on electronic communications? Yes. Does Echelon exist to eavesdrop on United States communications? Well... that's a thornier question. The NSA is allowed to do it, at the explicit request of the FBI, after being presented with a judicial warrant, and with a couple of oversight committees being informed, but they're not allowed to do it of their own accord.
And you haven't presented one shred of evidence to suggest that it's being used illegally. Only that it exists, and since it exists it must be being used illegally--a cause-and-effect relation which I don't buy.
Do the US/UK signals intelligence services enjoy an extremely close relationship? Yes. Is this relationship formalized in classified agreements? Yes. Is the purpose of this relationship to evade the laws forbidding both governments from spying on their own citizens in violation of their laws? You seem to be claiming that "since the relationship exists, it must be being used for nefarious purposes."
Prove it.
I'm not asking you to prove Echelon exists, nor that a US/UK relationship exists, or that the NSA (in accordance with US law and at the order of executive officials in government) has spied on European industry to counter industrial espionage from the French DGSE. All of this is true.
I'm just asking you to prove your accusations that they are breaking the law. Which you haven't done, and which you seem incapable of realizing that the law might be very different from what you think it is.