Most of these projects, like most VC projects of any kind, were not only expected to fail, they were required to fail.
Consider LinuxCare: the VCs installed crooked executives who raided the cash box, handing much of it to the VC's other ventures, and pocketing the rest.
How many startups got a few million and then handed half over to Oracle, Sun, and EMC, and handed the rest to the execs, and then folded? How many went on a buying spree, handing over boatloads of inflated shares to the VCs (to sell immediately) in exchange for other failing companies, right before they tanked themselves? How many went public and the bankers got enormous kickbacks, buying captive shares at a fraction of their value the next day, and then selling out immediately? The losers were not the VCs -- they made out like bandits on those "failures".
Enormous amounts of money changed hands under very little official scrutiny. That was the point. Business successes, where they happened despite all, were just icing on the cake.
As I understand it, one of the reasons satellites can't read your credit card is because of the diffraction limit. Yes, you also have distortion caused by inhomogeneities in atmospheric density, but that's correctable with adaptive optics. Scattering by particulates isn't correctable, but there often isn't much there.
Does this development mean that the main limit on satellite telescope resolution has fallen?
Visual Basic is not BASIC. Delphi isn't Pascal. Both are proprietary languages with exactly zero portability; as their platforms fade, the code will fade with them. (How much Clascal, Apollo Pascal, or Bliss do you see these days?) Code written in such languages vanishes even faster than Java code will.
C remains the canonical language for interoperability, purely because every existing commercially viable language (like every new language, for at least two decades to come) provides a way to call out to C functions. That is not true of any other language, and may never be.
Most jobs posted on job sites are fakes, filled with the current popular buzzwords. (This is easily verified by distributing a stellar resume and seeing how many callbacks you get.) When the next fad pops up, the fake listings will use its buzzwords instead. Actual Java jobs that pay more than scale for web page designers remain rare.
There are ISO standards for a few languages. Those languages have a chance to be viable for a while.
Why not present a C interface? You can get at that from any language, and anybody can maintain it. Why not present a C++ interface? It remains unsurpassed as an industrial language. Ten years from now when Java and C# are as nearly forgotten as BASIC and Pascal are now, C will remain an important language, at least for interoperability purposes, and C++ will still be well known and heavily used.
There's no better way for your work to wash away than to associate it with passing fads.
It seems like they are going to be extremely reluctant to revoke keys in hardware players. They will be way less reluctant to revoke keys in software players, and might even do it on a regular schedule. If you have a legitimate copy, you can download an update from the same place as you got it. It's certainly a lot easier to extract the key from a software player -- although maybe the key will be in the drive, and not in the software. Emulating and whatnot doesn't help then.
Also, they might put hundreds of keys on each machine. If it's equally hard to extract each one after the previous one is revoked, then people might stop bothering after a while. Revoking a key doesn't hurt the vendors at all, then, so they'll do it freely, maybe even on a regular schedule, as above. They might go through a dozen per year, per player -- every time a hit movie comes out, a key from each player (or each player whose keys they have seen compromised) is revoked. Then, the impact of free downloads on sales is delayed for a few key weeks or months until somebody gets around to extracting the next key and distributing it to everybody who needs it.
There's no absolute security, but there can be enough. Safes are designed not to keep people out indefinitely, but to keep them out longer than they can afford to take trying to get in.
Speaking of evil...
From the press release: "ensuring the safety and reliability of the nation's nuclear arsenal"
They don't mention, in these press releases, how they have redefined the words "safety" and "reliability". In their usage, "safety" is defined as "it really will pop when you press the button", and "reliability" is defined as "it really will demolish as much as it's rated to demolish". This is a neat bit of Orwellianism on their part. Everybody likes safety, right? But nothing in the charter, under their interpretation, says that it's their job to make sure they don't leak, or pop by accident, or vanish mysteriously, despite that any normal person would assume that from reading it.
Emacs and Vi are now the same program. Just make viper-mode your default in Emacs. Amazingly, the command sets for Emacs and Vi are almost disjoint, so you can use both at the same time. It really works.
No, I don't use C++ for everything. I use bash for scripting, and have written Python programs recently. (That's not to mention C, Pascal, BASIC, Fortran, assembly, Scheme, Prolog, and what-have-you from the old days.) Lots of people use Matlab for prototyping real programs.
Rather, I meant to suggest that there's no job for which C# or Java is the right tool, unless it's padding one's corporate IT department budget with a staff of interchangeable monkeys. (That is an important criterion for some, but, again, not in the Free Software world.)
I don't see how there needs to be a tradeoff between performance and quick development. Wny not have both? Similarly, why trade off performance against safety? Why not have both?
C++ is *far* from the best possible language for those things it's best at. It's only the best so far.
Nobody ever said C was expressive. If you don't think C++ is as expressive and powerful as, say, ML, you know very little about it. (See http://boost.org/ for an eye-opening experience.) Expressiveness isn't an abstract virtue: it means you can write libraries that are very powerful, yet easy to use.
C++ the language is mature. G++ is mostly there. Even "two years ago" it was in good enough shape that hundreds of the programs that come with your favorite distro are written in it -- many times more than all those in Perl, Python, Java, and C# combined. That you haven't noticed is because they work with no fuss. (Do you run *any* Java program that is not obviously a Java program?)
Support for "export" (not "extern") turns out not to be very important for portability, as very few other compilers support it either. Most people who think they want it are mainly concerned with not exposing their source code; which is not of much interest in the Free Software world.
Garbage collection is one of the main reasons Java and C# are so slow. (Benchmarks claim only 3x. Experience shows 30x is more common, due largely to GC's effect on cache performance.) Multiple inheritance costs nothing; why bring it up?
Consider carefully why only promoters of dull tools endlessly intone "the right tool for the job"? A sharp tool works well everywhere. Java and C# are "higher level" only under a facetious definition of the term; are blunt kiddie scissors "higher-level" than my Fiskers? Programs written as if performance doesn't matter interfere with operation of other programs where it does.
C#, like Java, was designed to solve problems we don't have in the Free Software world. The compromises that are designed into the language make it, like Java, inherently less useful for Free Software than languages designed purely for performance and expressiveness. The haste with which it, like Java, was cobbled up make it poorly suited to describing what we want done with our machines. We don't need to "write once, run hardly anywhere"; we already build and run wherever we like.
I don't have a Java VM on my hosts, and I don't see any reason to saddle them with a Mono VM, or VMs, either. The only Java program I have found a need or desire to run (pdftk, a PDF toolkit) runs (as well as any Java program can) as a native binary compiled with Gcj. A C# front-end to Gcc might have some value for compiling programs so unwisely written in that language, but a bytecode interpreter seems just silly.
We already have a powerful, mature, and efficient language, proven effective for myriad successful Free Software projects. It's called C++. It integrates so well with Free Software systems that nobody even needs to know that they are running a C++ program. Murray Cummings has stepped up and produced well-packaged C++ library bindings for all of GTK and Gnome components, so it is easy to use for writing Gnome applications.
Miguel's unhappy experience with Microsoft's buggy pre-standard compiler (mislabeled "C++") has unfortunately led him astray. We need not be similarly misled.
If there's something unacceptable in the contract, just cross it out before you sign. If that means they retract the offer, and that keeps you from crossing it out, then it's not really unacceptable after all, is it?
I'm the "original poster", and einhverfr is right: "know-nothing bozos", in this context, does refer to 99% of computer users, and way more than 99% of humanity at large. By that I mean that they will use what they are told to use, and like it. It includes crack-house addicts, university presidents, bubblegum groupies and writers of intricate political thrillers alike.
As in every technical field, it's up to those people who can be bothered to study the matter to tell the rest what to use, and what not to. The difference with computer software is that they have long failed miserably in their responsibility to distinguish the gold from the dross, and to tell others. Instead they have become boosters and toadies of the reigning monopoly. Toadyism has a long and in a few cases distinguished history, but is no more honorable for it.
Screeds like this come out every few months. They always say the same thing, and they always get the same "ditto" responses. It happened when there were 1000 Linux systems, and when there were ten thousand, and a hundred thousand, and a million, and ten million. Pretty soon there will be a hundred million, and maybe a billion a little later.
At each stage the claim has been that to get anywhere, we have to change what we're doing. Each time they have been wrong. Nobody knows for sure what will work best, but the best bet is what worked already. What we have is still growing by leaps and bounds, just as it always has done.
Imagine a world in which Free Software precisely as it is today was the norm. Imagine Microsoft trying to nose into it. BSOD? DLL wars? Viruses, worms, spyware, adware, pop-ups, DRM, "no-print" flags? Downloading drivers? Re-booting with every hiccup and adjustment, and re-installing every few months as the system decays? Forced upgrades that break what you had? Ever-increasing license fees for ever decreasing value?
All such diatribes have one thing in common. They are about what it takes to get two groups to embrace Free Software: proprietary software vendors, and know-nothing bozos. The former will never embrace Free Software because, frankly, they have little to offer it, and less all the time. The latter will use what they're given and like it, as they always have. Everybody else already sees the advantage, and has switched or is planning to switch.
My cousin, working for Raul Cano at CalPoly, worked with bacteria extracted from the crops of bees stuck in amber tens of millions of years ago. Of course everyone insisted the bacteria they got were just lab contamination, until they sequenced the critters and showed that they were ancestral to modern strains living in modern bees!
Of course the bacteria were entirely dessicated, not just frozen, so it's a better model of the martian situation.
The reason nobody releases software in the public domain is that it would expose them to liability for bugs found in it. You can't make use of it depend on acknowledging the lack of warranty etc. if in fact anybody can use it without restriction.
Of course real inkjet images will always look better. I know a small company called R-Quest makes printers that produce an astonishingly good image, using an HP mechanism. (No, I don't work for them.)
I had Javascript enabled, which is probably necessary. It compromised a pop-up-blocked Galeon 1.3.18 window just fine. You guys reporting invulnerability, do you have Javascript on?
I just got a job making coffee for the, um, interrogators at Guantanamo bay. They're used to percolated mud. I'd like for them to have better coffee, but they wouldn't go for any sort of espresso drink -- if it's not in the pot when they walk up, it's not coffee. What can I do to get them better coffee?
The answer is, some people don't deserve good coffee. If you want a job making good coffee, go where people can tell the difference.
For bug tracking... let the bigots rent some $25,000 bugpile, and suffer with it. When some machine gets rotated out of service because it's not up to running bloatware, put a Linux or BSD on it, and set up a little bugzilla server, "just as an experiment". Tell a few people (ones who have problems with the bugpile) about it so they can use it for their own purposes, sans management, and let them spread the word. Gradually it will become impossible to shut it off, because too many people depend on it. Start adding other services to supplant official stuff that doesn't work. Eventually, you will be asked to move it to a beefier host, because so many people depend on it, and the official services will come to languish. .
Slashdot Mirror
Just practicing.
Most of these projects, like most VC projects of any kind, were not only expected to fail, they were required to fail.
Consider LinuxCare: the VCs installed crooked executives who raided the cash box, handing much of it to the VC's other ventures, and pocketing the rest.
How many startups got a few million and then handed half over to Oracle, Sun, and EMC, and handed the rest to the execs, and then folded? How many went on a buying spree, handing over boatloads of inflated shares to the VCs (to sell immediately) in exchange for other failing companies, right before they tanked themselves? How many went public and the bankers got enormous kickbacks, buying captive shares at a fraction of their value the next day, and then selling out immediately? The losers were not the VCs -- they made out like bandits on those "failures".
Enormous amounts of money changed hands under very little official scrutiny. That was the point. Business successes, where they happened despite all, were just icing on the cake.
As I understand it, one of the reasons satellites can't read your credit card is because of the diffraction limit. Yes, you also have distortion caused by inhomogeneities in atmospheric density, but that's correctable with adaptive optics. Scattering by particulates isn't correctable, but there often isn't much there.
Does this development mean that the main limit on satellite telescope resolution has fallen?
Freenet was an awful implementation not despite, but specifically because of "being written in Java". (Probably there were other reasons too.)
C remains the canonical language for interoperability, purely because every existing commercially viable language (like every new language, for at least two decades to come) provides a way to call out to C functions. That is not true of any other language, and may never be.
Most jobs posted on job sites are fakes, filled with the current popular buzzwords. (This is easily verified by distributing a stellar resume and seeing how many callbacks you get.) When the next fad pops up, the fake listings will use its buzzwords instead. Actual Java jobs that pay more than scale for web page designers remain rare.
C++ book sales are still increasing.
There are ISO standards for a few languages. Those languages have a chance to be viable for a while. Why not present a C interface? You can get at that from any language, and anybody can maintain it. Why not present a C++ interface? It remains unsurpassed as an industrial language. Ten years from now when Java and C# are as nearly forgotten as BASIC and Pascal are now, C will remain an important language, at least for interoperability purposes, and C++ will still be well known and heavily used. There's no better way for your work to wash away than to associate it with passing fads.
It seems like they are going to be extremely reluctant to revoke keys in hardware players. They will be way less reluctant to revoke keys in software players, and might even do it on a regular schedule. If you have a legitimate copy, you can download an update from the same place as you got it. It's certainly a lot easier to extract the key from a software player -- although maybe the key will be in the drive, and not in the software. Emulating and whatnot doesn't help then.
Also, they might put hundreds of keys on each machine. If it's equally hard to extract each one after the previous one is revoked, then people might stop bothering after a while. Revoking a key doesn't hurt the vendors at all, then, so they'll do it freely, maybe even on a regular schedule, as above. They might go through a dozen per year, per player -- every time a hit movie comes out, a key from each player (or each player whose keys they have seen compromised) is revoked. Then, the impact of free downloads on sales is delayed for a few key weeks or months until somebody gets around to extracting the next key and distributing it to everybody who needs it.
There's no absolute security, but there can be enough. Safes are designed not to keep people out indefinitely, but to keep them out longer than they can afford to take trying to get in.
Speaking of evil... From the press release: "ensuring the safety and reliability of the nation's nuclear arsenal" They don't mention, in these press releases, how they have redefined the words "safety" and "reliability". In their usage, "safety" is defined as "it really will pop when you press the button", and "reliability" is defined as "it really will demolish as much as it's rated to demolish". This is a neat bit of Orwellianism on their part. Everybody likes safety, right? But nothing in the charter, under their interpretation, says that it's their job to make sure they don't leak, or pop by accident, or vanish mysteriously, despite that any normal person would assume that from reading it.
Emacs and Vi are now the same program. Just make viper-mode your default in Emacs. Amazingly, the command sets for Emacs and Vi are almost disjoint, so you can use both at the same time. It really works.
No, I don't use C++ for everything. I use bash for scripting, and have written Python programs recently. (That's not to mention C, Pascal, BASIC, Fortran, assembly, Scheme, Prolog, and what-have-you from the old days.) Lots of people use Matlab for prototyping real programs.
Rather, I meant to suggest that there's no job for which C# or Java is the right tool, unless it's padding one's corporate IT department budget with a staff of interchangeable monkeys. (That is an important criterion for some, but, again, not in the Free Software world.)
I don't see how there needs to be a tradeoff between performance and quick development. Wny not have both? Similarly, why trade off performance against safety? Why not have both?
C++ is *far* from the best possible language for those things it's best at. It's only the best so far.
There is no such language as "C/C++". C is a language. C++ is a different language. Good C code is bad C++. Good C++ code is not C at all.
Nobody ever said C was expressive. If you don't think C++ is as expressive and powerful as, say, ML, you know very little about it. (See http://boost.org/ for an eye-opening experience.) Expressiveness isn't an abstract virtue: it means you can write libraries that are very powerful, yet easy to use.
C++ the language is mature. G++ is mostly there. Even "two years ago" it was in good enough shape that hundreds of the programs that come with your favorite distro are written in it -- many times more than all those in Perl, Python, Java, and C# combined. That you haven't noticed is because they work with no fuss. (Do you run *any* Java program that is not obviously a Java program?)
Support for "export" (not "extern") turns out not to be very important for portability, as very few other compilers support it either. Most people who think they want it are mainly concerned with not exposing their source code; which is not of much interest in the Free Software world.
Garbage collection is one of the main reasons Java and C# are so slow. (Benchmarks claim only 3x. Experience shows 30x is more common, due largely to GC's effect on cache performance.) Multiple inheritance costs nothing; why bring it up? Consider carefully why only promoters of dull tools endlessly intone "the right tool for the job"? A sharp tool works well everywhere. Java and C# are "higher level" only under a facetious definition of the term; are blunt kiddie scissors "higher-level" than my Fiskers? Programs written as if performance doesn't matter interfere with operation of other programs where it does.
C#, like Java, was designed to solve problems we don't have in the Free Software world. The compromises that are designed into the language make it, like Java, inherently less useful for Free Software than languages designed purely for performance and expressiveness. The haste with which it, like Java, was cobbled up make it poorly suited to describing what we want done with our machines. We don't need to "write once, run hardly anywhere"; we already build and run wherever we like.
I don't have a Java VM on my hosts, and I don't see any reason to saddle them with a Mono VM, or VMs, either. The only Java program I have found a need or desire to run (pdftk, a PDF toolkit) runs (as well as any Java program can) as a native binary compiled with Gcj. A C# front-end to Gcc might have some value for compiling programs so unwisely written in that language, but a bytecode interpreter seems just silly.
We already have a powerful, mature, and efficient language, proven effective for myriad successful Free Software projects. It's called C++. It integrates so well with Free Software systems that nobody even needs to know that they are running a C++ program. Murray Cummings has stepped up and produced well-packaged C++ library bindings for all of GTK and Gnome components, so it is easy to use for writing Gnome applications.
Miguel's unhappy experience with Microsoft's buggy pre-standard compiler (mislabeled "C++") has unfortunately led him astray. We need not be similarly misled.
If there's something unacceptable in the contract, just cross it out before you sign. If that means they retract the offer, and that keeps you from crossing it out, then it's not really unacceptable after all, is it?
As in every technical field, it's up to those people who can be bothered to study the matter to tell the rest what to use, and what not to. The difference with computer software is that they have long failed miserably in their responsibility to distinguish the gold from the dross, and to tell others. Instead they have become boosters and toadies of the reigning monopoly. Toadyism has a long and in a few cases distinguished history, but is no more honorable for it.
At each stage the claim has been that to get anywhere, we have to change what we're doing. Each time they have been wrong. Nobody knows for sure what will work best, but the best bet is what worked already. What we have is still growing by leaps and bounds, just as it always has done.
Imagine a world in which Free Software precisely as it is today was the norm. Imagine Microsoft trying to nose into it. BSOD? DLL wars? Viruses, worms, spyware, adware, pop-ups, DRM, "no-print" flags? Downloading drivers? Re-booting with every hiccup and adjustment, and re-installing every few months as the system decays? Forced upgrades that break what you had? Ever-increasing license fees for ever decreasing value?
All such diatribes have one thing in common. They are about what it takes to get two groups to embrace Free Software: proprietary software vendors, and know-nothing bozos. The former will never embrace Free Software because, frankly, they have little to offer it, and less all the time. The latter will use what they're given and like it, as they always have. Everybody else already sees the advantage, and has switched or is planning to switch.
Of course the bacteria were entirely dessicated, not just frozen, so it's a better model of the martian situation.
Bzzzt. Wrong.
The reason nobody releases software in the public domain is that it would expose them to liability for bugs found in it. You can't make use of it depend on acknowledging the lack of
warranty etc. if in fact anybody can use it without restriction.
The first thing they should post is a detailed explanation of why nobody releases software into the public domain.
Of course real inkjet images will always look better. I know a small company called R-Quest makes printers that produce an astonishingly good image, using an HP mechanism. (No, I don't work for them.)
If it doesn't interfere with revenue, it's not a bug, by Bill's definition.
I had Javascript enabled, which is probably necessary. It compromised a pop-up-blocked Galeon 1.3.18 window just fine. You guys reporting invulnerability, do you have Javascript on?
The answer is, some people don't deserve good coffee. If you want a job making good coffee, go where people can tell the difference.
For bug tracking... let the bigots rent some $25,000 bugpile, and suffer with it. When some machine gets rotated out of service because it's not up to running bloatware, put a Linux or BSD on it, and set up a little bugzilla server, "just as an experiment". Tell a few people (ones who have problems with the bugpile) about it so they can use it for their own purposes, sans management, and let them spread the word. Gradually it will become impossible to shut it off, because too many people depend on it. Start adding other services to supplant official stuff that doesn't work. Eventually, you will be asked to move it to a beefier host, because so many people depend on it, and the official services will come to languish. .
It seems as if NASDAQ should have something to say about this...