MIME attachments to SOAP messages are acutally entirely 'standard' (or at least as standard as any non-W3C XML-related spec gets). There's a W3C Note describing a standard means of handling multipart MIME messages with the SOAP framework; that would allow you to 'attach' the raw binary data to your message, and simply reference it from the SOAP envelope via a relative URI.
Of course, you're still not going to have absolute efficiency, since along with XML's verbosity, you have the additional overhead of the full SOAP envelope and mutipart MIME formatting to deal with. If single messages contain large BLOBs, though, that's going to be water under the bridge.
Not to nitpick, but using that example of how Lisp is just 'syntactically' different from procedural languages shows your conditioning for them pretty strongly; the whole idea of functional programming is to reduce side effects such as variable assignment to a bare minimum, and have the program directly represent the correct solution to the problem statement. That way, you can actually divide a program into its individual algorithms, and understand them, without running around with a debugger, tracing two dozen variables at a hundred breakpoints, just to understand a single subroutine.
Right now, OOP is often over-hyped in business situations where there the management is making key technological decisions, rather than letting the people who are actually in a position to know what would be a good design paradigm (basically, the programmers) choose. If some executive gets a really nice, flashy demo from Rational, Microsoft, or ATG, they're probably going to believe a lot more of the buzzword/technobabble that the salespeople throw out there than an experienced developer would.
However, it's pretty impossible to argue with the productivity that something like COM or JavaBeans allows for non-mission-critical systems (or with EJBs, even for some more advanced systems, so long as you follow the 'rules'). Visual Basic, Java, et. al., can do a very good job of allowing programmers of many different skill levels to produce working code, and that, guys and gals, is often all that matters.
The programmers who claim that OOP is the only way to go are often the ones who really don't care to understand any other design paradigms; I've known quite a few developers who were basically only in it for the paycheck, and since OOP and component systems were hot in the business world, they did everything they could to play along. Hell, I work almost exclusively in Java at the office, 'cause that's what the (business) people want. At home, it's Perl, Python, and ML, but I can only afford the time and hardware to play with those languages because of my day job.
Like it or not, business programming is becoming more and more one of the new "blue-collar" occupations. Most people doing it are there because they like the wages and the predictable work, not because they're hardcore geeks.
Look, folks, I agree with many of you in saying that a child's physchological, emotional, and social growth is important. I'm not really going to try to convince you all that I know the perfect answers for how to accomplish this, and most of you who don't have children probably shouldn't either.
However, that's not what the poster asked. The original question was, to paraphrase, "I am going to tutor this very gifted child for a limited amount of time, in a limited vartiety of subjects; he's already shown interest in computers and programming, and I would like to encourage that. What subjects and material would best allow me to do that?"
In answer to that question, I have a few suggestions:
Math, math, and more math. It's the basis of everything that kid will be doing with a computer, and it sounds like he's both young and bright enough to be able to think about it that way. Too many people who learn programming, or even just become computer literate, in later life, or without a full education in the math they're using on a daily basis, never have those wonderful "Eureka!" moments of spontaneously applying something learned from a calculus text to a piece of code, or visa-versa.
Linguistics, or at least a foreign language. There's nothing more valuable for someone (like a programmer) who's trying to be at the same time creative and precise as to have had the experience of stepping outside the mental wiring you developed for the first few years of your life, (your native language) and think and speak in a wholly different way.
Music, both classical and modern. Don't shove it down the kid's throat, if he's not interested, but if he likes music, and listens to it anyway, you could "randomly" pick some really great pieces (think Mozart, Miles Davis, Tchaicovsky) to have playing while you're working with him, and if he has questions about it, be full of all kinds of interesting details.
Finally, some programming. A basic procedural language is, of course, a must. However, if you can, try to steer him towards other language designs at the same time -- Lisp, Haskell, or even Python could be much better vehicles for a young mind's creativity than something where everything has been done, and only remains to be re-implemented.
Yes, I know this is not a complete education. Tutors aren't usually asked to provide one, however; their role is generally to provide extra assistance or encouragement in a few subjects, and let the kid's full-time teachers and parents worry about the rest of their education.
Anyway, good luck, and much good karma (the spiritual, as well as geek kind) for taking time to do one of the most important things humans can do: teach.
You cannot make a dialect of XML dependent on a particular application, database server, or programming language -- at least, if you want anyone else to be able to parse it, validate it, etc. That's the appeal of XML in a nutshell. Yes, Microsoft may only directly support the generation of that type of XML through the newest version of BackOffice/.NET/SQL Server, but if there's a DTD or schma for it out there, I (or any other programmer at all familiar with XML technologies) can parse it, generate new documents that follow it, etc.
--- begin rant mode ---
Personally, the only reason that I give Oracle any more slack than Microsoft is that their software basically does what it's supposed to, reliably and consistently. Now, if you try to run any medium to large-scale Oracle database on an OS other than Solaris, you're probably in for some major headaches, but it can be done. As a business entity, though, Oracle is just as bitchy, proprietary, and overpriced as Microsoft, and they are just as happy to run over anything that stands in the way of their total market domination. Just a bunch of good capitalists, I suppose, but not great at instilling warm fuzzies in me.
--- end rant mode ---
There's nothing that ties an XML schema to a particular database or OS, except the laziness of programmers and managers; if you need to implement that B2B communications tool today, you're probably going to go with the tool that (at least in theory) allows you to do it without reinventing the wheel. From a business point of view, if Microsoft offers tools that let you do that without risking a screwup by one of your programmers, then their solution seems very attractive.
In all reality, both of these companies are highly involved in the creation of XML standards largely because that's how the W3C and the rest of the Internet business community want it; the whole idea of the period between Candidate Recommendation and Recomendation status at the W3C is a sort of trial period for software companies (read: big, influental software companies) to attempt implementation of a new 'standard', and give the group feedback on what areas worked, what areas gave them major headaches, etc. Think of it as popular approval from the business world, where market share means everything.
Why do you think XML has taken off for business messaging and rapid application development, while the really cool XML applications like SVG and RDF, though they've been bouncing around for years, have yet to get the kind of major industry support they need to reach success? There's no incentive for the big players (Sun, MS, IBM, et. al.) to spend their time working on things that would primarily benefit consumers, academics, and the Internet community as a whole when they could be making the "next big thing" for businesses.
Actually, embedding a JVM (or at least major chunks of it) in the kernel would be a great idea -- you'd have the whole Java security model to insulate you from sketchy code, and Java apps could get near-native performance quite easily. Of course, in 95% or cases you'd probably only want to compile it as a module, but either one would be an amazing step for cinching Linux's dominance in the entry to mid-level server market.
Screw CORBA -- give me Java, and I can have RMI-IIOP, SOAP, etc., and much better security, portability, etc. And, it'd be something that no other OS out there has right now -- not Solaris, or the IBM *NIXes, or True64, or Win2k...actually, MacOS-X might have it; I'm not really familiar enough with its kernel architecture to be able to say how deep the Java integration goes.
I agree with you in saying that, for the time being at least, an ORB in the kernel is probably a special-purpose add-on, which won't be necessary for the majority of users. However, your statements about "the goal and purpose of [an] O/S" are somewhat short-sighted. CORBA is not an 'application', it's a means of allowing applications to communicate in a language and platform independent way across a network. How many *NIX apps already use sockets to make them accessible to multiple 'client' programs on the same machine? Are you suggesting that socket management shouldn't be part of the kernel?
True, CORBA is not commonly in use today for these purposes, but that is not because it would be unsuitable for them; rather, the technology has simply not begun to establish itself at the LAN and workstation level as a viable option. Huge enterprise installations often rely heavily on high-performance, scalable ORBs to manage communications between legacy system, user applications, web applications, etc., and distributed computing is becoming more and more a point of interest on the desktop.
There are a number of things that the addition of (a later, more stable version of) kORBit to the core kernel distribution could offer: instant, painless cluster development; increased acceptance of Linux in enterprise-scale networks (now, your Linux router can scream through CORBA calls, as well...); and, as mentioned in the article, distributed hardware and resource access.
The world standardized around TCP/IP to satisfy the need for standard network connection and data transfer management, and CORBA looks to be a contender for that role in distributed service and resource management. Just as C++, Java, Perl, and other high-level languages are rapidly supplanting C for most application development due to their increased abstraction, programmer productivity, and portability (more so with Java or Perl, of course), CORBA could one day all but replace TCP/IP for the majority of network applications, since while the data being passed between network nodes will be more complex, access to it would be more general and flexible.
Please also note that you could replace the word CORBA in the above post with SOAP, or any other distributed network application protocol with sufficient momentum and protability to potentially become the standard. In fact, SOAP (or a twisted version thereof) is going to be a major component of Microsoft's.NET framework, which, for all the hatred and suspicion I have of MS, is likely going to do some fucking impressive things for distributed computing (at least, for those running Win2k and later). Right now, the capabilities of Microsoft software are not significantly ahead of the available free alternatives, but if MS gets a huge head start in this area, they just might be able to hold on to a new proprietary stranglehold on the business computing world.
We should encourage experiementation with projects like the one described in the article, as a means of keeping Linux and free software as a whole on the cutting edge. This is an area where no clear leader has emerged yet, and where an early lead by free software could make a huge difference years down the road.
Flash memory can only survive a fairly limited number (low tens of thousands, if I remember correctly) of read/write cycles before it goes 'pop'. That's partly why, for high-usage, random-access storage, there are still very good reasons for using a hard drive. Also, just look at the maximum storage capacities you can get for flash vs. hard drives in a palmtop-sized package: I have yet to see any device with more than 64MB-128MB of flash (and even that drives the price up considerably), while IBM is happily shipping 1GB microdrives.
Not that I wouldn't love to see solid state take over, mind you; it's just that magnetic devices still offer so much more cost effective and reliable (over hundreds of thousands or millions of read/write cycles) storage, even in the handheld arena.
Would you run a seperate instance of X-Windows for every little graphical utility you want available simultaneously? How about a seperate copy of the kernel for every command-line app? No, I didn't think so...
Why, then, should Java apps be expected to be massivley memory efficient when running in independent VMs?
The problem with many standalone desktop Java applications is that they are written with the assumption that they will be run independently of any other software aside from the VM and core Java libraries.
That's a syntax issue, not a functional one; you can always use string1.equals(string2), and get a result equivalent to the intention of the C-style boolean operator. Remember, Java object variables are just references, not values! Trying to directly compare them would be like trying to compare two pointers in C, and then being shocked if they weren't equal, even if the data structures they pointed to were of the same type and had the same contents.
The only way to do that is to use the Microsoft GUI toolkit, which then makes the code completely non-portable. What I'm very impressed with the Mozilla code is the face that they've put together a completely skinnable GUI that runs on a huge array of platforms relatively reliably and still manages to perform well enough for many people to not mind the difference. Look at AWT/Swing apps for Java if you want a comparison for a similar package, and then come back and complain about the GUI's responsiveness.
Speaking of which, I'd really like to see some JNI bindings for the Mozilla GUI toolkit...sure would kick the crap out of AWT, if the component models were at all reconcileable. Looks like maybe it's time to start brushing up on my JNI.
You know, most Java developers write server software, as well. Strangely, the amount of use of Java on the server seems to be increasing, rather than decreasing, as time goes on; that would seem to indicate that at least some people out there think it 'cuts the mustard' for 'real software'.
Just like any language, Java can be very, very fast and efficient, or very, very slow. No, it will probably not blow away well-written C/C++ for low-level operations, nor will it provide the degree of fine-grained control of memory and low-level system operations that a natively compiled language will. However, most programmers don't want to have to deal with that every time they sit down to write a piece of code. It's actually far easier to tell your boss that hardware requirements have increased than it is to tell him that you missed a memory leak in the production version of your code, which was just purchased and installed by your ten largest clients, that will slowly grind their far more expensive hardware to a halt.
I would actually state the reverse of your end users vs. server developers statement: for end users (think Windows-only, non-geek types here) Java is maddeningly slow -- the GUI toolkits basically suck, and starting even a small program can take several seconds on a newish machine. However, for server programmers, Java can be 'Fast Enough', while freeing them from potentially maddening tracking of every malloc/free pair, the idiosyncracies of their destination platform(s), etc.
By most of your arguments, no one should use Perl, or Python, or even shell scripts: their primary usage is on the server, yet none of them are natively compiled, and don't offer the same degree of low-level hardware control and memory manipulation. And yet, developers flock to them, and continue to do so. Why? A simple reason -- the reason computers exist is to automate repetitive operations far more quickly and efficiently than humans could, and Java, Perl, Python, and other higher-level languages put more of the burden of things like memory allocation (which are repetitive, uninteresting ops) on the system, rather than the developer, leaving the developer free to actually implement something that works in a fraction of the time.
I'd like to see your source for the blanketing declaration that any Java method call results in a 100ms lag, and how any of the tens of thousands of sites using servlets or JSPs instead of CGI on the server side could run at all if that were the case. You make the same mistake that so many people seem to have made in this thread -- assuming that Java is applets, and always runs like applets, and suffers from the same inconsistencies and performance issues that applets do. Java does indeed suck for most GUI applications, but does what it is supposed to quickly, reliably, and portably on the server.
And what is this 'hundreds of dollars' that programmers are paying to use Java? I have written several commercial Java applications, and even more non-commercial ones, and never once encountered a requirement that I pay a licensing fee for a basic Java runtime environment or libraries.
My only hope is that your second-to-last paragraph indicates a sense of irony, and that your entire posting was intended to be taken a a single large sarcastic wisecrack.
What exactly in Java has Sun not opened up to other vendors? The source code to every internal working of their implementation of the JVM and core libraries? That doesn't really bother me as much as most closed-source bullshit does -- there are other versions and suppliers of both, many of which are simply more usable. True, Sun has not simply given up the keys to Java, but they haven't really abused their position, either. Look at the state of the language and its associated libraries today -- it's usable, robust, and flexible, and there are many different potential suppliers.
JSP/ASP (with or without version numbers, plus signs, etc.) are:
Completely different technologies, with totally different server-side architectures (JSPs are pre-compiled into Servlets, which are fast and reusable)
Both broken from a design standpoint, since they allow for free mixing of business logic and presentation
More or less insignificant in an Internet environment dominated by XML, since you're going to have to work on that native object model directly, anyway
The fact that Corel has signed an agreement with Microsoft to be port the.NET framework if Microsoft requests it does not impress me. Microsoft could do the exact same thing, if they liked -- they have more programmers than most anyone, and Linux is not so complex that a decent development and runtime environment couldn't be hacked together in a matter of a few months.
Lastly, Java is not interpreted! The first-generation JVMs treated the bytecode like an interpreted language, but the more recent high-performance JIT environments (as well as native compilers, like gcj) remove that bottleneck, while still allowing for compatibility on systems that don't have (or want) native compilation.
The goal of.NET is to perpetuate the lock-in that they've had on RAD tools (and the projects created with them) by preventing the mass exodus away from VB and VC++ that would otherwise be inevitable in the next few years. Yes, distributed objects, transactions, and inheritance will be available to users of those coding in a number of different languages, but that's simply the effects of using XML as a universal exchange protocol, not some mystic MS voodoo.
Of course, it makes good business sense, and if there's anything MS doesn't consistently screw up, it's business. PHBs will eat this shit up, and I forsee a long, dark winter for would-be liberators trying to urge their employers away from MS-specific development environments, langauges, and tools.
...applets suck. Really, they were a poor first stab at finding a use for Java technology, and have continued to be more or less retarded cousins of regular desktop applications.
However, Java on the server makes sense, and works consistently. I write J2EE apps for a living, and I can tell you with confidence that code that I write that relies on nothing but pure Java will run reliably on Solaris, Windows, and Linux at minimum, UNIX, and if I play it safe with my choice of runtime libraries (not core language or logic, just convenience classes), on MacOS, BSD, AIX, Tru64, HP/UX, OS/390, and a few others that I'm forgetting at the moment.
Don't get me wrong -- Perl is great. The minute you start taking advantage of your 'closer access to the OS', though, you restrict yourself to a small subset of the possible environments it runs on (POSIX is not universal).
Umm -- ever written any JavaBeans? You can (in fact, are strongly encouraged to) provide multiple types of descriptive text for every class, method, private or public field, etc. As a matter of fact, any Java class can be interrogated at design (or run) time through the Java reflection mechanisms, and most of the major IDEs will display your beloved 'popups,' along with method signatures, comments, (if provided) and reverse-engineered source code to compiled classes. Plus, JavaBean objects can be 'wrapped' in an ActiveX layer that makes them usable in Visual Studio, etc.
The last means of accessing COM objects from Java I worked was the Visual J++ COM "compiler," which put references to all the Windows-native calls into comment blocks in your Java source, and added the low-level code at compile time. Not exactly pleasant to debug, and completely non-portable.
It's not anywhere near close to happening yet. Remember all those news reports a couple of months ago about unexpected deaths during gene therapy? People were dying while doctors were trying to change alter a few genes that were already present in the human genome. Splicing a totally new caffeine-generating gene into human DNA is not only several orders of magnitude more complex, it is also largely pointless without years of additional study, testing, and exploration of the human genome.
Remeber, there are a lot of genes in our DNA that don't do anything in most people -- they may code proteins that predecessor speceis used, or they may simply not be activated. In order to add caffeine synthesis to the human body's bag of tricks, you would not only need to add the gene that describes the synthetic process (which would undoubtedly be very, very different in a mallaian body than in a plant), you would need to set up an entire production system. That means either "hacking" a custom gland, tapping the resources of an existing one, generating it in various cells throughout the body, etc.
Every one of these changes carries the risk of causing all kinds of nasty chemical imbalances, genetic defects, or just plain wierd side effects completely independent of increased caffeine levels. I for one will not be jumping in to have by DNA tweaked anywhere near that drastically until the study of human genetics and biochemistry is significantly further along.
The word "endorphin" is actually short for "endogenous morphine" -- basically, when endorphins were isolated and studied, morphine was already well-known, so they were simply identified as the body's closest naturally-occuring substitute.
Just think: if things had gone a little differently, you could be calling dopamine 'endophetam', or serotonin 'endobanis'...
There may be cultural traditions of tipping in Europe and the US, but in Japan, for exmaple, tipping is not a part of classic etiquette. When in Japan, I actually saw a restarant owner run outside to return the tip I had left automatically on the table.
This may be changing as their culture becomes increasingly Westernized, but I wonder how many other parts of the world have never really included tipping as a part of their heritage.
You are only partially wrong. Most neurologically active drugs do indeed bind to receptors of endogenous chemicals that they "impersonate," and have a direct effect on the levels and/or action of that transmitter. However, they seldom function as simple analogues -- a single drug can bind to many types of receptors, and can directly increase or decrease the levels of many endogenous compounds.
Caffeine, though, is sort of a special case. Unlike the "classic" stimulants such as amphetamine, cocaine, or ephedra, it does not have a dramatic effect on dopamine or epinephrine (adrenaline) levels in the CNS. Instead, it increases calcium ion transfer in the nervous system, effectively lowering the threshold for a signal to get through. Every nerve cell in your body simply becomes more active, but continues carrying more or less the same data as before.
Think of it this way: Most drugs work like new components in a computer, such as a processor or drive. Just like a processor upgrade, or new sound card, they fundamentally alter the way it operates, and may or may not be totally compatible with the rest of the system. Caffeine, on the other hand, is much more like overclocking the system bus. None of the data being transferred changes, but it moves at a faster rate from place to place.
Unfortunately, just like OC'ing a machine, caffeinating your body doesn't do wonders for its reliability. Sometimes those nerve cells really don't take well to being pushed harder, and the signals start getting noisy while passing from place to place. Hence, the random tics and changes in mental state that accompany ecessive use of caffeine.
Not that I would have it any other way, mind you...
The "runner's high" is an adaptation designed to allow people's bodies to continue to operate under extreme duress -- the endorphins help counteract the physical pain and psychological stresses of difficult activities.
Caffeine, on the other hand, jacks the body up. It increases nervous system activity throughout the body by basically lowering the threshold for signals passing between nerve cells. It's "enjoyable" effects are largely conditioned response, as people learn to expect and appreciate the perceived increase in their mental and physical energy levels.
Drinking coffee is "just doing drugs," albeit in a socially acceptable and ritualistic fashion. Many "hard" drug users have an equal amount of daily ritual to their usage, and probably gain similar psychological imprinting. If you want to make caffeine a more "natural" reward, then trigger its release only after certain phsyical criteria are met, just as endorphins are only released when the body has a reason for it.
However, the body already has a similar response in its use of adrenaline (or epinephrine to you Europeans out there). It would be difficult to find situations in which caffeine was a more physically useful stimulant, especially since its use carries at least as many (arguably worse) side effects as adrenaline.
...Codewarrior... feels like mac development ten years ago...
Palm OS...feels like Mac OS ten years ago...
Seriously, though, how elaborate a development environment do you need for a device with the size and complexity of a Palm? You can use Codewarrior or gcc for full-blown app coding, or you can use Jump, LispMe, or any number of other almost-there-environments for RAD and prototyping.
The reason for the high cost of the data discs, and Sony's reluctance to develop anything other than the audio format, is licensing fees. Right now, they own the rights to the compression scheme used on MDs, and anyone who wants to market a compatible recorder, player, or disc has to pay them for the privelage. If Sony were to start pushing MD-Data, they could lose that revenue per unit, since people would simply be putting whatever data they chose onto the discs.
Sony has the "vision" to try and put one of their pieces of hardware in front of every data source you have -- TV, Internet, phone, etc. They don't have a great history of supporting open standards (see Beta, MiniDisc, Memory Stick, etc.), and I personally don't necessarily want to simply hand the keys to all my data and connectivity over to their benevolent hands.
Sony has repeatedly come up with decent compact storage formats. They also often build integrated compression and encryption in at the hardware interface level for that format. So long as all you use is Sony (or Sony-licensed) hardware, you're all set. However, if you want to migrate away from that platform...you're screwed. Under the DMCA, accessing your data that's been compressed and encrypted in a Sony-owned format with anything other than an authorized Sony product is reverse engineering, and you can be arrested.
Q-1: What is Hewlett-Packard?
A-1: A profit-seeking private corporation.
Q-2: Why would they use Linux?
A-2: Cheap, realiable, customizeable OS available for a variety of hardware.
Q-3: Why do most/.'ers run Linux?
A-3: See answer #2.
Q-4: What has HP taken away from open source?
A-4: A free license to use Linux.
Q-5: What do most/.'ers take away from open source?
A-5: See answer #4.
Q-6: What has HP given back to the open source community?
A-6: Some code, another high-profile Linux-based product, and more validity in the market.
Q-7: What does the average/.'er give back to the open source community?
A-7: Some code, perhaps a few low- to medium-profile Linux-based products, and evangalism in the market.
Slashdot Mirror
Of course, you're still not going to have absolute efficiency, since along with XML's verbosity, you have the additional overhead of the full SOAP envelope and mutipart MIME formatting to deal with. If single messages contain large BLOBs, though, that's going to be water under the bridge.
Not to nitpick, but using that example of how Lisp is just 'syntactically' different from procedural languages shows your conditioning for them pretty strongly; the whole idea of functional programming is to reduce side effects such as variable assignment to a bare minimum, and have the program directly represent the correct solution to the problem statement. That way, you can actually divide a program into its individual algorithms, and understand them, without running around with a debugger, tracing two dozen variables at a hundred breakpoints, just to understand a single subroutine.
However, it's pretty impossible to argue with the productivity that something like COM or JavaBeans allows for non-mission-critical systems (or with EJBs, even for some more advanced systems, so long as you follow the 'rules'). Visual Basic, Java, et. al., can do a very good job of allowing programmers of many different skill levels to produce working code, and that, guys and gals, is often all that matters.
The programmers who claim that OOP is the only way to go are often the ones who really don't care to understand any other design paradigms; I've known quite a few developers who were basically only in it for the paycheck, and since OOP and component systems were hot in the business world, they did everything they could to play along. Hell, I work almost exclusively in Java at the office, 'cause that's what the (business) people want. At home, it's Perl, Python, and ML, but I can only afford the time and hardware to play with those languages because of my day job.
Like it or not, business programming is becoming more and more one of the new "blue-collar" occupations. Most people doing it are there because they like the wages and the predictable work, not because they're hardcore geeks.
However, that's not what the poster asked. The original question was, to paraphrase, "I am going to tutor this very gifted child for a limited amount of time, in a limited vartiety of subjects; he's already shown interest in computers and programming, and I would like to encourage that. What subjects and material would best allow me to do that?"
In answer to that question, I have a few suggestions:
Yes, I know this is not a complete education. Tutors aren't usually asked to provide one, however; their role is generally to provide extra assistance or encouragement in a few subjects, and let the kid's full-time teachers and parents worry about the rest of their education.
Anyway, good luck, and much good karma (the spiritual, as well as geek kind) for taking time to do one of the most important things humans can do: teach.
--- begin rant mode ---
Personally, the only reason that I give Oracle any more slack than Microsoft is that their software basically does what it's supposed to, reliably and consistently. Now, if you try to run any medium to large-scale Oracle database on an OS other than Solaris, you're probably in for some major headaches, but it can be done. As a business entity, though, Oracle is just as bitchy, proprietary, and overpriced as Microsoft, and they are just as happy to run over anything that stands in the way of their total market domination. Just a bunch of good capitalists, I suppose, but not great at instilling warm fuzzies in me.
--- end rant mode ---
There's nothing that ties an XML schema to a particular database or OS, except the laziness of programmers and managers; if you need to implement that B2B communications tool today, you're probably going to go with the tool that (at least in theory) allows you to do it without reinventing the wheel. From a business point of view, if Microsoft offers tools that let you do that without risking a screwup by one of your programmers, then their solution seems very attractive.
In all reality, both of these companies are highly involved in the creation of XML standards largely because that's how the W3C and the rest of the Internet business community want it; the whole idea of the period between Candidate Recommendation and Recomendation status at the W3C is a sort of trial period for software companies (read: big, influental software companies) to attempt implementation of a new 'standard', and give the group feedback on what areas worked, what areas gave them major headaches, etc. Think of it as popular approval from the business world, where market share means everything.
Why do you think XML has taken off for business messaging and rapid application development, while the really cool XML applications like SVG and RDF, though they've been bouncing around for years, have yet to get the kind of major industry support they need to reach success? There's no incentive for the big players (Sun, MS, IBM, et. al.) to spend their time working on things that would primarily benefit consumers, academics, and the Internet community as a whole when they could be making the "next big thing" for businesses.
Screw CORBA -- give me Java, and I can have RMI-IIOP, SOAP, etc., and much better security, portability, etc. And, it'd be something that no other OS out there has right now -- not Solaris, or the IBM *NIXes, or True64, or Win2k...actually, MacOS-X might have it; I'm not really familiar enough with its kernel architecture to be able to say how deep the Java integration goes.
True, CORBA is not commonly in use today for these purposes, but that is not because it would be unsuitable for them; rather, the technology has simply not begun to establish itself at the LAN and workstation level as a viable option. Huge enterprise installations often rely heavily on high-performance, scalable ORBs to manage communications between legacy system, user applications, web applications, etc., and distributed computing is becoming more and more a point of interest on the desktop.
There are a number of things that the addition of (a later, more stable version of) kORBit to the core kernel distribution could offer: instant, painless cluster development; increased acceptance of Linux in enterprise-scale networks (now, your Linux router can scream through CORBA calls, as well...); and, as mentioned in the article, distributed hardware and resource access.
The world standardized around TCP/IP to satisfy the need for standard network connection and data transfer management, and CORBA looks to be a contender for that role in distributed service and resource management. Just as C++, Java, Perl, and other high-level languages are rapidly supplanting C for most application development due to their increased abstraction, programmer productivity, and portability (more so with Java or Perl, of course), CORBA could one day all but replace TCP/IP for the majority of network applications, since while the data being passed between network nodes will be more complex, access to it would be more general and flexible.
Please also note that you could replace the word CORBA in the above post with SOAP, or any other distributed network application protocol with sufficient momentum and protability to potentially become the standard. In fact, SOAP (or a twisted version thereof) is going to be a major component of Microsoft's .NET framework, which, for all the hatred and suspicion I have of MS, is likely going to do some fucking impressive things for distributed computing (at least, for those running Win2k and later). Right now, the capabilities of Microsoft software are not significantly ahead of the available free alternatives, but if MS gets a huge head start in this area, they just might be able to hold on to a new proprietary stranglehold on the business computing world.
We should encourage experiementation with projects like the one described in the article, as a means of keeping Linux and free software as a whole on the cutting edge. This is an area where no clear leader has emerged yet, and where an early lead by free software could make a huge difference years down the road.
Just my $2x10^-2
Not that I wouldn't love to see solid state take over, mind you; it's just that magnetic devices still offer so much more cost effective and reliable (over hundreds of thousands or millions of read/write cycles) storage, even in the handheld arena.
Why, then, should Java apps be expected to be massivley memory efficient when running in independent VMs?
The problem with many standalone desktop Java applications is that they are written with the assumption that they will be run independently of any other software aside from the VM and core Java libraries.
That's a syntax issue, not a functional one; you can always use string1.equals(string2), and get a result equivalent to the intention of the C-style boolean operator. Remember, Java object variables are just references, not values! Trying to directly compare them would be like trying to compare two pointers in C, and then being shocked if they weren't equal, even if the data structures they pointed to were of the same type and had the same contents.
Speaking of which, I'd really like to see some JNI bindings for the Mozilla GUI toolkit...sure would kick the crap out of AWT, if the component models were at all reconcileable. Looks like maybe it's time to start brushing up on my JNI.
Just like any language, Java can be very, very fast and efficient, or very, very slow. No, it will probably not blow away well-written C/C++ for low-level operations, nor will it provide the degree of fine-grained control of memory and low-level system operations that a natively compiled language will. However, most programmers don't want to have to deal with that every time they sit down to write a piece of code. It's actually far easier to tell your boss that hardware requirements have increased than it is to tell him that you missed a memory leak in the production version of your code, which was just purchased and installed by your ten largest clients, that will slowly grind their far more expensive hardware to a halt.
I would actually state the reverse of your end users vs. server developers statement: for end users (think Windows-only, non-geek types here) Java is maddeningly slow -- the GUI toolkits basically suck, and starting even a small program can take several seconds on a newish machine. However, for server programmers, Java can be 'Fast Enough', while freeing them from potentially maddening tracking of every malloc/free pair, the idiosyncracies of their destination platform(s), etc.
By most of your arguments, no one should use Perl, or Python, or even shell scripts: their primary usage is on the server, yet none of them are natively compiled, and don't offer the same degree of low-level hardware control and memory manipulation. And yet, developers flock to them, and continue to do so. Why? A simple reason -- the reason computers exist is to automate repetitive operations far more quickly and efficiently than humans could, and Java, Perl, Python, and other higher-level languages put more of the burden of things like memory allocation (which are repetitive, uninteresting ops) on the system, rather than the developer, leaving the developer free to actually implement something that works in a fraction of the time.
And what is this 'hundreds of dollars' that programmers are paying to use Java? I have written several commercial Java applications, and even more non-commercial ones, and never once encountered a requirement that I pay a licensing fee for a basic Java runtime environment or libraries.
My only hope is that your second-to-last paragraph indicates a sense of irony, and that your entire posting was intended to be taken a a single large sarcastic wisecrack.
JSP/ASP (with or without version numbers, plus signs, etc.) are:
The fact that Corel has signed an agreement with Microsoft to be port the .NET framework if Microsoft requests it does not impress me. Microsoft could do the exact same thing, if they liked -- they have more programmers than most anyone, and Linux is not so complex that a decent development and runtime environment couldn't be hacked together in a matter of a few months.
Lastly, Java is not interpreted! The first-generation JVMs treated the bytecode like an interpreted language, but the more recent high-performance JIT environments (as well as native compilers, like gcj) remove that bottleneck, while still allowing for compatibility on systems that don't have (or want) native compilation.
The goal of .NET is to perpetuate the lock-in that they've had on RAD tools (and the projects created with them) by preventing the mass exodus away from VB and VC++ that would otherwise be inevitable in the next few years. Yes, distributed objects, transactions, and inheritance will be available to users of those coding in a number of different languages, but that's simply the effects of using XML as a universal exchange protocol, not some mystic MS voodoo.
Of course, it makes good business sense, and if there's anything MS doesn't consistently screw up, it's business. PHBs will eat this shit up, and I forsee a long, dark winter for would-be liberators trying to urge their employers away from MS-specific development environments, langauges, and tools.
However, Java on the server makes sense, and works consistently. I write J2EE apps for a living, and I can tell you with confidence that code that I write that relies on nothing but pure Java will run reliably on Solaris, Windows, and Linux at minimum, UNIX, and if I play it safe with my choice of runtime libraries (not core language or logic, just convenience classes), on MacOS, BSD, AIX, Tru64, HP/UX, OS/390, and a few others that I'm forgetting at the moment.
Don't get me wrong -- Perl is great. The minute you start taking advantage of your 'closer access to the OS', though, you restrict yourself to a small subset of the possible environments it runs on (POSIX is not universal).
The last means of accessing COM objects from Java I worked was the Visual J++ COM "compiler," which put references to all the Windows-native calls into comment blocks in your Java source, and added the low-level code at compile time. Not exactly pleasant to debug, and completely non-portable.
Remeber, there are a lot of genes in our DNA that don't do anything in most people -- they may code proteins that predecessor speceis used, or they may simply not be activated. In order to add caffeine synthesis to the human body's bag of tricks, you would not only need to add the gene that describes the synthetic process (which would undoubtedly be very, very different in a mallaian body than in a plant), you would need to set up an entire production system. That means either "hacking" a custom gland, tapping the resources of an existing one, generating it in various cells throughout the body, etc.
Every one of these changes carries the risk of causing all kinds of nasty chemical imbalances, genetic defects, or just plain wierd side effects completely independent of increased caffeine levels. I for one will not be jumping in to have by DNA tweaked anywhere near that drastically until the study of human genetics and biochemistry is significantly further along.
Just think: if things had gone a little differently, you could be calling dopamine 'endophetam', or serotonin 'endobanis'...
This may be changing as their culture becomes increasingly Westernized, but I wonder how many other parts of the world have never really included tipping as a part of their heritage.
Caffeine, though, is sort of a special case. Unlike the "classic" stimulants such as amphetamine, cocaine, or ephedra, it does not have a dramatic effect on dopamine or epinephrine (adrenaline) levels in the CNS. Instead, it increases calcium ion transfer in the nervous system, effectively lowering the threshold for a signal to get through. Every nerve cell in your body simply becomes more active, but continues carrying more or less the same data as before.
Think of it this way: Most drugs work like new components in a computer, such as a processor or drive. Just like a processor upgrade, or new sound card, they fundamentally alter the way it operates, and may or may not be totally compatible with the rest of the system. Caffeine, on the other hand, is much more like overclocking the system bus. None of the data being transferred changes, but it moves at a faster rate from place to place.
Unfortunately, just like OC'ing a machine, caffeinating your body doesn't do wonders for its reliability. Sometimes those nerve cells really don't take well to being pushed harder, and the signals start getting noisy while passing from place to place. Hence, the random tics and changes in mental state that accompany ecessive use of caffeine.
Not that I would have it any other way, mind you...
The "runner's high" is an adaptation designed to allow people's bodies to continue to operate under extreme duress -- the endorphins help counteract the physical pain and psychological stresses of difficult activities.
Caffeine, on the other hand, jacks the body up. It increases nervous system activity throughout the body by basically lowering the threshold for signals passing between nerve cells. It's "enjoyable" effects are largely conditioned response, as people learn to expect and appreciate the perceived increase in their mental and physical energy levels.
Drinking coffee is "just doing drugs," albeit in a socially acceptable and ritualistic fashion. Many "hard" drug users have an equal amount of daily ritual to their usage, and probably gain similar psychological imprinting. If you want to make caffeine a more "natural" reward, then trigger its release only after certain phsyical criteria are met, just as endorphins are only released when the body has a reason for it.
However, the body already has a similar response in its use of adrenaline (or epinephrine to you Europeans out there). It would be difficult to find situations in which caffeine was a more physically useful stimulant, especially since its use carries at least as many (arguably worse) side effects as adrenaline.
Palm OS...feels like Mac OS ten years ago...
Seriously, though, how elaborate a development environment do you need for a device with the size and complexity of a Palm? You can use Codewarrior or gcc for full-blown app coding, or you can use Jump, LispMe, or any number of other almost-there-environments for RAD and prototyping.
The reason for the high cost of the data discs, and Sony's reluctance to develop anything other than the audio format, is licensing fees. Right now, they own the rights to the compression scheme used on MDs, and anyone who wants to market a compatible recorder, player, or disc has to pay them for the privelage. If Sony were to start pushing MD-Data, they could lose that revenue per unit, since people would simply be putting whatever data they chose onto the discs.
Sony has repeatedly come up with decent compact storage formats. They also often build integrated compression and encryption in at the hardware interface level for that format. So long as all you use is Sony (or Sony-licensed) hardware, you're all set. However, if you want to migrate away from that platform...you're screwed. Under the DMCA, accessing your data that's been compressed and encrypted in a Sony-owned format with anything other than an authorized Sony product is reverse engineering, and you can be arrested.
A-1: A profit-seeking private corporation.
Q-2: Why would they use Linux?
A-2: Cheap, realiable, customizeable OS available for a variety of hardware.
Q-3: Why do most /.'ers run Linux?
A-3: See answer #2.
Q-4: What has HP taken away from open source?
A-4: A free license to use Linux.
Q-5: What do most /.'ers take away from open source?
A-5: See answer #4.
Q-6: What has HP given back to the open source community?
A-6: Some code, another high-profile Linux-based product, and more validity in the market.
Q-7: What does the average /.'er give back to the open source community?
A-7: Some code, perhaps a few low- to medium-profile Linux-based products, and evangalism in the market.