There is one aspect of the OLPC that really worries me: the software.
There are alternatives - Pepper Computer's Linux environment runs on the OLPC. It's more mature than the OLPC software, and was designed from the beginning for consumers. It focuses on web browsing and media rather than education, although it's possible to run things like eToys too. Pepper integrates Firefox, MPlayer, Helix, and a number of other open-source projects into something much simpler and easier to use than your standard GNOME/KDE clone of the Windows desktop. If you're at CES, stop by the booth for a hands-on demo of Pepper on the OLPC.
Have you looked at the Pepper Pad? Unlike the i-Opener it's portable (2.2lbs, built-in Wi-Fi so you can use it on your couch). Our third version, the Pepper Pad 3, has an x86 chip + runs a variant of Fedora Core. The software is based on Firefox 1.5. It includes Flash and Acrobat plugins, and has a popup blocker. It starts shipping this month.
We've designed the Pad and its software to be an appliance. The user never needs to interact with the underlying OS, although it is an option for those who want to. While we do provide software updates on a regular basis, the Pad can be configured not to get them.
What I want to know is why nobody has made a 1-2lb, 8-12" screen, convertible tablet with the power of a PDA instead of a laptop (and the cost to match).
We did.
The Pepper Pad has an 8.4", 800x600 screen, a 624Mhz Xscale CPU, a 20GB disk, Wi-Fi, bluetooth, USB, and a full keyboard for about $800. It runs Linux and includes both Firefox 1.5 and Flash 7.
When building model trains, virtually all serious modellers will customize everything (locomotives, rolling stock, structures, etc) or they will build stuff from scratch. There's plenty of build-your-own-train and design modification going on. No serious modeller will just buy a car, hook it onto the rest and watch it go. Instead, they will:
Change the couplers
Perhaps change the trucks to something that's smoother/more appropriate/etc
Change the road name and other markings
Add stanchions, brakes, lights, and other details that the manufacturer didn't include
Weather the car so it looks like it's been around for awhile
Add ballast so the car behaves properly and produces the correct load on the locomotive
For a passenger car, the modeller will often scratchbuild an interior including seats, people, baggage, stove, lighting, shades, etc
For locomotives, in additon to the above modellers will often:
Replace the running gear
Add a sound system
Add Digital Command and Control (DCC) so that they can control the specific locomotive without affecting others on the same track
and so on.
And that's just what they do for storebought locomotives and rolling stock. Scratchbuilding a locomotive can take weeks or months, depending on the level of detail.
Then there's the matter of scenery. Running trains around a circle of track gets pretty boring (unless you have a cat....). The good news is that you can build scenery to surround the trains. You get to build entire cities, towns, farms, rivers, mountains, hills, canyons, and industries from scratch. Basically anything you can imagine can be incororated into a model railroad. It's world-building in your basement (or garage, or spare room, or bookshelf).
For the electrically-minded, there are all sorts of fun wiring problems to be solved, and you can do many interesting things with computers if you want to (train scheduling, locomotive control, switch control, lighting, etc).
If you like spending time outdoors, you may enjoy harvesting plants, rocks and dirt for your layout so that it has authentic colors, shapes, and textures.
If you're a people person, you and your friends may enjoy operating sessions where everyone has a train and you're working cooperatively to service the industries along your route without creating gridlock.
If you like brainteasers, there are [railroad car] switching problems that can keep you busy for hours or days.
Model railroading is one of those rare hobbies where there's truly something for everyone. You can be as involved as you want, and since you're inventing as you go nobody can tell you that you did a bad job.
There are plenty of webapp frameworks out there, but are they really the right way to write an app? Picking a technology (like servlets) and then writing an application based on that technology - or based on a framework that wraps that tech - is fundamentally broken for many apps.*
The problem is that technologies change over time. Tech-oriented frameworks make writing the app easier in the short run, but they don't consider the long-term life of the app. Applications that are tightly coupled to any given tech become a liability as that tech ages, and quite often migration to a new tech involves a ground-up rewrite of the application. Instead of tying the app to a framework like Struts or a tech like EJB, write the app to stand on its own, using interfaces to the various techs it needs. Particular technologies like Struts (for a web UI) or EJB (for persistence) can be swapped in + out of the application as necessary without changing the function of the application itself.
There are a number of benefits to a technology-agnostic approach like this. The technology implementations can be upgraded: find out that EJB is a dud? Switch to Hibernate! Perhaps more interestingly, the technology implementations can be supplemented: Have a web UI, but need to ship a desktop application too? Plug in the desktop app tech implementation and presto! You now have both a web UI and a Swing/SWT/etc UI for the same app. Testing becomes far easier too, because you have clearly defined boundaries between the different components of the app (so it's easy to figure out which part isn't behaving).
There are drawbacks, of course. To work as advertised you need to invest a fair amount of architecture to get such a system off the ground. Someone has to write the tech implementations, as well - an SWT UI for your app won't just fall out of the sky when you want it.
Everyone has their pet project. Mine is Sandboss, an approach to enterprise application development that's application-centric, not technology centric. It concentrates on the app itself - you don't wind up with a "Struts application" or an "EJB app". Instead you wind up with an application that can use Struts and EJB, but can also work with Hibernate and WebWork. It's not for everyone - it requires a fair amount of committment to the methodology - but it works well in practice. The time savings are pretty incredible, and the components really are reusable.
*There are many places where a front end for a database is all you need. Of course, once the requirements for that project start to grow you'll wish you had something more powerful.
Take a look at http://sandboss.org for an example of this in action. Sandboss is a tool for building enterprise apps, so it's rather domain-specific. It makes extensive use of generators as part of the build cycle, so you get the benefits without the BS. In the included sample app, a few hundred lines of application source get turned into 150,000+ lines of communication, configuration, persistence, serialization, and UI code (html, servlets, etc). That sounds like a lot (and it is), but that's 150k lines of code that you don't have to worry about maintaining.
XDoclet is awesome, but it makes a fundamental mistake IMHO. XDoclet requires that you embed specific technology dependencies into your app's source code. The javadoc tags are specific to EJB or JBoss or whatever, so if you ever want to switch to a different tech for something you have to clean out the old tags and insert the new tags into every file. That's exactly what things like EJB have been trying to avoid, and as with EJB, XDoclet doesn't quite get the job done.
Instead, XDoclet should let you specify what you want accomplished, not how you want it accomplished. The code generation engine should be smart enough to figure out how to accomplish the specific tasks. For example, you should be able to tell the generator "this object gets persisted," not "this object should have a corresponding entity bean named Foo that can be found in JNDI as FooEJB." That way you can switch to straight JDBC by swapping out your generator, instead of changing all those javadoc tags.
Granted, this approach isn't appropriate for all projects (especially legacy apps). It makes writing new apps much easier though, and if you ever have to switch app servers or web frameworks you'll be thrilled.
You're assuming you run the generator once, and that's it. That's what many people do, and it's wrong. The generator should be part of the build cycle. If you want to change the generated code snippet, change the generator!
While I agree with you in principle - that better abstraction is usually the way to go - that's not always possible in the real world. For example, sometimes you have to produce an API for someone else, or hook up to their API. In those cases, better abstraction isn't always an option. Sometimes your boss says "you're using EJB" and you're stuck with it. In those cases a generator can be a big help.
The cool thing about integrating a generator into your build is that you get the benefits of abstraction without many of the drawbacks. The generator becomes your abstraction, so you can make modifications in one place. Sure, using a generator requires a little more thought than cut-n-paste. So does proper abstraction. The two aren't all that different, and both approaches have their place.
There's an open-source implementation of a very similar generation system living at http://sandboss.org. It does everything from bean classes to database schemas, and unlike many code generators it's not tied (implicitly or explicitly) to any particular output like EJBs or XML. Although written in Java, the underlying generator architecture is designed to spit out C code just as happily as it spits out Java. The Sandboss generator infrastructure is part of a larger framework for building message-based enterprise apps, and it makes adding new interfaces to those apps much easier.
Unlike other generation engines, the Sandboss engine concentrates on the application requirements + not the implementation technologies (EJB/XML/etc). Using Sandboss, you can plug in new generators (to change the persistence layer from EJB to straight JDBC) without modifying your app's code *at all*. Generators like XDoclet embed technology dependencies right into your app's code, which makes switching technologies harder. I'm a developer on the project so perhaps I'm biased, but I think it's pretty damn cool.
The parent is right to warn about maintenance. Meta-progamming of any kind requires a little more thought + understanding than many coders are used to. Generators are basically power tools, and as with any power tool if you're not paying attention you're likely to get yourself into trouble.
Re:What I want to know - We need benchmarks!
on
Virtual PC 6 Review
·
· Score: 3, Interesting
VPC does indeed take advantage of multiple CPUs, but only to the effect that it pushes some of the threads (disk, graphics) to the other CPU. The emulation core itself is single-threaded (as it has to be; a multithreaded core would be a nightmare to code, if it could be made to work at all). While there's a definite speedup because of the second processor, it's on the order of 5-10% IIRC.
Something else....one of the most important factors in VPC's speed is the size of the host processor's cache. The 1.42ghz machines have a 256k on-chip L2 cache and a 2MB L3 cache. That's pretty big, which benefits VPC. The extra 1MB of cache (compared to my Powerbook) is probably worth a few %.
Even with the second CPU and extra cache, I think that 750-800Mhz is about all you can reasonably expect from the 1.42ghz machines. Of course, I've never tried it so I could be wrong.
What about programs that require OpenGL or Direct3D that aren't games? There are plenty of CAD, modelling, visualization, etc packages out there that use 3D graphics but aren't games. Furthermore, many of these programs are low-volume or custom programs that have no chance of being ported to the Mac. Better 3D support in VPC for these programs would do nothing but *help* people.
About the game market....does it really matter if there's a mac game market, if Windows games work just fine? Instead of late/non-existent/half-assed/broken/etc ports, Mac users would be able to run new games right when they came out. I bet they'd even be compatible with their PC counterparts, so people playing (say) Everquest wouldn't have to use Mac-only servers. That would be a *good* thing IMHO.
(FWIW, many games today require so much horsepower that emulation - even with 3D acceleration - simply wouldn't be feasible, so a port would be the only viable option for playing on the Mac anyway. That should keep the Mac game market up + running).
Re:What I want to know - We need benchmarks!
on
Virtual PC 6 Review
·
· Score: 3, Informative
In my experience, VPC on a 1ghz powerbook runs at about the same speed as a 500mhz PIII with really slow disk and graphics subsystems. Unfortunately the disk + graphics systems put a damper on overall performance. The CPU emulation itself is quite fast, however. Depending on exactly what you're doing, it ranges from about.4x to.75x the speed of host's processor. On one of the new 1.42ghz towers, I'd expect to see CPU performance roughly equal to a 750mhz PIII.
Re:I was hoping to play more games
on
Virtual PC 6 Review
·
· Score: 2, Interesting
Command & Conquer (and Red Alert) worked quite well in VPC last I tried them on my 7600 w/ 450mhz G4. I used to play the original GTA on that machine back when I had a 266mhz G3, and it was more than playable. This is all under OS 9, however; OS 9 has always provided better performance for VPC than OS X. Give that a shot, you might be surprised at the difference.
Also keep in mind that games aren't a priority for the VPC team, and Connectix has repeatedly said that VPC is not a gaming solution.
One more for the list....Structs and Nodes Development is a methodology for developing enterprise apps that leverages aspects for almost every part of the system. Unlike many of the other AOP tools out there, you don't need extra preprocessors or special compilers. Instead, SAND uses code generators to implement aspects across the entire application. It's like XDoclet on steroids.
The result is a convergence of AOP and model-driven architecture (MDA; another buzzword) that actually works. Writing enterprise apps with SAND is a joy, and there's even an open-source implementation on Sourceforge called "sandboss". (yeah, I'm a sandboss developer. It rocks).
AOP is definitely a buzzword, but it's here to stay because it makes things so much easier. It's not as applicable for consumer applications, but in the enterprise world it's a godsend. There are 2 different types of code you have to write in an enterprise app. First is the business logic - what the application does. The second part is the plumbing - how the application does it. This includes persistence, caching, user interfaces (web site, client application, etc), IPC, and so on. The first part is far more important than the second part, but the second part is where most of the time gets spent. A good AOP tool can drastically cut the time needed to put together the app's plumbing, and that's why AOP is here to stay.
The article doesn't say the Mozilla developers were hurt! It says they either a) agree with Apple or b) don't care. For example:
One Mozilla staff member called KHTML selection an understandable if not foregone conclusion, given Mozilla's technical problems.
and
"I guess I'm supposed to be mortally offended--or at least embarrassed--that they went with KHTML instead of our Gecko engine, but I'm having trouble working up the indignation," wrote Mike Shaver in a Web log posting. "We've all known forever that Gecko missed its 'small-and-lean' target by an area code, and we've been slogging back towards the goal, dragging our profilers and benchmarks behind us, for years."
Apple hurt Mozilla? The only thing that hurt Mozilla was Mozilla. And for the most part, the Mozilla developers know that already.
1.5MIPS seems awfully slow to me....like orders of magnitude slower than it should be. VirtualPC - a commerical product that emulates a PC - runs somewhere around the speed of a 233Mhz PII on my crufty old Powermac, which rockets along at 450Mhz. VPC provides full emulation of a PC the way Bochs does, but it's ~200x faster. That's an awfully big difference. What accounts for that difference? Is there any chance that Bochs will close the gap sometime soon? I'd much rather use a free product than VPC, but with a performance gap like that it's tough to justify...
Believe it or not, tetraethyl lead did change the way you live - it's just that the change probably happened before you were born, so you don't notice it. Tetraethyl lead was used as a additive to gasoline; it prevented internal combustion engines from "knocking." Knock is otherwise known as detonation or "abnormal combustion." It is one of the main limiting factors when trying to tune gasoline engines for maximum performance, efficiency, etc. Knock also severly degrades reliability and longevity of these engines.
The discovery that tetraethyl lead could prevent knock was huge leap forward; it was a huge boost to the automotive industry, since it allowed manufacturers to build safer/more reliable/more powerful/etc engines.
These days all we hear about are the health risks of tetraethyl lead (it's toxic as hell), but back in the early 1900's it was seen as a tremendous leap forward. Without it, cars, airplanes, etc would be very different today.
I'm a little leery of your anecdote; presumably you reported it to the correct authorities, since up until now there haven't been many (any?) documented cases where cell phones actually interfere with communication equipment onboard aircraft.
A little digging reveals that the frequencies that cell phones operate on aren't the same frequencies aircraft use for navigation/communication, and those $5/minute airphones are actually cellular telephones!
In fact, it turns out that the cell phone ban wasn't an FAA regulation until very recently - it was an FCC ban! The cell network isn't designed for rapidly-moving phones, nor is it designed for phones 30,000 feet up in the air. Instead, it's designed for stationary/slow-moving phones at or near ground level. An airborne cell phone can wreak havoc with the network; that's why the FCC banned them on airplanes. The ban has nothing to do with safety.
If you end up with a big pile of servlets like this then you aren't using the framework properly
...which is why we need to keep building better frameworks. Struts attempts to point you in the right direction, but it's still fairly easy to abuse. Unfortunately, only a handful of the developers I've seen/heard/worked with actually have a clue on these things; most of them just want to get something built. Design is never a question in their mind - the only important thing is "what's easiest/what's fastest."
By choosing a more powerful framework, the consequences of such an approach can be mitigated. The key piece of a good framework IMHO is that the best way of doing things is also the easiest way of doing things. That way people looking to take the easy way out will wind up producing a better module than they would otherwise. Struts solves many of these problems, but it's still too easy to mush your application's functionality together with its implementation. The Struts doc even says something to the effect of "the obvious way is the easy way, but we don't recommend it." To me, that means the framework needs some help.
The first step in answering you question is to define your requirements. One the the [non]requirements you need is maintainability. That should play a big part in your implementation. If the app needs to be robust, maintainable, extensible, etc, you should approach it completely differently than you would if those weren't concerns.
That's where MVC comes in. It forces to you think about your implementation instead of blindly charging forward. That's overkill for some projects, but IMHO it's absolutely necessary for others (i.e. any project where more than about 2 people need to touch the code). Otherwise you wind up spending more and more time on maintenance/adding features.
FWIW, Slashdot uses more of the spaghetti pattern than anything else...
Structs is cool, but it's just a small piece of a much bigger picture. There are many cases where a simple 1- or 2-tier app is perfectly adequate, and basing your app on Struts is appropriate for that. Those are rightly called "web applications."
If you're building an enterprise app, however, basing your app on Struts (or any other "web application" technology) isn't a good idea. Why? You wind up mixing your app's functionality with its implementation. Using an MVC framework like Struts alleviates this problem to a great deal, but when it comes down to it you still have a big pile of servlets that does everything from database access to presentation.
That approach isn't scalable, it's not adaptable to different technologies (there's a new webapp framework every week, it seems), it's not easy to integrate with other applications, and so on.
What's really needed is a way to define an application independently of the implementation details. Once you've defined the application, you can generate whatever interfaces it needs - like a Struts UI, an EJB persistence engine, etc. This is where my shameless plug begins: check out the Sandboss project for a way to define your enterprise app without being chained to a particular implementation detail like Struts or EJB.
While the techniques used in Sandboss are designed for the enterprise world, they're useful for web apps, too. I think it makes much more sense to over-engineer an application than it does to under-engineer it; overengineering takes more time up front but saves you 10x as much or more once development starts, since the well-don overengineered solution is more flexible and capable of responding to marketing's feature of the week. By picking Sandboss you get the best of both worlds - a robust framework where someone else has already done the engineering. You just define your app, and bam! Persistence, communication, control, the UI are all done for you.</shameless plug>
Munich may have made the right choice, considering that there's already an existing infrastructure and the distance is relatively short. However, some of your facts need to be put in perspective.
You state that the maglev needs "5km just to get up to 300 km/h." While correct, you neglect to compare this to ICE, which takes 30km to reach the same speed. Since there's no wheel/rail friction, maglevs can accelerate much more quickly than conventional high-speed trains.
Furthermore, maglev trains use less power than conventional high-speed trains once you get past about 200km/h. At 300km/h, ICE trains use 71 Wh/km. Maglevs use 47 Wh/km; a maglev could go 400km/h on the same amount of power it takes to get the ICE up to 300km/h.
Maglevs are also quieter, safer, easier to maintain (no moving parts!), and so on.
If you look harder, you'll find out that they used a specially-prepared trainset and a specially-prepared section of track for that speed run. Furthermore, the TGV runs about 300km/h in production; nowhere near 515km/h. As I understand it, the maglevs will run ~450km/h in production, which is substantially faster than the TGV.
Not to mention that steel-rail trains are a completely different technology than maglevs. You might as well say, "so what, we've had airplanes that go >450km/h for 70 years."
Actually, that isn't correct. I've read Ben's bio, Kelly's bio, etc, and one of the things that struck me was that Kelly insisted on giving money back to the government when a project ran under budget (which happened more than once). Hell, even Have Blue (the precursor to the F-117) only cost $14 million/unit. Compare that to the "low cost" F-16, which is about $20m, or the $185 million "Tacit Blue," which was Northrop's first foray into world of stealth. $14m vs. $185m. Think about that.
Johnson and Rich were also proponents of having Lockheed engineers maintain their aircraft instead of having military personnel do it. Using Lockheed engineers would save a ton of money because they aren't rotated and therefore don't need to be retrained. Sure, Lockheed would get some money out of the deal, but not as much as the gov't would save.
The Skunk Works wasn't perfect, but overall they were pretty good with money under Kelly and Ben.
Good, Fast, and Cheap can happen, even in software. If the aircraft industry can pull it off, so can the software industry. Read up on the Lockheed Skunk Works. They did incredible stuff with very few engineers in a very short amount of time. The key is people. You need a top-notch staff and more often than not a world-class leader. Such a team is hard to come by, but when they do get together they can pull off some amazing stuff.
Slashdot Mirror
There are alternatives - Pepper Computer's Linux environment runs on the OLPC. It's more mature than the OLPC software, and was designed from the beginning for consumers. It focuses on web browsing and media rather than education, although it's possible to run things like eToys too. Pepper integrates Firefox, MPlayer, Helix, and a number of other open-source projects into something much simpler and easier to use than your standard GNOME/KDE clone of the Windows desktop. If you're at CES, stop by the booth for a hands-on demo of Pepper on the OLPC.
(I work for Pepper)
Have you looked at the Pepper Pad? Unlike the i-Opener it's portable (2.2lbs, built-in Wi-Fi so you can use it on your couch). Our third version, the Pepper Pad 3, has an x86 chip + runs a variant of Fedora Core. The software is based on Firefox 1.5. It includes Flash and Acrobat plugins, and has a popup blocker. It starts shipping this month.
We've designed the Pad and its software to be an appliance. The user never needs to interact with the underlying OS, although it is an option for those who want to. While we do provide software updates on a regular basis, the Pad can be configured not to get them.
Disclaimer: I work for Pepper.
We did.
The Pepper Pad has an 8.4", 800x600 screen, a 624Mhz Xscale CPU, a 20GB disk, Wi-Fi, bluetooth, USB, and a full keyboard for about $800. It runs Linux and includes both Firefox 1.5 and Flash 7.
For locomotives, in additon to the above modellers will often:
And that's just what they do for storebought locomotives and rolling stock. Scratchbuilding a locomotive can take weeks or months, depending on the level of detail.
Then there's the matter of scenery. Running trains around a circle of track gets pretty boring (unless you have a cat....). The good news is that you can build scenery to surround the trains. You get to build entire cities, towns, farms, rivers, mountains, hills, canyons, and industries from scratch. Basically anything you can imagine can be incororated into a model railroad. It's world-building in your basement (or garage, or spare room, or bookshelf).
For the electrically-minded, there are all sorts of fun wiring problems to be solved, and you can do many interesting things with computers if you want to (train scheduling, locomotive control, switch control, lighting, etc).
If you like spending time outdoors, you may enjoy harvesting plants, rocks and dirt for your layout so that it has authentic colors, shapes, and textures.
If you're a people person, you and your friends may enjoy operating sessions where everyone has a train and you're working cooperatively to service the industries along your route without creating gridlock.
If you like brainteasers, there are [railroad car] switching problems that can keep you busy for hours or days.
Model railroading is one of those rare hobbies where there's truly something for everyone. You can be as involved as you want, and since you're inventing as you go nobody can tell you that you did a bad job.
The problem is that technologies change over time. Tech-oriented frameworks make writing the app easier in the short run, but they don't consider the long-term life of the app. Applications that are tightly coupled to any given tech become a liability as that tech ages, and quite often migration to a new tech involves a ground-up rewrite of the application. Instead of tying the app to a framework like Struts or a tech like EJB, write the app to stand on its own, using interfaces to the various techs it needs. Particular technologies like Struts (for a web UI) or EJB (for persistence) can be swapped in + out of the application as necessary without changing the function of the application itself.
There are a number of benefits to a technology-agnostic approach like this. The technology implementations can be upgraded: find out that EJB is a dud? Switch to Hibernate! Perhaps more interestingly, the technology implementations can be supplemented: Have a web UI, but need to ship a desktop application too? Plug in the desktop app tech implementation and presto! You now have both a web UI and a Swing/SWT/etc UI for the same app. Testing becomes far easier too, because you have clearly defined boundaries between the different components of the app (so it's easy to figure out which part isn't behaving).
There are drawbacks, of course. To work as advertised you need to invest a fair amount of architecture to get such a system off the ground. Someone has to write the tech implementations, as well - an SWT UI for your app won't just fall out of the sky when you want it.
Everyone has their pet project. Mine is Sandboss, an approach to enterprise application development that's application-centric, not technology centric. It concentrates on the app itself - you don't wind up with a "Struts application" or an "EJB app". Instead you wind up with an application that can use Struts and EJB, but can also work with Hibernate and WebWork. It's not for everyone - it requires a fair amount of committment to the methodology - but it works well in practice. The time savings are pretty incredible, and the components really are reusable.
*There are many places where a front end for a database is all you need. Of course, once the requirements for that project start to grow you'll wish you had something more powerful.
Take a look at http://sandboss.org for an example of this in action. Sandboss is a tool for building enterprise apps, so it's rather domain-specific. It makes extensive use of generators as part of the build cycle, so you get the benefits without the BS. In the included sample app, a few hundred lines of application source get turned into 150,000+ lines of communication, configuration, persistence, serialization, and UI code (html, servlets, etc). That sounds like a lot (and it is), but that's 150k lines of code that you don't have to worry about maintaining.
Instead, XDoclet should let you specify what you want accomplished, not how you want it accomplished. The code generation engine should be smart enough to figure out how to accomplish the specific tasks. For example, you should be able to tell the generator "this object gets persisted," not "this object should have a corresponding entity bean named Foo that can be found in JNDI as FooEJB." That way you can switch to straight JDBC by swapping out your generator, instead of changing all those javadoc tags.
Granted, this approach isn't appropriate for all projects (especially legacy apps). It makes writing new apps much easier though, and if you ever have to switch app servers or web frameworks you'll be thrilled.
While I agree with you in principle - that better abstraction is usually the way to go - that's not always possible in the real world. For example, sometimes you have to produce an API for someone else, or hook up to their API. In those cases, better abstraction isn't always an option. Sometimes your boss says "you're using EJB" and you're stuck with it. In those cases a generator can be a big help.
The cool thing about integrating a generator into your build is that you get the benefits of abstraction without many of the drawbacks. The generator becomes your abstraction, so you can make modifications in one place. Sure, using a generator requires a little more thought than cut-n-paste. So does proper abstraction. The two aren't all that different, and both approaches have their place.
Unlike other generation engines, the Sandboss engine concentrates on the application requirements + not the implementation technologies (EJB/XML/etc). Using Sandboss, you can plug in new generators (to change the persistence layer from EJB to straight JDBC) without modifying your app's code *at all*. Generators like XDoclet embed technology dependencies right into your app's code, which makes switching technologies harder. I'm a developer on the project so perhaps I'm biased, but I think it's pretty damn cool.
The parent is right to warn about maintenance. Meta-progamming of any kind requires a little more thought + understanding than many coders are used to. Generators are basically power tools, and as with any power tool if you're not paying attention you're likely to get yourself into trouble.
Something else....one of the most important factors in VPC's speed is the size of the host processor's cache. The 1.42ghz machines have a 256k on-chip L2 cache and a 2MB L3 cache. That's pretty big, which benefits VPC. The extra 1MB of cache (compared to my Powerbook) is probably worth a few %.
Even with the second CPU and extra cache, I think that 750-800Mhz is about all you can reasonably expect from the 1.42ghz machines. Of course, I've never tried it so I could be wrong.
About the game market....does it really matter if there's a mac game market, if Windows games work just fine? Instead of late/non-existent/half-assed/broken/etc ports, Mac users would be able to run new games right when they came out. I bet they'd even be compatible with their PC counterparts, so people playing (say) Everquest wouldn't have to use Mac-only servers. That would be a *good* thing IMHO.
(FWIW, many games today require so much horsepower that emulation - even with 3D acceleration - simply wouldn't be feasible, so a port would be the only viable option for playing on the Mac anyway. That should keep the Mac game market up + running).
In my experience, VPC on a 1ghz powerbook runs at about the same speed as a 500mhz PIII with really slow disk and graphics subsystems. Unfortunately the disk + graphics systems put a damper on overall performance. The CPU emulation itself is quite fast, however. Depending on exactly what you're doing, it ranges from about .4x to .75x the speed of host's processor. On one of the new 1.42ghz towers, I'd expect to see CPU performance roughly equal to a 750mhz PIII.
Also keep in mind that games aren't a priority for the VPC team, and Connectix has repeatedly said that VPC is not a gaming solution.
The result is a convergence of AOP and model-driven architecture (MDA; another buzzword) that actually works. Writing enterprise apps with SAND is a joy, and there's even an open-source implementation on Sourceforge called "sandboss". (yeah, I'm a sandboss developer. It rocks).
AOP is definitely a buzzword, but it's here to stay because it makes things so much easier. It's not as applicable for consumer applications, but in the enterprise world it's a godsend. There are 2 different types of code you have to write in an enterprise app. First is the business logic - what the application does. The second part is the plumbing - how the application does it. This includes persistence, caching, user interfaces (web site, client application, etc), IPC, and so on. The first part is far more important than the second part, but the second part is where most of the time gets spent. A good AOP tool can drastically cut the time needed to put together the app's plumbing, and that's why AOP is here to stay.
Apple hurt Mozilla? The only thing that hurt Mozilla was Mozilla. And for the most part, the Mozilla developers know that already.
"Editors," indeed.
1.5MIPS seems awfully slow to me....like orders of magnitude slower than it should be. VirtualPC - a commerical product that emulates a PC - runs somewhere around the speed of a 233Mhz PII on my crufty old Powermac, which rockets along at 450Mhz. VPC provides full emulation of a PC the way Bochs does, but it's ~200x faster. That's an awfully big difference. What accounts for that difference? Is there any chance that Bochs will close the gap sometime soon? I'd much rather use a free product than VPC, but with a performance gap like that it's tough to justify...
The discovery that tetraethyl lead could prevent knock was huge leap forward; it was a huge boost to the automotive industry, since it allowed manufacturers to build safer/more reliable/more powerful/etc engines.
These days all we hear about are the health risks of tetraethyl lead (it's toxic as hell), but back in the early 1900's it was seen as a tremendous leap forward. Without it, cars, airplanes, etc would be very different today.
A little digging reveals that the frequencies that cell phones operate on aren't the same frequencies aircraft use for navigation/communication, and those $5/minute airphones are actually cellular telephones!
In fact, it turns out that the cell phone ban wasn't an FAA regulation until very recently - it was an FCC ban! The cell network isn't designed for rapidly-moving phones, nor is it designed for phones 30,000 feet up in the air. Instead, it's designed for stationary/slow-moving phones at or near ground level. An airborne cell phone can wreak havoc with the network; that's why the FCC banned them on airplanes. The ban has nothing to do with safety.
ZDNet article on the topic.
...which is why we need to keep building better frameworks. Struts attempts to point you in the right direction, but it's still fairly easy to abuse. Unfortunately, only a handful of the developers I've seen/heard/worked with actually have a clue on these things; most of them just want to get something built. Design is never a question in their mind - the only important thing is "what's easiest/what's fastest."
By choosing a more powerful framework, the consequences of such an approach can be mitigated. The key piece of a good framework IMHO is that the best way of doing things is also the easiest way of doing things. That way people looking to take the easy way out will wind up producing a better module than they would otherwise. Struts solves many of these problems, but it's still too easy to mush your application's functionality together with its implementation. The Struts doc even says something to the effect of "the obvious way is the easy way, but we don't recommend it." To me, that means the framework needs some help.
That's where MVC comes in. It forces to you think about your implementation instead of blindly charging forward. That's overkill for some projects, but IMHO it's absolutely necessary for others (i.e. any project where more than about 2 people need to touch the code). Otherwise you wind up spending more and more time on maintenance/adding features.
FWIW, Slashdot uses more of the spaghetti pattern than anything else...
If you're building an enterprise app, however, basing your app on Struts (or any other "web application" technology) isn't a good idea. Why? You wind up mixing your app's functionality with its implementation. Using an MVC framework like Struts alleviates this problem to a great deal, but when it comes down to it you still have a big pile of servlets that does everything from database access to presentation.
That approach isn't scalable, it's not adaptable to different technologies (there's a new webapp framework every week, it seems), it's not easy to integrate with other applications, and so on.
What's really needed is a way to define an application independently of the implementation details. Once you've defined the application, you can generate whatever interfaces it needs - like a Struts UI, an EJB persistence engine, etc. This is where my shameless plug begins: check out the Sandboss project for a way to define your enterprise app without being chained to a particular implementation detail like Struts or EJB.
While the techniques used in Sandboss are designed for the enterprise world, they're useful for web apps, too. I think it makes much more sense to over-engineer an application than it does to under-engineer it; overengineering takes more time up front but saves you 10x as much or more once development starts, since the well-don overengineered solution is more flexible and capable of responding to marketing's feature of the week. By picking Sandboss you get the best of both worlds - a robust framework where someone else has already done the engineering. You just define your app, and bam! Persistence, communication, control, the UI are all done for you.</shameless plug>
You state that the maglev needs "5km just to get up to 300 km/h." While correct, you neglect to compare this to ICE, which takes 30km to reach the same speed. Since there's no wheel/rail friction, maglevs can accelerate much more quickly than conventional high-speed trains.
Furthermore, maglev trains use less power than conventional high-speed trains once you get past about 200km/h. At 300km/h, ICE trains use 71 Wh/km. Maglevs use 47 Wh/km; a maglev could go 400km/h on the same amount of power it takes to get the ICE up to 300km/h.
Maglevs are also quieter, safer, easier to maintain (no moving parts!), and so on.
Not to mention that steel-rail trains are a completely different technology than maglevs. You might as well say, "so what, we've had airplanes that go >450km/h for 70 years."
Johnson and Rich were also proponents of having Lockheed engineers maintain their aircraft instead of having military personnel do it. Using Lockheed engineers would save a ton of money because they aren't rotated and therefore don't need to be retrained. Sure, Lockheed would get some money out of the deal, but not as much as the gov't would save.
The Skunk Works wasn't perfect, but overall they were pretty good with money under Kelly and Ben.
Good, Fast, and Cheap can happen, even in software. If the aircraft industry can pull it off, so can the software industry. Read up on the Lockheed Skunk Works. They did incredible stuff with very few engineers in a very short amount of time. The key is people. You need a top-notch staff and more often than not a world-class leader. Such a team is hard to come by, but when they do get together they can pull off some amazing stuff.