The big problem with JNI interfaces is that you have to build new binary code specifically to interface between Java and the native library. On top of that you have to deal with version incompatibility issues (what if the library you are talking to is a growing and changing thing), delivery issues (where do I put these JNI interfaces), configuration issues (how do I make sure that the Java picks up the appropriate JNI interfaces), and debugging issues (when the thing crashes -- I have one more place to look). The cool thing about C# is that you can call native methods in a dynamically loadable native module directly from C# (in a manner reminiscent of Visual Basic calling methods in DLLs). It makes the language a lot less safe in some respects, but it is sure convenient if you are already committed to being partially native.
C# does not force you to use a level of abstraction away from the native C-style structures and function calls (at least in the Microsoft implementation).
There is seems to be a belief that C# plus.NET is equivalent to Java and J2EE. Although there are a lot of similarities, one of the big differences that sticks out is that C# encourages you to use native APIs on a particular operating system. The concept of "pure C#" is not as meaningful an idea as it is for Java. Although you might be able to write a solution at an abstraction layer that allows portability using C# and.NET, the language and environment encourages you to write applications that target a specific platform. For example,.NET has a lot of things in it to manage interfaces to natively implemented third part libraries.
The reason why I would prefer C# and.NET on Linux is that I can write a C++ style application using native Linux calls with far less hassle than with Java. For example, I can use native X-window concepts and calls instead of going through some ridiculously slow "swing" abstraction with horrible dialog popup focus handling problems. If I have a native implementation of some encrytion standard, communication standard, or file system locking standard, they are much easier to access through C#. For me, C# is the perfect language if you already were thinking of writing a native application for a specific environment but you wanted some of the many advantages of "hot-optimized-compiled/linked-scripting" language.
There are two types of ways that you usually access files.
1. I know precisely where one more more files are located and I want to see their contents as fast as possible. I want to move around 100s of such files easily from directory to directory at the potentially optimal speed of the disk subsystem. I might also want to do batch edits or renames of these files. Speed is the only truly important characteristic.
2. I vaguely have an idea of what type of file I am looking for. I want to find one or more files satisfying a particular metadata (or full text) criteria and manipulate one or more such files. I want all versions of my files to be maintained and there to be full auditing of interactions with these files.
Many times 1. and 2. are mutually incompatible. The typical way these days to address having both is to have an automatic spider that maintains an indexed view of the files and the file's metadata and hope that the spider is not too far behind the actual changes being made to the contents of the files or the locations of the files. If you want to have a transactionally guaranteed implementation of 2., then you have pretty much eliminated batch manipulation of files as a reasonably performing option. Database tracked file systems do not do well when you unzip a large collection of files and then start batch copying those files to different locations.
Now, I know almost nothing about the current implementation of the new "database" file system being discussed. But, I would very much want to allow a user to designate which directories or file types would be put into relational tables and which ones would not. I might also want to be able to choose whether the relational tables were interacted with using a transactional guarantee or whether a "spider" was used. If the end user had control over when the "heavier" management of the files occurred and how much of it should be applied, then it might have utility. Part of the user's file system would then be a document management library and other parts would be a normal file system. However, I would find creating a user interface that tried to make such a solution comprehensible to an end user somewhat of a nightmare.
Some say we should get rid of software patents. Personally, I am not sure that the issues with patents only apply to software. There is a large grey area where somebody has to decide "how obvious" or "how directly relevant" is the prior art before a judge or jury decides that the patent is legally enforceable. Currently, our courts are too likely to allow truly obvious ideas to be successfully enforceable as a patent.
To my mind, a good patent has one of the following two characteristics.
1. It requires much study to even comprehend the patent and a peer review of experts in the field say that it is a SIGNIFICANT advance.
2. The patent opens so much new ground in ideas that even though the ideas are somewhat obvious, the unique combination is so explosively new that there is clearly no prior art that could possibly be referenced to invalidate the patent.
By the way, I do not think that HTML at any point was a patentable idea. There have been many markup languages and even some that were used in an internet setting before HTML came along. HTML was successful not just because it was a clear and easy simplification of SGML, but because there was a good and "free" implementation (the Mosaic browser) of it readily available. Also, if you look at the RFCs for HTTP it is clear that HTTP rested very strongly on the notions already known in other internet protocols (email, ftp, etc.). HTTP and HTML are clearly evolutionay ideas (if you examine the context in which they were created), and it was how they were used that was revolutionary.
"And has been doing. Forbes points out that SCO has pulled this same shit with Microsoft -- and won. In this case they bought the rights to an old, 'decrepit' version of DOS and proceeded to sue the shit out of Redmond. They are crafty bastards. And they basically leverage intellectual property law to fuck other people over."
To compare the DRDOS suit with the current SCO activity means that you have not been studying your history. The basis of the DRDOS (the "decrepit" version of DOS) lawsuit is as follows.
DRDOS was superior (by many peoples accounts) to DOS for a brief period in Microsoft's history. The Windows operating system (Windows 3.1 and earlier) ran on top of both versions of DOS. Microsoft deliberately put into their Windows code a test to see if it was running on top of DRDOS and then create a nasty looking crash. Microsoft then spread rumours through its vendors that DRDOS was unreliable. This killed the market for DRDOS.
There is clear and verifiable evidence of this and this is why Microsoft settled.
To compare the current SCO lawsuit to a lawsuit based on clear criminal behavior is to legitimize SCO's current lawsuit -- exactly why Forbes and other magazines give the current lawsuit credibility. The previous lawsuits were valid, why can't this one be as well? Absurd, unfortunate, but probably true.
Sometimes I am amazed by the ability of people to avoid seeing the obvious. If I told you that the only way to get to the top of a mountain was to climb it and that somebody had patented "climbing mountains" (let us assume for a moment that there was no "prior art" that you could reference), it would be obvious that the patent had no merit because the basic idea was too "easily realized from simple thought" or too clearly the "simple reapplication of already existing notions" (I can climb a hill, hmmm... maybe the same technique can be used on mountains). It may not be obvious to members of a jury, but to anybody who does any real programming, it is clear that a notion of a browser plugin is pretty equivalent in obviousness (in software terms) to the notion of "mountain climbing". All the details of how such plugins should work are almost mandated by the very concept of the idea.
If our court system allows trivial software notions to be patented, it is eventually going to cause serious harm to any attempts to create a viable long term open source software movement. Sometime in the not too distant future, software companies with money to lose our going to figure out that if they cannot win in the marketplace, the courts will provide the leverage that they need.
So for anybody who thinks that it is a good thing that Microsoft lost this case, they need to seriously take another look at this issue and realize that this case could be the start of a very bad trend. Just because my most hated enemy has to pay royalties to "climb mountains" does not make it right.
When a user configures and uses a browser they create an environment around that browser that is used to enrich the experience they get when they interact with web sites around the world. This environment includes (but is not limited to),
Cookies
Accepted Certificate Authorities (CA)
Current Authentication Credentials (Basic or NTLM login state)
Configuration for Proxys and Firewalls
Let us say that you want to create a rich and wonderful application hosted in this environment so it can use all this browser state information when talking to a web server.
Sun's Java plugin will not let you do this. It opens direct socket connections to a web server (bypassing the browser) and it impossible in an applet to determine any of the browser settings. You certainly cannot pick up cookies or ride on top of an NTLM login. Also, the certificate authorities for SSL may be completely different then the browser's settings.
Microsoft's VM inside the browser let you do all these things.
Where else am I going to get a solution that lets be write code that will run inside a tight sandbox, use the full browser environment for connecting to the web server, and let me do full OO style programming with all the extras (threads, container classes, support for interfaces, reflection, serialization of data, XML parsing, locales, etc.)? How do I get such an environment in a way where the user gets a seamless download experience once they install just one plugin?
I love how there are some fundamental assumptions made about an "acceptable" form for creating and delivering content. These assumptions control the type of "enterprise content management system" that content management experts think you should buy. Here are some "must have" features that make the problem of content management unacceptably hard.
I can't just email other people to see what they think of a document I created. The creation and approval process has to be enforced by a rigid workflow.
It has got to mimic file system style storage structures although it is precisely a file system's inability to multiply classify (example -- classify content by type, purpose, importance, geography and create views of the content oriented towards any one of these independent classification choices -- very difficult to do with file systems) content that contributed to a desire to acquire an expensive content management system in the first place.
Security must be on a document by document basis with contributors dictating precisely who can view or edit the document.
Relationships between documents must be actively managed. A broken link would be truly horrifying and unacceptable.
There is a horrible truth about content that creators of web sites cannot seem to grasp. The value of the site is the actual content, not in its presentation. A well written informative blog is far more useful than a "formulaic" pretty business web site. Not all content created by a company is destined as website "adware". Some of it may actually be intended to help employees do their jobs more efficiently. If that content is not fully polished so be it.
If I were looking for a content management system, I would look for one that does the basics. Version control, metadata classification, multi repository search, simple security classifications, archiving/retrieval, and some automated notification procedures. If you know who authored a content item, when it was authored, and the title the author chose to gave it, you already have a lot of useful information with which to do a search. It is the basics that give you the most ROI.
The demo I saw was of an open source port of C# to Linux. I do not think that there was a cheat. It is weird in a way that there is now an active open source development in progress for C# but not of Java.
However, C# does cheat in the sense that it does not use cross platform GUI libraries, it uses the native window APIs of whatever OS it is working on. In that respect, it has a fundamentally different mission than Java.
I must admit this was smaller than I suspected. I am basing my claims on the simple configuration dialogs that I have written that in spite of their simplicity can take a long time to start (2 seconds is way too long for a trivial app like this) and seem to take up an inordinate amount of memory.
Then somebody at a convention demoed a sophisticated user interface application on Linux using C# that used a tree control and tabbed dialogs. It came up immediately and took only a couple megabytes of memory.
It is also possible that Sun has improved this a bit in 1.4.1_02 using the client optimized launch. I have not checked the numbers recently.
So the fact that almost all real world Java applications (including Sun's) use shell scripts to launch their Java applications just so they can get around the limitations of the classpath is not sufficient proof of the problem.
Ten applications share a common library. You want to upgrade the library but the name of the jar file has changed or you do not want to move or delete the existing library. In the best possible scenario, you would like to suggest to these 10 applications where they should go for the latest and greatest version of library API, but allow them to fall back to an older version. It is a real pain to have to write complicated shell scripts or custom classloaders to do this and once I use shell scripts or a custom classloader, there will be no textbook out there to explain to others what crazy things I did.
An example would be some XML library APIs (Xerxes?) that have incompatibilities with some of the shipping Java SDK libraries depending on which version of the Java SDK you are using. It would be nice to have a parameter that could test for version before deciding which XML library you would load.
In the old days when people talked about Linux, there was an expression "What about the big pink elephant in the middle of room" and it was referencing the fact that Linux did not support truetype fonts and font aliasing. Now some of that has been fixed, but Java still has its big pink elephant. Here are some of the things that people don't talk about.
The memory foot print for loading Java is 20meg + and growing. I am part of a team that has been developing a complex Java application for the last few years and we have created about a 3meg library (and it probably does at least as much as the more popularily used Java classes). I have looked at some of the source code for the core Java libraries and it is clear that a good rewrite could reduce this footprint by a factor of 2 to 4. Currently, C# loads with a footprint of 2 meg to 4 meg. Most other scripting languages usually have engines that are about the same size. To put it simply, the base core Java libaries are unjustifiably large. Maybe if Java were truly open source this could be addressed, but of course Sun doesn't even believe in submitting Java to a standards board.
You cannot load the Java VM once and run multiple processes (note "processes", not "threads") from the same Java VM memory footprint. I hear that such a thing is becoming possible for C# on Linux. You would have to build all the core Java classes into a "DLL" or ("so" on Linux), but that shouldn't be so difficult.
You still cannot do basic OS operations in Java without writing your own JNI library. The one that stands out is the inability to get the ID for the current running process. The "nio" package has corrected some of these issues, but the "nio" package should be the "io" package instead of having two separate packages (similar to AWT vs. Swing).
Window focus handling is still terrible. Ever have two frame windows up, have a modal dialog pop up on one frame while you were looking at the other? The frame window without the popop modal dialog becomes unresponsive and the other frame cannot be reached by tabbing through the windows. Only if you are lucky and that window is still visible on your desktop can you successfully reach it. Also, if a user clicks on a button that generates a modal dialog, the frame is only locked out from user input once the dialog manifests. This creates the infamous "double" clicking problem.
Java's package management is still primitive. If you want to do anything more subtle then using the classpath to load in custom libraries, you have to write your own class loader. Having an auxillary file specifying parameterizable rules for class loading would be nice. It would also be nice if you could ask a running Java process what packages it had loaded (and metadata about them such as location and version). Compare this to C# (or the way some of the web server oriented scripting languages work).
Some of the basic core library functions have some major weaknesses. For example, the Hashtable should be written as a native object when using String lookup keys and also allow you to dictate the algorithm for creating hashes (ex: use first 8 characters, last 8, or middle 8). There should also be a non thread safe version as well as a thread safe version. The lack of such a natively implemented primitive object is one of the big reasons why some less cleverly implemented scripting languages (such as python) can beat Java in performance on many web applications. In general, the core collection classes should be implemented in pure optimized (down to the actual chosen assembly code) native code.
Many of the utility libraries are broken in fundamental ways. Send back a badly formed response to the HTTP library and you go into an infinite loop when it falls into its keep-alive/retry logic. Date parsing is still behind what is available in the C standard library. Locale specifications do not allow you to independently specify date formats, language, floating point format, currency format, and time zone. You get o
One of the common mistakes when futurists try to make guesses about the nature of society a few decades from now is that they presume that trends that have been true will continue to be true. There are many examples of this.
During the 50s and 60s, there was a steep up ramp in energy consumption. Because of this, there were many dire predictions in the 70s that we would soon run out of energy. But the steep curve leveled off and the "energy crisis" never happened.
From the late 1800s to the 1960s, our ability to go faster and farther was also on a steep upward curve. Futurists naturally extending this trend assumed that travel to the planets would become commonplace and that personal air transport would soon become a cheaply available transport solution.
From the early 1900s to the 1960s there was great increase in leisure time. Some futurists postulated a future existence where only a few people worked and most just goofed off.
From the 1800s to the 1960s there was a tremendous improvement in using machines to replace humans when it came to various tasks. Again, it was natural to extend this trend to the point that robots manufactured most of the goods consumed by society. Also, during this period there was a large growth in household convenience devices. Extending this trend, it was natural to assume that there would soon be robots that performed all your housework,
Sometimes it is more interesting to examine what was missed. For most of the modern age up to the 1970s, there was not a great improvement in the speed (and quantity) in which written communication was delivered. It still took at least a few days for mail to arrive and international mail still could be a matter of weeks. In order to disseminate information (such as research), large mass printings had to be created and distributed in a very manual way. TV improved the communication process somewhat, but for information with a more limited audience, the basic infrastructure and approach for delivery had not changed for quite some time. That is why "email" and "website" was not on the minds of most futurists.
Also during this period, the mechanisms by which numeric and financial calculations were performed did not change much. It was both expensive to do the calculations and expensive to disseminate the results (My childhood was still in the era where we had to consult large logarithm tables to assist in doing simple arithmetic - something they were doing back in the 1700s). Thus it was not a natural presumption that computers could manage all the details of various financial transactions. In particular, EBay and PayPal were not envisioned.
So my challenge to futurists is to look a little deeper and try to anticipate changes that are not already occurring and extrapolate those. But that is not happening. Every futurist these days seems to be obsessed with small-computerized gadgets linked in high-speed communication networks that allow users to access broadband entertainment. A completely natural but probably mistaken prediction based on current trends.
I have been wondering when the first truly "data driven" solution would be created for standard heavy client GUIs. HTML created a standardized approach to simple "Info" presentation (and submittal) GUIs. Even though the primary goal for HTML was quite limited, this idea of having a "data" driven solution to info presentation has been such a hit that it has generated huge and powerful scripting solutions all devoted to enhancing this one simple GUI idea. It seems obvious to me that almost all facets of an application should be data driven in a similar way, including all GUI presentation in heavy weight applications. In a truly modern application environment, all code that determines placement of GUI elements and the simple logic that binds them together should be done in an HTML style environment (or its cousin XML). This data driven approach should be so pervasive that much of the higher-level logic of an application should be in data and script.
I laud Mozilla for going down this road and it is clear to me that the core developers for Mozilla are a step above your standard programmer. Some accuse Mozilla for not following a method that would create "standards" for their XML GUI description language, but I have found that the successful "standards" usually follow already adopted and reasonably mature technologies. You do not know how you want to design something until you have done it, used it, and given it to other people to play with. Only after an application has grown sufficiently to include all the thousands of unexpected details is it sufficiently mature for people to talk about standards. For example, I consider the EJB specification's largest failing is that they tried to standardize it before it was actively used for a couple of years. Only now that we have some mature app servers do we really have an idea what needs to be in the core EJB specification. If EJB had followed this road, maybe application developers would not need to use vendor specific code for the critical parts of the functionality. Like OO, the mantra of "standards" seems to be more of a marketing tool to get Fortune 500 companies to cough up millions of dollars than something that really influences how sophisticated and successful applications get developed.
I have my own questions for the Mozilla team. How do you deploy "overrides" of existing configurations. Suppose I want to deploy a "batch" of changes that I want to turn on or off. Is there a way to create configuration "layerings" in XML files so a group of data specifications can be conditionally included from a set of external files? How much scripting is allowed in these files? If I want to write conditional code for specifying a color (such as a color choice per day of the week), is there a way to write scripting solutions for that need? Of course, I could read the book but I am lazy and I suspect that it would not give a full answer.
I am responding because it is rare for me to see somebody endorse a position I hold dear. Although it is probably a bit off-topic since the general issue is a review of a EJB enterprise book, but it does seem crazy that certain OO solutions can be advocated with a straight face. There seems to be an almost instinctive negative reaction by most programmers to the idea that data might be retrieved by lookup keys instead of using an explicit attribute. This is in spite of the fact that mapping all data into explicit attributes creates all sorts of nightmarish headaches in many applications (persistent serialization to name just one complication).
Few people are willing to question this OO dogma. Somehow they cannot believe that a data value will be given its full "semantic" meaning unless it is explicitly defined as an attribute in a particular object. If the compiler does not enforce the declaration of "type", they just don't think it is a proper data value. Although a compiler may prevent you from accidentally violating certain proper usages of that attribute, that small utility of preventing "typo" style errors is hardly worth the cost of the infrastructure that approach generates. When I examine field information using the JDBC api, I can discover all relevant type information without actually having an attribute declared to be that type. It seems silly to not use that information directly instead of having to load the information into an explicit attribute.
In the world of RFCs and the Internet, almost all parameters in a protocol are specified using some type of name-value approach (HTTP headers is the classic example). No implementation of these RFCs (such as web servers for HTTP) explicitly binds all of these parameters in their code. There is a soup of data out there, you grab the data items you need into temporary attributes (using human written code), but let the rest slide along with your main data objects as you process a request. It is a winning formula that creates tight and flexible code. It is the type of code that drives Apache, PHP, perl, and all the stuff that is actually out there in real usage instead of a the demo ware data entry apps created for fortune 500 companies.
Nobody seems to be addressing some of the real painful spots in the current app server architectures. Jboss seems to do a better job of addressing these issues then other app servers, but I do not have the luxury of that choice.
First, how are you supposed to do development in an environment where it takes almost a minute to restart the application and find out if your latest change is working properly? That type of coding harks back to the dark ages of coding when you had to wait minutes before the compile and run was finished. There are kludges for creating "simulated" app server environments that give you faster development times, but that can only take you so far.
Secondly, it is practically impossible to create a distributable self-installing application that installs with no fuss into an app server environment. I am amazed that people are willing to put up with the configuration headaches for delivering app server solutions that they would never accept for their desktop applications.
Thirdly, there is a constant confusion surrounding issues like "session" and "non-session" beans, maintaining "transaction compliance", and whole hosts of finagle issues. Many of these issues have a drastic impact on performance depending on your choice, and usually the choices that give sufficient flexibility and acceptable performance are only available with completely proprietary vendor specific solutions.
As far as I can tell, the original vision of having easily developed, easily deployable, and high performing server-side application solutions has been lost and has been replaced by an environment in which it is difficult to create code, painful to deploy solutions, and a real headache to tune for speed.
This is such an unfortunate fate for EJBs. In the original vision, EJBs were to be the server side equivalent of Microsoft's ActiveX controls for the desktop. There are still some good ideas buried in the EJB specs, but the heavy weight app servers have buried these little nuggets inside massive overachieving bloat ware.
In the discussion on multi-threaded vs. single threaded and performance, there has been no discussion on caching issues. One of the big places caching is very effective is for user authentication. If you have to go to an enterprise user storage repository for every client request, you quickly find that your system's throughput is limited to the throughput of the user store. In most company environments the user store is already under serious stress from multiple other applications and web sites, so without some type of caching solution built into the web server, the performance for security is abysmal.
In an environment that spawns 100s of processes to handle requests, each process can end up creating a duplicate cache of the same user information. Since I do not know of way in Apache to have the same users visit the same process, it is difficult not to create 100s of copies of the same user cache. If the cache is dumped every couple of minutes for each user, it is very easy to create a scenario where a cache in a particular process is too old to be usable by the time a user visits the same process again. The general effect of this is that Apache 1.3 cannot be used for solutions that emphasize caching. This problem also manifests for scripting solutions where scripting pages are preloaded, parsed, and cached (does anybody know how mod perl handles this?).
Using memory shared across processes or writing data to temporary files could potentially solve such issues, but that can have its own headaches and costs. For example, there can be significant overhead in serializing information from/to an IO system (memory files or temp files on a file system) if there is more than a trivial amount of information being cached.
Part of the promise of Apache 2.0 is that it will create an environment for creating complicated and scalable applications for the enterprise. As far as I can tell, without a threading model solution, Apache would be considered not much more than a toy for real industrial applications. It is possible to create Apache 1.3 applications that serve many users and have much content, but the users usually have to be locally stored (in particular passwords are directly available) and the content has to be "prepackaged" for optimized delivery. This may work for focused web sites, but in the new universe of "web services" and pushing mainstream business apps onto the web, Apache 1.3 falls far short.
Every now and then I read broad sweeping claims about how we could fix our secondary education. Let us look at some of the reasons why it is so hard to educate our children properly.
I have a Ph.d. in mathematics. I work as a software developer and I have not even used simple algebra in over 5 years. That does not mean that my job is boring or lacks the need for reasoning skills, but it does imply that a lot of my education has less relevancy than many people would like to believe.
This is a general problem. It is very hard to pursuade students that their education has relevancy and to some extent the students are right. Our education establishment is focused on properly preparing students to be ready for the late 19th century. Many teachers in secondary education are teachers because they were not clever enough to get an education that made them relevant to the work needs of our current generation. It is very hard for such teachers to pursuade students that their education matters.
Many of the teachers who teach math never had the "ah ha" experience that is vital to true understanding. Such teachers are unlikely to generate any real understanding in their students. Since I taught myself mostly from books, I always thought this business of having teachers and classrooms as being overrated. The books did a much better job in explaining the material than the teacher.
Although I hate the type of teaching that standardized testing inspires, I also hate teaching that has no accountability. Given the choice between two evils, I tend to choose the standardized tests. Over the years there have been many attempts to bring "creativity" or "understanding" back into our classrooms. Except for a few model classrooms with very motivated and bright teachers, these "innovations" have usually been an excuse for teachers to create an even more muddled and useless experience for their students.
In particular the "new math", that was being taught when I was in middle school, is especially brain dead. Students would end up stripped of any mastery of the basics of math and were not sufficiently compensated with any "deeper" or "creative" insights into mathematics. When I got to college, I saw some of the point of teaching students about "sets", but only a really inspired and talented teacher could have communicated the deeper ideas in "new math" to a standard classroom of kids.
I see no easy fix to our secondary education problems. But with no way to hold our teachers accountable for the educations they provide, there is no way to know if a particular idea is actually helping or hurting.
Re:Forget bigger numbers, how about smaller words?
on
More on Riemann Hypothesis
·
· Score: 2, Insightful
Well -- having been in this business myself, I'll try to explain the relevancy of this problem. In Fourier analysis, the problem is usually to take a look at data, apply a transform and look at the underlying harmonics of the data (this works best on sound or light because the harmonics correspond to actual physical properties such as "pitch" or "frequency"). For example such techniques can be used to clean up images by removing the "noise" type frequencies in the data.
A similar technique can be applied to numeric entities such as prime numbers. Ideas such as this produce something called the Zeta function which can capture various statistical properties of prime numbers (statistical properties of the entire infinite series of prime numbers).
The "zeros" of the Zeta function (I'll avoid explaining what I mean by this) capture some of the statistical properties of primes in the way Fourier transforms explain light and sound. The Riemann hypothesis comes down in essense to claiming that prime numbers never behave too statistically perverse (the equivalent in Fourier transform data of saying that the harmonics are not too skewed -- the "sound" never "gangs" up on certain frequency areas).
Although the mathematics can seem a bit obscure to those outside the field, it is probably one of the more profound questions out there. As a comparison, Fermat's last theorem (when evaluated purely for its mathematical significance) is merely a curiousity and was proved as a minor consequence of proving more important theorems in elliptic curves, which themselves are only stepping stones towards another really large unproved mathematical question.
For the record, the question is: "Are all elliptic curves modular?" -- which is way more obscure than the Riemann Hypothesis and I consider to be the number one potentially solvable mathematical question that has ever been posed. It is a really cool problem.
If you are involved in a large complicated software project and you write 10000 lines of code then that code will have many conditionals, loops, and branches each of which involved a design or implementation decision. Bad programmers think that not much is involved in those choices, good programmers are still internally debating the choices years later.
The more I do software development, the more I believe that there is a general lack of awareness just how difficult it is to write a good useful sellable software program. Every few years there is some new methedology that is going to revolutionize software development (remember when you could find Object Oriented Programming Gurus at every software convention). None of them have a technique for naming a function so that two years later you do not regret the name because a.) it is not specific enough. b.) violates the thematic pattern of other function names. Or c.) no longer precisely describes the purpose of the function.
Slashdot Mirror
The big problem with JNI interfaces is that you have to build new binary code specifically to interface between Java and the native library. On top of that you have to deal with version incompatibility issues (what if the library you are talking to is a growing and changing thing), delivery issues (where do I put these JNI interfaces), configuration issues (how do I make sure that the Java picks up the appropriate JNI interfaces), and debugging issues (when the thing crashes -- I have one more place to look). The cool thing about C# is that you can call native methods in a dynamically loadable native module directly from C# (in a manner reminiscent of Visual Basic calling methods in DLLs). It makes the language a lot less safe in some respects, but it is sure convenient if you are already committed to being partially native. C# does not force you to use a level of abstraction away from the native C-style structures and function calls (at least in the Microsoft implementation).
The reason why I would prefer C# and .NET on Linux is that I can write a C++ style application using native Linux calls with far less hassle than with Java. For example, I can use native X-window concepts and calls instead of going through some ridiculously slow "swing" abstraction with horrible dialog popup focus handling problems. If I have a native implementation of some encrytion standard, communication standard, or file system locking standard, they are much easier to access through C#. For me, C# is the perfect language if you already were thinking of writing a native application for a specific environment but you wanted some of the many advantages of "hot-optimized-compiled/linked-scripting" language.
1. I know precisely where one more more files are located and I want to see their contents as fast as possible. I want to move around 100s of such files easily from directory to directory at the potentially optimal speed of the disk subsystem. I might also want to do batch edits or renames of these files. Speed is the only truly important characteristic.
2. I vaguely have an idea of what type of file I am looking for. I want to find one or more files satisfying a particular metadata (or full text) criteria and manipulate one or more such files. I want all versions of my files to be maintained and there to be full auditing of interactions with these files.
Many times 1. and 2. are mutually incompatible. The typical way these days to address having both is to have an automatic spider that maintains an indexed view of the files and the file's metadata and hope that the spider is not too far behind the actual changes being made to the contents of the files or the locations of the files. If you want to have a transactionally guaranteed implementation of 2., then you have pretty much eliminated batch manipulation of files as a reasonably performing option. Database tracked file systems do not do well when you unzip a large collection of files and then start batch copying those files to different locations.
Now, I know almost nothing about the current implementation of the new "database" file system being discussed. But, I would very much want to allow a user to designate which directories or file types would be put into relational tables and which ones would not. I might also want to be able to choose whether the relational tables were interacted with using a transactional guarantee or whether a "spider" was used. If the end user had control over when the "heavier" management of the files occurred and how much of it should be applied, then it might have utility. Part of the user's file system would then be a document management library and other parts would be a normal file system. However, I would find creating a user interface that tried to make such a solution comprehensible to an end user somewhat of a nightmare.
To my mind, a good patent has one of the following two characteristics.
1. It requires much study to even comprehend the patent and a peer review of experts in the field say that it is a SIGNIFICANT advance.
2. The patent opens so much new ground in ideas that even though the ideas are somewhat obvious, the unique combination is so explosively new that there is clearly no prior art that could possibly be referenced to invalidate the patent.
By the way, I do not think that HTML at any point was a patentable idea. There have been many markup languages and even some that were used in an internet setting before HTML came along. HTML was successful not just because it was a clear and easy simplification of SGML, but because there was a good and "free" implementation (the Mosaic browser) of it readily available. Also, if you look at the RFCs for HTTP it is clear that HTTP rested very strongly on the notions already known in other internet protocols (email, ftp, etc.). HTTP and HTML are clearly evolutionay ideas (if you examine the context in which they were created), and it was how they were used that was revolutionary.
"And has been doing. Forbes points out that SCO has pulled this same shit with Microsoft -- and won. In this case they bought the rights to an old, 'decrepit' version of DOS and proceeded to sue the shit out of Redmond. They are crafty bastards. And they basically leverage intellectual property law to fuck other people over."
To compare the DRDOS suit with the current SCO activity means that you have not been studying your history. The basis of the DRDOS (the "decrepit" version of DOS) lawsuit is as follows.
DRDOS was superior (by many peoples accounts) to DOS for a brief period in Microsoft's history. The Windows operating system (Windows 3.1 and earlier) ran on top of both versions of DOS. Microsoft deliberately put into their Windows code a test to see if it was running on top of DRDOS and then create a nasty looking crash. Microsoft then spread rumours through its vendors that DRDOS was unreliable. This killed the market for DRDOS.
There is clear and verifiable evidence of this and this is why Microsoft settled.
To compare the current SCO lawsuit to a lawsuit based on clear criminal behavior is to legitimize SCO's current lawsuit -- exactly why Forbes and other magazines give the current lawsuit credibility. The previous lawsuits were valid, why can't this one be as well? Absurd, unfortunate, but probably true.
If our court system allows trivial software notions to be patented, it is eventually going to cause serious harm to any attempts to create a viable long term open source software movement. Sometime in the not too distant future, software companies with money to lose our going to figure out that if they cannot win in the marketplace, the courts will provide the leverage that they need.
So for anybody who thinks that it is a good thing that Microsoft lost this case, they need to seriously take another look at this issue and realize that this case could be the start of a very bad trend. Just because my most hated enemy has to pay royalties to "climb mountains" does not make it right.
Cookies
Accepted Certificate Authorities (CA)
Current Authentication Credentials (Basic or NTLM login state)
Configuration for Proxys and Firewalls
Let us say that you want to create a rich and wonderful application hosted in this environment so it can use all this browser state information when talking to a web server.
Sun's Java plugin will not let you do this. It opens direct socket connections to a web server (bypassing the browser) and it impossible in an applet to determine any of the browser settings. You certainly cannot pick up cookies or ride on top of an NTLM login. Also, the certificate authorities for SSL may be completely different then the browser's settings.
Microsoft's VM inside the browser let you do all these things.
Where else am I going to get a solution that lets be write code that will run inside a tight sandbox, use the full browser environment for connecting to the web server, and let me do full OO style programming with all the extras (threads, container classes, support for interfaces, reflection, serialization of data, XML parsing, locales, etc.)? How do I get such an environment in a way where the user gets a seamless download experience once they install just one plugin?
I love how there are some fundamental assumptions made about an "acceptable" form for creating and delivering content. These assumptions control the type of "enterprise content management system" that content management experts think you should buy. Here are some "must have" features that make the problem of content management unacceptably hard.
I can't just email other people to see what they think of a document I created. The creation and approval process has to be enforced by a rigid workflow.
It has got to mimic file system style storage structures although it is precisely a file system's inability to multiply classify (example -- classify content by type, purpose, importance, geography and create views of the content oriented towards any one of these independent classification choices -- very difficult to do with file systems) content that contributed to a desire to acquire an expensive content management system in the first place.
Security must be on a document by document basis with contributors dictating precisely who can view or edit the document.
Relationships between documents must be actively managed. A broken link would be truly horrifying and unacceptable.
There is a horrible truth about content that creators of web sites cannot seem to grasp. The value of the site is the actual content, not in its presentation. A well written informative blog is far more useful than a "formulaic" pretty business web site. Not all content created by a company is destined as website "adware". Some of it may actually be intended to help employees do their jobs more efficiently. If that content is not fully polished so be it.
If I were looking for a content management system, I would look for one that does the basics. Version control, metadata classification, multi repository search, simple security classifications, archiving/retrieval, and some automated notification procedures. If you know who authored a content item, when it was authored, and the title the author chose to gave it, you already have a lot of useful information with which to do a search. It is the basics that give you the most ROI.
The demo I saw was of an open source port of C# to Linux. I do not think that there was a cheat. It is weird in a way that there is now an active open source development in progress for C# but not of Java.
However, C# does cheat in the sense that it does not use cross platform GUI libraries, it uses the native window APIs of whatever OS it is working on. In that respect, it has a fundamentally different mission than Java.
I must admit this was smaller than I suspected. I am basing my claims on the simple configuration dialogs that I have written that in spite of their simplicity can take a long time to start (2 seconds is way too long for a trivial app like this) and seem to take up an inordinate amount of memory.
Then somebody at a convention demoed a sophisticated user interface application on Linux using C# that used a tree control and tabbed dialogs. It came up immediately and took only a couple megabytes of memory.
It is also possible that Sun has improved this a bit in 1.4.1_02 using the client optimized launch. I have not checked the numbers recently.
So the fact that almost all real world Java applications (including Sun's) use shell scripts to launch their Java applications just so they can get around the limitations of the classpath is not sufficient proof of the problem. Ten applications share a common library. You want to upgrade the library but the name of the jar file has changed or you do not want to move or delete the existing library. In the best possible scenario, you would like to suggest to these 10 applications where they should go for the latest and greatest version of library API, but allow them to fall back to an older version. It is a real pain to have to write complicated shell scripts or custom classloaders to do this and once I use shell scripts or a custom classloader, there will be no textbook out there to explain to others what crazy things I did.
An example would be some XML library APIs (Xerxes?) that have incompatibilities with some of the shipping Java SDK libraries depending on which version of the Java SDK you are using. It would be nice to have a parameter that could test for version before deciding which XML library you would load.
In the old days when people talked about Linux, there was an expression "What about the big pink elephant in the middle of room" and it was referencing the fact that Linux did not support truetype fonts and font aliasing. Now some of that has been fixed, but Java still has its big pink elephant. Here are some of the things that people don't talk about.
The memory foot print for loading Java is 20meg + and growing. I am part of a team that has been developing a complex Java application for the last few years and we have created about a 3meg library (and it probably does at least as much as the more popularily used Java classes). I have looked at some of the source code for the core Java libraries and it is clear that a good rewrite could reduce this footprint by a factor of 2 to 4. Currently, C# loads with a footprint of 2 meg to 4 meg. Most other scripting languages usually have engines that are about the same size. To put it simply, the base core Java libaries are unjustifiably large. Maybe if Java were truly open source this could be addressed, but of course Sun doesn't even believe in submitting Java to a standards board.
You cannot load the Java VM once and run multiple processes (note "processes", not "threads") from the same Java VM memory footprint. I hear that such a thing is becoming possible for C# on Linux. You would have to build all the core Java classes into a "DLL" or ("so" on Linux), but that shouldn't be so difficult.
You still cannot do basic OS operations in Java without writing your own JNI library. The one that stands out is the inability to get the ID for the current running process. The "nio" package has corrected some of these issues, but the "nio" package should be the "io" package instead of having two separate packages (similar to AWT vs. Swing).
Window focus handling is still terrible. Ever have two frame windows up, have a modal dialog pop up on one frame while you were looking at the other? The frame window without the popop modal dialog becomes unresponsive and the other frame cannot be reached by tabbing through the windows. Only if you are lucky and that window is still visible on your desktop can you successfully reach it. Also, if a user clicks on a button that generates a modal dialog, the frame is only locked out from user input once the dialog manifests. This creates the infamous "double" clicking problem.
Java's package management is still primitive. If you want to do anything more subtle then using the classpath to load in custom libraries, you have to write your own class loader. Having an auxillary file specifying parameterizable rules for class loading would be nice. It would also be nice if you could ask a running Java process what packages it had loaded (and metadata about them such as location and version). Compare this to C# (or the way some of the web server oriented scripting languages work).
Some of the basic core library functions have some major weaknesses. For example, the Hashtable should be written as a native object when using String lookup keys and also allow you to dictate the algorithm for creating hashes (ex: use first 8 characters, last 8, or middle 8). There should also be a non thread safe version as well as a thread safe version. The lack of such a natively implemented primitive object is one of the big reasons why some less cleverly implemented scripting languages (such as python) can beat Java in performance on many web applications. In general, the core collection classes should be implemented in pure optimized (down to the actual chosen assembly code) native code.
Many of the utility libraries are broken in fundamental ways. Send back a badly formed response to the HTTP library and you go into an infinite loop when it falls into its keep-alive/retry logic. Date parsing is still behind what is available in the C standard library. Locale specifications do not allow you to independently specify date formats, language, floating point format, currency format, and time zone. You get o
One of the common mistakes when futurists try to make guesses about the nature of society a few decades from now is that they presume that trends that have been true will continue to be true. There are many examples of this.
During the 50s and 60s, there was a steep up ramp in energy consumption. Because of this, there were many dire predictions in the 70s that we would soon run out of energy. But the steep curve leveled off and the "energy crisis" never happened.
From the late 1800s to the 1960s, our ability to go faster and farther was also on a steep upward curve. Futurists naturally extending this trend assumed that travel to the planets would become commonplace and that personal air transport would soon become a cheaply available transport solution.
From the early 1900s to the 1960s there was great increase in leisure time. Some futurists postulated a future existence where only a few people worked and most just goofed off.
From the 1800s to the 1960s there was a tremendous improvement in using machines to replace humans when it came to various tasks. Again, it was natural to extend this trend to the point that robots manufactured most of the goods consumed by society. Also, during this period there was a large growth in household convenience devices. Extending this trend, it was natural to assume that there would soon be robots that performed all your housework,
Sometimes it is more interesting to examine what was missed. For most of the modern age up to the 1970s, there was not a great improvement in the speed (and quantity) in which written communication was delivered. It still took at least a few days for mail to arrive and international mail still could be a matter of weeks. In order to disseminate information (such as research), large mass printings had to be created and distributed in a very manual way. TV improved the communication process somewhat, but for information with a more limited audience, the basic infrastructure and approach for delivery had not changed for quite some time. That is why "email" and "website" was not on the minds of most futurists.
Also during this period, the mechanisms by which numeric and financial calculations were performed did not change much. It was both expensive to do the calculations and expensive to disseminate the results (My childhood was still in the era where we had to consult large logarithm tables to assist in doing simple arithmetic - something they were doing back in the 1700s). Thus it was not a natural presumption that computers could manage all the details of various financial transactions. In particular, EBay and PayPal were not envisioned.
So my challenge to futurists is to look a little deeper and try to anticipate changes that are not already occurring and extrapolate those. But that is not happening. Every futurist these days seems to be obsessed with small-computerized gadgets linked in high-speed communication networks that allow users to access broadband entertainment. A completely natural but probably mistaken prediction based on current trends.
I laud Mozilla for going down this road and it is clear to me that the core developers for Mozilla are a step above your standard programmer. Some accuse Mozilla for not following a method that would create "standards" for their XML GUI description language, but I have found that the successful "standards" usually follow already adopted and reasonably mature technologies. You do not know how you want to design something until you have done it, used it, and given it to other people to play with. Only after an application has grown sufficiently to include all the thousands of unexpected details is it sufficiently mature for people to talk about standards. For example, I consider the EJB specification's largest failing is that they tried to standardize it before it was actively used for a couple of years. Only now that we have some mature app servers do we really have an idea what needs to be in the core EJB specification. If EJB had followed this road, maybe application developers would not need to use vendor specific code for the critical parts of the functionality. Like OO, the mantra of "standards" seems to be more of a marketing tool to get Fortune 500 companies to cough up millions of dollars than something that really influences how sophisticated and successful applications get developed.
I have my own questions for the Mozilla team. How do you deploy "overrides" of existing configurations. Suppose I want to deploy a "batch" of changes that I want to turn on or off. Is there a way to create configuration "layerings" in XML files so a group of data specifications can be conditionally included from a set of external files? How much scripting is allowed in these files? If I want to write conditional code for specifying a color (such as a color choice per day of the week), is there a way to write scripting solutions for that need? Of course, I could read the book but I am lazy and I suspect that it would not give a full answer.
Few people are willing to question this OO dogma. Somehow they cannot believe that a data value will be given its full "semantic" meaning unless it is explicitly defined as an attribute in a particular object. If the compiler does not enforce the declaration of "type", they just don't think it is a proper data value. Although a compiler may prevent you from accidentally violating certain proper usages of that attribute, that small utility of preventing "typo" style errors is hardly worth the cost of the infrastructure that approach generates. When I examine field information using the JDBC api, I can discover all relevant type information without actually having an attribute declared to be that type. It seems silly to not use that information directly instead of having to load the information into an explicit attribute.
In the world of RFCs and the Internet, almost all parameters in a protocol are specified using some type of name-value approach (HTTP headers is the classic example). No implementation of these RFCs (such as web servers for HTTP) explicitly binds all of these parameters in their code. There is a soup of data out there, you grab the data items you need into temporary attributes (using human written code), but let the rest slide along with your main data objects as you process a request. It is a winning formula that creates tight and flexible code. It is the type of code that drives Apache, PHP, perl, and all the stuff that is actually out there in real usage instead of a the demo ware data entry apps created for fortune 500 companies.
First, how are you supposed to do development in an environment where it takes almost a minute to restart the application and find out if your latest change is working properly? That type of coding harks back to the dark ages of coding when you had to wait minutes before the compile and run was finished. There are kludges for creating "simulated" app server environments that give you faster development times, but that can only take you so far.
Secondly, it is practically impossible to create a distributable self-installing application that installs with no fuss into an app server environment. I am amazed that people are willing to put up with the configuration headaches for delivering app server solutions that they would never accept for their desktop applications.
Thirdly, there is a constant confusion surrounding issues like "session" and "non-session" beans, maintaining "transaction compliance", and whole hosts of finagle issues. Many of these issues have a drastic impact on performance depending on your choice, and usually the choices that give sufficient flexibility and acceptable performance are only available with completely proprietary vendor specific solutions.
As far as I can tell, the original vision of having easily developed, easily deployable, and high performing server-side application solutions has been lost and has been replaced by an environment in which it is difficult to create code, painful to deploy solutions, and a real headache to tune for speed.
This is such an unfortunate fate for EJBs. In the original vision, EJBs were to be the server side equivalent of Microsoft's ActiveX controls for the desktop. There are still some good ideas buried in the EJB specs, but the heavy weight app servers have buried these little nuggets inside massive overachieving bloat ware.
In an environment that spawns 100s of processes to handle requests, each process can end up creating a duplicate cache of the same user information. Since I do not know of way in Apache to have the same users visit the same process, it is difficult not to create 100s of copies of the same user cache. If the cache is dumped every couple of minutes for each user, it is very easy to create a scenario where a cache in a particular process is too old to be usable by the time a user visits the same process again. The general effect of this is that Apache 1.3 cannot be used for solutions that emphasize caching. This problem also manifests for scripting solutions where scripting pages are preloaded, parsed, and cached (does anybody know how mod perl handles this?).
Using memory shared across processes or writing data to temporary files could potentially solve such issues, but that can have its own headaches and costs. For example, there can be significant overhead in serializing information from/to an IO system (memory files or temp files on a file system) if there is more than a trivial amount of information being cached.
Part of the promise of Apache 2.0 is that it will create an environment for creating complicated and scalable applications for the enterprise. As far as I can tell, without a threading model solution, Apache would be considered not much more than a toy for real industrial applications. It is possible to create Apache 1.3 applications that serve many users and have much content, but the users usually have to be locally stored (in particular passwords are directly available) and the content has to be "prepackaged" for optimized delivery. This may work for focused web sites, but in the new universe of "web services" and pushing mainstream business apps onto the web, Apache 1.3 falls far short.
Every now and then I read broad sweeping claims about how we could fix our secondary education. Let us look at some of the reasons why it is so hard to educate our children properly.
I have a Ph.d. in mathematics. I work as a software developer and I have not even used simple algebra in over 5 years. That does not mean that my job is boring or lacks the need for reasoning skills, but it does imply that a lot of my education has less relevancy than many people would like to believe.
This is a general problem. It is very hard to pursuade students that their education has relevancy and to some extent the students are right. Our education establishment is focused on properly preparing students to be ready for the late 19th century. Many teachers in secondary education are teachers because they were not clever enough to get an education that made them relevant to the work needs of our current generation. It is very hard for such teachers to pursuade students that their education matters.
Many of the teachers who teach math never had the "ah ha" experience that is vital to true understanding. Such teachers are unlikely to generate any real understanding in their students. Since I taught myself mostly from books, I always thought this business of having teachers and classrooms as being overrated. The books did a much better job in explaining the material than the teacher.
Although I hate the type of teaching that standardized testing inspires, I also hate teaching that has no accountability. Given the choice between two evils, I tend to choose the standardized tests. Over the years there have been many attempts to bring "creativity" or "understanding" back into our classrooms. Except for a few model classrooms with very motivated and bright teachers, these "innovations" have usually been an excuse for teachers to create an even more muddled and useless experience for their students.
In particular the "new math", that was being taught when I was in middle school, is especially brain dead. Students would end up stripped of any mastery of the basics of math and were not sufficiently compensated with any "deeper" or "creative" insights into mathematics. When I got to college, I saw some of the point of teaching students about "sets", but only a really inspired and talented teacher could have communicated the deeper ideas in "new math" to a standard classroom of kids.
I see no easy fix to our secondary education problems. But with no way to hold our teachers accountable for the educations they provide, there is no way to know if a particular idea is actually helping or hurting.
Well -- having been in this business myself, I'll try to explain the relevancy of this problem. In Fourier analysis, the problem is usually to take a look at data, apply a transform and look at the underlying harmonics of the data (this works best on sound or light because the harmonics correspond to actual physical properties such as "pitch" or "frequency"). For example such techniques can be used to clean up images by removing the "noise" type frequencies in the data. A similar technique can be applied to numeric entities such as prime numbers. Ideas such as this produce something called the Zeta function which can capture various statistical properties of prime numbers (statistical properties of the entire infinite series of prime numbers). The "zeros" of the Zeta function (I'll avoid explaining what I mean by this) capture some of the statistical properties of primes in the way Fourier transforms explain light and sound. The Riemann hypothesis comes down in essense to claiming that prime numbers never behave too statistically perverse (the equivalent in Fourier transform data of saying that the harmonics are not too skewed -- the "sound" never "gangs" up on certain frequency areas). Although the mathematics can seem a bit obscure to those outside the field, it is probably one of the more profound questions out there. As a comparison, Fermat's last theorem (when evaluated purely for its mathematical significance) is merely a curiousity and was proved as a minor consequence of proving more important theorems in elliptic curves, which themselves are only stepping stones towards another really large unproved mathematical question. For the record, the question is: "Are all elliptic curves modular?" -- which is way more obscure than the Riemann Hypothesis and I consider to be the number one potentially solvable mathematical question that has ever been posed. It is a really cool problem.
If you are involved in a large complicated software project and you write 10000 lines of code then that code will have many conditionals, loops, and branches each of which involved a design or implementation decision. Bad programmers think that not much is involved in those choices, good programmers are still internally debating the choices years later. The more I do software development, the more I believe that there is a general lack of awareness just how difficult it is to write a good useful sellable software program. Every few years there is some new methedology that is going to revolutionize software development (remember when you could find Object Oriented Programming Gurus at every software convention). None of them have a technique for naming a function so that two years later you do not regret the name because a.) it is not specific enough. b.) violates the thematic pattern of other function names. Or c.) no longer precisely describes the purpose of the function.