Re:Scripting languages and archives
on
Tomcat 5.0 Released
·
· Score: 3, Interesting
Packages, as a namespace boundary separating functional areas of a program, do add a nice chunk of metadata for compilers and debuggers to work with. PHP, by throwing everything into one giant flat namespace, reminds me far too much of C -- in other words, fine if you're dealing with legacy code that uses it, but not exactly where I want to be if I'm trying to be produce quality code.
However, I think that the runtime cost of interpreting a handful of source scripts for each webapp request is really quite minor compared to, say, the cost of opening a connection to a remote service, (RMI/EJB, SQL server, or whatever) marshalling and unmarshalling a series of data structures over that socket connection, generating return text from a template, and all the other work that makes up dynamic web page construction.
Pre-compiled modules are much more important for efficient distribution and deployment of code than they are for its execution. Being able to package an entire application into a single network-transferrable file is by far the most useful contribution of the Servlet container specs -- just drop that WAR file into your apps directory, and off you go.
Have you used a normal BSD installation? Think console/shell at startup (nice full-screen framebuffer-based one, though, at least on PPC), and XWindows for your choice of desktop environments.
Of course, you've got effectively the NeXTStep/OpenStep/OS X system environment, which means Frameworks, NetInfo, etc., are all in there, along with a Mach-based kernel-land environment, which is fairly opaque at the user level.
I actually worked on a ~500pg. documentation project with a couple of other developers a couple of years back, and after about six months of debate, they finally agreed to let me recode the thing from TeX to DocBook XML.
The conversion was a PITA, but once that was finished, we had about 40 source XML files which were independently version-controlled, some minor customizations to the standard DocBook XSLT stylesheets, and slick, easily-updated HTML, plain text, and PDF versions of the document being produced straight out of CVS by a cron job.
A nice benefit of the conversion was that we were actually able to add another few hundred pages of documentation that was automatically generated from grammar definitions and source code to the batch build, and they could be integrated into the style and distribution methods we worked out for the hand-generated docs.
Unfortunately, "embedded" covers everything from headless PCs controlling industrial systems to system-on-chip devices that need to run on the same battery for 3 years.
On the large end, as others have suggested, you can just use a standard PC for development and prototyping. At the other extreme, you're probably going to want to just buy a packaged system like a uCdimm -- LinuxDevices has a good list.
In the middle, though, I've had good experiences with the OpenBrick; it's basically just a low-env VIA EPIA system, with onboard graphics, Ethernet, USB, etc. I actually ran one for lightweight web and MP3 serving for about a year, with it stuffed in between stacks of books on a shelf, and just the network and power cables running out the back.
Get one high-quality, reasonably-fast server box. Maybe two, if you've got the cash. Install a good UPS, RAID array, and backup drive (tape, CD-R, whatever). That box will run server daemons for POP/IMAP, NFS/SMB (for home directories), and whatever web-based business apps (timecard system, issue tracker, whatever) they need.
Then, accept whatever client systems you can get that will boot from CD with at least SVGA graphics support, and run everything as a "thick" client. Rip out the hard drives, or use them for little more than swap, browser cache, and tempfiles. When a client machine dies, don't troubleshoot it, just replace it with another one from the pile in the closet. Depending on the size of the office and resource requirements of the apps they use,
Yes, the whole system takes some setup. Once it gets running, though, the whole system should require about as much maintenance as your average web server. And the client systems are completely disposable.
I've played Warcraft III and Black & White on a 12" PB quite a bit, and it kept up nicely. The iBook will suffer a small performance penalty across the board, (slightly slower bus, less L2 cache, etc.) but you should still be able to get 30+ FPS if you play with the resolution and detail settings a bit.
Also, the iBook *should* have one serious advantage for extended gaming sessions: its plastic enclosure should transfer much less heat into the lap and hands of anyone using it. The 12" gets almost painfully warm after a couple of hours.
This is a pretty weird definition of "on the net". When I use my cable modem at home, I'm "tunneling" through the neighborhood cable infrastructure, into Comcast's network, then out through a backbone connection to the net. Or, if I'm at one of the free wireless nodes downtown, I'm "tunneling" through the wireless network, into some wired LAN, and finally onto a DSL or T1 connection to an ISP.
The whole point of TCP/IP is that it doesn't matter what kind of network you're connected through, so long as it implements the protocol correctly. See previous/. articles about TCP/IP using bongos -- it may be one of the slowest endpoints ever, but slap those drummers on a routable IP, and they're suddenly full-fledged Internet nodes.
...or you're using more than one OS on the same machine. I've routinely had as many as four different bootable partitions on my workstation, often running completely different operating systems (Linux, Net/OpenBSD, Win2k, BeOS R5).
Is it strictly necessary? No. Is it a big part of how I've learned to code for and support all of those systems? Yes. Would I like to shave a minute or two off every Linux boot time? Definitely.
Even if you're using Linux boxen purely in a server environment, having parellelized startup of system services could be a big win: if your SSH daemon could start up before or in parallel with log rotation, hardware monitoring (devfsd, kudzu, etc.), etc., you could log back on to the server that just rebooted much more quickly. I know, in an ideal world, you'd never have to reboot a production system, but we live in the world of failing hard drives and power supplies.
I actually thought about this idea some time back, when everyone started started clearing out refurb Handspring Visor models for less than $50. Add some sort of wireless, and appropriate add-ons for tasks like lab data acquisition or sound output, and you have an all-purpose educational computing tool.
Software development on that kind of device is still a huge pain, though. Think about it: how many developers do you know who work on anything less than the largest (either in size or number) available display surface they can? The information visibility needed for real coding is just too high to fit well onto a palmtop's display.
Now, resurrect HyperCard as a PalmOS app, and we can talk.
I don't agree that keyboards are more intuitive -- familiar, yes, but hardly a natural exercise for young students who may well still be working on their handwriting.
I agree that trying to do any significant amount of data entry or editing on a palmtop becomes frustrating quickly; however, I think that's much more a product of their small form factor than any inherent design problems.
If you want to see where this could go, just look at the eMate -- Apple took a standard Newton mobo and display and packaged it up with a keyboard in a compact, ruggedized enclosure. And they were even targetted to schools.
True, they were a market failure, but largely for the same reasons the original Newton was: they were trying to create a market that didn't exist yet, the technology was too new, and therefore too expensive, etc. It's a very different marketplace now, even in the educational sector.
...and that would work fine, as long as you didn't have to entrust your employees with any sort of creativity. Understanding the potential and limitations of the technology you're working with is essential in extending or applying it in innovative ways.
So basically, while most technology work is indeed better done with the use of pre-existing tools, the most important and ground-breaking work requires a little more flexibility and experimentation than that.
You write a translation script, the same way you would handle the move to a new production schema, or from one RDBMS vendor to another. And of course, since anyone so concerned about future-proofing their code would insure their business logic is using a nice polymorphic OO design, you'll be no more vulnerable to a change from Prevayler to JDO or another O/R mapping tool than you would be to schema changes.
First off, SQL is an idealized, functional language for querying large datasets -- in theory, you can run any imaginable query, but in reality, you can't touch an un-indexed field on most production databases unless you've got *lots* of horsepower to burn, and very patient (read: non-existent) users. Personally, I find that there are a pretty large number of queries that are also pretty difficult to write in SQL.
Really, it's not that different from the procedural-vs-functional or static-vs-dynamic typing issues in language design: a holy war that no one's going to win, except for the developers who learn to adopt the best pieces from each side without making dire claims about the imminent death of either side.
If you've ever worked in a help-desk or other support environment, you see that training is not the last word in indirect costs for software decisions. The amount of training required to move to Evolution or OpenOffice is really not significantly more than you need to move users to a new version of the equivalent Microsoft app.
It's not a definite win, and certainly something that would be difficult to do for everyone overnight, but you need your IT staff for something after all those thin clients get rolled out, right?
Having worked in thin-client (mostly Solaris XWindows servers, and Windows/Linux clients) and normal workstation-based environments, the thin-clients are definitely easier, cheaper, and faster to administer, and the advantages only increase as the number of users do.
Think of it this way: maintaining one server is a hell of a lot easier than maintaining 100 regular Windows systems, even if you just ghost each of them at the slightest sign of problems -- short of hardware failures on either the server (which should have high-quality, largely redundant components) or the client, (which is a power-efficient, low-temperature, sometimes even diskless system) you should be able to keep things running smoothly with very little intervention.
However, standalone workstations offer a few things that thin clients don't: customizability, top-notch graphics performance, and offline operation. Also, many users don't do a good job of seperating their idea of the software used on their computer, and the physical object itself, and it can be confusing or even bothersome to have the box removed or replaced at the first sign of trouble.
"Intellectual property" is no more real than cash, and similar in purpose: an agreed-upon convenience used to represent and transfer resources. Consentual shared hallucinations are still hallucinations.
However, if I make a copy of your book after you've started distributing it, it costs you nothing. Therefore, describing the outcome as theft is rediculous -- you still have your book, and now I have one, too. In fact, having additional copies of your work in circulation should bring you additional future rewards, as later works will be more highly valued.
In the US, and other developed nations, all of that may be true; however, in the developing world, you could probably find quite a few farmers, disease-sufferers, etc., who would argue with you. The nations that need economic support and free-trade agreements are forced to accept WIPO rules governing their IP laws, and therefore to immediately put valuable genetic, pharmeceutical, and telecommunications tech out of the reach of most of their population.
When I was in high school, my summer extra-credit homework from my Japanese language class was to beat a Japanese-language version of some Squaresoft RPG (don't remember which one, unfortunately). Needless to say, I had the coolest Japanese teacher of all time.
In short, though, some of us are more than willing to struggle through a few unfamiliar kanji in search of a new gaming experience, and I for one would be happy to have the opportunity to work through a few Japanese PS2 games, as well as start messing around with non-Sony-provided Linux boot discs.
OS X is, despite Apple's best engineering and marketing efforts, still not an operating system I would entrust a production system to. First and foremost, you have one and only one major vendor for rackmount server systems, (the XServe, from Apple) one major support vendor, (again, Apple) and one hardware repair and parts source (guess who?).
Beyond that, you have a microkernel system design which, while very interesting from a systems-architecture POV, has never proven itself to be a serious competitor in the performance world, along with a primary vendor focused on consumer applications. The last nail in the coffin is probably Apple's the lack of past experience in high-availability systems of any kind.
For personal workstations and laptops, I'm an Apple fan all the way, (and have two PowerBooks, an iMac, and a G4 tower in my home for just that reason) but I just don't think that the XServe (much less the G5, which far too few people have even seen in person to make any kind of judgement on its usability as a critical server) has proven itself sufficiently bullet-proof for any purpose outside of renderfarms or scientific clusters.
I personally consider "modern hardware" to be anything above a PII, and with an ATA (rather than just IDE) disk interface -- i.e., about 85% of computing hardware sold in the last 5 years. Solaris x86 is a complete joke compared to Linux or *BSD in terms of flexibility, support options, and performance.
Sun distributes and supports Solaris for Intel platforms because their big enterprise customers don't want to pay for Sun hardware to go on the desk of every developer, not because it's a competitive OS.
Just look at the plight of the JBoss or Tomcat developers when they started looking for J2EE certification -- Sun's entire revenue model for enterprise Java was based around the idea that only six-figure-license-cost server packages would ever seek that kind of endorsement, and so open source packages were left out in the cold.
Personally, I would be more than happy to deploy a production system on top of MySQL or Postgres instead of Oracle or DB2, since the licensing and support contracts for one mid-sized database installation of one of the major vendors could support several full-time developers on the open-source database of my company's choice.
For production systems, you want full-time admin planning and support, whether you're using major a commercial package or a totally home-grown system. Once you've invested that level of resources, I think that open source packages give you a flexibility and freedom that more than make up for the lack of glossy promotional material and overpriced support contracts that a BigCo offers.
Slashdot Mirror
Packages, as a namespace boundary separating functional areas of a program, do add a nice chunk of metadata for compilers and debuggers to work with. PHP, by throwing everything into one giant flat namespace, reminds me far too much of C -- in other words, fine if you're dealing with legacy code that uses it, but not exactly where I want to be if I'm trying to be produce quality code.
However, I think that the runtime cost of interpreting a handful of source scripts for each webapp request is really quite minor compared to, say, the cost of opening a connection to a remote service, (RMI/EJB, SQL server, or whatever) marshalling and unmarshalling a series of data structures over that socket connection, generating return text from a template, and all the other work that makes up dynamic web page construction.
Pre-compiled modules are much more important for efficient distribution and deployment of code than they are for its execution. Being able to package an entire application into a single network-transferrable file is by far the most useful contribution of the Servlet container specs -- just drop that WAR file into your apps directory, and off you go.
Have you used a normal BSD installation? Think console/shell at startup (nice full-screen framebuffer-based one, though, at least on PPC), and XWindows for your choice of desktop environments.
Of course, you've got effectively the NeXTStep/OpenStep/OS X system environment, which means Frameworks, NetInfo, etc., are all in there, along with a Mach-based kernel-land environment, which is fairly opaque at the user level.
See the x86 hardware database at http://www.opendarwin.org/hardware/
The link was about half-way through the announcement.
I actually worked on a ~500pg. documentation project with a couple of other developers a couple of years back, and after about six months of debate, they finally agreed to let me recode the thing from TeX to DocBook XML.
The conversion was a PITA, but once that was finished, we had about 40 source XML files which were independently version-controlled, some minor customizations to the standard DocBook XSLT stylesheets, and slick, easily-updated HTML, plain text, and PDF versions of the document being produced straight out of CVS by a cron job.
A nice benefit of the conversion was that we were actually able to add another few hundred pages of documentation that was automatically generated from grammar definitions and source code to the batch build, and they could be integrated into the style and distribution methods we worked out for the hand-generated docs.
Unfortunately, "embedded" covers everything from headless PCs controlling industrial systems to system-on-chip devices that need to run on the same battery for 3 years.
On the large end, as others have suggested, you can just use a standard PC for development and prototyping. At the other extreme, you're probably going to want to just buy a packaged system like a uCdimm -- LinuxDevices has a good list.
In the middle, though, I've had good experiences with the OpenBrick; it's basically just a low-env VIA EPIA system, with onboard graphics, Ethernet, USB, etc. I actually ran one for lightweight web and MP3 serving for about a year, with it stuffed in between stacks of books on a shelf, and just the network and power cables running out the back.
Probably not with a tomato, given the distance of the plants; however, you might have pretty good luck with hops.
No confusion necessary -- it's a damn strong Go position, as well, so even the mis-interpretation gives a positive impression.
Get one high-quality, reasonably-fast server box. Maybe two, if you've got the cash. Install a good UPS, RAID array, and backup drive (tape, CD-R, whatever). That box will run server daemons for POP/IMAP, NFS/SMB (for home directories), and whatever web-based business apps (timecard system, issue tracker, whatever) they need.
Then, accept whatever client systems you can get that will boot from CD with at least SVGA graphics support, and run everything as a "thick" client. Rip out the hard drives, or use them for little more than swap, browser cache, and tempfiles. When a client machine dies, don't troubleshoot it, just replace it with another one from the pile in the closet. Depending on the size of the office and resource requirements of the apps they use,
Yes, the whole system takes some setup. Once it gets running, though, the whole system should require about as much maintenance as your average web server. And the client systems are completely disposable.
I've played Warcraft III and Black & White on a 12" PB quite a bit, and it kept up nicely. The iBook will suffer a small performance penalty across the board, (slightly slower bus, less L2 cache, etc.) but you should still be able to get 30+ FPS if you play with the resolution and detail settings a bit.
Also, the iBook *should* have one serious advantage for extended gaming sessions: its plastic enclosure should transfer much less heat into the lap and hands of anyone using it. The 12" gets almost painfully warm after a couple of hours.
This is a pretty weird definition of "on the net". When I use my cable modem at home, I'm "tunneling" through the neighborhood cable infrastructure, into Comcast's network, then out through a backbone connection to the net. Or, if I'm at one of the free wireless nodes downtown, I'm "tunneling" through the wireless network, into some wired LAN, and finally onto a DSL or T1 connection to an ISP.
/. articles about TCP/IP using bongos -- it may be one of the slowest endpoints ever, but slap those drummers on a routable IP, and they're suddenly full-fledged Internet nodes.
The whole point of TCP/IP is that it doesn't matter what kind of network you're connected through, so long as it implements the protocol correctly. See previous
...or you're using more than one OS on the same machine. I've routinely had as many as four different bootable partitions on my workstation, often running completely different operating systems (Linux, Net/OpenBSD, Win2k, BeOS R5).
Is it strictly necessary? No. Is it a big part of how I've learned to code for and support all of those systems? Yes. Would I like to shave a minute or two off every Linux boot time? Definitely.
Even if you're using Linux boxen purely in a server environment, having parellelized startup of system services could be a big win: if your SSH daemon could start up before or in parallel with log rotation, hardware monitoring (devfsd, kudzu, etc.), etc., you could log back on to the server that just rebooted much more quickly. I know, in an ideal world, you'd never have to reboot a production system, but we live in the world of failing hard drives and power supplies.
I actually thought about this idea some time back, when everyone started started clearing out refurb Handspring Visor models for less than $50. Add some sort of wireless, and appropriate add-ons for tasks like lab data acquisition or sound output, and you have an all-purpose educational computing tool.
Software development on that kind of device is still a huge pain, though. Think about it: how many developers do you know who work on anything less than the largest (either in size or number) available display surface they can? The information visibility needed for real coding is just too high to fit well onto a palmtop's display.
Now, resurrect HyperCard as a PalmOS app, and we can talk.
I don't agree that keyboards are more intuitive -- familiar, yes, but hardly a natural exercise for young students who may well still be working on their handwriting.
I agree that trying to do any significant amount of data entry or editing on a palmtop becomes frustrating quickly; however, I think that's much more a product of their small form factor than any inherent design problems.
If you want to see where this could go, just look at the eMate -- Apple took a standard Newton mobo and display and packaged it up with a keyboard in a compact, ruggedized enclosure. And they were even targetted to schools.
True, they were a market failure, but largely for the same reasons the original Newton was: they were trying to create a market that didn't exist yet, the technology was too new, and therefore too expensive, etc. It's a very different marketplace now, even in the educational sector.
...and that would work fine, as long as you didn't have to entrust your employees with any sort of creativity. Understanding the potential and limitations of the technology you're working with is essential in extending or applying it in innovative ways.
So basically, while most technology work is indeed better done with the use of pre-existing tools, the most important and ground-breaking work requires a little more flexibility and experimentation than that.
You write a translation script, the same way you would handle the move to a new production schema, or from one RDBMS vendor to another. And of course, since anyone so concerned about future-proofing their code would insure their business logic is using a nice polymorphic OO design, you'll be no more vulnerable to a change from Prevayler to JDO or another O/R mapping tool than you would be to schema changes.
First off, SQL is an idealized, functional language for querying large datasets -- in theory, you can run any imaginable query, but in reality, you can't touch an un-indexed field on most production databases unless you've got *lots* of horsepower to burn, and very patient (read: non-existent) users. Personally, I find that there are a pretty large number of queries that are also pretty difficult to write in SQL.
Really, it's not that different from the procedural-vs-functional or static-vs-dynamic typing issues in language design: a holy war that no one's going to win, except for the developers who learn to adopt the best pieces from each side without making dire claims about the imminent death of either side.
If you've ever worked in a help-desk or other support environment, you see that training is not the last word in indirect costs for software decisions. The amount of training required to move to Evolution or OpenOffice is really not significantly more than you need to move users to a new version of the equivalent Microsoft app.
It's not a definite win, and certainly something that would be difficult to do for everyone overnight, but you need your IT staff for something after all those thin clients get rolled out, right?
Having worked in thin-client (mostly Solaris XWindows servers, and Windows/Linux clients) and normal workstation-based environments, the thin-clients are definitely easier, cheaper, and faster to administer, and the advantages only increase as the number of users do.
Think of it this way: maintaining one server is a hell of a lot easier than maintaining 100 regular Windows systems, even if you just ghost each of them at the slightest sign of problems -- short of hardware failures on either the server (which should have high-quality, largely redundant components) or the client, (which is a power-efficient, low-temperature, sometimes even diskless system) you should be able to keep things running smoothly with very little intervention.
However, standalone workstations offer a few things that thin clients don't: customizability, top-notch graphics performance, and offline operation. Also, many users don't do a good job of seperating their idea of the software used on their computer, and the physical object itself, and it can be confusing or even bothersome to have the box removed or replaced at the first sign of trouble.
"Intellectual property" is no more real than cash, and similar in purpose: an agreed-upon convenience used to represent and transfer resources. Consentual shared hallucinations are still hallucinations.
However, if I make a copy of your book after you've started distributing it, it costs you nothing. Therefore, describing the outcome as theft is rediculous -- you still have your book, and now I have one, too. In fact, having additional copies of your work in circulation should bring you additional future rewards, as later works will be more highly valued.
In the US, and other developed nations, all of that may be true; however, in the developing world, you could probably find quite a few farmers, disease-sufferers, etc., who would argue with you. The nations that need economic support and free-trade agreements are forced to accept WIPO rules governing their IP laws, and therefore to immediately put valuable genetic, pharmeceutical, and telecommunications tech out of the reach of most of their population.
When I was in high school, my summer extra-credit homework from my Japanese language class was to beat a Japanese-language version of some Squaresoft RPG (don't remember which one, unfortunately). Needless to say, I had the coolest Japanese teacher of all time.
In short, though, some of us are more than willing to struggle through a few unfamiliar kanji in search of a new gaming experience, and I for one would be happy to have the opportunity to work through a few Japanese PS2 games, as well as start messing around with non-Sony-provided Linux boot discs.
OS X is, despite Apple's best engineering and marketing efforts, still not an operating system I would entrust a production system to. First and foremost, you have one and only one major vendor for rackmount server systems, (the XServe, from Apple) one major support vendor, (again, Apple) and one hardware repair and parts source (guess who?).
Beyond that, you have a microkernel system design which, while very interesting from a systems-architecture POV, has never proven itself to be a serious competitor in the performance world, along with a primary vendor focused on consumer applications. The last nail in the coffin is probably Apple's the lack of past experience in high-availability systems of any kind.
For personal workstations and laptops, I'm an Apple fan all the way, (and have two PowerBooks, an iMac, and a G4 tower in my home for just that reason) but I just don't think that the XServe (much less the G5, which far too few people have even seen in person to make any kind of judgement on its usability as a critical server) has proven itself sufficiently bullet-proof for any purpose outside of renderfarms or scientific clusters.
I personally consider "modern hardware" to be anything above a PII, and with an ATA (rather than just IDE) disk interface -- i.e., about 85% of computing hardware sold in the last 5 years. Solaris x86 is a complete joke compared to Linux or *BSD in terms of flexibility, support options, and performance.
Sun distributes and supports Solaris for Intel platforms because their big enterprise customers don't want to pay for Sun hardware to go on the desk of every developer, not because it's a competitive OS.
Amen, brother.
Just look at the plight of the JBoss or Tomcat developers when they started looking for J2EE certification -- Sun's entire revenue model for enterprise Java was based around the idea that only six-figure-license-cost server packages would ever seek that kind of endorsement, and so open source packages were left out in the cold.
Personally, I would be more than happy to deploy a production system on top of MySQL or Postgres instead of Oracle or DB2, since the licensing and support contracts for one mid-sized database installation of one of the major vendors could support several full-time developers on the open-source database of my company's choice.
For production systems, you want full-time admin planning and support, whether you're using major a commercial package or a totally home-grown system. Once you've invested that level of resources, I think that open source packages give you a flexibility and freedom that more than make up for the lack of glossy promotional material and overpriced support contracts that a BigCo offers.