High traffic sites, the ones that are really dynamic anyway, do more than that.
They start with a load balancer at the front end, or possibly several layers of load balancer. If they run a distributed operation they'll use smart DNS systems or routers to direct requests to the most local server cluster. The server cluster will be fronted by a request scattering system.
Behind the request scattering system you'll find a cluster of machines whose job it is to serve static content (often the bulk of data served by a site) and route dynamic requests to another cluster of servers, enforcing session affinity for the dynamic requests.
Behind the static content servers are the application servers. They do the heavy lifting, building dynamic pages as appropriate for individual users and caching everything they can to offload the database.
Behind the application servers is the database or database cluster. The latter is really not that useful if you have a highly dynamic site as there are problems with data synchronization in database clusters (no matter what the database vendors tell you). But that's ok, single databases can handle a lot of volume if built correctly and caching is done appropriately at the application level.
And there you have it, the structure of a really large site.
As you say, databases are usually the bottleneck in a high-volume site. Contrary to what Oracle et al want you to believe, they still don't scale and in many cases it's not feasible to use a database cluster.
Big sites, really big sites, put caching in the application. The biggest thing to cache is session data, easy if you're running a single box but harder if you need to cluster (and you certainly do need to cluster if you're talking about a high-volume site; nobody makes single machines powerful enough for that). Clustering means session affinity and that means more complicated software. (Aside: Is there any open source software that manages session affinity yet? )
Frankly speaking, Intel-based hardware would not be my first choice for building a high-volume site (although "millions of page views per month" is really only a moderate volume site; sites I have worked on do millions per/day/). It would probably be my third or fourth choice. The hardware reliability isn't really the problem, it can be good enough, the issue is single box scalability.
To run a really large site you end up needing hundreds or even thousands of Intel boxes where a handful of midrange Suns would do the trick, or even just a couple of high-end Suns or IBM mainframes. Going the many-small-boxes route your largest cost ends up being maintenance. Your people spend all their time just fixing and upgrading boxes. Upgrading or patching in particular is a pain in the neck because you have to do it over such a broad base. It's what makes Windows very impractical as host for such a system; less so for something like Linux because of tools like rdist, but even so you have to do big, painful upgrades with some regularity.
What you need to do is find a point where the box count is low enough that it can be managed by a few people and yet the individual boxes are cheap enough that you don't go broke.
These days the best machines for that kind of application are midrange Suns. It will probably be a couple of years before Intel-based boxes are big and fast enough to realistically take that away... not because there isn't the hardware to do it (though such hardware is, as yet, unusual) but because the available operating systems don't scale well enough yet.
I would agree if the interface was dumbed down to make the touch screen useful. It would also help if you have smaller fingers (such as children), which would allow you to use smaller interface elements.
Sorry, by "touchscreen" I didn't necessarily mean that you touched the screen with your fingers. A stylus is entirely acceptable... like that of Palm boxes. The point (ha-ha) is that there's a direct association between what you see and what you interact with, whereas with a mouse it's indirect.
I entirely agree that some mouse-style operations such as drag-and-drop don't work well in a touchscreen paradigm, so don't use them. I do not agree that low-resolution is necessary for touch screens any more than it is for mice; I've personally used touchscreens with resolutions over 4k on a side (for interacting with satellite imagery).
The first system I ever used with a mouse was an Apple IIgs, which came with a little game that taught you how to use the mouse. I picked it up in less than 2 hours, and I don't think I was 10 years old at the time.
I had a similar experience, so I never thought it was a problem... until my in-laws were trying to learn to use a computer. They had severe motor control problems -- it was hard for them to get the pointer onto what they wanted without looking at the mouse, it was hard for them to click without moving the pointer, and the whole concept of drag-and-drop took a long time for them to pick up. This, unfortunately, seems to be the norm amongst people rather than the exception. Go to beginner computer courses and watch them! Mice are pretty hard to use.
I'd buy a proper tablet & stylus which is sensitive enough for those tasks (not to mention that the pen interface is familiar enough to those that draw on paper)
It's exactly this kind of interface that I'm suggesting. They are vastly easier to use than mice or trackballs (BTW, I too find the trackball to be ergonomically superior). With CRTs such an interface posed similar problems to the mouse: less motor control issues (since you probably already know how to write) but very difficult hand/eye coordination because you're watching the screen but manipulating the stylus on a separate pad. I never did get the hang of that. With flat screen panels being all the rage today there's no reason we can't apply a touchscreen to the flat screen and use it as a tablet interface.
We know those systems work... after all, there are some thirty million palmtops out there that use such an interface.
I have a two year old daughter. Almost a year ago, I gave her a computer. She picked up the use of the keyboard within a couple of days (she's using a simplified version with fewer and larger buttons) and within a couple of months exhausted the options available with the learning software that came with the keyboard.
We got new software that requires mouse interaction. It's been about six months and she's still not self-sufficient with the mouse, although she knows her way around the software quite well.
Some friends bought her a touchpad learning book (a Leap Pad) about a month ago. This uses a special pen to direct software by touching spots on a book. She picked up how to interact with the book in about two hours, which included learning that she had to push a particular spot on each page when she turned to it so that the computer would stay synchronized with the book.
Touch screens are, in my opinion, vastly easier to use than mouse-based systems. Motor control necessary for the mouse is difficult to learn; not only for children, but also for adults. It takes weeks or months for an adult to become adept with a mouse, and many never do for particularly fine tasks (like drawing). This is made all the harder by the idiocy of using hieroglyphics as a user interface design element in mouse-based interfaces.
Actually there was no breakdown on September 11. The tools they used to take over the plane were allowed at the time, and really aren't that big of a threat anyway. If the box cutters had been found by security they would have allowed them to pass. Security was interested in massively destructive weapons (explosives, guns) because those were what were considered to be threats, and no such weapons made it through security on September 11.
What the hijackers did that was special was take advantage of the psychology that had been drilled into airline passengers over decades, namely that if there's a hijacking you stay put and let it play itself out. That allowed a small number of hijackers to control a large number of people using primitive weapons that otherwise would not have been much of a threat.
This worked in the past because previously hijackers weren't committing suicide, and live passengers were to their benefit. The September 11 hijackers were playing by different rules.
In being successful at it they changed the psychology of airline passengers. We will not see another September 11 because the passengers will no longer sit around and let hijackers have their way. In fact, the technique didn't even last out the day... as proven by the crash of the flight in Pennsylvania, and later by the shoe bomber. We could use exactly the same security procedures we used, with the same effectiveness, as before September 11 and such an attack would not succeed today.
It's easy to blame the airline security people, but this was really an exploitation of mass psychology... a social engineering hack if you will.
I think he has a big misconception as to how design work happens with open source. It isn't the whole internet getting together to decide what is the best way to do things. If that were the case nothing would ever get done at all. Rather, open source is more of a democracy deciding which of many dictatorships should win.
In other words, we have many independent developers who each exercise complete control over whatever they're building, many of whom are building things that compete with other versions of the same thing. The version most people use wins.
Whether or not this is going to result in more usable software is debatable, but one way to become popular is to be easier to use than the next guy.
It's nice that the car is fast, but really
the performance if EVs is limited to power
output, not technology. If you want a really
fast EV use more or more powerful batteries or
shed weight... no surprises there, and no
funky new technology needed. We can make an
EV as fast as an IC car without a lot of
trouble, but it won't have much range.
In my mind the practicality of these vehicles,
independent of cost, revolves around the range versus recharge
cycle. If it takes more than a few minutes to
do a recharge, and the range is less than a
thousand miles, then they're just not good enough
for a general-purpose vehicle.
This is why hybrids are interesting... recharge
cycle is a tank fill.
What I'm waiting for is someone to look at making
a hybrid where the engine is always on, always
producing power, but the generator is producing
a bit more power than the thing normally will need
and charging a capacitor stack rather than
batteries. That gives you acceleration (for
awhile) but is much lighter and cheaper than
batteries and since the engine is operating
efficiently all the time, and requires quite a
bit less power than if it were producing motive
power directly (eg a few hundred cc ought to do
a pretty good job) it should still be more
efficient.
Back before 802.11 was a standard my company installed Lucent APs and handed out a lot of laptops and wireless cards.
It made a huge impact on the usefulness of the computer equipment; probably the biggest immediate change was nearly eliminating paper from meetings.
I set up a wireless net at home pretty much concurrent with the work rollout; it changed the way I used computers at home, too. One of the first things I did with it was get play-by-play of a Red Sox game while my wife watched the Mets on TV, but it didn't take long before IMDB overwhelmed Maltin's too.
I suppose the funniest thing about this whole idea, to me, was that Java on IE was vastly more compatible with the Java standard than Java on Netscape. I mean, Netscape's Java implementation was horrible. If Sun had really be interested in standards they would have pulled Netscape's license rather than suing Microsoft.
I've been writing Java code since JDK 1.0. I've done plenty of work with standalone clients, applets, and servers since that time and with every release since then, and blaming Microsoft is just plain revisionist history.
Not only was Netscape's compatibility with the Java standard much much worse than Microsoft's (Sun sued over nits while Netscape had major API differences!), but it wasn't even compatible between versions of itself. Minor point releases had major points of incompatibility with each other, and the stability of the JVMs included with Netscape was very poor to say the least.
I know that's not the popular viewpoint, but anyone who wrote significant java code for the browser back then should recall how painful it was to deal with the Netscape Java flavor-of-the-week and how hard it was to work around the things that would take out the browser. We gave up and went back to HTML.
But I don't think it's fair to blame Java's death on the client entirely on Netscape either. Anyone remember what it was like to write client code with AWT? I'll tell you what it was like - it sucked. It took Sun two major JDK releases (1.1 and 1.2) to fix that with Swing, and Swing is such a pig that you need a pretty heavy client to run nontrivial applications.
So what we had was a GUI library that was not really very good for building clients and a major vendor who couldn't make a stable version or maintain compatibility either within its own releases or with the standard itself. And that's completely independent of Microsoft.
I think any chance of Java making it on the client was killed when Sun decided not to offer it originally as a plug-in. Had it been a plug-in then at least Sun could have controlled the quality and compatibility of the implementations on the street - across all browser vendors. Notice that Macromedia has done an excellent job of that with Flash.
Sun did, eventually, move to that design - but only after the war had been lost.
It might be nice to blame Java's client woes on Microsoft, but in all honesty - as much as I hate Microsoft - I can't do that. Java failed on its own demerits.
Sure, I used the Omnisky service for a couple of years. My take in brief: CDPD sucks.
They claim 19.2kbps; I rarely saw a quarter of that. But worse than that is the fact that you lose service if you're moving around very much... e.g. in a car or on a train. Coverage is poor, too, even in major urban areas (e.g. Boston and New York City).
I had hoped to use the service to expand the capabilities of the palmtop device by allowing remote access to deep datastores (the web, of course, but also mail archives and personal files). The reality was that it was too slow and unreliable to use for anything but short data bursts ala AvantGo. I could only use it for e-mail in emergency situations, and it was next to worthless for the web both because of performance and display limitations.
The 2.5G network Verizon is rolling out may have a better shot at it. With much higher data rates and presumably better handling of cell migration it might just be good enough. Until then I'm using 802.11 despite its short range. CDPD is a bust.
The cite is right, but the number isn't, at least not literally.
Page 30 of the original edition:
"Programming managers have long recognized wide productivity variations between good programmers and poor ones. But the actual measured magnitudes have astounded all of us. In one of their studies, Sackman, Erikson, and Grant were measuring performances of a group of experienced programmers. Within just this group the ratios between best and worst performance averaged about 10:1 on productivity measurements and an amazing 5:1 on program speed and space measurements! [...] The data showed no correlation whatsoever between experience and performance."
Practically speaking, however, you have to account for not only productivity but ongoing cost of product. If bug counts follow the same approximate number as program speed and space measurements, then the actual value received by the company is easily a factor of 100 better with the good programmer (since you reduce the load on support and maintenance organizations).
This certainly mirrors my experience.
Another thing that hasn't been emphasized enough in this commentary (I don't know about the book) is the effect of flow (not just that it exists). When you're in the flow, which I've always called "going under" because that's what it feels like, you can be hugely productive -- my multiplier is more than a factor of five. Without distractions some programmers can maintain that state for days on end (my longest was 96 hours straight, though runs of 24-48 hours are far more typical). I know some people who can do it for weeks. Maximizing the effectiveness of flow in your best programmers can easily make the difference between success and failure of a project. Thus one of the things that differentiates a good and a bad manager to me is that the good ones know when to leave you alone.
Lastly, an important consideration about flow is recovery time. There are both mental and physical costs associated with that state that cannot be ignored. Some managers push their people to run at that rate all the time; that eats people alive. You need downtime between pushes like that.
You're likely confusing NT with OSF's operating system. The two were developed more or less concurrently. OSF was Mach based. NT was highly derivative of Prism, which was a next-generation portable VMS (which got cancelled, and that has a lot to do with how Cutler and clan ended up at Microsoft).
The other possibility is that you're confusing NT with NeXT, but I really hope not:-).
We still learn what music we want to hear from the Radio and from MTV; we just use P2P technology to get it cheaper/for free.
I dunno about you, but I gave up on MTV, it just sucks too much. I also don't listen to the radio too much, it's just more of the same crap that's on MTV. If you want to find a new artist who's any good, about the worst place to do it is MTV or the radio.
Mostly I find new music from referral from friends. "Hey, check this out." That used to be done by going out to a bar and listening to a band, something I don't really have the time for these days. These days someone sends me an MP3 clip. And you know what? If I like it, I first try to see if I can buy it straight from the artist (many many small bands sell them off their own websites). If I can't do that, I try Amazon. Because you can bet your bottom dollar that the cool stuff isn't at Best Buy.
Outside of those kinds of referrals, I've subscribed to an actual (gasp) pay-for-stream service, RealOne. Their commercial-free genre-based streaming system is worth $10/month; terrific for background noise.
But having used RealOne for a few months now, I can see places where their model is seriously incomplete. For one, if I like a clip it's a pain to go listen to it again or to go listen to the whole album. There's no way I can forward a reference to the clip to someone so they can hear it too. There's a link to Amazon to buy the album, but no way to buy it and get it on MP3 immediately and the album delivered later.
These companies really need to use a mixed model to build a strong business. You need streaming content for "browsing". You need referral services for audience building. You need purchasing features for retail. And, this being the internet, you need immediate gratification so that when you buy the album, you have it/now/. And if they're going to charge CD prices for MP3 content, they're going to have to send the CD too.
Cringely makes a pretty good case as to why this would be good for Microsoft, and the competition would likely be good for consumers, but precious little reason why it would be good for Apple. In truth, it would not be good for Apple.
Apple is a hardware company. They make their money selling hardware, not software. If you take away those hardware sales, and a MacOS on Intel would certainly do that, you impact their core business. That's the last thing they want.
You will never see MacOS on Intel. There's absolutely no motivation for it. Furthermore, Cringley seems completely ignorant of the fact that supporting the morass of hardware that is the Intel problem is a huge, huge job. One of the biggest reasons that Apple's stuff works so cleanly is that they don't have to support nearly the range of equipment.
C# is not tied to the CLR like Java is tied to the JVM. The CLR (Common Language Runtime) is designed to run IL code, and there are compilers for many different languages besides just C# that can generate IL. That said, it should be clear that the security of a C# program is not derived from the C# compiler. It comes from the CLR, so the security policy is enforced at the IL level, not prior to compilation.
This is precisely the model that Java uses. In fact, the whole design of C# and the CLR is clearly derivative of the JVM design; Microsoft simply took Sun's design and did some retargetting and extension.
It's also erroneous to say that the JVM and Java are tightly coupled. Java code can be natively compiled, or compiled to non-JVM bytecode representations like MSIL. Several native code compilers for Java do exist.
Similarly, the JVM may run code that was not produced from Java source and there exist several Java bytecode compilers for other languages. I know of at least two (a C variant and Ada) and certainly it would not be hard to support Pascal, Modula-3, Lisp, or many other languages in part if not in whole.
Joy's article is clearly self-serving, particularly when a direct analogue to "unsafe" exists in Java's "native" keyword. It is certain, though, that C#'s facility is a lot easier to use. Whether or not programmers actually will use it is something that only time will tell, but early reports are that it's enough of an extra hurdle that it's often easiest not to do so.
Re:interpretation is the only way to guarantee saf
on
Bill Joy's Takes on C#
·
· Score: 1
Interpretation is certainly not the only way to guarantee safety. It may be the easiest, but it's possible to take an arbitrary hunk of code and instrument it to introduce safety.
This is not easy to do with random machine code (although several commercial products have existed for close to a decade that did a passable job on typical code, eg Purify and TestCenter) but with an intermediate representation that was specifically designed to make it easy, such as Java bytecodes, it's not difficult at all.
And, more to the point, it can be done with much less drastic performance penalties than we see with interpreters. To see this in action simply compare the performance of interpreted Java to JIT-compiled Java. Moreover, if you're willing to pay a heavier compilation cost than is reasonable with a JIT, the performance penalty will be merely incremental.
It turned out that when MS saw Unix and Linux as a threat, and when they decided that reliability was one of the biggest advantages that Unix/Linux offered, they took reliability seriously and made enormous progress in a relatively short period of time.
No, not so short. Sure, it's short in the sense that Win2K and XP were reliable while Win9x/ME were not, but it's not short in that 2K and XP were directly derived from more than a decade of previous work on NT, and it in a less direct manner from significant previous work on VMS and Prism. As much as people harped on the unreliability of NT, even 3.1 was a vast improvement over all previous Microsoft operating systems. That was, however, the work of quite a few years. Security will be, too, particularly since they still have the albatross of backwards compatibility to deal with.
The shift in priorities, however, can't be anything but good in the long term.
Generally speaking I agree with you. I note, however, that Java has always had the ability to integrate with unsafe code via native libraries. In effect Java's version of the "unsafe" keyword is "native".
This is occasionally useful, but practically speaking I've not had to use it even once in a production setting and I would avoid it if at all possible because you see best benefit from Java if you're taking advantage of its protection mechanisms. I find myself to be a solid 300% more productive long-term in Java than I was in either C or C++ (and I'm prodigious in all of them). On top of that, released bug counts are down an astounding 90% and tend to have much reduced impact. I don't know about you, but a three-fold improvement in productivity and an order of magnitude reduction in bug counts is something I can (and do) take to the bank.
Regarding the viability of C#, I don't see any particular reason why it cannot be quite popular, although I would have significant reservations in architecting systems that utilize code downloading even in a safe environment. In my experience downloading code into a runtime becomes a real problem whenever you can't be sure that the runtime is the same version as the one which you originally targetted. Differences, even very minor differences, show up as improperly executing code. We saw this in spades while trying to develop Java applets that would run in various versions of Netscape.
I am as yet unfamiliar with how C# handles this particular wrinkle, but it is critical to the widespread success of a downloadable format.
I for one think that C# is likely to be a huge step forward in any case, particularly if Microsoft redesigned its APIs in the process. God knows that the MFC classes suck rocks. They did a rather nice job in J++ (RIP), and I can only hope that the J++ work carried over to C#.
Even if that weren't the case, though, it's pretty much the same place you're standing if you were developing for PalmOS or WinCE/PPC.
If the proposition is "this is no worse than PalmOS or WinCE", that's not a particularly good one. I expect more from Linux, and not just technically.
I don't much buy into the theory that Linux ought to be an all-free-or-nothing proposition. If it is the case that I can get a better tool if I pay for it (and, historically, that has been very much the case) then I'm happy to pay for it.
This tool is the most open of any of the palm devices I've seen;
Perhaps you haven't seen much then. The Compaq iPaq runs full Linux with X11 and allows you to use whatever toolkit you like. The AgendaVR runs a full version of Linux and X11 as well. Availability of powerful handhelds running fully open Linux has not been a problem.
I don't count the iPAQ as an "open" palmtop because, when you pull it out of the package, it's proprietary all the way. Granted you can convert it, but I have a lot of better things to do with my time than doing that kind of thing, and I certainly have no intention of trying to sell palmtop software that's created for an iPAQ running Linux until Compaq sells them that way, hopefully for obvious reasons.
Even if you do, the iPAQ is a substantially larger and more expensive unit (at least if you want expansion capabilities). Cheap stuff wins.
anyone with any Linux or UNIX experience at all is going to be able to make this thing do backflips.
Well, no. A Java programmer can create Java applications for it, but a Java programmer can also create Java applications for Palm or WinCE. A C programmer can't write any GUI apps for it. And a C++ programmer has to learn a new toolkit and completely change the GUI code of their existing X11 applications.
Well, ok, some UNIX programmers will have to learn some new tricks to make it sing, but they ought to be fairly comfortable doing things with it.
Regarding rewriting GUI code for X11 applications, I would kind of expect that to do a good job for a palmtop application you're going to have to rework you UI to a significant degree anyway -- different form factor and input considerations usually means different design. The fact that Microsoft didn't want to do that has a lot to do with why WinCE sucked so much.
YMMV, of course, but this is unit has a lot of potential in my opinion. The fact that there are likely to be a lot of different handhelds running Linux doesn't change that, although it does make this one even more appealing to me as an early-adopter system.
I suppose how interesting this is, versus something like an iPAQ with Linux, has a lot to do with your goals. I don't want a device for personal hacking, I want a tool that makes it easy for me to build software I can sell.
It won't sync with MacOS out of the box. In fact, it won't sync with Linux out of the box. The software only runs on Win9x/ME/2K... not even WinXP (though the latter will almost certainly be corrected rapidly).
If there's one thing that this box needs, it's improved sync support. The default system uses an IP-based scheme with predefined addresses that conflict with many small networks. That's easily fixable by editing some files and making a configuration change on the Windows box, but it shouldn't have been an issue at all. The cradle is a bit touchy, and the Windows drivers -- if they work at all -- even moreso. There is no network sync support.
On the other hand, this thing is so programmable that it's no problem to develop your own sync program. I'm just using tar to a CF card right now, but it's a no-brainer to turn that into a network backup to some box via either PPP over USB , a CF ethernet card, or a CF 802.11 card. You can bet on a host of sync programs being out before this thing goes into consumer mode.
It's got its problems, but this is still the most mature pre-production developer system I've yet to use.
Add to that when.NET comes out, you'll have a lot of WinCE applications that are just an extension of what you have on your desktop (I've heard some about what you will be able to do, and it will be damned neat for anyone who doesn't have a vendetta against Microsoft). For example, I have a friend who has an iPAQ with a wireless card in it, and he can use Terminal Services to TS to his main workstation while he's in a meeting, monitor his build progress, change a few things and recompile, and a bunch of other things. It's really quite neat.
Umm, if you're developing under UNIX you've been able to do that for years since remote login support has always been there. Being able to do it with a palmtop has been possible for years too; telnet over a wireless connection has been available on PalmOS since before the first WinCE device shipped (I tried it in 1997 over a CDPD modem), and at this point all of the palmtops have 802.11 support and available telnet applications.
This is one of the reasons I prefer to develop on UNIX. I can leave the computer wherever I normally use it and access it via any network-connected device.
I have no comments on the viability of building things for embedded Linux at this point, having done no programming for the device yet, although in general it looks and feels like a stripped-down UNIX, and not all that stripped-down at that. I am very certain I can work with that. I can especially work with it given that there's a decent Java interpreter. Maybe that's not good enough for production but it's sure good enough for proof of concept.
I don't have anything in particular against WinCE/PPC other than that the units are much too expensive to compete against PalmOS, at least until someone comes up with a killer app that makes the extra functionality of the PPC worth the extra money. Right now it's like paying hundreds of dollars more for flashier versions of the same applications, and getting a box that doesn't even fit in your pocket to boot.
The Zaurus has some of these faults too. The developer unit, at $400, is still more expensive than any PalmOS unit I've ever bought. It's much larger than the Palm V or the Visor Edge or the Clio.
Where the Zaurus stands out over the PalmOS units is that it is fully internet aware and has superb 802.11b driver support in the box, plus a full-function web browser. This unit, plus $100 for a wireless card, makes a very nice network access device for a lot less money than a similar WinCE/PPC unit or a laptop.
This thing may never be popular as a consumer device, not when the production unit is expected to be priced well above even the most expensive PalmOS devices. But it sure as heck could find some niches in vertical market applications.
Qt is still being released under the GPL to generate business for Qt from commercial customers. You may think that arrangement is pretty swell, I think it will ultimately kill Linux on handhelds if any commercial developer has to pay thousands of dollars before being able to create GUI software for something like the Sharp.
Actually, buying the development unit entitles you to the development software. Even if that weren't the case, though, it's pretty much the same place you're standing if you were developing for PalmOS or WinCE/PPC. Somebody here was saying that QPE was more money than MSDN. Uh, have you received your MSDN bill recently? Sure, if you're getting the docs only subscription it's still relatively cheap, but if you want those compilers you better cough up a lung.
The best part about MSDN, for me, was sitting there opening my mail and watching the news and hearing that Microsoft had told the judge that they weren't a price-gouging monopoly. I opened my MSDN renewal invoice and in the span of one year the price had jumped 40%. That was the year that the last of the competitive Windows development tools producers gave up....
As a developer I am not especially turned off by the fact that the whole thing isn't open source. It's more important that it be open information. This tool is the most open of any of the palm devices I've seen; anyone with any Linux or UNIX experience at all is going to be able to make this thing do backflips.
Lots of people have been wondering where the market will be for this device, since Linux people are such a small market in and of themselves. I don't see that being the issue at all. We're the seed market, but the real market going out the door is going to be integrators and vertical market apps people. Java and superb 802.11b support? Damn, in a couple of weeks I could deploy this thing as a handheld database access tool with a custom application. And this can be done for about $600/unit ($100 less for the preproduction units). You can't touch the extensibility with the Palms and you can't touch the price with the PPCs.
And that, my friends, is going to sell units -- even if they don't do anything to the unit at all by the time it ships.
If there's any one thing I'd like to see, though, it would be Qt bindings for the Java interpreter. AWT sucks, and Swing (you/can/ get Swing) is just too much of a pig. Still, you really want the widgets... and Qt has 'em and they're tight and fast like you wish Swing would be.
Slashdot Mirror
They start with a load balancer at the front end, or possibly several layers of load balancer. If they run a distributed operation they'll use smart DNS systems or routers to direct requests to the most local server cluster. The server cluster will be fronted by a request scattering system.
Behind the request scattering system you'll find a cluster of machines whose job it is to serve static content (often the bulk of data served by a site) and route dynamic requests to another cluster of servers, enforcing session affinity for the dynamic requests.
Behind the static content servers are the application servers. They do the heavy lifting, building dynamic pages as appropriate for individual users and caching everything they can to offload the database.
Behind the application servers is the database or database cluster. The latter is really not that useful if you have a highly dynamic site as there are problems with data synchronization in database clusters (no matter what the database vendors tell you). But that's ok, single databases can handle a lot of volume if built correctly and caching is done appropriately at the application level.
And there you have it, the structure of a really large site.
Big sites, really big sites, put caching in the application. The biggest thing to cache is session data, easy if you're running a single box but harder if you need to cluster (and you certainly do need to cluster if you're talking about a high-volume site; nobody makes single machines powerful enough for that). Clustering means session affinity and that means more complicated software. (Aside: Is there any open source software that manages session affinity yet? )
Frankly speaking, Intel-based hardware would not be my first choice for building a high-volume site (although "millions of page views per month" is really only a moderate volume site; sites I have worked on do millions per /day/). It would probably be my third or fourth choice. The hardware reliability isn't really the problem, it can be good enough, the issue is single box scalability.
To run a really large site you end up needing hundreds or even thousands of Intel boxes where a handful of midrange Suns would do the trick, or even just a couple of high-end Suns or IBM mainframes. Going the many-small-boxes route your largest cost ends up being maintenance. Your people spend all their time just fixing and upgrading boxes. Upgrading or patching in particular is a pain in the neck because you have to do it over such a broad base. It's what makes Windows very impractical as host for such a system; less so for something like Linux because of tools like rdist, but even so you have to do big, painful upgrades with some regularity.
What you need to do is find a point where the box count is low enough that it can be managed by a few people and yet the individual boxes are cheap enough that you don't go broke.
These days the best machines for that kind of application are midrange Suns. It will probably be a couple of years before Intel-based boxes are big and fast enough to realistically take that away ... not because there isn't the hardware to do it (though such hardware is, as yet, unusual) but because the available operating systems don't scale well enough yet.
Sorry, by "touchscreen" I didn't necessarily mean that you touched the screen with your fingers. A stylus is entirely acceptable ... like that of Palm boxes. The point (ha-ha) is that there's a direct association between what you see and what you interact with, whereas with a mouse it's indirect.
I entirely agree that some mouse-style operations such as drag-and-drop don't work well in a touchscreen paradigm, so don't use them. I do not agree that low-resolution is necessary for touch screens any more than it is for mice; I've personally used touchscreens with resolutions over 4k on a side (for interacting with satellite imagery).
The first system I ever used with a mouse was an Apple IIgs, which came with a little game that taught you how to use the mouse. I picked it up in less than 2 hours, and I don't think I was 10 years old at the time.
I had a similar experience, so I never thought it was a problem ... until my in-laws were trying to learn to use a computer. They had severe motor control problems -- it was hard for them to get the pointer onto what they wanted without looking at the mouse, it was hard for them to click without moving the pointer, and the whole concept of drag-and-drop took a long time for them to pick up. This, unfortunately, seems to be the norm amongst people rather than the exception. Go to beginner computer courses and watch them! Mice are pretty hard to use.
I'd buy a proper tablet & stylus which is sensitive enough for those tasks (not to mention that the pen interface is familiar enough to those that draw on paper)
It's exactly this kind of interface that I'm suggesting. They are vastly easier to use than mice or trackballs (BTW, I too find the trackball to be ergonomically superior). With CRTs such an interface posed similar problems to the mouse: less motor control issues (since you probably already know how to write) but very difficult hand/eye coordination because you're watching the screen but manipulating the stylus on a separate pad. I never did get the hang of that. With flat screen panels being all the rage today there's no reason we can't apply a touchscreen to the flat screen and use it as a tablet interface.
We know those systems work ... after all, there are some thirty million palmtops out there that use such an interface.
We got new software that requires mouse interaction. It's been about six months and she's still not self-sufficient with the mouse, although she knows her way around the software quite well.
Some friends bought her a touchpad learning book (a Leap Pad) about a month ago. This uses a special pen to direct software by touching spots on a book. She picked up how to interact with the book in about two hours, which included learning that she had to push a particular spot on each page when she turned to it so that the computer would stay synchronized with the book.
Touch screens are, in my opinion, vastly easier to use than mouse-based systems. Motor control necessary for the mouse is difficult to learn; not only for children, but also for adults. It takes weeks or months for an adult to become adept with a mouse, and many never do for particularly fine tasks (like drawing). This is made all the harder by the idiocy of using hieroglyphics as a user interface design element in mouse-based interfaces.
What the hijackers did that was special was take advantage of the psychology that had been drilled into airline passengers over decades, namely that if there's a hijacking you stay put and let it play itself out. That allowed a small number of hijackers to control a large number of people using primitive weapons that otherwise would not have been much of a threat.
This worked in the past because previously hijackers weren't committing suicide, and live passengers were to their benefit. The September 11 hijackers were playing by different rules.
In being successful at it they changed the psychology of airline passengers. We will not see another September 11 because the passengers will no longer sit around and let hijackers have their way. In fact, the technique didn't even last out the day ... as proven by the crash of the flight in Pennsylvania, and later by the shoe bomber. We could use exactly the same security procedures we used, with the same effectiveness, as before September 11 and such an attack would not succeed today.
It's easy to blame the airline security people, but this was really an exploitation of mass psychology ... a social engineering hack if you will.
In other words, we have many independent developers who each exercise complete control over whatever they're building, many of whom are building things that compete with other versions of the same thing. The version most people use wins.
Whether or not this is going to result in more usable software is debatable, but one way to become popular is to be easier to use than the next guy.
In my mind the practicality of these vehicles, independent of cost, revolves around the range versus recharge cycle. If it takes more than a few minutes to do a recharge, and the range is less than a thousand miles, then they're just not good enough for a general-purpose vehicle.
This is why hybrids are interesting ... recharge
cycle is a tank fill.
What I'm waiting for is someone to look at making a hybrid where the engine is always on, always producing power, but the generator is producing a bit more power than the thing normally will need and charging a capacitor stack rather than batteries. That gives you acceleration (for awhile) but is much lighter and cheaper than batteries and since the engine is operating efficiently all the time, and requires quite a bit less power than if it were producing motive power directly (eg a few hundred cc ought to do a pretty good job) it should still be more efficient.
It made a huge impact on the usefulness of the computer equipment; probably the biggest immediate change was nearly eliminating paper from meetings.
I set up a wireless net at home pretty much concurrent with the work rollout; it changed the way I used computers at home, too. One of the first things I did with it was get play-by-play of a Red Sox game while my wife watched the Mets on TV, but it didn't take long before IMDB overwhelmed Maltin's too.
I've been writing Java code since JDK 1.0. I've done plenty of work with standalone clients, applets, and servers since that time and with every release since then, and blaming Microsoft is just plain revisionist history.
Not only was Netscape's compatibility with the Java standard much much worse than Microsoft's (Sun sued over nits while Netscape had major API differences!), but it wasn't even compatible between versions of itself. Minor point releases had major points of incompatibility with each other, and the stability of the JVMs included with Netscape was very poor to say the least.
I know that's not the popular viewpoint, but anyone who wrote significant java code for the browser back then should recall how painful it was to deal with the Netscape Java flavor-of-the-week and how hard it was to work around the things that would take out the browser. We gave up and went back to HTML.
But I don't think it's fair to blame Java's death on the client entirely on Netscape either. Anyone remember what it was like to write client code with AWT? I'll tell you what it was like - it sucked. It took Sun two major JDK releases (1.1 and 1.2) to fix that with Swing, and Swing is such a pig that you need a pretty heavy client to run nontrivial applications.
So what we had was a GUI library that was not really very good for building clients and a major vendor who couldn't make a stable version or maintain compatibility either within its own releases or with the standard itself. And that's completely independent of Microsoft.
I think any chance of Java making it on the client was killed when Sun decided not to offer it originally as a plug-in. Had it been a plug-in then at least Sun could have controlled the quality and compatibility of the implementations on the street - across all browser vendors. Notice that Macromedia has done an excellent job of that with Flash.
Sun did, eventually, move to that design - but only after the war had been lost.
It might be nice to blame Java's client woes on Microsoft, but in all honesty - as much as I hate Microsoft - I can't do that. Java failed on its own demerits.
Sure, I used the Omnisky service for a couple of years. My take in brief: CDPD sucks.
They claim 19.2kbps; I rarely saw a quarter of that. But worse than that is the fact that you lose service if you're moving around very much ... e.g. in a car or on a train. Coverage is poor, too, even in major urban areas (e.g. Boston and New York City).
I had hoped to use the service to expand the capabilities of the palmtop device by allowing remote access to deep datastores (the web, of course, but also mail archives and personal files). The reality was that it was too slow and unreliable to use for anything but short data bursts ala AvantGo. I could only use it for e-mail in emergency situations, and it was next to worthless for the web both because of performance and display limitations.
The 2.5G network Verizon is rolling out may have a better shot at it. With much higher data rates and presumably better handling of cell migration it might just be good enough. Until then I'm using 802.11 despite its short range. CDPD is a bust.
Page 30 of the original edition:
"Programming managers have long recognized wide productivity variations between good programmers and poor ones. But the actual measured magnitudes have astounded all of us. In one of their studies, Sackman, Erikson, and Grant were measuring performances of a group of experienced programmers. Within just this group the ratios between best and worst performance averaged about 10:1 on productivity measurements and an amazing 5:1 on program speed and space measurements! [...] The data showed no correlation whatsoever between experience and performance."
Practically speaking, however, you have to account for not only productivity but ongoing cost of product. If bug counts follow the same approximate number as program speed and space measurements, then the actual value received by the company is easily a factor of 100 better with the good programmer (since you reduce the load on support and maintenance organizations).
This certainly mirrors my experience.
Another thing that hasn't been emphasized enough in this commentary (I don't know about the book) is the effect of flow (not just that it exists). When you're in the flow, which I've always called "going under" because that's what it feels like, you can be hugely productive -- my multiplier is more than a factor of five. Without distractions some programmers can maintain that state for days on end (my longest was 96 hours straight, though runs of 24-48 hours are far more typical). I know some people who can do it for weeks. Maximizing the effectiveness of flow in your best programmers can easily make the difference between success and failure of a project. Thus one of the things that differentiates a good and a bad manager to me is that the good ones know when to leave you alone.
Lastly, an important consideration about flow is recovery time. There are both mental and physical costs associated with that state that cannot be ignored. Some managers push their people to run at that rate all the time; that eats people alive. You need downtime between pushes like that.
No, WinCE is an NT derivative. That's not so clear now, but it was really clear in 1.0.
The other possibility is that you're confusing NT with NeXT, but I really hope not :-).
NT isn't in any way derivative of MS's UNIX experience. It's a clear derivative of VMS, and a direct derivative of Prism.
This is basically what Gibson's glasses did in _Virtual Light_. Not really a new idea. jim
I dunno about you, but I gave up on MTV, it just sucks too much. I also don't listen to the radio too much, it's just more of the same crap that's on MTV. If you want to find a new artist who's any good, about the worst place to do it is MTV or the radio.
Mostly I find new music from referral from friends. "Hey, check this out." That used to be done by going out to a bar and listening to a band, something I don't really have the time for these days. These days someone sends me an MP3 clip. And you know what? If I like it, I first try to see if I can buy it straight from the artist (many many small bands sell them off their own websites). If I can't do that, I try Amazon. Because you can bet your bottom dollar that the cool stuff isn't at Best Buy.
Outside of those kinds of referrals, I've subscribed to an actual (gasp) pay-for-stream service, RealOne. Their commercial-free genre-based streaming system is worth $10/month; terrific for background noise.
But having used RealOne for a few months now, I can see places where their model is seriously incomplete. For one, if I like a clip it's a pain to go listen to it again or to go listen to the whole album. There's no way I can forward a reference to the clip to someone so they can hear it too. There's a link to Amazon to buy the album, but no way to buy it and get it on MP3 immediately and the album delivered later.
These companies really need to use a mixed model to build a strong business. You need streaming content for "browsing". You need referral services for audience building. You need purchasing features for retail. And, this being the internet, you need immediate gratification so that when you buy the album, you have it /now/. And if they're going to charge CD prices for MP3 content, they're going to have to send the CD too.
Apple is a hardware company. They make their money selling hardware, not software. If you take away those hardware sales, and a MacOS on Intel would certainly do that, you impact their core business. That's the last thing they want.
You will never see MacOS on Intel. There's absolutely no motivation for it. Furthermore, Cringley seems completely ignorant of the fact that supporting the morass of hardware that is the Intel problem is a huge, huge job. One of the biggest reasons that Apple's stuff works so cleanly is that they don't have to support nearly the range of equipment.
This is precisely the model that Java uses. In fact, the whole design of C# and the CLR is clearly derivative of the JVM design; Microsoft simply took Sun's design and did some retargetting and extension.
It's also erroneous to say that the JVM and Java are tightly coupled. Java code can be natively compiled, or compiled to non-JVM bytecode representations like MSIL. Several native code compilers for Java do exist.
Similarly, the JVM may run code that was not produced from Java source and there exist several Java bytecode compilers for other languages. I know of at least two (a C variant and Ada) and certainly it would not be hard to support Pascal, Modula-3, Lisp, or many other languages in part if not in whole.
Joy's article is clearly self-serving, particularly when a direct analogue to "unsafe" exists in Java's "native" keyword. It is certain, though, that C#'s facility is a lot easier to use. Whether or not programmers actually will use it is something that only time will tell, but early reports are that it's enough of an extra hurdle that it's often easiest not to do so.
This is not easy to do with random machine code (although several commercial products have existed for close to a decade that did a passable job on typical code, eg Purify and TestCenter) but with an intermediate representation that was specifically designed to make it easy, such as Java bytecodes, it's not difficult at all.
And, more to the point, it can be done with much less drastic performance penalties than we see with interpreters. To see this in action simply compare the performance of interpreted Java to JIT-compiled Java. Moreover, if you're willing to pay a heavier compilation cost than is reasonable with a JIT, the performance penalty will be merely incremental.
It turned out that when MS saw Unix and Linux as a threat, and when they decided that reliability was one of the biggest advantages that Unix/Linux offered, they took reliability seriously and made enormous progress in a relatively short period of time.
No, not so short. Sure, it's short in the sense that Win2K and XP were reliable while Win9x/ME were not, but it's not short in that 2K and XP were directly derived from more than a decade of previous work on NT, and it in a less direct manner from significant previous work on VMS and Prism. As much as people harped on the unreliability of NT, even 3.1 was a vast improvement over all previous Microsoft operating systems. That was, however, the work of quite a few years. Security will be, too, particularly since they still have the albatross of backwards compatibility to deal with.
The shift in priorities, however, can't be anything but good in the long term.
This is occasionally useful, but practically speaking I've not had to use it even once in a production setting and I would avoid it if at all possible because you see best benefit from Java if you're taking advantage of its protection mechanisms. I find myself to be a solid 300% more productive long-term in Java than I was in either C or C++ (and I'm prodigious in all of them). On top of that, released bug counts are down an astounding 90% and tend to have much reduced impact. I don't know about you, but a three-fold improvement in productivity and an order of magnitude reduction in bug counts is something I can (and do) take to the bank.
Regarding the viability of C#, I don't see any particular reason why it cannot be quite popular, although I would have significant reservations in architecting systems that utilize code downloading even in a safe environment. In my experience downloading code into a runtime becomes a real problem whenever you can't be sure that the runtime is the same version as the one which you originally targetted. Differences, even very minor differences, show up as improperly executing code. We saw this in spades while trying to develop Java applets that would run in various versions of Netscape.
I am as yet unfamiliar with how C# handles this particular wrinkle, but it is critical to the widespread success of a downloadable format.
I for one think that C# is likely to be a huge step forward in any case, particularly if Microsoft redesigned its APIs in the process. God knows that the MFC classes suck rocks. They did a rather nice job in J++ (RIP), and I can only hope that the J++ work carried over to C#.
If the proposition is "this is no worse than PalmOS or WinCE", that's not a particularly good one. I expect more from Linux, and not just technically.
I don't much buy into the theory that Linux ought to be an all-free-or-nothing proposition. If it is the case that I can get a better tool if I pay for it (and, historically, that has been very much the case) then I'm happy to pay for it.
This tool is the most open of any of the palm devices I've seen;
Perhaps you haven't seen much then. The Compaq iPaq runs full Linux with X11 and allows you to use whatever toolkit you like. The AgendaVR runs a full version of Linux and X11 as well. Availability of powerful handhelds running fully open Linux has not been a problem.
I don't count the iPAQ as an "open" palmtop because, when you pull it out of the package, it's proprietary all the way. Granted you can convert it, but I have a lot of better things to do with my time than doing that kind of thing, and I certainly have no intention of trying to sell palmtop software that's created for an iPAQ running Linux until Compaq sells them that way, hopefully for obvious reasons.
Even if you do, the iPAQ is a substantially larger and more expensive unit (at least if you want expansion capabilities). Cheap stuff wins.
anyone with any Linux or UNIX experience at all is going to be able to make this thing do backflips.
Well, no. A Java programmer can create Java applications for it, but a Java programmer can also create Java applications for Palm or WinCE. A C programmer can't write any GUI apps for it. And a C++ programmer has to learn a new toolkit and completely change the GUI code of their existing X11 applications.
Well, ok, some UNIX programmers will have to learn some new tricks to make it sing, but they ought to be fairly comfortable doing things with it.
Regarding rewriting GUI code for X11 applications, I would kind of expect that to do a good job for a palmtop application you're going to have to rework you UI to a significant degree anyway -- different form factor and input considerations usually means different design. The fact that Microsoft didn't want to do that has a lot to do with why WinCE sucked so much.
YMMV, of course, but this is unit has a lot of potential in my opinion. The fact that there are likely to be a lot of different handhelds running Linux doesn't change that, although it does make this one even more appealing to me as an early-adopter system.
I suppose how interesting this is, versus something like an iPAQ with Linux, has a lot to do with your goals. I don't want a device for personal hacking, I want a tool that makes it easy for me to build software I can sell.
It won't sync with MacOS out of the box. In fact, it won't sync with Linux out of the box. The software only runs on Win9x/ME/2K ... not even WinXP (though the latter will almost certainly be corrected rapidly).
If there's one thing that this box needs, it's improved sync support. The default system uses an IP-based scheme with predefined addresses that conflict with many small networks. That's easily fixable by editing some files and making a configuration change on the Windows box, but it shouldn't have been an issue at all. The cradle is a bit touchy, and the Windows drivers -- if they work at all -- even moreso. There is no network sync support.
On the other hand, this thing is so programmable that it's no problem to develop your own sync program. I'm just using tar to a CF card right now, but it's a no-brainer to turn that into a network backup to some box via either PPP over USB , a CF ethernet card, or a CF 802.11 card. You can bet on a host of sync programs being out before this thing goes into consumer mode.
It's got its problems, but this is still the most mature pre-production developer system I've yet to use.
Add to that when .NET comes out, you'll have a lot of WinCE applications that are just an extension of what you have on your desktop (I've heard some about what you will be able to do, and it will be damned neat for anyone who doesn't have a vendetta against Microsoft). For example, I have a friend who has an iPAQ with a wireless card in it, and he can use Terminal Services to TS to his main workstation while he's in a meeting, monitor his build progress, change a few things and recompile, and a bunch of other things. It's really quite neat.
Umm, if you're developing under UNIX you've been able to do that for years since remote login support has always been there. Being able to do it with a palmtop has been possible for years too; telnet over a wireless connection has been available on PalmOS since before the first WinCE device shipped (I tried it in 1997 over a CDPD modem), and at this point all of the palmtops have 802.11 support and available telnet applications.
This is one of the reasons I prefer to develop on UNIX. I can leave the computer wherever I normally use it and access it via any network-connected device.
I have no comments on the viability of building things for embedded Linux at this point, having done no programming for the device yet, although in general it looks and feels like a stripped-down UNIX, and not all that stripped-down at that. I am very certain I can work with that. I can especially work with it given that there's a decent Java interpreter. Maybe that's not good enough for production but it's sure good enough for proof of concept.
I don't have anything in particular against WinCE/PPC other than that the units are much too expensive to compete against PalmOS, at least until someone comes up with a killer app that makes the extra functionality of the PPC worth the extra money. Right now it's like paying hundreds of dollars more for flashier versions of the same applications, and getting a box that doesn't even fit in your pocket to boot.
The Zaurus has some of these faults too. The developer unit, at $400, is still more expensive than any PalmOS unit I've ever bought. It's much larger than the Palm V or the Visor Edge or the Clio.
Where the Zaurus stands out over the PalmOS units is that it is fully internet aware and has superb 802.11b driver support in the box, plus a full-function web browser. This unit, plus $100 for a wireless card, makes a very nice network access device for a lot less money than a similar WinCE/PPC unit or a laptop.
This thing may never be popular as a consumer device, not when the production unit is expected to be priced well above even the most expensive PalmOS devices. But it sure as heck could find some niches in vertical market applications.
Qt is still being released under the GPL to generate business for Qt from commercial customers. You may think that arrangement is pretty swell, I think it will ultimately kill Linux on handhelds if any commercial developer has to pay thousands of dollars before being able to create GUI software for something like the Sharp.
/can/ get Swing) is just too much of a pig. Still, you really want the widgets ... and Qt has 'em and they're tight and fast like you wish Swing would be.
Actually, buying the development unit entitles you to the development software. Even if that weren't the case, though, it's pretty much the same place you're standing if you were developing for PalmOS or WinCE/PPC. Somebody here was saying that QPE was more money than MSDN. Uh, have you received your MSDN bill recently? Sure, if you're getting the docs only subscription it's still relatively cheap, but if you want those compilers you better cough up a lung.
The best part about MSDN, for me, was sitting there opening my mail and watching the news and hearing that Microsoft had told the judge that they weren't a price-gouging monopoly. I opened my MSDN renewal invoice and in the span of one year the price had jumped 40%. That was the year that the last of the competitive Windows development tools producers gave up....
As a developer I am not especially turned off by the fact that the whole thing isn't open source. It's more important that it be open information. This tool is the most open of any of the palm devices I've seen; anyone with any Linux or UNIX experience at all is going to be able to make this thing do backflips.
Lots of people have been wondering where the market will be for this device, since Linux people are such a small market in and of themselves. I don't see that being the issue at all. We're the seed market, but the real market going out the door is going to be integrators and vertical market apps people. Java and superb 802.11b support? Damn, in a couple of weeks I could deploy this thing as a handheld database access tool with a custom application. And this can be done for about $600/unit ($100 less for the preproduction units). You can't touch the extensibility with the Palms and you can't touch the price with the PPCs.
And that, my friends, is going to sell units -- even if they don't do anything to the unit at all by the time it ships.
If there's any one thing I'd like to see, though, it would be Qt bindings for the Java interpreter. AWT sucks, and Swing (you
It's a very interesting unit.