Yes, this happens occasionally. Why, in some states, you can even kill me as you recover your property, and the courts wind up not caring. Only if it turns out not to have been your property at all do you risk some minor punishment.
Huh? That question doesn't make sense. Violating standard copyright law is the entire legal mechanism the GPL operates by. Duplicating the code is illegal, but the copyright holder has agreed to give copying permission to anyone who obeys the GPL.
Like the GPL says: 5. You are not required to accept this License, since you have not signed it. However, nothing else grants you permission to modify or distribute the Program or its derivative works. These actions are prohibited by law if you do not accept this License.
A theoretical "test" of the GPL might find that the license text is all correct and legal. Or, maybe a court would declare the license invalid. This could mean that every user of Linux and other GPL software is in violation of copyright (until the authors work up another way to give out permission). That would be a major news story, and is why people get excited when the possibility of a "test" arises.
It's brilliant! It's occasionally scary and convoluted, but it's GOOD CODE!
Code is GOOD if it provides users with the features they need. The old Unix code may be robust and elegant, but it lacks features. Essential things like networking, graphics, and user IO over anything but a vt100.
When users start to demand features that are far beyond the scope of the original design, the developer can take two courses:
Stuff the new capabilities into the original software anyplace they'll fit. This created Unix variants like Linux (and Solaris, and the others that are still maintained). The code may be a mishmash, but new features are provided, and direct backwards compatibility wasn't sacrificed.
Toss out the old design and create something new which includes all the desired features from the beginning. This is what the elgance-minded inventors of Unix did, but the change was so drastic that it would've required legions of existing users to re-engineer their systems. Today, nobody uses the result.
It's pragmatism versus ideals. In a vacum, the most beautiful approach may seem best. But is it "GOOD" if you can't really deploy it? Today's WWW is an ugly, hackish rat's nest compared to the design of the Xanadu proposal from decades earlier. But it exists, and it works.
(Even aside from unforseen new capabilities, the old Unix utils for things like text processing filters often turning out to be inadequate. They'd have firm upper limits on input sizes, or would deccelerate unacceptably when asked to do a big job. Simplistic design mean shortcomings in some uses. GNU versions of fileutils, for instance, corrected a lot of these limitations, at the cost of uglified source code)
Sendmail is good code.
If it's so great (and also free), why have so many people been inspired to reinvent the mail server? Qmail, Exim, Postfix...
And Bill Gates stated that MS EULAs don't endanger privacy.
The text of the license is the only thing with a legal standing. Anything else you hear is just so much hot air. A statement by RMS might suffice as a promise that the FSF won't pursue you for violating the GPL in that manner. But it has no bearing on how Linus Torvalds or AOL-Time Warner might react.
And without seeing a quote, I'd doubt that RMS would've said something quite like that. (Especially considering that an "Organization" can be construed to be a huge group, like "US Taxpayers")
Maybe you're talking about this GPL FAQ. It says that you're not required to release modified versions. (The fact that you've modifed GPL code doesn't force you to either send patches upstream, or post it on your own website). But it doesn't let you forbid release either. That FAQ ends with "but the decision of whether to release it is up to you". Who is "you" in that sentence? It's not the manager or board of directors- it's every single person with a copy of the software. (Another FAQ makes this more explicit)
In any organization of nontrivial size, you'll eventually find someone who both wants to publish the code, and doesn't care about keeping his job (or is secretive enough to be anonymous).
The GPL contains no "in-house" or "internal use" exception. If you have 1000 programmers editing the code, 5% of them will spontaneously decide to mail some patches to Linus. And you can't stop him. Your programmers distribute the code to each other via the GPL- otherwise they're not allowed to share with each other. This gives any of them permission to send copies to whoever he wishes.
Sure, as long as you're his boss, you can command him not to give copies to anyone without your personal approval. But a good lawyer could argue this is a GPL violation. By distributing code under GPL, you gave the recepient permission to distribute it. But at the same time, you gave him instructions not to distribute it. That's tantamount to editing the GPL in an impermissable way.
A related lawsuit has already happened: before recieving modifed copies of a GPL program, users were made to sign a separate contract promising not to redistribute it. That is a flagrant violation. (The defendants backed down before making it to court, so it's not a watertight precedent)
(Even if that argument doesn't hold up in court, the turnover rate for 1000 programmers will be significant. Soon enough, an ex-employee will find himself with a leftover copy of the code, and then he's free of your control)
it doesn't force me to release my changes, and if it did it would be unenforcable.
Many quasi-Open Source licenses (including some created in the past by Sun and Apple) have required all changes be transmitted to the original publisher. Their lawyers seemed to think it was enforcable (although impractical, and it made their code untouchable once people learned of it, so they've backed away towards more agreeable conditions)
Your experience is non-representative of modern use. Google has seen "flood fill" 490,000 times, but only knows of 246,000 uses of "bucket fill".
Flood Fill is the original description used by computer graphics programmers. "Bucket Fill" is a variation invented by Xerox or Apple to matchup with the icon on their GUI toolbar.
Funny? Not really. Faster, modern disk IO means no more spending 80% of game time waiting for screens to load.
It also means you can save your game every 60 seconds, without waiting (swap game disk for save disk...wait wait wait... swap back), and with no concern for running out of space. That'll save you a lot of lost time when the game pointlessly kills you (carnivorous mushrooms, anyone?)
PS. SQ2 had no mechanized pugilists. You're off by one sequel. For minigames, SQ1 had desert-racing and anti-Sarien gunslinging. I don't remeber any in SQ2, but the 3rd game (which changed to a totally different graphics engine) had AstroChicken and boxing. AstroChicken had catchy music and was rather fun. Two more sequels, and they were reduced to "You Sunk My Battlecruiser", one of the least entertaining things imaginable.
CowboyNeal is mistaken if he thinks a Sierra game like SQ or LLL forced the user to watch floodfilling happen. Those games used precomputed pixmaps for graphics- there was be a severe delay as they were loaded from a (5.25") floppy for each new screen, but you couldn't actually watch the graphics redraw.
There were other games who exposed the process of rendering 2d vector graphics. I recall a few "Carmen Sandiego" clones for IBM PC or Apple that did this around 1982.
Going back even further, Sierra had some games like "Mystery House" which did monochrome line art. IDR if there was floodfilling or not.
We don't have to do it alone. We could just as well lead a partnership of world space agencies to accomplish the same goal. I'd prefer this, actually.
Even if it were to be a multinational effort, a moonbase facility would be difficult to secure. Whichever nation has the most personnel on the moon can seize control at will. (Or whoever first decides to smuggle up weapons- which is possible for whoever runs the launches).
A moonbase with longterm habitation and electrical power (eventually more than several traditional nuculear plants!) would be a potent platform to assault anyplace on earth. Yeah, Heinlein's gravity-well bombardment might not work. But modifying the microwave beam to a tighter focus or a different bandwidth- or flat out replacing it with a laser- you could start to scorch the planet.
(Or at minimum, melt off the antennas of any opposing satellites)
A military moonstation would make an entertaining element for speculative fiction. You can imagine paranoid dictators synchronizing themselves to a lunar cycle- refusing to go outdoors when the moon is in the sky.
Even if he didn't take something, I don't think you could really claim that the burgler did a positive thing... he spoiled the trust and made people fearful.
Depends on the magnitude of the theoretical Greater Bad Guy.
If someday the residents he didn't visit are found chopped up in their dishwashers, then I would totally claim the first intruder was doing a good thing. (Not great, but more good than bad. And leaving an informative note is a positive factor in your example, but Kevin did nothing of the sort)
"Spoiled trust?" False trust is more dangerous than none at all.
Depending on implementation details, they can still maintain a lot of control. As was mentioned, Blizzard's Battle.Net uses P2P between the individual players for long-lasting, high-bandwidth connections that run a game. But the administrative functions- user login, player matchmaking, and game startup- are handled on their own systems.
That way, they've got fairly low server costs, yet control how the product is used. Woe to he who thinks to wrest the central server from them.
"already has libraries written" = "someone else had to write it". That tells nothing about how difficult it was.
I could similarly say that "Quicksort can be implemented as 2 lines of C code (because a library's already written)".
Besides, Erlang isn't really a purely functional language. Well, "pure functional" languages hardly ever amount to more than academic toys, but there are other languages that come a lot closer.
Here's a one line Erlang program: hello() -> io:fwrite("hello\n").
See that "fwrite"? It means "write to the file called io". Telling the computer to do something- that's imperative.
Here's the equivalent in ML: val it = "hello" : string The criticial distinction here is that there's no verb-equivalent. In a functional style, everything is either a statement of fact- standalone like a noun (constant), or relative to another like an adjective (function). ML isn't purely functional either, but it looks closer.
Of course, any useful language can be used for programming in either imperative or functional styles (with some small additional awkwardness). Take the QuickSort example someone gave. Even though they're called "imperative" languages, developers working in C++, Java, or Perl would tend to implement something that directly follows the functional outline.
(Note that some academics will say that the criticial distinction of a functional language is that functions are treated as first-class objects. "functional vs non-functional". I'm using the simpler definition- functions as per math functions- which treats the distinction as "functional vs imperative")
Nintendo uses Lisp for game programming, maybe even Mario64.
Of course I haven't seen the code, but if they're at all like most game developers, Mario64 isn't written in Lisp- it is C and assembler. "Behaviors of monsters inside the game" may be in Lisp, that's a fairly common approach. But not "the game" itself. Things like "load the texture resources from disk, calculate normals for polygonal models, run a 40hz event loop on gamepad input"... they're just too hard to describe functionally.
Solar panels are what's being proposed. Did you read the article? The guy has written 200 papers about it... if there were a significantly better way, he might've thought of it already.
Because in a binary system -1 is not a valid number.
Why not? -1 is just as valid in binary as in octal, decimal, or hex. "binary" just means base-two.
Maybe you think it implies the values are unsigned, which is the simplest obvious way to handle numbers in a computer. Some programmers observe how their computers behave, and assume this is the truth. This can lead them to pronounce absurdities like 65536+2=1. But computers are limited- the definitions of math provide the real authoritative true results (unless you state a specifc set of alternative assumptions).
Some examples may exist- but remember that there are counterexamples too. Some problems are not inherently recursive or functional, and trying to adapt functional programming styles just brings pain.
Humans are (mostly) imperative creatures. Computers are completely imperative machines, although they can emulate functional behavior. Sometimes its safer to stay closer to the natural abilities of your hardware, rather than going too far beyond.
Try sketching out the overall structure of something like Apache or SuperMario64 as a functional program to see what I mean.
The flood-fill algorithim in bitmapped graphics is easy to describe functionally, but running the program might swamp your computer. (Depending on smartness of your compiler, and other factors).
Even a compiler (seemingly a class of software most closely resembling a unary mathematical function) is difficult to write purely functionally. I recall when a respected college professor attempted this. The result was essentially correct, but mind-bendingly ugly, and he'd spent much more time than needed.
Those things that are drastically easier to describe in a functional style (such as the Quicksort described by another respondant) tend to be fairly brief algorithims, and heavy documentation on them is easily accessible,
Even so, a site in southern Texas, along the coast, would share all of those qualities, or be even better.
And the humidity would be less. Not like it really matters though. When you've got thousands of liters of liquid oxygen sitting there, condensation will happen from any kind of air.
Why not? Because it would've made them cry, that's why. They'd struggle through a spacewalk, see the damage, and know they were all going to die. Since there was no way to fix it, they didn't bother to look.
It would've been honest and responsible to try and inspect for damage, but NASA kept its fingers crossed and optimistically hoped that nothing could go wrong.
Why could nothing be done about it? They couldn't wait for a rescue shuttle (well, there's was a slim chance). They couldn't go to ISS and wait there (unless they were launched on an intercept course, that much travel would exceed their manuvering fuel). And, assuming the damage was to the fragile heat-insulating tiles, they couldn't fix it themselves.
Why couldn't they fix it? They had no spares? Why not? Because even standing on a scaffold with proper tools, it takes 30 hours to replace one fist-sized tile. (I had trouble believing it took so long, but NASA said so. Retiling is one of the slowest parts of refiting a shuttle for another flight)
Bouncing a tennis ball of the shuttle would break 2-4 tiles. If that happens after lift off, you've just gotta write off the whole vehicle.
PS: The long-shot approach (waiting for another shuttle to be launched for rescue) might've involved the kinds of bitter calculations sociology undergraduates tackle in classroom exercises each spring. In a rush, the ground crews might've taken 3-5 weeks to prepare a another trip. No shuttle so far has stayed up even 3 weeks. I can imagine them doing the math: "They rescue us in 25 days. But we suffocate in 21 days- unless we kill two people immediately!"
A cool concept, but the nations of the earth would be too fearful of weaponization to allow any one group the chance to control something like that. "Harmless microwaves" they say- the spectre of GW Bush ordering lunar energy beams to raze North Korean nuculear sites will be on everyone's minds. The James Bond / Dr. Evil scenario come to life.
(Aside from the ongoing dispute as to the feasibility of assembling a solar-panel whose total potential energy output will exceed that used to construct it.)
It would be additionally great if other aspects of your remote terminal could be reported to an application server in the same variable as well.
Stuff like: joysticks, cdroms, writable local storage (under strict permissions set by the Xserver config), even local USB devices.
Because you know, if thin-clients based on *nix and X11 ever become popular, users will want to save files to a floppydisk in front of them without navigating down/mnt/samba/what_hostname_am_i_sitting_at_again?
Of course, developing this would be much harder than building audio capabilities- terrible OS incompatibilities, as well as conflicting with existing X abilities.
To reach this goal, you'd nearly have to create a new application-service system, with X11 as just one component.
The exact transport mechanism is a library implementation detail - why should the end user or even the application developer care?
That's why it's an advantage. Using the same transport for graphics and sound reduces the chance that a user will need to care what the transport is.
Once an end user gets a remotely running application displayed, he doesn't want to worry about all his beeps and honks coming out of/dev/dsp in the server room. But that's what'll happen until he figures out how to configure a completely separate transport mechanism to tell the audio where he's sitting.
Most people have enough trouble handling $DISPLAY, xhost+, and MIT-Magic-Cookie. Piling extra variables on top of that will make end-users throw up their hands.
"Oh, now I need to start esound client, esound server, esd-dsp when running programs, and then allow a separate UDP port through my firewall". "And now running X11-over-ssh, I have to create a separate VPN-tunnel for the audio data"
Sure, there are Linux distributions and smart sysadmins who prepare those things for you. But even they often mess up, and they can never plan ahead for all the flexibility an end-user may want. For instance, X-servers are available on Microsoft Windows. It'd be much easier to get a new version of one of those to understand "audio-over-X protocol" than to try running esoundd under cygwin!
But not necessarily highest. The Russian alphabet scores higher
The very-important criteria of ease of learning is composed of 2 parts: inherent simplicity, and existing skilled base. Existing skilled persons both reduces the total amount of learning needed, and provides new learners with educational resources.
That's where the Roman alphabet really dominates. It is the primary component of the native character sets of all Americans (North & South), most Europeans, many Indians and Africans, and is recognized and used by the computer-using classes of China, Korea, Japan and Singapore.
(Did I forget Australia? Oh well, won't bother to go search for what they use)
Which is plenty close-enough to "doom" for all long-range planning purposes (up to and including extraterrestrial colonization)
Today there are 500 times as many humans as when we last weathered an ice age. Losing 499/500ths of something doesn't count as total destruction, especially if it's something that can regrow, but it's still unspeakably bad. (And there'd only have to be one more tiny push- like a few more degrees of cold- to finish off the 1/500th remaining)
Slashdot Mirror
Do you have the right to come steal it back?
Yes, this happens occasionally. Why, in some states, you can even kill me as you recover your property, and the courts wind up not caring. Only if it turns out not to have been your property at all do you risk some minor punishment.
(Oops, was bash-Texas day last week?)
Huh? That question doesn't make sense. Violating standard copyright law is the entire legal mechanism the GPL operates by. Duplicating the code is illegal, but the copyright holder has agreed to give copying permission to anyone who obeys the GPL.
Like the GPL says:
5. You are not required to accept this License, since you have not signed it. However, nothing else grants you permission to modify or distribute the Program or its derivative works. These actions are prohibited by law if you do not accept this License.
A theoretical "test" of the GPL might find that the license text is all correct and legal. Or, maybe a court would declare the license invalid. This could mean that every user of Linux and other GPL software is in violation of copyright (until the authors work up another way to give out permission). That would be a major news story, and is why people get excited when the possibility of a "test" arises.
Code is GOOD if it provides users with the features they need. The old Unix code may be robust and elegant, but it lacks features. Essential things like networking, graphics, and user IO over anything but a vt100.
When users start to demand features that are far beyond the scope of the original design, the developer can take two courses:
It's pragmatism versus ideals. In a vacum, the most beautiful approach may seem best. But is it "GOOD" if you can't really deploy it? Today's WWW is an ugly, hackish rat's nest compared to the design of the Xanadu proposal from decades earlier. But it exists, and it works.
(Even aside from unforseen new capabilities, the old Unix utils for things like text processing filters often turning out to be inadequate. They'd have firm upper limits on input sizes, or would deccelerate unacceptably when asked to do a big job. Simplistic design mean shortcomings in some uses. GNU versions of fileutils, for instance, corrected a lot of these limitations, at the cost of uglified source code)
Sendmail is good code.
If it's so great (and also free), why have so many people been inspired to reinvent the mail server? Qmail, Exim, Postfix...
And Bill Gates stated that MS EULAs don't endanger privacy.
The text of the license is the only thing with a legal standing. Anything else you hear is just so much hot air. A statement by RMS might suffice as a promise that the FSF won't pursue you for violating the GPL in that manner. But it has no bearing on how Linus Torvalds or AOL-Time Warner might react.
And without seeing a quote, I'd doubt that RMS would've said something quite like that. (Especially considering that an "Organization" can be construed to be a huge group, like "US Taxpayers")
Maybe you're talking about this GPL FAQ. It says that you're not required to release modified versions. (The fact that you've modifed GPL code doesn't force you to either send patches upstream, or post it on your own website). But it doesn't let you forbid release either. That FAQ ends with "but the decision of whether to release it is up to you". Who is "you" in that sentence? It's not the manager or board of directors- it's every single person with a copy of the software. (Another FAQ makes this more explicit)
In any organization of nontrivial size, you'll eventually find someone who both wants to publish the code, and doesn't care about keeping his job (or is secretive enough to be anonymous).
The GPL contains no "in-house" or "internal use" exception. If you have 1000 programmers editing the code, 5% of them will spontaneously decide to mail some patches to Linus. And you can't stop him. Your programmers distribute the code to each other via the GPL- otherwise they're not allowed to share with each other. This gives any of them permission to send copies to whoever he wishes.
Sure, as long as you're his boss, you can command him not to give copies to anyone without your personal approval. But a good lawyer could argue this is a GPL violation. By distributing code under GPL, you gave the recepient permission to distribute it. But at the same time, you gave him instructions not to distribute it. That's tantamount to editing the GPL in an impermissable way.
A related lawsuit has already happened: before recieving modifed copies of a GPL program, users were made to sign a separate contract promising not to redistribute it. That is a flagrant violation. (The defendants backed down before making it to court, so it's not a watertight precedent)
(Even if that argument doesn't hold up in court, the turnover rate for 1000 programmers will be significant. Soon enough, an ex-employee will find himself with a leftover copy of the code, and then he's free of your control)
it doesn't force me to release my changes, and if it did it would be unenforcable.
Many quasi-Open Source licenses (including some created in the past by Sun and Apple) have required all changes be transmitted to the original publisher. Their lawyers seemed to think it was enforcable (although impractical, and it made their code untouchable once people learned of it, so they've backed away towards more agreeable conditions)
Your experience is non-representative of modern use. Google has seen "flood fill" 490,000 times, but only knows of 246,000 uses of "bucket fill".
Flood Fill is the original description used by computer graphics programmers. "Bucket Fill" is a variation invented by Xerox or Apple to matchup with the icon on their GUI toolbar.
Funny? Not really. Faster, modern disk IO means no more spending 80% of game time waiting for screens to load.
It also means you can save your game every 60 seconds, without waiting (swap game disk for save disk...wait wait wait... swap back), and with no concern for running out of space. That'll save you a lot of lost time when the game pointlessly kills you (carnivorous mushrooms, anyone?)
PS. SQ2 had no mechanized pugilists. You're off by one sequel. For minigames, SQ1 had desert-racing and anti-Sarien gunslinging. I don't remeber any in SQ2, but the 3rd game (which changed to a totally different graphics engine) had AstroChicken and boxing. AstroChicken had catchy music and was rather fun. Two more sequels, and they were reduced to "You Sunk My Battlecruiser", one of the least entertaining things imaginable.
CowboyNeal is mistaken if he thinks a Sierra game like SQ or LLL forced the user to watch floodfilling happen. Those games used precomputed pixmaps for graphics- there was be a severe delay as they were loaded from a (5.25") floppy for each new screen, but you couldn't actually watch the graphics redraw.
There were other games who exposed the process of rendering 2d vector graphics. I recall a few "Carmen Sandiego" clones for IBM PC or Apple that did this around 1982.
Going back even further, Sierra had some games like "Mystery House" which did monochrome line art. IDR if there was floodfilling or not.
We don't have to do it alone. We could just as well lead a partnership of world space agencies to accomplish the same goal. I'd prefer this, actually.
Even if it were to be a multinational effort, a moonbase facility would be difficult to secure. Whichever nation has the most personnel on the moon can seize control at will. (Or whoever first decides to smuggle up weapons- which is possible for whoever runs the launches).
A moonbase with longterm habitation and electrical power (eventually more than several traditional nuculear plants!) would be a potent platform to assault anyplace on earth. Yeah, Heinlein's gravity-well bombardment might not work. But modifying the microwave beam to a tighter focus or a different bandwidth- or flat out replacing it with a laser- you could start to scorch the planet.
(Or at minimum, melt off the antennas of any opposing satellites)
A military moonstation would make an entertaining element for speculative fiction. You can imagine paranoid dictators synchronizing themselves to a lunar cycle- refusing to go outdoors when the moon is in the sky.
I expect court officials to be held to the standards (that is, not lying and cheating) that it is their job to uphold.
Lying is not illegal. In a court it is, and for fraud it is, but in general being untruthful is no crime.
Undercover police have always lied when approaching suspects.
"Are you a cop?" "No."
how does this help justice
The concensus is that officials lying during investigation/interrogation is OK, as long as they come clean when giving evidence in court.
It would violate his parole to substitute d1g1ts for v0w3ls.
Even if he didn't take something, I don't think you could really claim that the burgler did a positive thing ... he spoiled the trust and made people fearful.
Depends on the magnitude of the theoretical Greater Bad Guy.
If someday the residents he didn't visit are found chopped up in their dishwashers, then I would totally claim the first intruder was doing a good thing. (Not great, but more good than bad. And leaving an informative note is a positive factor in your example, but Kevin did nothing of the sort)
"Spoiled trust?" False trust is more dangerous than none at all.
Depending on implementation details, they can still maintain a lot of control. As was mentioned, Blizzard's Battle.Net uses P2P between the individual players for long-lasting, high-bandwidth connections that run a game. But the administrative functions- user login, player matchmaking, and game startup- are handled on their own systems.
That way, they've got fairly low server costs, yet control how the product is used. Woe to he who thinks to wrest the central server from them.
"already has libraries written" = "someone else had to write it". That tells nothing about how difficult it was.
I could similarly say that "Quicksort can be implemented as 2 lines of C code (because a library's already written)".
Besides, Erlang isn't really a purely functional language. Well, "pure functional" languages hardly ever amount to more than academic toys, but there are other languages that come a lot closer.
Here's a one line Erlang program:
hello() -> io:fwrite("hello\n").
See that "fwrite"? It means "write to the file called io". Telling the computer to do something- that's imperative.
Here's the equivalent in ML:
val it = "hello" : string
The criticial distinction here is that there's no verb-equivalent. In a functional style, everything is either a statement of fact- standalone like a noun (constant), or relative to another like an adjective (function). ML isn't purely functional either, but it looks closer.
Of course, any useful language can be used for programming in either imperative or functional styles (with some small additional awkwardness). Take the QuickSort example someone gave. Even though they're called "imperative" languages, developers working in C++, Java, or Perl would tend to implement something that directly follows the functional outline.
(Note that some academics will say that the criticial distinction of a functional language is that functions are treated as first-class objects. "functional vs non-functional". I'm using the simpler definition- functions as per math functions- which treats the distinction as "functional vs imperative")
Nintendo uses Lisp for game programming, maybe even Mario64.
Of course I haven't seen the code, but if they're at all like most game developers, Mario64 isn't written in Lisp- it is C and assembler. "Behaviors of monsters inside the game" may be in Lisp, that's a fairly common approach. But not "the game" itself. Things like "load the texture resources from disk, calculate normals for polygonal models, run a 40hz event loop on gamepad input"... they're just too hard to describe functionally.
Solar panels are what's being proposed. Did you read the article? The guy has written 200 papers about it... if there were a significantly better way, he might've thought of it already.
Because in a binary system -1 is not a valid number.
Why not? -1 is just as valid in binary as in octal, decimal, or hex. "binary" just means base-two.
Maybe you think it implies the values are unsigned, which is the simplest obvious way to handle numbers in a computer. Some programmers observe how their computers behave, and assume this is the truth. This can lead them to pronounce absurdities like 65536+2=1. But computers are limited- the definitions of math provide the real authoritative true results (unless you state a specifc set of alternative assumptions).
Some examples may exist- but remember that there are counterexamples too. Some problems are not inherently recursive or functional, and trying to adapt functional programming styles just brings pain.
Humans are (mostly) imperative creatures. Computers are completely imperative machines, although they can emulate functional behavior. Sometimes its safer to stay closer to the natural abilities of your hardware, rather than going too far beyond.
Try sketching out the overall structure of something like Apache or SuperMario64 as a functional program to see what I mean.
The flood-fill algorithim in bitmapped graphics is easy to describe functionally, but running the program might swamp your computer. (Depending on smartness of your compiler, and other factors).
Even a compiler (seemingly a class of software most closely resembling a unary mathematical function) is difficult to write purely functionally. I recall when a respected college professor attempted this. The result was essentially correct, but mind-bendingly ugly, and he'd spent much more time than needed.
Those things that are drastically easier to describe in a functional style (such as the Quicksort described by another respondant) tend to be fairly brief algorithims, and heavy documentation on them is easily accessible,
Even so, a site in southern Texas, along the coast, would share all of those qualities, or be even better.
And the humidity would be less. Not like it really matters though. When you've got thousands of liters of liquid oxygen sitting there, condensation will happen from any kind of air.
Why not? Because it would've made them cry, that's why. They'd struggle through a spacewalk, see the damage, and know they were all going to die. Since there was no way to fix it, they didn't bother to look.
It would've been honest and responsible to try and inspect for damage, but NASA kept its fingers crossed and optimistically hoped that nothing could go wrong.
Why could nothing be done about it? They couldn't wait for a rescue shuttle (well, there's was a slim chance). They couldn't go to ISS and wait there (unless they were launched on an intercept course, that much travel would exceed their manuvering fuel). And, assuming the damage was to the fragile heat-insulating tiles, they couldn't fix it themselves.
Why couldn't they fix it? They had no spares? Why not? Because even standing on a scaffold with proper tools, it takes 30 hours to replace one fist-sized tile. (I had trouble believing it took so long, but NASA said so. Retiling is one of the slowest parts of refiting a shuttle for another flight)
Bouncing a tennis ball of the shuttle would break 2-4 tiles. If that happens after lift off, you've just gotta write off the whole vehicle.
PS: The long-shot approach (waiting for another shuttle to be launched for rescue) might've involved the kinds of bitter calculations sociology undergraduates tackle in classroom exercises each spring. In a rush, the ground crews might've taken 3-5 weeks to prepare a another trip. No shuttle so far has stayed up even 3 weeks. I can imagine them doing the math: "They rescue us in 25 days. But we suffocate in 21 days- unless we kill two people immediately!"
A cool concept, but the nations of the earth would be too fearful of weaponization to allow any one group the chance to control something like that. "Harmless microwaves" they say- the spectre of GW Bush ordering lunar energy beams to raze North Korean nuculear sites will be on everyone's minds. The James Bond / Dr. Evil scenario come to life.
(Aside from the ongoing dispute as to the feasibility of assembling a solar-panel whose total potential energy output will exceed that used to construct it.)
It would be additionally great if other aspects of your remote terminal could be reported to an application server in the same variable as well.
/mnt/samba/what_hostname_am_i_sitting_at_again?
Stuff like: joysticks, cdroms, writable local storage (under strict permissions set by the Xserver config), even local USB devices.
Because you know, if thin-clients based on *nix and X11 ever become popular, users will want to save files to a floppydisk in front of them without navigating down
Of course, developing this would be much harder than building audio capabilities- terrible OS incompatibilities, as well as conflicting with existing X abilities.
To reach this goal, you'd nearly have to create a new application-service system, with X11 as just one component.
The exact transport mechanism is a library implementation detail - why should the end user or even the application developer care?
/dev/dsp in the server room. But that's what'll happen until he figures out how to configure a completely separate transport mechanism to tell the audio where he's sitting.
That's why it's an advantage. Using the same transport for graphics and sound reduces the chance that a user will need to care what the transport is.
Once an end user gets a remotely running application displayed, he doesn't want to worry about all his beeps and honks coming out of
Most people have enough trouble handling $DISPLAY, xhost+, and MIT-Magic-Cookie. Piling extra variables on top of that will make end-users throw up their hands.
"Oh, now I need to start esound client, esound server, esd-dsp when running programs, and then allow a separate UDP port through my firewall". "And now running X11-over-ssh, I have to create a separate VPN-tunnel for the audio data"
Sure, there are Linux distributions and smart sysadmins who prepare those things for you. But even they often mess up, and they can never plan ahead for all the flexibility an end-user may want. For instance, X-servers are available on Microsoft Windows. It'd be much easier to get a new version of one of those to understand "audio-over-X protocol" than to try running esoundd under cygwin!
But not necessarily highest. The Russian alphabet scores higher
The very-important criteria of ease of learning is composed of 2 parts: inherent simplicity, and existing skilled base. Existing skilled persons both reduces the total amount of learning needed, and provides new learners with educational resources.
That's where the Roman alphabet really dominates. It is the primary component of the native character sets of all Americans (North & South), most Europeans, many Indians and Africans, and is recognized and used by the computer-using classes of China, Korea, Japan and Singapore.
(Did I forget Australia? Oh well, won't bother to go search for what they use)
I suppose supplying a link or searchable keyword would've been easier than ranting along. But I love to watch myself type.
In other words, a fall of civilization
Which is plenty close-enough to "doom" for all long-range planning purposes (up to and including extraterrestrial colonization)
Today there are 500 times as many humans as when we last weathered an ice age. Losing 499/500ths of something doesn't count as total destruction, especially if it's something that can regrow, but it's still unspeakably bad. (And there'd only have to be one more tiny push- like a few more degrees of cold- to finish off the 1/500th remaining)