wrist splints at night would probably only be needed if something about your sleeping position or habits would aggravate your condition. wrist splints during the day can *prolong* various RSI conditions by not allowing weak muscles to strengthen.
Hot vs. cold is a similar issue. Heat increases blood flow, allows better stretching, but acts to aggravate inflammation. Cold decreases swelling, and can reduce pain, but also decreases blood flow.
Different situations call for different treatment combinations. Consult a physician (which I am not!) experienced in successfully treating conditions like yours, before accepting what some other person tells you what worked for them.
You've had good luck so far. So had I, until one all-night session grading papers (an unusual activity for me) pushed me over the edge to tendonitis. Once you've gone over that edge, you've probably damaged soft tissues that take a *long* time to heal, and might not heal at all under the same conditions that you were in before. Then you'll really have to adjust.
I think you should take the pain-free opportunity you have now to adjust your habits to make sure you are taking better steps to avoid a pain-ful future. That would be much better than to risk finding yourself suffering from some "hysterics" that don't go away.
Then again, I bet you've been smoking two packs a day for years now and haven't needed a laryngectomy yet, so you'll keep on rolling! Good luck.
Re:space-based "reactors"
on
Duct Tape
·
· Score: 1
You are probably referring to the radio-thermal generators on board deep-space probes. These, as the other poster mentioned, are used to generate electricity when solar power would be insufficient.
It is a stretch to call them "reactors." They depend on the heat generated by radioactive decay (of plutonium, I think) which can be converted to electricity. They don't involve a controlled chain reaction, and produce considerably less energy than the same amount of radioactive material consumed in a conventional reactor. They also operate at a fixed, slowly decaying power level. But they are simple, compact, robust, and long-lived. So they are good for long-duration spaceflights (like to Saturn). Think more like a super battery than a reactor.
Just a wild-assed guess, but I would think that the energy density of gasoline would be much higher than the energy density of one of these sources. Certainly the peak power you could attain would be higher for gasoline+internal combustion engine.
By the way, nuclear submarines are substantially larger than the diesel equivalents. Real trade-offs are probably made to make them even moderately compact, the shielding is non-trivial, and the whole technology of nuclear sub propulsion is extremely closely guarded. The USA believes it gets a substantial strategic advantage from having nuclear subs, and the technical barriers are substantial (just look what a mess the Russians have made with their nuclear subs, with much less safe operation, and the Chinese nuclear sub reportedly spends most of its time hanging around its home port).
Oh, come on. Lisp has practically *no* syntax. What it has is so logical and uniform that it gives huge power to macros, and allows editors to sensibly indent programs to reveal their semantic structure.
Common Lisp lets you totally redefine the language's syntax anyway, if you don't like it. Want to write your math expressions using infix notation? Download the infix package, that lets you write #I'sin(x)+y^2' if you don't like
(+ (sin x) (expt y 2))
The very logic that you supposedly find appealing in Lisp drives inevitably toward the syntax that Lisp uses: code and list data have the same representation, so that the same operators that you use manipulate lists also lets you manipulate programs!!! That is the essence of macros.
C++ is an example of a language that misses that great chance. How do you manipulate programs in C++? You either use the C-style preprocessor, which is so limited that it is deprecated in favor of things like inline functions, or you use templates, which introduce a whole new meta-language and a corresponding layer of complexity, and is living is such an over-syntaxified environment that you must remember to leave that extra space in << or the parser will barf on you.
Arguments about syntax are going to favor Lisp over C++. Consider trigraphs, for God's sake.
I find it hard to believe that anyone would prefer the syntax of C++ templates, for instance, over CLOS.
You are assuming that the typical (i.e. popular) process of choosing a language in which to program weighs both the difficulty of learning and benefits of both C++ and Lisp. I think that assumption is false.
I believe rather that most programmers *fail* to recognize how difficult C++ is to use well, and in fact don't use C++ well, whether they know it or not. Most programmers have never attempted to learn to use Lisp well (I'm not talking about Scheme, and I'm not talking about the "Lisp is interpreted and has only one data structure" 1950's view of the language), so they have no way of measuring the difficulty anyhow.
My view is that most C++ programmers have accepted the challenge of C++ without knowing about, much less rationally considering, Common Lisp as an alternative. That is why I depict them as having their eyes closed.
It is possible (see Graham's books) to ignore the object-oriented features (CLOS) that come with Lisp, and define your own object-oriented dialect of Lisp in about 100 lines of ordinary Lisp, using macros. And once you've done so, there is essentially no way to tell that your dialect was not part of Lisp to start with.
To do the same thing in C, Stroustrup had to write cfront. Which is substantially more than 100 lines, and is far from transparent.
Walking around with your eyes closed is more challenging than walking with your eyes open. It doesn't mean you are smarter when you do so.
What "features" of C++ exist to facilitate larger programs? Packages? Stolen (including the:: syntax) from Common Lisp. Templates? Get real. Lisp macros do more, and do it better, without the gross syntax and without the code bloat. Object orientation? CLOS is objects with all the power of C++ and more.
(defun f (x y z)
"Routine to frobnicate X with Y, with Z degrees of freedom"
(let ((result1 (- (g y) 2))
(result2 (h (/ z 2) x)))
(* 2.6 result1 result2)))
Notice how much more compact the Lisp code is. I use "let" all the time for this kind of mathematical stuff, and also more ordinary common-expression elimination.
The "let" is just syntax, that most compilers will compile as efficiently as the version that doesn't state intermediate results.
Want speed? Use "declare" I'm not totally sure I have the syntax right, as my Lisp implementation is in the shop,...
(defun f (x y z)
"Routine to frobnicate X with Y, with Z degrees of freedom"
(declare (double-float x y z))
(let ((result1 (- (g y) 2))
(result2 (h (/ z 2) x)))
(* 2.6 result1 result2)))
If g, h are properly defined with declarations, a good Lisp compiler will infer that the results of the computations are also doubles, and will omit type checking when optimization for speed is turned up and for safety is turned down. Chances are, you will get close to the same code as C.
What do you mean by vanilla Lisp? Scheme? Emacs Lisp? Common Lisp includes CLOS ("Common Lisp Object System") by definition. Since most industrial-strength Lisp implemenations are Common Lisp, they also include CLOS.
No serious Lisp programmer uses a Lisp interpreter. All the major Common Lisp implementations in use today are compiled.
They are, however, interactive. When you type in your code, function by function, you can compile each function as you complete it, and test it out by calling it by hand with arguments, or writing another routine that calls it with test cases.
Your mention of SICP is a straw-man, having nothing to do with my point, as the textbook doesn't introduce Lisp macros at all. Even as far as Scheme goes (which I don't lump together with Lisp), SICP doesn't mention continuations, the most powerful feature of Scheme.
Your holding up of CPAN as an example is pretty pathetic. Perl and CPAN pretty much exist as a bunch of hacks meant to deal with the fact that most UNIX programmers think that uniquely-formatted-but-only-quasi-documented text files are the best way to exchange data between processes.
I'll concede that LAPACK is probably best written in Fortran. However, LAPACK is now a solved problem. Furthermore, LAPACK is meant as a foundation on which other programs will be built. If you want a convenient, yet efficient, INTERFACE to LAPACK, you can get one in Lisp. (Matlisp)
Instead of the FreeBSD kernel, why don't you take a look at Lisp machines? They're Lisp all the way down to the machine code level. There are still programmers who develop on *twenty-year-old* Lisp machines because the environment kicks serious ass over any other development environment.
Before you criticize Lisp, show me a language with a better macro system. Not C++ templates, not cpp, but a serious, robust way to do extensive and arbitrary computations and code manipulations at compile-time. Using the same language as the target language.
"fast, efficient development of an application like the Yahoo store builder"
They make programmers FASTER and MORE EFFICIENT, by allowing them to EXTEND the language to meet the problem definition, until the problem can be solved with a one-page program. Then, you're done.
If you are writing Lisp, and you find yourself repeating code, then you write a macro that repeats the code for you. It is the ultimate labor-saving device.
Competent programmers know how to pick the tool that will let them solve the problem most efficiently. For most problems, that is Lisp. The fact that there are few programmers using Lisp is a clue as to how few competent programmers there actually are.
But I thought Microsoft's original raison d'etre was that "the IT department locks up all the computing power in their big air-conditioned rooms and just lets you have the apps they want you to have, but with the IBM PC and MS, you can have whatever you want at your fingertips, without having to kow-tow to anybody."
Hmmmm. Funny how things work out, isn't it.
And aren't all these web forms scarily like old 3970 terminal apps?
The situations you mention aren't addressed by your concept of what you call "classical economics" but is really just uninformed clap-trap.
The scarce resource in Ethiopia was generally food transportation and storage, as well as a generally messed up economic structure caused by Soviet-influenced (i.e. totally wrong-headed) economic and political policies. If you can't get the food *delivered* to the hungry people, they still starve, no matter how scarce or abundant your food is.
The "scarcity" in drug research is the research ability and clinical resources used to develop the drugs, not the raw materials or the manufacturing capacity. Sure, an Indian company can produce a knock-off of a developed drug and sell it cheap, just like anyone like Cheapbytes or a Hong Kong pirate can copy a Windows or Linux CD or a Britney Spears CD. But are you going to wait for that Indian company to develop an AIDS vaccine? Hope you're ready to wait a long time, because it's not going to happen. An AIDS vaccine, if it can be developed, is going to be developed in the First World, using highly trained medical researchers. They don't come cheap, because they really are scarce.
Think for a moment about what really pays your salary, Mr. CTO. Somebody pays you money for something that you have that the average lower-paid person (e.g., the person who washes your office windows) doesn't. Or, they made a mistake. Is your talent "artificially" scarce?
Hmmm. Pick a better example, Pinball Wizard. The Highland brand of the product you link to happens to be a trademark of....3M. So this product isn't a knockoff, just a relabeling.
streetlawyer is rather sarcastically stating what be said more clearly: it still remains to be proven that anyone who *authors* code and releases it under the GPL can make a profit from having done so. It seems to me that streetlawyer would be satisfied with a single example. I share what seems to be his suspicion that anyone who is making a profit on a GPL work is not actually the author; I am not current enough on Open Source companies' financial performance to know if *any* company is making a profit on Open Source.
LaTeX may protect you from some common problems, e.g. margins too small, but it certainly doesn't stop you from making terrible-looking tables, or figures which are too big/small, or just plain typos that make things look darn ugly.
It also doesn't contain everything you would want in a technical writing environment.
Well, just compile the program into continuation-passing style (CPS) code, so that the current continuation is always available. Paul Graham demonstrates this in _On Lisp_, by implementing call/cc in Common Lisp macros. It has some restrictions, but only because he embedded it in CL not implement an entire language interpreter.
It's a few dozen lines of Common Lisp. Oh, yeah, I forgot, the original poster was going to use Perl. Good luck.
*Acrobat* is not *PDF*. Adobe upgrading Acrobat, or even releasing new versions of the PDF spec, does not invalidate previous PDF specs or documents made using earlier versions.
Now, people sending you PDF-99.9 documents could someday be a problem, but complain about that when Adobe comes up with a.PDF format that isn't publically and clearly documented, or can't be read or generated by a sufficiently "free" program.
The problem is that Postscript is *executable*, so it is potentially hardware dependent, but more importantly, the results of printing are due to running a Postscript program.
This makes it extremely hard to do things like "extract page 10", because you have to run the program until it outputs 9 pages, somehow defeating the actual output, wait for it to request output for the 10th time, capture the raster memory, then kill the program.
PDF is a document format. It is static data, not dynamic program flow.
The problem with HTML+images is
1) every browser displays and formats them differently
2) what image format to use?
PDF practically eliminates (1) and gives you essentially all the power of Postscript vector and bitmap graphics for (2), independent of output device.
There is no technological reason why PDF can't be displayed just as transparently as HTML+images. Browser vendors seem to think that plugins are just fine.
I mean, what is really the difference between "downloading a file" and downloading a HTML+images file, except that the browser holds your hand a bit more and hides all the details for the latter?
OK. Your point is clear. But is this really a problem for a *document* format?
For an *executable* format, API, or ABI, you need change in order to keep up with new market demands, and the development of new APIs on the target platform. Software is often upgraded.
Paper documents, however, which.PDF is supposed to represent, are meant to be quasi-permanent records. What matters is sending data back and forth to different users on different platforms. PDF-3.0, for example, is a fixed target. If you follow the rules, a PDF-3.0 document should work with a PDF-3.0 reader, forever and ever, amen. That's the goal.
I agree that as documents resemble executables more and more, the goal of an open standard is a good one. Nonetheless, if I have a PDF-3.0 document, nothing forces me to "recompile" it to PDF-4.0 to access some new feature of that "platform." The original document creator didn't use those features anyway. The point is that even if Adobe does something evil and nasty to PDF-4.0, it doesn't degrade compatibility of a PDF document to any preexisting PDF reader. Whereas if Sun changes Java, your Java code might stop working.
I'm not quite sure about the legal details, but I think it would be quite possible to develop an Open equivalent for PDF, which would be defined by variation from a fixed PDF reference.
How is PDF not open? It's fully defined in open literature. *Acrobat* is not an open source program, but many free programs exist that understand PDF, without any license needed from Adobe.
Off topic, probably, but I believe this "every image at the end of chapter" can occur when you have mistakenly used the same label for two or more captions, which can be very easy to do when you cut-and-paste, or don't feel like being very creative with your labels.
I find the LaTeX source incomprehensible, and TeX source reprehensible, so don't ask me for a real fix. Hope this helps.
Oh, please. There is also a third statute, providing for manual recounts. The court agreed that it doesn't make sense to provide for manual recounts without also providing time for the manual recounts to take place.
You seem to favor either,
1) hold the counties to the original deadline,
meaning no manual recounts at all.
or
2) based on your last paragraph, allow enough time for the manual recounts to happen.
2) is just as "arbitrary," according to your definition, as the court's decision, so either you only would accept (1), or you really aren't concerned about the arbitrariness at all, in which case you are full of baloney.
Solution (1), however, has the nasty effect of denying the legal right for manual recounts, as they couldn't be completed in time. The court decided that this side effect was more serious than the effect of ignoring the legislative deadline, for which no one seems to know any purpose.
Courts *must* have some flexibility to craft remedies, or they are useless. The real conflict wasn't between "may" or "shall" but between "manual recounts" or "no manual recounts." The court tried to create a ruling that allowed manual recounts to be implemented. Presumably, legislators wanted manual recounts to happen, or they wouldn't have written it into law.
It is pretty naive to believe that something as large and complicated as the body of Florida state law is going to cover every conceivable situation without any internal contradictions. It is the job of the courts to use interpretation and powers of relief to allow the law to adapt to the situations that happen to occur in the real world.
Think of an open source program. One day, it fails an assert(). You've found a bug. What do you do? You go back, find out what the bug is, and fix it. Sure, you wish the original programmer hadn't written the bug, but you need your results *NOW*, not when a version is released that might fix your bug. Are you changing what the original programmer wrote? Of course. Are you committing some heinous crime against humanity because of that? No. The original programmer didn't mean to write bugs. He meant to write a working program, and screwed up, probably because he didn't anticipate some crazy input. Welcome to the real world.
Legislatures write *statutes.* Courts interpret statutes, given the particulars of the case, and are given broad powers to make things work out when reality is conflict-ridden and messy. That is *law*. Sometimes it doesn't work the way one might like, but its the best we can do. Deal with it.
In the end, this is why you need to pick competent people to serve as judges.
Slashdot Mirror
wrist splints at night would probably only be needed if something about your sleeping position or habits would aggravate your condition. wrist splints during the day can *prolong* various RSI conditions by not allowing weak muscles to strengthen.
Hot vs. cold is a similar issue. Heat increases blood flow, allows better stretching, but acts to aggravate inflammation. Cold decreases swelling, and can reduce pain, but also decreases blood flow.
Different situations call for different treatment combinations. Consult a physician (which I am not!) experienced in successfully treating conditions like yours, before accepting what some other person tells you what worked for them.
You've had good luck so far. So had I, until one all-night session grading papers (an unusual activity for me) pushed me over the edge to tendonitis. Once you've gone over that edge, you've probably damaged soft tissues that take a *long* time to heal, and might not heal at all under the same conditions that you were in before. Then you'll really have to adjust.
I think you should take the pain-free opportunity you have now to adjust your habits to make sure you are taking better steps to avoid a pain-ful future. That would be much better than to risk finding yourself suffering from some "hysterics" that don't go away.
Then again, I bet you've been smoking two packs a day for years now and haven't needed a laryngectomy yet, so you'll keep on rolling! Good luck.
You are probably referring to the radio-thermal generators on board deep-space probes. These, as the other poster mentioned, are used to generate electricity when solar power would be insufficient.
It is a stretch to call them "reactors." They depend on the heat generated by radioactive decay (of plutonium, I think) which can be converted to electricity. They don't involve a controlled chain reaction, and produce considerably less energy than the same amount of radioactive material consumed in a conventional reactor. They also operate at a fixed, slowly decaying power level. But they are simple, compact, robust, and long-lived. So they are good for long-duration spaceflights (like to Saturn). Think more like a super battery than a reactor.
Just a wild-assed guess, but I would think that the energy density of gasoline would be much higher than the energy density of one of these sources. Certainly the peak power you could attain would be higher for gasoline+internal combustion engine.
By the way, nuclear submarines are substantially larger than the diesel equivalents. Real trade-offs are probably made to make them even moderately compact, the shielding is non-trivial, and the whole technology of nuclear sub propulsion is extremely closely guarded. The USA believes it gets a substantial strategic advantage from having nuclear subs, and the technical barriers are substantial (just look what a mess the Russians have made with their nuclear subs, with much less safe operation, and the Chinese nuclear sub reportedly spends most of its time hanging around its home port).
Oh, come on. Lisp has practically *no* syntax. What it has is so logical and uniform that it gives huge power to macros, and allows editors to sensibly indent programs to reveal their semantic structure.
Common Lisp lets you totally redefine the language's syntax anyway, if you don't like it. Want to write your math expressions using infix notation? Download the infix package, that lets you write #I'sin(x)+y^2' if you don't like
(+ (sin x) (expt y 2))
The very logic that you supposedly find appealing in Lisp drives inevitably toward the syntax that Lisp uses: code and list data have the same representation, so that the same operators that you use manipulate lists also lets you manipulate programs!!! That is the essence of macros.
C++ is an example of a language that misses that great chance. How do you manipulate programs in C++? You either use the C-style preprocessor, which is so limited that it is deprecated in favor of things like inline functions, or you use templates, which introduce a whole new meta-language and a corresponding layer of complexity, and is living is such an over-syntaxified environment that you must remember to leave that extra space in << or the parser will barf on you.
Arguments about syntax are going to favor Lisp over C++. Consider trigraphs, for God's sake.
I find it hard to believe that anyone would prefer the syntax of C++ templates, for instance, over CLOS.
You are assuming that the typical (i.e. popular) process of choosing a language in which to program weighs both the difficulty of learning and benefits of both C++ and Lisp. I think that assumption is false.
I believe rather that most programmers *fail* to recognize how difficult C++ is to use well, and in fact don't use C++ well, whether they know it or not. Most programmers have never attempted to learn to use Lisp well (I'm not talking about Scheme, and I'm not talking about the "Lisp is interpreted and has only one data structure" 1950's view of the language), so they have no way of measuring the difficulty anyhow.
My view is that most C++ programmers have accepted the challenge of C++ without knowing about, much less rationally considering, Common Lisp as an alternative. That is why I depict them as having their eyes closed.
"new fancy features" == standardized in 1994. And, unlike some standards, existed before it was standardized.
Perhaps an example will illuminate things.
It is possible (see Graham's books) to ignore the object-oriented features (CLOS) that come with Lisp, and define your own object-oriented dialect of Lisp in about 100 lines of ordinary Lisp, using macros. And once you've done so, there is essentially no way to tell that your dialect was not part of Lisp to start with.
To do the same thing in C, Stroustrup had to write cfront. Which is substantially more than 100 lines, and is far from transparent.
"C++ is more challenging to use than Lisp"
:: syntax) from Common Lisp. Templates? Get real. Lisp macros do more, and do it better, without the gross syntax and without the code bloat. Object orientation? CLOS is objects with all the power of C++ and more.
Walking around with your eyes closed is more challenging than walking with your eyes open. It doesn't mean you are smarter when you do so.
What "features" of C++ exist to facilitate larger programs? Packages? Stolen (including the
Try
(defun f (x y z)
"Routine to frobnicate X with Y, with Z degrees of freedom"
(let ((result1 (- (g y) 2))
(result2 (h (/ z 2) x)))
(* 2.6 result1 result2)))
Notice how much more compact the Lisp code is. I use "let" all the time for this kind of mathematical stuff, and also more ordinary common-expression elimination.
The "let" is just syntax, that most compilers will compile as efficiently as the version that doesn't state intermediate results.
Want speed? Use "declare" I'm not totally sure I have the syntax right, as my Lisp implementation is in the shop,...
(defun f (x y z)
"Routine to frobnicate X with Y, with Z degrees of freedom"
(declare (double-float x y z))
(let ((result1 (- (g y) 2))
(result2 (h (/ z 2) x)))
(* 2.6 result1 result2)))
If g, h are properly defined with declarations, a good Lisp compiler will infer that the results of the computations are also doubles, and will omit type checking when optimization for speed is turned up and for safety is turned down. Chances are, you will get close to the same code as C.
What do you mean by vanilla Lisp? Scheme? Emacs Lisp? Common Lisp includes CLOS ("Common Lisp Object System") by definition. Since most industrial-strength Lisp implemenations are Common Lisp, they also include CLOS.
No serious Lisp programmer uses a Lisp interpreter. All the major Common Lisp implementations in use today are compiled.
They are, however, interactive. When you type in your code, function by function, you can compile each function as you complete it, and test it out by calling it by hand with arguments, or writing another routine that calls it with test cases.
Your mention of SICP is a straw-man, having nothing to do with my point, as the textbook doesn't introduce Lisp macros at all. Even as far as Scheme goes (which I don't lump together with Lisp), SICP doesn't mention continuations, the most powerful feature of Scheme.
Your holding up of CPAN as an example is pretty pathetic. Perl and CPAN pretty much exist as a bunch of hacks meant to deal with the fact that most UNIX programmers think that uniquely-formatted-but-only-quasi-documented text files are the best way to exchange data between processes.
I'll concede that LAPACK is probably best written in Fortran. However, LAPACK is now a solved problem. Furthermore, LAPACK is meant as a foundation on which other programs will be built. If you want a convenient, yet efficient, INTERFACE to LAPACK, you can get one in Lisp. (Matlisp)
Instead of the FreeBSD kernel, why don't you take a look at Lisp machines? They're Lisp all the way down to the machine code level. There are still programmers who develop on *twenty-year-old* Lisp machines because the environment kicks serious ass over any other development environment.
Before you criticize Lisp, show me a language with a better macro system. Not C++ templates, not cpp, but a serious, robust way to do extensive and arbitrary computations and code manipulations at compile-time. Using the same language as the target language.
The whole point of macros is they are key for
"fast, efficient development of an application like the Yahoo store builder"
They make programmers FASTER and MORE EFFICIENT, by allowing them to EXTEND the language to meet the problem definition, until the problem can be solved with a one-page program. Then, you're done.
If you are writing Lisp, and you find yourself repeating code, then you write a macro that repeats the code for you. It is the ultimate labor-saving device.
Competent programmers know how to pick the tool that will let them solve the problem most efficiently. For most problems, that is Lisp. The fact that there are few programmers using Lisp is a clue as to how few competent programmers there actually are.
But I thought Microsoft's original raison d'etre was that "the IT department locks up all the computing power in their big air-conditioned rooms and just lets you have the apps they want you to have, but with the IBM PC and MS, you can have whatever you want at your fingertips, without having to kow-tow to anybody."
Hmmmm. Funny how things work out, isn't it.
And aren't all these web forms scarily like old 3970 terminal apps?
The situations you mention aren't addressed by your concept of what you call "classical economics" but is really just uninformed clap-trap.
The scarce resource in Ethiopia was generally food transportation and storage, as well as a generally messed up economic structure caused by Soviet-influenced (i.e. totally wrong-headed) economic and political policies. If you can't get the food *delivered* to the hungry people, they still starve, no matter how scarce or abundant your food is.
The "scarcity" in drug research is the research ability and clinical resources used to develop the drugs, not the raw materials or the manufacturing capacity. Sure, an Indian company can produce a knock-off of a developed drug and sell it cheap, just like anyone like Cheapbytes or a Hong Kong pirate can copy a Windows or Linux CD or a Britney Spears CD. But are you going to wait for that Indian company to develop an AIDS vaccine? Hope you're ready to wait a long time, because it's not going to happen. An AIDS vaccine, if it can be developed, is going to be developed in the First World, using highly trained medical researchers. They don't come cheap, because they really are scarce.
Think for a moment about what really pays your salary, Mr. CTO. Somebody pays you money for something that you have that the average lower-paid person (e.g., the person who washes your office windows) doesn't. Or, they made a mistake. Is your talent "artificially" scarce?
Hmmm. Pick a better example, Pinball Wizard. The Highland brand of the product you link to happens to be a trademark of....3M. So this product isn't a knockoff, just a relabeling.
Now quit trying to troll for trolls.
Don't you see, though?
The artists won't make money by performing *music*, but they'll be able to make it up by consulting and tech support revenue.
This way, they'll be able to make gobs of money, just like open source software, right?
streetlawyer is rather sarcastically stating what be said more clearly: it still remains to be proven that anyone who *authors* code and releases it under the GPL can make a profit from having done so. It seems to me that streetlawyer would be satisfied with a single example. I share what seems to be his suspicion that anyone who is making a profit on a GPL work is not actually the author; I am not current enough on Open Source companies' financial performance to know if *any* company is making a profit on Open Source.
LaTeX may protect you from some common problems, e.g. margins too small, but it certainly doesn't stop you from making terrible-looking tables, or figures which are too big/small, or just plain typos that make things look darn ugly.
It also doesn't contain everything you would want in a technical writing environment.
Well, just compile the program into continuation-passing style (CPS) code, so that the current continuation is always available. Paul Graham demonstrates this in _On Lisp_, by implementing call/cc in Common Lisp macros. It has some restrictions, but only because he embedded it in CL not implement an entire language interpreter.
It's a few dozen lines of Common Lisp. Oh, yeah, I forgot, the original poster was going to use Perl. Good luck.
*Acrobat* is not *PDF*. Adobe upgrading Acrobat, or even releasing new versions of the PDF spec, does not invalidate previous PDF specs or documents made using earlier versions.
.PDF format that isn't publically and clearly documented, or can't be read or generated by a sufficiently "free" program.
Now, people sending you PDF-99.9 documents could someday be a problem, but complain about that when Adobe comes up with a
The problem is that Postscript is *executable*, so it is potentially hardware dependent, but more importantly, the results of printing are due to running a Postscript program.
This makes it extremely hard to do things like "extract page 10", because you have to run the program until it outputs 9 pages, somehow defeating the actual output, wait for it to request output for the 10th time, capture the raster memory, then kill the program.
PDF is a document format. It is static data, not dynamic program flow.
The problem with HTML+images is
1) every browser displays and formats them differently
2) what image format to use?
PDF practically eliminates (1) and gives you essentially all the power of Postscript vector and bitmap graphics for (2), independent of output device.
There is no technological reason why PDF can't be displayed just as transparently as HTML+images. Browser vendors seem to think that plugins are just fine.
I mean, what is really the difference between "downloading a file" and downloading a HTML+images file, except that the browser holds your hand a bit more and hides all the details for the latter?
OK. Your point is clear. But is this really a problem for a *document* format?
.PDF is supposed to represent, are meant to be quasi-permanent records. What matters is sending data back and forth to different users on different platforms. PDF-3.0, for example, is a fixed target. If you follow the rules, a PDF-3.0 document should work with a PDF-3.0 reader, forever and ever, amen. That's the goal.
For an *executable* format, API, or ABI, you need change in order to keep up with new market demands, and the development of new APIs on the target platform. Software is often upgraded.
Paper documents, however, which
I agree that as documents resemble executables more and more, the goal of an open standard is a good one. Nonetheless, if I have a PDF-3.0 document, nothing forces me to "recompile" it to PDF-4.0 to access some new feature of that "platform." The original document creator didn't use those features anyway. The point is that even if Adobe does something evil and nasty to PDF-4.0, it doesn't degrade compatibility of a PDF document to any preexisting PDF reader. Whereas if Sun changes Java, your Java code might stop working.
I'm not quite sure about the legal details, but I think it would be quite possible to develop an Open equivalent for PDF, which would be defined by variation from a fixed PDF reference.
How is PDF not open? It's fully defined in open literature. *Acrobat* is not an open source program, but many free programs exist that understand PDF, without any license needed from Adobe.
Off topic, probably, but I believe this "every image at the end of chapter" can occur when you have mistakenly used the same label for two or more captions, which can be very easy to do when you cut-and-paste, or don't feel like being very creative with your labels.
I find the LaTeX source incomprehensible, and TeX source reprehensible, so don't ask me for a real fix. Hope this helps.
Oh, please. There is also a third statute, providing for manual recounts. The court agreed that it doesn't make sense to provide for manual recounts without also providing time for the manual recounts to take place.
You seem to favor either,
1) hold the counties to the original deadline,
meaning no manual recounts at all.
or
2) based on your last paragraph, allow enough time for the manual recounts to happen.
2) is just as "arbitrary," according to your definition, as the court's decision, so either you only would accept (1), or you really aren't concerned about the arbitrariness at all, in which case you are full of baloney.
Solution (1), however, has the nasty effect of denying the legal right for manual recounts, as they couldn't be completed in time. The court decided that this side effect was more serious than the effect of ignoring the legislative deadline, for which no one seems to know any purpose.
Courts *must* have some flexibility to craft remedies, or they are useless. The real conflict wasn't between "may" or "shall" but between "manual recounts" or "no manual recounts." The court tried to create a ruling that allowed manual recounts to be implemented. Presumably, legislators wanted manual recounts to happen, or they wouldn't have written it into law.
It is pretty naive to believe that something as large and complicated as the body of Florida state law is going to cover every conceivable situation without any internal contradictions. It is the job of the courts to use interpretation and powers of relief to allow the law to adapt to the situations that happen to occur in the real world.
Think of an open source program. One day, it fails an assert(). You've found a bug. What do you do? You go back, find out what the bug is, and fix it. Sure, you wish the original programmer hadn't written the bug, but you need your results *NOW*, not when a version is released that might fix your bug. Are you changing what the original programmer wrote? Of course. Are you committing some heinous crime against humanity because of that? No. The original programmer didn't mean to write bugs. He meant to write a working program, and screwed up, probably because he didn't anticipate some crazy input. Welcome to the real world.
Legislatures write *statutes.* Courts interpret statutes, given the particulars of the case, and are given broad powers to make things work out when reality is conflict-ridden and messy. That is *law*. Sometimes it doesn't work the way one might like, but its the best we can do. Deal with it.
In the end, this is why you need to pick competent people to serve as judges.