The tremendous question, which remains unanswered by Stallman, is: How will free software generate the revenues necessary to pay programmers? Because it's very difficult to charge money for something people could easily acquire for free.
This question seems to be "brushed aside" by Stallman every time he talks about these issues. He mentions something to the effect of "you can charge for distribution." But right now CheapBytes sells CDs for $0.89 and that's not enough to pay any programmers.
Thus far, free software has been funded by two main factors. First, corporate largesse, where some large corporation (like AOL, IBM, or Sun) deems it worthwhile to fund some project (like Mozilla, the Linux kernel, or OpenOffice). Second, developers donating their time, which is usually done out of interest (as a hobby) or to gain a kind of credential ("I'm one of the authors of Apache").
These two sources of funding have worked very well thus far, but they're both quite limited. Because the funding for free software is limited, the amount of free software is limited as well. The vast majority of the software in the world remains proprietary, and will remain proprietary, until free software has a means of generating revenue to pay more programmers than it does at present.
It seems to me that Stallman should advocate government subsidies for free software development. The money could be distributed as grants to groups of developers who previously have demonstrated (and continue to demonstrate) productivity in releasing software that a great many people use.
It would only require a few billion dollars a year to produce an enormous amount of free software. This tax wouldn't have to be shouldered by the U.S. alone; it could be paid for by a large number of countries, including European countries, Japan, etc. The total bill per citizen could very well end up being less than $1/year.
This would solve the funding issue for free software. Adequate desktop free software could rapidly be produced.
This suggestion is entirely in line with what the government does already. This is because governments fund much or most of the research that is already carried out, and software is actually a kind of research, not production. Take the NIH as an example (the National Institutes of Health). That publically funded entity produces the majority of the research done on disease; and the entire U.S. pharmaceutical industry is dependent on its findings.
Public funding for free software could very easily save the economy money, in the long run. Look at how much money we pay to the Microsoft monopoly...
Egads man, the entire web is all about multimedia. How on earth can you claim that it's a flop?
The web is not about "multimedia." The term "multimedia" was coined long before the web; and the web was not based at all on some idea of multimedia. The web isn't multimedia unless you mean "it has pictures and sound" in which case 1930s films are multimedia.
Well the rs232 spec doesn't mention anything about using 25 pins. 9 pin connectors are also very common as well as using POTS telephone cabling (very popular back in the day to wire terminals).
The rs232 spec requires 25 pins. The 9-pin connectors were rs422.
POTS was the kind of CABLE used, not the kind of port. When an RS-232 was connected to POTS, 19 of the 25 pins weren't connected to anything.
Multimedia was a buzzword only. Technically it means "more than one kind of media at once" and television therefore qualifies. But the buzzword had all kinds of additional meanings that never materialized.
Cobol was not on the list; I said "english-like languages that promised to make programming as easy as speaking." Nobody makes english-like programming languages any more; the idea is universally agreed to be silly.
Apple II was not the list; the list included the Apple IIgs which was an incredible flop.
8" floppies had a very brief tenure because as a "compact" form of 10" floppies they weren't much of an advance, but were incompatible with older drives.
Apple IIgs Apple Newton Apple Lisa Next Cube Be BeBox CASE tools "Object Databases" as a replacement to RDBMSes VRML Gopher "English-like" programming langauges that will make programming as easy as speaking (COBOL) "War room" programming "Multimedia" Graphics cards that allow you to watch television on your monitor, by plugging a coax cable into the card. 8" floppies Interactive television Integrating the PC with the TV RS-232 serial port (25 pins, of which 4 are used) WORM drives for PCs QuarterDesk Audio Cassettes for data storage Commodore 16 Windows 1.0 PL/I MSX Dec Alpha "21164-PC" personal computer processor "MPC-compliant PCs" GeoWorks Project Monterey (IBM, SCO, & some others) Micro Channel (bus arch from IBM)
Most of these ideas failed because they were outlandishly stupid. The only reason they got any press in the first place was because the companies promoting them were good at hyping ("it's revolutionary!"), and some people just get caught up in the emotional hysteria.
A few of the ideas (Apple Newton, Apple Lisa) were excellent ideas that just were introduced too early.
"However - this is not the reason that we, the American people, were told was the reason we were sending our troops to war. We were told it was to find WMDs and stop Al Queda - neither of which has happened."
You were told that by whom? When?
You've got to be kidding. George Bush, C Rice, D Rumsfeld, and Colin Powell all repeatedly said that the reason for going to war was to find WMDs and stop Al Queda. Colin Powell even gave a speech to the UN Sec Council (trying to convince them to vote for war) which showed satellite photos of supposed WMD sites in Iraq; after that he listed the Al Queda operatives supposedly in Baghdad. When Bush was asked why the war had to be conducted right then, he responded that if we waited the result could be a mushroom cloud over a major Amercian city.
You were never mislead. You are an idiot, however, which leads you to the conclusion that because you didn't understand, you must have been lied to.
Were you paying attention at all? Are you honestly that obtuse? Or are you just capable of "re-writing" the history in your own mind to fit your political convictions? It's ironic that you accuse someone else of being an idiot.
Clearly what's necessary is to have a small keypad on the card itself, as well as a small CPU, a private key that is encrypted by the user's PIN, and the public key of the bank. That way, all communication between the card and the bank can be encrypted, and no unencrypted information is ever sent through the ATM.
Such a card would not be much larger than current ATM cards.
The worst fraud that could then be perpetrated is to have a fake ATM that deducts $20 from your account but without dispensing the $20. But that scheme would be very quickly identified.
The X team amongst others have done tests (you know, where you measure things), and the implementation... is as fast as you can get.
Tests have been done of the peak bandwidth of X (pixels/sec), and in this regard only, X performs well. But X's latency is TERRIBLE and it takes WAY too long to do things like open windows, resize windows, move windows around, etc. And don't say "they've done tests." Everyone who uses X can tell that it's extremely slow. Right now, Java 1.4.2 Swing GUIs under Windows are far zippier and more responsive than natively compiled GUIs under X, on similar hardware. Moving & resizing windows is instantaneous under Win2k on a 300MHz box; with X it's nowhere near instantaneous on a 2GHz box. That's the biggest problem with X.
Apparently X is slow because it requires a context switch to kernel space every time you move a window one pixel to the left. Additionally, X is unbuffered, so every window beneath that window must redraw itself even if its contents are unchanged. Additionally, X is a protocol and so requires marshalling and unmarshalling with every action performed.
Kill off your own platform! Don't kill your competitor's platform. No. Kill your own platform.
SGI: "Commercial Unix and RISC are dead anyway. Let's just make Windows PCs. No, wait, linux boxen."
DEC: "Vax/vms. No, Mips/Ultrix. No, Alpha/OSF."
HP (with their Unix boxen, which used to have more marketshare than sun BY FAR until they hinted they'd drop PA/RISC, and perhaps even HP/UX eventually).
...Even if your platform is doomed, it will take decades for it to finally die, if you keep developing and updating it. IBM still makes huge money off S/390 and AS/400 (both of which were 'dead' around 1985).
Re:The very worst fashion...
on
Software Fashion
·
· Score: 2, Informative
Just because EJBs [are] misapplied does not mean they have no value... For example, container managed entity beans can make object-relational mapping happen (along with transaction management) with hardly any code. It may seem complicated... but really this is a very simple solution relative to the complexity of the actual task to be performed.
Container-managed persistence may have some value, but it's an ancillary feature of EJB and is included as an "add-in." There are lots of libraries and tools to handle Object/Relational mapping, and the other ones work as well but do not involve the complexity and overhead of EJB.
Not to mention, it appears that container-managed persistence usually just maps each instance variable to a single column in a relational table, with each object being a row. Thus, the code rendered unnecessary by container-manager persistence was actually quite trivial, and the persistence mechanism handles the simplest cases only. The more complicated cases must use bean-managed persistence, which requires as much custom programming as avoiding EJB altogether.
I'm sincerely quite curious to learn what is the actual benefit of EJB. It's possible, of course, that there is some benefit of which I'm unaware. All of the claimed benefits, like scalability and simplicity, seem to be falsely claimed. If there is some situation in which EJBs are genuinely called for, then I'd be grateful if you'd tell me what it is.
Wow, you didn't work hard enough memorizing the anti-Java propaganda sheet.
My post was about EJBs not Java in general. Thus I presume you mean the "anti-EJB propaganda sheet." You probably are the only person who's seen such a propaganda sheet, because all I hear is mindless adulation of the technology, mostly from managers.
It's seven files, if you count XML descriptors and perhaps a DTO.
No, once again, it's up to seven classes, including but not limited to (from memory): Remote Interface, Remote Home Interface, Local Interface, Local Home Interface, Bean Class, and Primary Key class. If you count files it's even more.
"And where a simple constructor would previously have served, EJB requires a long JNDI call." What, can't cache the Home interface? Have you ever written an EJB in your life?
Caching an object doesn't avoid having to construct it. Caching in this case is a way of avoiding EJB mechanisms for constructing an object and (unnecessarily) transporting it over a network. I certainly agree that avoiding the EJB mechanisms is desirable, but this is not a vindication of EJB technology.
Unfortunately I have written EJBs in my life.
I've seen.NET code bring an 8-way box to it's knees. That code would execute faster on my digital watch! Uh-huh.
You apparently think I'm making up the incredibly poor performance of EJBs, even though it's a very well-understood fact within the industry. Once again, running the "shopping cart" demo on a 1GHz 512MB box requires approximately 20-30 seconds to generate each page, and doing so causes enormous amounts of disk thrashing. Generating a single page of text (html) from a database would be blindingly fast when done without EJB. Quite unfortunately, I'm neither making this up nor exaggerating.
The very worst fashion...
on
Software Fashion
·
· Score: 4, Interesting
The very worst fashion has to be EJBs.
EJBs complicate development. Where a single class would previously have worked just fine, EJB requires up to seven (!) classes to define things like the Remote Interface, Remote Home Interface, etc. And where a simple constructor would previously have served, EJB requires a long JNDI call. Not to mention, there are zillions of arbitrary coding restrictions that must be memorized and followed for EJB to work properly.
Furthermore, EJBs drastically impair performance. The "shopping cart" demo that comes with a major commercial app server brings my 1GHz 512M machine to its knees. Such a program could otherwise execute quickly on a 286 8MHz, a machine less than 1/1000th as powerful as the one running the EJB. I regularly encounter shops that have huge farms of commodity boxes to run very trivial EJBs that would otherwise execute on a single box just fine.
And EJBs do not scale any better than 2-tiered systems. 2-tiered systems allow you to horizontally scale the business logic by adding commodity machines to the second tier. Adding another tier does not help this at all.
...For this crippling blow to development, you get to pay Bea $40k/developer. Snake oil! Very expensive snake oil!
Software development resembles a foot race between you and your competitors, and using EJB resembles paying a surgeon exorbitant sums to cut off your left leg before the race. It costs craploads of money, it cripples progress, and it hurts!
The command does not get executed if the write to disk fails. So a failure *IS* handled. The transaction is aborted... You still have all requirements of ACID fullfilled.
No, the failure is not handled. If the write fails in the middle of command serialization, then "junk data" is written to the end of the log. I have tried this by running Prevayler and simulating a failure during command serialization, and "junk data" is created. Prevayler never recovers this "junk data"; it remains in the log forever. Whether deserialization works correctly at that point is dependent on how the VM implements deserialization, but the correct behavior is not guaranteed (see the serialization spec from sun). Deserialization could just as easily throw an exception which Prevayler does not catch. If an Exception is thrown, then Prevayler's logs are corrupted and Prevayler becomes unable to start again.
Thus, Prevayler is not a durable data store. I have verified that Prevayler doesn't clean up this "junk data" and that this leads to a serialization stream which is not guaranteed to work.
There are other serious bugs in Prevayler as well. The most important is: prevayler never recovers or reuses any of its logs. After a snapshot, the prior logs are never used again and are unreachable. But they are simply forgotten by Prevayler, and are never "cleaned up." Thus, prevayler "leaks" disk space over time. The demo they provide leaks about 100 kilobytes a second, even after snapshots. This is not the same as using more disk space with new data. If you have "create" and "delete" commands and continually create and then delete the same object over and over again, then take a snapshot, the database will be empty, and the snapshot file will be very small, but there will be gigabytes of "garbage logs" that Prevayler has forgotten about but which are left lying around on your disk.
Prevayler also leaks temporary snapshot files if a snapshot creation is interrupted, but this is rare enough that it's not critical.
A number of startups that I've dealt with are wrongly convinced of the great importance of what they're doing. They sincerely believe that IBM and Microsoft are spying on them and tracking their movements, desperately trying to learn their secrets.
To most of them, I would say: you have only a few lines of crappy code and a silly idea. Microsoft and IBM don't care about you, and neither does anybody else. When you have some innovative complicated algorithm, or a large code base that's difficult to duplicate, only then should you worry about protecting your IP, not before. Having IP worth protecting is the difficult part; keeping secrets is comparatively easy.
I suspect that the more serious case is when the previous command took 1/2 page and was successful (thus the user had a successful commit) and the current command takes 3/4 page and fails 1/4 of the way into it, possibly corrupting the page that the last command was stored on. This probably won't happen, but who knows what bits are being written when the lights go out? However, any application (including Oracle, DB2, etc) that is writing to disk has to contend with the same issues.
Oracle & DB2 have logic to deal with the case of transactions that were half-written before system failure. Thus, Oracle & DB2 can recover no matter when the lights go out. Prevayler contains no logic to recover if a corrupted object is written to the stream because of a failure during the write. From the java.io javadoc: "All exceptions are fatal to the InputStream and leave it in an indeterminate state; it is up to the caller to ignore or recover the stream state." Prevayler has no capacity to do this. Java.io does not guarantee transaction semantics and neither does Prevayler that runs on top of it.
That means if the write crashes... the transaction is completely lost. And the business objects are all unchanged.
You're mistaken about this. If the system fails during a transaction that requires more than one page write to disk, the result could be an incomplete or corrupted command being written to the log. Java.io.ObjectInputStream does not guarantee transaction semantics, and neither does Prevayler running on top of it. From the java.io javadoc : "All exceptions are fatal to the InputStream and leave it in an indeterminate state; it is up to the caller to ignore or recover the stream state. ". Prevayler never recovers the stream state. Prevayler contains no logic to handle this case.
The code above you show is no "the transaction". The coe above is BEFORE the transaction, writing the "before image".
The code I show is of a command being written to the log. There is no logic to handle the case of failure during the writing of commands that are more than a single page in length. Thus, an incomplete transaction can be written to the log, and prevayler has no way of recovering in that case.
The execution of the command is the transaction, not writing the command to disk, like you think.
A transaction is always what is written to disk, otherwise you don't have a durable data store, and the 'D' component of "ACID" is not fulfilled. If there is any possibility that what you have on disk is inconsistent, and cannot be recovered, then you do not have a durable data store. Prevayler has a case where what is written to disk is inconsistent and cannot be recovered, because it has no logic to handle the case of failures in the middle of writing a multi-page command. Therefore, prevayler is not a durable data store, as was claimed.
P.S., no did find nothing, so you gain nothing.
I did find a bug, a serious one, and I deserve a prize!
What is more likely to happen is that Prevayler applies the transaction log, sees that the last transaction is incomplete/corrupt, and then stops. Result: consistent DB state.
Prevayler doesn't appear to have any logic to handle this case. Java.io.ObjectInputStream doesn't have logic to handle this case either. Therefore, what would likely occur is: a failure of the application.
ObjectOutputStream does not guarantee atomicity. If your command object is larger than the page size of your disk, the "transaction" will take at least two page writes. A software failure between those page writes will lead to "half a transaction" being committed and a subsequent corruption of data. Once data integrity is lost, it is often difficult or impossible to recover. Prevayler has nothing to handle this case. Thus, prevayler does not correctly implement ACID, because it doesn't guarantee atomicity (half a transaction can be committed), consistency (referential integrity would be destroyed in such a case), isolation (this failure wouldn't be isolated to a single transaction) or durability (the problem would only show up upon reloading).
Finding this bug took very little searching. I am apparently the first person ever to find a bug in prevayler. Do I get a prize?
The "Prevayler Team" has written a persistent HashMap with a redo log, using the command pattern. This is exceptionally trivial and is in no way comparable to a database. A database has things like: 4GL query language, referential integrity constraints, data integrity, queryable metadata, separation of logical and physical layers, data independence, declarative rather than imperative querying, dynamically assembled queries, and gazillions of other things. These are the real features that we mean when we say "database." These features are absolutely necessary. Prevayler includes none of them. It is an extremely trivial persistent HashMap, that's all.
Thus, when the prevayler team says "throw away your database," I must assume one of two things. 1) They're trolling for publicity by saying outrageous and purposefully stupid things. Or 2) They are shockingly, mind-numbingly naive, and they don't know what a database is or what it does.
The author of Prevayler wrote this about himself: "Carlos Eduardo Villela is a 19-year old Brazilian graduate in Information Systems... almost 8 years experience has made him a Java and Python enthusiast."
Thus, I have to assume that the authors are mind-numbingly naive. Don't get me wrong, I'm sure the authors are very bright, and I know that some good insights that went into the implementation of prevayler. But let's not throw away our databases quite yet.
Garbage collection in Java is not guranteed... It'll clean up when it god damn well feels like it.
This is false. Garbage collection in Java is guaranteed. The VM times the garbage collection to occur when the CPU was otherwise idle, or when additional memory is needed by the VM or by other programs. This is the most reasonable behavior.
In the meantime, the system slows to a crawl.
This is false. Garbage collection is deferred to improve performance. Deferring gc does not make anything "slow to a crawl," since unused objects consume no cache and take no processor cycles.
Graphics in Java are abysmally slow.
This is an exaggeration. It is noticeably less responsive however.
Java was supposed to be: Write once, run anywhere, but what it is in reality is: Write once, debug everywhere... over and over and over.
Java requires far fewer debug cycles than C or C++, since an entire class of bugs (tricky "pointer bugs") is eliminated. Thus, "over and over and over" is not accurate.
I've worked in a variety of Java development projects in the past and not once has it ever risen to the task to show itself as a worthy choice and/or a mature language. Instead it has invariably wasted companies time and money.
It's possible the difficulty was with you or your team, not Java. Perhaps you're unfamiliar with the tools or the language. Other organizations have produced enormous projects, successfully, in Java.
Stick with C and C++ for most development, there's a reason they are the standard: they work.
For backend development and enterprise applications, Java is the standard, not C or C++. It's been that way for some time. There's a reason for it.
There's no performance overhead for a VM
on
Does C# Measure Up?
·
· Score: 2, Interesting
I've done significant work in benchmarking Java programs versus equivalent C/C++ programs. I've found that garbage collection is the sole reason that Java is slower than C++; having a "virtual machine" imposes no performance penalty whatsoever. This is unsurprising, when you think about it; a JIT compiler simply moves the latter phases of compilation ("byte code->assembly") to runtime.
Contary to what many people think, even most traditional C compilers work by compiling source to byte code, optimizing the byte code, then compiling byte code to assembly. There's no reason to expect that the resultant assembly will be any slower just because the final phase is done at run time by a JIT.
Programs compiled using IBM's Java compiler routinely outperform equivalent programs compiled using "gcc -02", if garbage collection is not used in the Java program being compiled.
What will this do to OS and database design?!
on
MRAM in 2004?
·
· Score: 1
Right now, operating systems and databases are designed around a particular storage model. Storage is divided into several levels. At the lowest level is large, extremely slow, non-volatile disk for permanent storage. Above that is RAM, used for running programs and caching oft-used data from the slower disks. Above that is cache, used for caching oft-used data in slower RAM.
But now, we'll have MRAM, which is non-volatile like disks, but faster than cache. And with memory densities growing according to Moore's law, soon we'll have MRAM memories as large as disks traditionally were, allowing large non-volatile "disks" that are faster than cache SRAM.
This completely reverses many of the assumptions made in designing OSes and databases. Will there even be a separation between disk and RAM any more? What is the point in having separate MRAM disks and MRAM memory? If an MRAM disk is faster than cache, then why have caches at all? Why have "paging" operating systems, why have OSes that cache disk data, why have complicated algorithms to reduce disk access? Why have buffers, if writing to a non-volatile file is faster than writing to a buffer?
Having a single, large, cacheless MRAM bank would seem to be the most appropriate scheme, with perhaps a disk used (with a swapping scheme) if the MRAM bank isn't large enough. A filesystem would still be required, but it would be in RAM. (Filesystem design would be very different).
The appearance of large MRAM disks will cause many things to be reconsidered.
Would revolutionize databases & OLTP
on
MRAM in 2004?
·
· Score: 1
Right now a database transaction must be written to disk before it commits. This is because a database must be durable, meaning it retains all committed transactions after an OS crash or power failure. Since disks are terribly slow, and since transactions must be written to disk, disk speed is the limiting factor in database performance.
Large databases get around this bottleneck by having thousands of disks writing in parallel. This increases the speed, since thousands of disk heads writing in parallel are thousands of times faster than a single disk writing alone. The multiple disks are used for speed only; most of the space is unused.
Thus, large OLTP databases require enormous disk arrays, with a huge number of disks writing in parallel, to make the performance of disk adequate. These huge disk arrays can cost millions of dollars.
MRAM is non-volatile. And MRAM is so vastly faster than disk, that a single MRAM drive could sustain a write bandwidth greater than 10,000 SCSI disks in parallel. Therefore, 2-3 MRAM drives could replace the huge multi-million dollar drive arrays and offer better performance. This would allow extremely busy OLTP databases to use a small number of commodity parts, rather than using huge million-dollar disk arrays.
Extremely fast databases would become a commodity item, rather than something costing millions of dollars. Since the new HP 4-way Itanium2 server offers >100,000 tpm/c (greater than the old 64-way E10000!), a single 4-way i2 box with a few MRAM drives could probably power the database for Ebay.
agnostic. A person who holds the view that any ultimate reality (as God) is unknown and prob. unknowable
"Agnostic" does not mean indifferent, lonesome, or disaffected! It does not refer to a program that can run on more than one kind of computer ("platform agnostic")!
I understand that language changes all the time. But this change waters down the word "agnostic" to such an extent, that it goes from being a precise and useful word to a vague and practically meaningless one. The new use is NOT EVEN ANALAGOUS to the original use of the term!
Fuck, this guy is a writer for the LA Times; you'd think he'd own a dictionary.
By definition, this isn't a flawed business model. SCO is making incredible amounts of cash. It's unethical, but since when did big businessmen care about ethics when they have a money printing press like this?
SCO isn't making any cash. SCO doesn't get any cash until they sell products, win a lawsuit, or coerce people to buy licenses, none of which have happened yet. They have experienced a temporary rise in stock price but SCO doesn't get any money from it, although their investors will get some. If SCO loses these lawsuits then it could be the quick end of SCO, since they have only $10m in cash and could easily spend that on legal bills fighting IBM.
Right now they're charging $699 per processor for a license, but that rate is going to double (to $1399) after October 15. The implication is: you'd better get your license soon!
Bear in mind that the specific evidence of infractions may not even be released until after October 15 (this lawsuit could take more than a year). In short, they're saying: "Pay us $699 based on accusation alone. If you wait until you can see the evidence, the price will double. So buy now!"
The balls! I can't even believe it. Even your typical scummy lawyer would probably be shocked. I don't care what other people think, Sco is cool.
Now I want to be a lawyer. I had no idea you could even legally demand money while withholding any evidence of wrongdoing. Think of the implications for personal injury law! "My client was injured by you; we won't say how; pay before you see the evidence or we'll sue you for twice as much." A fortune could be made suing people for anything.
Slashdot Mirror
The tremendous question, which remains unanswered by Stallman, is: How will free software generate the revenues necessary to pay programmers? Because it's very difficult to charge money for something people could easily acquire for free.
This question seems to be "brushed aside" by Stallman every time he talks about these issues. He mentions something to the effect of "you can charge for distribution." But right now CheapBytes sells CDs for $0.89 and that's not enough to pay any programmers.
Thus far, free software has been funded by two main factors. First, corporate largesse, where some large corporation (like AOL, IBM, or Sun) deems it worthwhile to fund some project (like Mozilla, the Linux kernel, or OpenOffice). Second, developers donating their time, which is usually done out of interest (as a hobby) or to gain a kind of credential ("I'm one of the authors of Apache").
These two sources of funding have worked very well thus far, but they're both quite limited. Because the funding for free software is limited, the amount of free software is limited as well. The vast majority of the software in the world remains proprietary, and will remain proprietary, until free software has a means of generating revenue to pay more programmers than it does at present.
It seems to me that Stallman should advocate government subsidies for free software development. The money could be distributed as grants to groups of developers who previously have demonstrated (and continue to demonstrate) productivity in releasing software that a great many people use.
It would only require a few billion dollars a year to produce an enormous amount of free software. This tax wouldn't have to be shouldered by the U.S. alone; it could be paid for by a large number of countries, including European countries, Japan, etc. The total bill per citizen could very well end up being less than $1/year.
This would solve the funding issue for free software. Adequate desktop free software could rapidly be produced.
This suggestion is entirely in line with what the government does already. This is because governments fund much or most of the research that is already carried out, and software is actually a kind of research, not production. Take the NIH as an example (the National Institutes of Health). That publically funded entity produces the majority of the research done on disease; and the entire U.S. pharmaceutical industry is dependent on its findings.
Public funding for free software could very easily save the economy money, in the long run. Look at how much money we pay to the Microsoft monopoly...
The web is not about "multimedia." The term "multimedia" was coined long before the web; and the web was not based at all on some idea of multimedia. The web isn't multimedia unless you mean "it has pictures and sound" in which case 1930s films are multimedia.
Well the rs232 spec doesn't mention anything about using 25 pins. 9 pin connectors are also very common as well as using POTS telephone cabling (very popular back in the day to wire terminals).
The rs232 spec requires 25 pins. The 9-pin connectors were rs422.
POTS was the kind of CABLE used, not the kind of port. When an RS-232 was connected to POTS, 19 of the 25 pins weren't connected to anything.
Cobol was not on the list; I said "english-like languages that promised to make programming as easy as speaking." Nobody makes english-like programming languages any more; the idea is universally agreed to be silly.
Apple II was not the list; the list included the Apple IIgs which was an incredible flop.
8" floppies had a very brief tenure because as a "compact" form of 10" floppies they weren't much of an advance, but were incompatible with older drives.
Apple IIgs
Apple Newton
Apple Lisa
Next Cube
Be BeBox
CASE tools
"Object Databases" as a replacement to RDBMSes
VRML
Gopher
"English-like" programming langauges that will make programming as easy as speaking (COBOL)
"War room" programming
"Multimedia"
Graphics cards that allow you to watch television on your monitor, by plugging a coax cable into the card.
8" floppies
Interactive television
Integrating the PC with the TV
RS-232 serial port (25 pins, of which 4 are used)
WORM drives for PCs
QuarterDesk
Audio Cassettes for data storage
Commodore 16
Windows 1.0
PL/I
MSX
Dec Alpha "21164-PC" personal computer processor
"MPC-compliant PCs"
GeoWorks
Project Monterey (IBM, SCO, & some others)
Micro Channel (bus arch from IBM)
Most of these ideas failed because they were outlandishly stupid. The only reason they got any press in the first place was because the companies promoting them were good at hyping ("it's revolutionary!"), and some people just get caught up in the emotional hysteria.
A few of the ideas (Apple Newton, Apple Lisa) were excellent ideas that just were introduced too early.
You were told that by whom? When?
You've got to be kidding. George Bush, C Rice, D Rumsfeld, and Colin Powell all repeatedly said that the reason for going to war was to find WMDs and stop Al Queda. Colin Powell even gave a speech to the UN Sec Council (trying to convince them to vote for war) which showed satellite photos of supposed WMD sites in Iraq; after that he listed the Al Queda operatives supposedly in Baghdad. When Bush was asked why the war had to be conducted right then, he responded that if we waited the result could be a mushroom cloud over a major Amercian city.
You were never mislead. You are an idiot, however, which leads you to the conclusion that because you didn't understand, you must have been lied to.
Were you paying attention at all? Are you honestly that obtuse? Or are you just capable of "re-writing" the history in your own mind to fit your political convictions? It's ironic that you accuse someone else of being an idiot.
Clearly what's necessary is to have a small keypad on the card itself, as well as a small CPU, a private key that is encrypted by the user's PIN, and the public key of the bank. That way, all communication between the card and the bank can be encrypted, and no unencrypted information is ever sent through the ATM.
Such a card would not be much larger than current ATM cards.
The worst fraud that could then be perpetrated is to have a fake ATM that deducts $20 from your account but without dispensing the $20. But that scheme would be very quickly identified.
Tests have been done of the peak bandwidth of X (pixels/sec), and in this regard only, X performs well. But X's latency is TERRIBLE and it takes WAY too long to do things like open windows, resize windows, move windows around, etc. And don't say "they've done tests." Everyone who uses X can tell that it's extremely slow. Right now, Java 1.4.2 Swing GUIs under Windows are far zippier and more responsive than natively compiled GUIs under X, on similar hardware. Moving & resizing windows is instantaneous under Win2k on a 300MHz box; with X it's nowhere near instantaneous on a 2GHz box. That's the biggest problem with X.
Apparently X is slow because it requires a context switch to kernel space every time you move a window one pixel to the left. Additionally, X is unbuffered, so every window beneath that window must redraw itself even if its contents are unchanged. Additionally, X is a protocol and so requires marshalling and unmarshalling with every action performed.
Kill off your own platform! Don't kill your competitor's platform. No. Kill your own platform.
SGI: "Commercial Unix and RISC are dead anyway. Let's just make Windows PCs. No, wait, linux boxen."
DEC: "Vax/vms. No, Mips/Ultrix. No, Alpha/OSF."
HP (with their Unix boxen, which used to have more marketshare than sun BY FAR until they hinted they'd drop PA/RISC, and perhaps even HP/UX eventually).
...Even if your platform is doomed, it will take decades for it to finally die, if you keep developing and updating it. IBM still makes huge money off S/390 and AS/400 (both of which were 'dead' around 1985).
Container-managed persistence may have some value, but it's an ancillary feature of EJB and is included as an "add-in." There are lots of libraries and tools to handle Object/Relational mapping, and the other ones work as well but do not involve the complexity and overhead of EJB.
Not to mention, it appears that container-managed persistence usually just maps each instance variable to a single column in a relational table, with each object being a row. Thus, the code rendered unnecessary by container-manager persistence was actually quite trivial, and the persistence mechanism handles the simplest cases only. The more complicated cases must use bean-managed persistence, which requires as much custom programming as avoiding EJB altogether.
I'm sincerely quite curious to learn what is the actual benefit of EJB. It's possible, of course, that there is some benefit of which I'm unaware. All of the claimed benefits, like scalability and simplicity, seem to be falsely claimed. If there is some situation in which EJBs are genuinely called for, then I'd be grateful if you'd tell me what it is.
Thanks...
My post was about EJBs not Java in general. Thus I presume you mean the "anti-EJB propaganda sheet." You probably are the only person who's seen such a propaganda sheet, because all I hear is mindless adulation of the technology, mostly from managers.
It's seven files, if you count XML descriptors and perhaps a DTO.
No, once again, it's up to seven classes, including but not limited to (from memory): Remote Interface, Remote Home Interface, Local Interface, Local Home Interface, Bean Class, and Primary Key class. If you count files it's even more.
"And where a simple constructor would previously have served, EJB requires a long JNDI call." What, can't cache the Home interface? Have you ever written an EJB in your life?
Caching an object doesn't avoid having to construct it. Caching in this case is a way of avoiding EJB mechanisms for constructing an object and (unnecessarily) transporting it over a network. I certainly agree that avoiding the EJB mechanisms is desirable, but this is not a vindication of EJB technology.
Unfortunately I have written EJBs in my life.
I've seen .NET code bring an 8-way box to it's knees. That code would execute faster on my digital watch! Uh-huh.
You apparently think I'm making up the incredibly poor performance of EJBs, even though it's a very well-understood fact within the industry. Once again, running the "shopping cart" demo on a 1GHz 512MB box requires approximately 20-30 seconds to generate each page, and doing so causes enormous amounts of disk thrashing. Generating a single page of text (html) from a database would be blindingly fast when done without EJB. Quite unfortunately, I'm neither making this up nor exaggerating.
The very worst fashion has to be EJBs.
EJBs complicate development. Where a single class would previously have worked just fine, EJB requires up to seven (!) classes to define things like the Remote Interface, Remote Home Interface, etc. And where a simple constructor would previously have served, EJB requires a long JNDI call. Not to mention, there are zillions of arbitrary coding restrictions that must be memorized and followed for EJB to work properly.
Furthermore, EJBs drastically impair performance. The "shopping cart" demo that comes with a major commercial app server brings my 1GHz 512M machine to its knees. Such a program could otherwise execute quickly on a 286 8MHz, a machine less than 1/1000th as powerful as the one running the EJB. I regularly encounter shops that have huge farms of commodity boxes to run very trivial EJBs that would otherwise execute on a single box just fine.
And EJBs do not scale any better than 2-tiered systems. 2-tiered systems allow you to horizontally scale the business logic by adding commodity machines to the second tier. Adding another tier does not help this at all.
...For this crippling blow to development, you get to pay Bea $40k/developer. Snake oil! Very expensive snake oil!
Software development resembles a foot race between you and your competitors, and using EJB resembles paying a surgeon exorbitant sums to cut off your left leg before the race. It costs craploads of money, it cripples progress, and it hurts!
No, the failure is not handled. If the write fails in the middle of command serialization, then "junk data" is written to the end of the log. I have tried this by running Prevayler and simulating a failure during command serialization, and "junk data" is created. Prevayler never recovers this "junk data"; it remains in the log forever. Whether deserialization works correctly at that point is dependent on how the VM implements deserialization, but the correct behavior is not guaranteed (see the serialization spec from sun). Deserialization could just as easily throw an exception which Prevayler does not catch. If an Exception is thrown, then Prevayler's logs are corrupted and Prevayler becomes unable to start again.
Thus, Prevayler is not a durable data store. I have verified that Prevayler doesn't clean up this "junk data" and that this leads to a serialization stream which is not guaranteed to work.
There are other serious bugs in Prevayler as well. The most important is: prevayler never recovers or reuses any of its logs. After a snapshot, the prior logs are never used again and are unreachable. But they are simply forgotten by Prevayler, and are never "cleaned up." Thus, prevayler "leaks" disk space over time. The demo they provide leaks about 100 kilobytes a second, even after snapshots. This is not the same as using more disk space with new data. If you have "create" and "delete" commands and continually create and then delete the same object over and over again, then take a snapshot, the database will be empty, and the snapshot file will be very small, but there will be gigabytes of "garbage logs" that Prevayler has forgotten about but which are left lying around on your disk.
Prevayler also leaks temporary snapshot files if a snapshot creation is interrupted, but this is rare enough that it's not critical.
I've now found 3 bugs. I should get 3 prizes.
A number of startups that I've dealt with are wrongly convinced of the great importance of what they're doing. They sincerely believe that IBM and Microsoft are spying on them and tracking their movements, desperately trying to learn their secrets.
To most of them, I would say: you have only a few lines of crappy code and a silly idea. Microsoft and IBM don't care about you, and neither does anybody else. When you have some innovative complicated algorithm, or a large code base that's difficult to duplicate, only then should you worry about protecting your IP, not before. Having IP worth protecting is the difficult part; keeping secrets is comparatively easy.
Oracle & DB2 have logic to deal with the case of transactions that were half-written before system failure. Thus, Oracle & DB2 can recover no matter when the lights go out. Prevayler contains no logic to recover if a corrupted object is written to the stream because of a failure during the write. From the java.io javadoc: "All exceptions are fatal to the InputStream and leave it in an indeterminate state; it is up to the caller to ignore or recover the stream state." Prevayler has no capacity to do this. Java.io does not guarantee transaction semantics and neither does Prevayler that runs on top of it.
You're mistaken about this. If the system fails during a transaction that requires more than one page write to disk, the result could be an incomplete or corrupted command being written to the log. Java.io.ObjectInputStream does not guarantee transaction semantics, and neither does Prevayler running on top of it. From the java.io javadoc : "All exceptions are fatal to the InputStream and leave it in an indeterminate state; it is up to the caller to ignore or recover the stream state. ". Prevayler never recovers the stream state. Prevayler contains no logic to handle this case.
The code above you show is no "the transaction". The coe above is BEFORE the transaction, writing the "before image".
The code I show is of a command being written to the log. There is no logic to handle the case of failure during the writing of commands that are more than a single page in length. Thus, an incomplete transaction can be written to the log, and prevayler has no way of recovering in that case.
The execution of the command is the transaction, not writing the command to disk, like you think.
A transaction is always what is written to disk, otherwise you don't have a durable data store, and the 'D' component of "ACID" is not fulfilled. If there is any possibility that what you have on disk is inconsistent, and cannot be recovered, then you do not have a durable data store. Prevayler has a case where what is written to disk is inconsistent and cannot be recovered, because it has no logic to handle the case of failures in the middle of writing a multi-page command. Therefore, prevayler is not a durable data store, as was claimed.
P.S., no did find nothing, so you gain nothing.
I did find a bug, a serious one, and I deserve a prize!
Prevayler doesn't appear to have any logic to handle this case. Java.io.ObjectInputStream doesn't have logic to handle this case either. Therefore, what would likely occur is: a failure of the application.
The somewhat naive authors of prevayler confidently announce the following on their website:
"No one has yet found a bug in Prevayler in a Production release. Who will be the first? [bold in original text]."
I already found a serious bug in the current production release. From the prevayler source:
ObjectOutputStream oos = logStream();
try {
oos.writeObject(command);
oos.reset();
oos.flush();
} catch (IOException iox) {
ObjectOutputStream does not guarantee atomicity. If your command object is larger than the page size of your disk, the "transaction" will take at least two page writes. A software failure between those page writes will lead to "half a transaction" being committed and a subsequent corruption of data. Once data integrity is lost, it is often difficult or impossible to recover. Prevayler has nothing to handle this case. Thus, prevayler does not correctly implement ACID, because it doesn't guarantee atomicity (half a transaction can be committed), consistency (referential integrity would be destroyed in such a case), isolation (this failure wouldn't be isolated to a single transaction) or durability (the problem would only show up upon reloading).
Finding this bug took very little searching. I am apparently the first person ever to find a bug in prevayler. Do I get a prize?
The "Prevayler Team" has written a persistent HashMap with a redo log, using the command pattern. This is exceptionally trivial and is in no way comparable to a database. A database has things like: 4GL query language, referential integrity constraints, data integrity, queryable metadata, separation of logical and physical layers, data independence, declarative rather than imperative querying, dynamically assembled queries, and gazillions of other things. These are the real features that we mean when we say "database." These features are absolutely necessary. Prevayler includes none of them. It is an extremely trivial persistent HashMap, that's all.
Thus, when the prevayler team says "throw away your database," I must assume one of two things. 1) They're trolling for publicity by saying outrageous and purposefully stupid things. Or 2) They are shockingly, mind-numbingly naive, and they don't know what a database is or what it does.
The author of Prevayler wrote this about himself: "Carlos Eduardo Villela is a 19-year old Brazilian graduate in Information Systems... almost 8 years experience has made him a Java and Python enthusiast."
Thus, I have to assume that the authors are mind-numbingly naive. Don't get me wrong, I'm sure the authors are very bright, and I know that some good insights that went into the implementation of prevayler. But let's not throw away our databases quite yet.
I disagree.
Garbage collection in Java is not guranteed... It'll clean up when it god damn well feels like it.
This is false. Garbage collection in Java is guaranteed. The VM times the garbage collection to occur when the CPU was otherwise idle, or when additional memory is needed by the VM or by other programs. This is the most reasonable behavior.
In the meantime, the system slows to a crawl.
This is false. Garbage collection is deferred to improve performance. Deferring gc does not make anything "slow to a crawl," since unused objects consume no cache and take no processor cycles.
Graphics in Java are abysmally slow.
This is an exaggeration. It is noticeably less responsive however.
Java was supposed to be: Write once, run anywhere, but what it is in reality is: Write once, debug everywhere... over and over and over.
Java requires far fewer debug cycles than C or C++, since an entire class of bugs (tricky "pointer bugs") is eliminated. Thus, "over and over and over" is not accurate.
I've worked in a variety of Java development projects in the past and not once has it ever risen to the task to show itself as a worthy choice and/or a mature language. Instead it has invariably wasted companies time and money.
It's possible the difficulty was with you or your team, not Java. Perhaps you're unfamiliar with the tools or the language. Other organizations have produced enormous projects, successfully, in Java.
Stick with C and C++ for most development, there's a reason they are the standard: they work.
For backend development and enterprise applications, Java is the standard, not C or C++. It's been that way for some time. There's a reason for it.
I've done significant work in benchmarking Java programs versus equivalent C/C++ programs. I've found that garbage collection is the sole reason that Java is slower than C++; having a "virtual machine" imposes no performance penalty whatsoever. This is unsurprising, when you think about it; a JIT compiler simply moves the latter phases of compilation ("byte code->assembly") to runtime.
Contary to what many people think, even most traditional C compilers work by compiling source to byte code, optimizing the byte code, then compiling byte code to assembly. There's no reason to expect that the resultant assembly will be any slower just because the final phase is done at run time by a JIT.
Programs compiled using IBM's Java compiler routinely outperform equivalent programs compiled using "gcc -02", if garbage collection is not used in the Java program being compiled.
Right now, operating systems and databases are designed around a particular storage model. Storage is divided into several levels. At the lowest level is large, extremely slow, non-volatile disk for permanent storage. Above that is RAM, used for running programs and caching oft-used data from the slower disks. Above that is cache, used for caching oft-used data in slower RAM.
But now, we'll have MRAM, which is non-volatile like disks, but faster than cache. And with memory densities growing according to Moore's law, soon we'll have MRAM memories as large as disks traditionally were, allowing large non-volatile "disks" that are faster than cache SRAM.
This completely reverses many of the assumptions made in designing OSes and databases. Will there even be a separation between disk and RAM any more? What is the point in having separate MRAM disks and MRAM memory? If an MRAM disk is faster than cache, then why have caches at all? Why have "paging" operating systems, why have OSes that cache disk data, why have complicated algorithms to reduce disk access? Why have buffers, if writing to a non-volatile file is faster than writing to a buffer?
Having a single, large, cacheless MRAM bank would seem to be the most appropriate scheme, with perhaps a disk used (with a swapping scheme) if the MRAM bank isn't large enough. A filesystem would still be required, but it would be in RAM. (Filesystem design would be very different).
The appearance of large MRAM disks will cause many things to be reconsidered.
Right now a database transaction must be written to disk before it commits. This is because a database must be durable, meaning it retains all committed transactions after an OS crash or power failure. Since disks are terribly slow, and since transactions must be written to disk, disk speed is the limiting factor in database performance.
Large databases get around this bottleneck by having thousands of disks writing in parallel. This increases the speed, since thousands of disk heads writing in parallel are thousands of times faster than a single disk writing alone. The multiple disks are used for speed only; most of the space is unused.
Thus, large OLTP databases require enormous disk arrays, with a huge number of disks writing in parallel, to make the performance of disk adequate. These huge disk arrays can cost millions of dollars.
MRAM is non-volatile. And MRAM is so vastly faster than disk, that a single MRAM drive could sustain a write bandwidth greater than 10,000 SCSI disks in parallel. Therefore, 2-3 MRAM drives could replace the huge multi-million dollar drive arrays and offer better performance. This would allow extremely busy OLTP databases to use a small number of commodity parts, rather than using huge million-dollar disk arrays.
Extremely fast databases would become a commodity item, rather than something costing millions of dollars. Since the new HP 4-way Itanium2 server offers >100,000 tpm/c (greater than the old 64-way E10000!), a single 4-way i2 box with a few MRAM drives could probably power the database for Ebay.
"Agnostic" does not mean indifferent, lonesome, or disaffected! It does not refer to a program that can run on more than one kind of computer ("platform agnostic")!
I understand that language changes all the time. But this change waters down the word "agnostic" to such an extent, that it goes from being a precise and useful word to a vague and practically meaningless one. The new use is NOT EVEN ANALAGOUS to the original use of the term!
Fuck, this guy is a writer for the LA Times; you'd think he'd own a dictionary.
Sorry, I needed to rant about this.
SCO isn't making any cash. SCO doesn't get any cash until they sell products, win a lawsuit, or coerce people to buy licenses, none of which have happened yet. They have experienced a temporary rise in stock price but SCO doesn't get any money from it, although their investors will get some. If SCO loses these lawsuits then it could be the quick end of SCO, since they have only $10m in cash and could easily spend that on legal bills fighting IBM.
Right now they're charging $699 per processor for a license, but that rate is going to double (to $1399) after October 15. The implication is: you'd better get your license soon!
Bear in mind that the specific evidence of infractions may not even be released until after October 15 (this lawsuit could take more than a year). In short, they're saying: "Pay us $699 based on accusation alone. If you wait until you can see the evidence, the price will double. So buy now!"
The balls! I can't even believe it. Even your typical scummy lawyer would probably be shocked. I don't care what other people think, Sco is cool.
Now I want to be a lawyer. I had no idea you could even legally demand money while withholding any evidence of wrongdoing. Think of the implications for personal injury law! "My client was injured by you; we won't say how; pay before you see the evidence or we'll sue you for twice as much." A fortune could be made suing people for anything.