Not that this possibility isn't intriguing, but I certainly wouldn't want to have to be a manager in one the major European carriers for the next few months
The same rules apply for US carriers flying in EU, naturally. They'd be hurting just as much.
Don't forget that EU rules apply to all companies doing business in the EU, and that includes all US carriers flying into EU as well. So if the US bans flights for this reason, they will ban flights by US carriers as well as EU ones.
My main address is fairly old - I have been using it for over ten years. I've also been using it with wild abandon pretty much anywhere on the net for as far back as I can remember, and it attracts an absolutely ridiculous amount of spam today. If it was a person, it would have it's own red-carpeted VIP entrance at the veneral disease department at the university hospital.
I today filter with a bayesian filter, and only with a bayesian filter - I quit using those on-line services over a year ago. In addition I pre-approve some addresses to make sure I don't miss anything from people important to me. I see perhaps one spam every third day on average. It spikes temporarily when there's a shift in tactics - I get three or four a day - and then it calms down again to one a week or thereabouts.
The data analysis would have taken a few weeks if it weren't for some clever optimisations. So I don't think the time I spent on that is wasted time.
It's not wasted time if the time spent optimizing is less than the time saved. So for your example, assuming it wasn't algorithmic optimizations (which are orthogonal to doing funky assembler stuff), you may save a few days on a few weeks running time. So if the optimization took a couple of days of coding it may have been worth it. Otherwise it was not.
And for scientific apps especially, you really do have to factor in the added cost of tweaking the software - you _always_ need to tweak, often over many cycles - when part of it is as opaque and difficult to understand as assembly optimizations are (which often implies explicit use of the semi-parallel features of modern CPU_s today).
I have spamcop checking turned off. Maybe because the service is tuned to north american audiences, I don't know, but its recommendations seem completely arbitrary and frequently mistakenly marks genuine email for me. With two emails (from a legitimate source) one can be marked OK, the other one not.
By contrast, local filtering generally works excellenty. When I finally turned off all on-line checking, I have a perceptible bump in the quality of filtering.
Hand optimizing code is what I do as a game developer and I can assure you that it is very relevant to my job.
It makes sense for a game developer - and even more an embedded developer. You spend the time to optimize once, and then the code is run on hundreds of thousands or millions of sites, over years. The time you spend can effectively be amortized over all those customers.
For scientific software the calculation generally changes. You write code, and that code is typically used in one single place (the lab where the code was written), and only run a comparatively few times, indeed sometimes only once.
For a game developer to spend three months extra to shave a few seconds of one run of a piece of code makes perfect sense. For an embedded developer using a couple of months' worth of development cost to be able to use a slower, cheaper chip, shaving a dollar of the production of perhaps tens of millions of gadgets makes sense.
For a graduate student (cheap as they are in the funny-mirror economics of science) to spend three months to make one single run of a piece of software run a few hours faster does not make sense at all.
In fact, disregarding the inherent coolness factor of custom hardware, in most situations it just doesn't pay to make custom stuff for science when you can just run it for a little longer to get the same result. In fact, not infrequently have I heard about labs spending the time and effort to make custom stuff, but by the time they're done, the off the shelf hardware had already caught up.
The code has to be written, tested, debugged, usability tested, fought over on an include/exclude basis, documented, patent-checked, marketed, and supported. And as has been pointed out in comments: more features (or functions) means greater complexity and more chances for things to go wrong.
You're doing all of it anyway for the full-featured, very expensive, everything-but-the-kitchen-sink phones that are, don't forget, selling very well. Adding the software to lower-end phones is very cheap, since the margin cost is zero. Your argument that software is expensive only applies if a manufacturer decides to offer no models other than the basic ones (which would probably be market suicide even if there was interest in doing so).
I want a phone I can make calls with.
Great. Buy a phone you can make calls with and nothing else. All providers here in Japan, and in Sweden, at least, offer such models. If that is what you want, why haven't you bought such a one already? But as I argued in my parent post, chances are you're like everybody else and want a phone to make calls with - and one or two other simple fiunctions that differ from buyer to buyer.
The phone you argue for does exist. Multiple models, in fact, for every phone system out there. They don't sell very well, though.
I want a service that works. I want a bill that's predictable and reasonable. And I want as few strings as possible, to exercise my customer and citizen rights to walk if I'm not satisfied.
*shrug* get such a service. I've haven't had coverage problems either in Sweden nor here in Japan. I don't need to prepay minutes, I can change provider whenever I want while keeping my number, and I have never had any problems understanding my bill. You aren't happy with your service, walk away. Vote with your feet.
Problem is, manufacturers and providers are offering simple, stripped down, easy-to-use phones. And very few buy them. Just like simple, functional, easy DVD players; simple internet terminals and so on.
One problem is, simple phones aren't appreciably cheaper to produce since most of the differences lie in software, so the simple phones don't get a lot cheaper (and especially so when the phone is offered as part of a package deal).
A second problem is the lure of features. We like long lists of features, _especially_ for technology we aren't too familiar with. After all, since we aren't familiar with it, we don't know what functions will turn out to be important, so better get as much ass possible.
Third, even among us that want a simple phone, there creeps in a "that can also...". Just look at the other comments to this story. I want a simple phone - that can also do good email, since I in practice use email more than speech. Oh, and having a radio on it is essential, so I don't have to lug around a second device. For other people, real email is pointless and radio is a waste - but they really want that integrated camera since it's such a convenient way to communicate (was it this part you wanted me to buy or was that one?). For a third person, having a Java VM for a steady supply of small games to play during their commute is critical, though they have no interest in any other function.
So, you could not make a simple telephone with mass market appeal. You would have to make a whole series of phones, all with different combinations of features. Which of course in practice means making one or two hardware designs, and selectively disable stuff in software. But then, of course, the users can simply refrain from using the features they don't want; they'r enot going to pay as much for the identical hardware but with less functionality, after all. Which brings us right back to where we are now.
On my phone, I have a web browser, music shop service, IR remote controller, OCR translation from English to Japanese, and probably a dozen other features I don't even remember. I simply don't use them, which suits me fine. It doesn't bother me that I have a set of icons I don't use, since the functions I do use - radio, email and sound player - are implemented well, and since I have them assigned on hotkeys, bypassing the need to ever delve into the interface itself.
We have been doing effectively this for a couple of years; I stay in a rented room close to work during the week and we see each other during the weekends (it's changing this month though). However, and that's the big one, we have no children and live in an apartment - running the household by yourself is thus no problem. With children and a house (and, I guess, a daily commute for your spouse as well) things are of course more difficult.
If you can, yes, you probably should move. But beyond the important issues of your spouses career and what moving will do for your total cost of living, you really do need to consider the possible downside: what happens if you lose your nice, high-paying job? If your spouse does not have a job at the new place, what would happen to your economy? If you need to borrow a large sum for a new home, what will happen with those payments? Is the area you move to filled with opportunities in your field so it's easy to find a new job, or do you need to budget for a possible second move if you lose this job?
I remember reading an article not to long ago where a company painted a fly onto each urinal in an effort to keep them peeing in the ideal spot to reduce mess.
It's pretty common today; you see some variation everywhere. It started, if I remember correctly, at Kastrup airport in Denmark. The idea is pretty sound too - give people somewhere, anywhere, to aim, and they'll prefer doing so (and no, the exit drain doesn't count because of the splashback).
I don't know if it's possible in the US, but here in Japan, a common range of punishments for corporation is to forbid them from bidding for public contracts for a period of time; forbid taking on new customers for some period; or, the most serious, forbid any business activity at all.
For instance, recently one consumer loan shark^H^H^H^Hcorporation was found guilty of breaching rules regarding non-payment of customers, and had their operations partially stopped for a couple of weeks (which becomes very expensive, especially since they still need to pay salaries and all other business costs). And PriceWaterhousCooper's Japanese office has been found guity of cooking the books on some large corporations and has been suspended for a couple of months, leaving clients like Sony scrambling to find a replacement (and quite possibly killing the accounting firm altogether here in Japan).
Possibly the biggest problem working on this laptop is its small 12' screen. I wish I could see what kind of resolution that results in but I can't see the screen in any of these shots.
My current laptop has a 10.4' screen at 1024x768, and I actually use it as my main machine, both for writing and development. My plan was to complement this machine with a full-size desktop, but that purchase got delayed for various reasons and I found I don't need one after all.
Yes, the screen is small, but since I sit close to it (the whole machine being compact), it's not a problem for me in practice.
Well, it makes you wonder whether you have been to any conference that included even a small social-like part where no one causes some stir. Usually, with alcohol involved.
I've been to any number of conference dinners large and small, and you'd be amazed how often people do not start fights. I have never seen that happen, in fact.
I think that becoming more modular than now is probably not feasible. You have so tight constraints on heat dissipation, for instance, that adding a higher-performance graphics card, or higher clocked cpu could well end up killing your laptop. And with everybody wanting the smallest, lightest package possible within their other design constraints, I don't really see manufacturers adding "spare" capacity in any but the largest, heaviest desktop replacement machines.
You do have quite a bit of upgradeability with PC cards, USB2 and upcoming high-performance connectors. These connectors are easy to design for, in the sense that the manufacturer knows the highest allowable poser draw, heat dissipation and so on. I don't think you'll ever see real modularity beyond that.
Instead, there's been a pretty steady trend the past few years that the highest possible performance is no longer as important. It used to be you needed to upgrade your machine with every new high-impact game, or every new version of your word processing app. Purely anectotally, this does not seem to be the case anymore; a three year old machine is still perfectly able to run just about everything you want to throw at it. And for laptops, the upgrade cycle is definitively dampened by other constraints; the newest version of my (soon) two year old machine has an 1.3Ghz cpu rather than mine 1.1Ghz, and the integrated graphics are presumably a bit faster.
So, my feeling on this is that instead of becoming a lot modular, it's becoming steadily less important to be upgradeable in the first place. There's little point in being able to upgrade the CPU if the original one is still well in the game after three or four years, when you'd be thinking about replacing the machine anyhow.
Those who want to have all the latest and greatest are most likely to use a desktop in any case, since the absolute performance of a fast tower machine is going to kill any laptop, and at a lower cost. That's where upgradeability makes sense.
I have the same issue with ordinary mice. The problem I have, I think (this is anectotal, not researched), is that the mouse positioning is analog (pixel level positioning at least), while the object of interaction, the text, is digital (discrete secuence of characters). It is altogether possible that if the mouse driver code was written to only allow the marker to jump around in full character increments, that it would become a bit easier. Ideally, you'd have tactile feedback on the device itself to feel those discrete jumps as well.
And yes, I know about TOG's views on this - I have taught usability design - and I have three comments on it, basically:
First, his is one study on this, and one study does not a truth make. Second, it is demonstrably false in the particular case of myself - it is really, objectively slower for me.
And third - and most important - his study famously does not adress _why_ the keyboard feels faster: it feels faster precisey because of what I wrote above, in that you do not lose focus on your task to the same degree as switching input modality does. Measuring only the time from starting to mark to the time the text is moved is disingenious; what should be measured is the time from stop writing to the point you start writing again - or even better, total time to produce the text, thus fully accounting for the effects on task focus disruption.
This goes the other way too, of course: good professional graphics applications allow you to select all common operations by just touching particular spots on the graphics tablet so the user does not have to disrupt their workflow by going to the keyboard or other ancilliary device needlessly.
My distaste has nothing to do with the interaction style per se. For me, with a trackpad it is a real pain to position the pointer to within the accuracy of one character; I have to actually drop focus on what I was doing, look straight at the point I want to be and concentrate on the positioning, which is exactly opposite of what I should be doing (ie. focus on my writing, not on operation of the computer). How the editor uses the mouse is beside the point for me, since just having to use it means I've already lost my concentration and brought my writing to a grinding halt.
And since you're using the keyboard for text input anyhow, using it for movements and operations as well is no extra burden; or are you using the mouse rather than the keyboard for character deletion, cursor movement and new line as well? Perhaps an on-screen keyboard where you can click the characters with the mouse would work for you, so you don't need to use the keyboard at all?
...about 30 days of using acme to be sufficiently sold you'll never go back to vi.
Assuming you're not sitting on a laptop, where "chording" will be anything between an annoying pain and impossible.
In this I'm with other commenters - a large part of why I started using Vi is because I can use it very efficiently without ever having to touch the mouse. For me, what this editor promises is very close to hell on earth as far as editors are concerned.
and you highlight make debug and middle click(I don't remember exactly which button do what) for instance and it will run, making the debug build.
Or you could have that window open, higlight "make debug" and middle click in any shell window with that working directory and it will run the debug build. No special editor necessary.
putting up some kind of special signs - along the major roads, perhaps, or on buildings. Then you print some really _huge_ images to put on those sign things; some inspirational image, like the space shuttle and an astronaut against the earth seen from space. And then, to cap it off, print some short text, something kind of punchy and really easy to remember, on top. You know, something like "The Shuttle - Don't Leave Home Without It", or "Call NASA For a Good Time". Perhaps with an URL printed small so people can go find out more.
You know, I bet that if you paid a few magazines or newspapers enough, they'll be sure to agree to print the same images too. And maybe do the same for some television show - I bet _that_ will really make people sit up and take notice!
Now, tell a government inspector to take apart a Lenovo and verify that there are no spychips in it. They'll simply laugh and say, "It has spent time outside of this country, it cannot be used to store or process sensitive information." This isn't saying "Chinese bad," it's simply a fail safe security measure for them.
And why does this not go for the subsystems in any computer, not just the assembled whole? How do you for a fact know that the IC in that ethernet board or video card really is bog standard and not a "special" version? How do you know that the motherboard does not have a few "extras" implemented, in hardware or in the BIOS? They've all been manufactured abroad, after all.
With your logic, nothing that isn't built ground up within the US borders should be allowed - and good luck with that.
No, to paraphrase Freud, sometimes a xenophobix knee-jerk reaction is just a xenophobic knee-jerk reaction.
Well, neither definition strictly holds. IIRC, you can follow the spread of one seagull species eastwards from northern Europe, and it can (and does) interbreed all along the way. But by the time you come back around to England, it is a different species, no longer able to interbreed with the species you started with. There is a chain of fink species across Asia with a similar structure as well.
And having the same number and structure of chromosomes is not always a prerequisite to be able to interbreed either.
A tangential comment: You say a large part of your problem is a convoluted, complex architecture that's been growing for some years. That happens - in fact, it's probably inevitable to some extent, whenever you have a codebase that needs to change as requirements and use-cases do.
And to solve that problem, doing a redesign and rewrite (or a close analogue) is probably a good idea, no matter what language you'd be doing it in. You need to get rid of all cruft, strange corner cases and mismatches between the envisioned architecture and the reality. Look at any large, well established OSS project and you'll see that they've done that too, sometimes more than once. And if you're going to rebuild from the ground up, more or less, you might as well take advantage of the better tools that's become available as well. And from C++, any of the newer development languages - whether Java, C# or even Perl/Python/Ruby - would probably be a step up in development speed and maintainability.
Of course, OSS projects are also a showcase for how wrong it can go. You do need ample time and resources to do it - a rush job will just make the new system as bad as the old one, but with all-new problems in addition to the old ones. You also need serious constraints. Without them you'll inevitably succumb to feature creep ("wouldn't it be nice if we could..."), which will kill the system just as surely as a crappy reimplementation would.
For every OSS project out there who did a redesign and rewrite and came out stronger, faster and better for it, there is a project that started a redesign just to get rid of cruft, went off into the design neverland and never appeared again, suicided by the endless opportunities that rewrite gave them.
I think the use of Java is beside the point. The opportunities and pitfalls lie with the redesign and reimplementation. The tools are just an implementation detail.
Slashdot Mirror
Not that this possibility isn't intriguing, but I certainly wouldn't want to have to be a manager in one the major European carriers for the next few months
The same rules apply for US carriers flying in EU, naturally. They'd be hurting just as much.
Don't forget that EU rules apply to all companies doing business in the EU, and that includes all US carriers flying into EU as well. So if the US bans flights for this reason, they will ban flights by US carriers as well as EU ones.
My main address is fairly old - I have been using it for over ten years. I've also been using it with wild abandon pretty much anywhere on the net for as far back as I can remember, and it attracts an absolutely ridiculous amount of spam today. If it was a person, it would have it's own red-carpeted VIP entrance at the veneral disease department at the university hospital.
I today filter with a bayesian filter, and only with a bayesian filter - I quit using those on-line services over a year ago. In addition I pre-approve some addresses to make sure I don't miss anything from people important to me. I see perhaps one spam every third day on average. It spikes temporarily when there's a shift in tactics - I get three or four a day - and then it calms down again to one a week or thereabouts.
The data analysis would have taken a few weeks if it weren't for some clever optimisations. So I don't think the time I spent on that is wasted time.
It's not wasted time if the time spent optimizing is less than the time saved. So for your example, assuming it wasn't algorithmic optimizations (which are orthogonal to doing funky assembler stuff), you may save a few days on a few weeks running time. So if the optimization took a couple of days of coding it may have been worth it. Otherwise it was not.
And for scientific apps especially, you really do have to factor in the added cost of tweaking the software - you _always_ need to tweak, often over many cycles - when part of it is as opaque and difficult to understand as assembly optimizations are (which often implies explicit use of the semi-parallel features of modern CPU_s today).
I have spamcop checking turned off. Maybe because the service is tuned to north american audiences, I don't know, but its recommendations seem completely arbitrary and frequently mistakenly marks genuine email for me. With two emails (from a legitimate source) one can be marked OK, the other one not.
By contrast, local filtering generally works excellenty. When I finally turned off all on-line checking, I have a perceptible bump in the quality of filtering.
Hand optimizing code is what I do as a game developer and I can assure you that it is very relevant to my job.
It makes sense for a game developer - and even more an embedded developer. You spend the time to optimize once, and then the code is run on hundreds of thousands or millions of sites, over years. The time you spend can effectively be amortized over all those customers.
For scientific software the calculation generally changes. You write code, and that code is typically used in one single place (the lab where the code was written), and only run a comparatively few times, indeed sometimes only once.
For a game developer to spend three months extra to shave a few seconds of one run of a piece of code makes perfect sense. For an embedded developer using a couple of months' worth of development cost to be able to use a slower, cheaper chip, shaving a dollar of the production of perhaps tens of millions of gadgets makes sense.
For a graduate student (cheap as they are in the funny-mirror economics of science) to spend three months to make one single run of a piece of software run a few hours faster does not make sense at all.
In fact, disregarding the inherent coolness factor of custom hardware, in most situations it just doesn't pay to make custom stuff for science when you can just run it for a little longer to get the same result. In fact, not infrequently have I heard about labs spending the time and effort to make custom stuff, but by the time they're done, the off the shelf hardware had already caught up.
The code has to be written, tested, debugged, usability tested, fought over on an include/exclude basis, documented, patent-checked, marketed, and supported. And as has been pointed out in comments: more features (or functions) means greater complexity and more chances for things to go wrong.
You're doing all of it anyway for the full-featured, very expensive, everything-but-the-kitchen-sink phones that are, don't forget, selling very well. Adding the software to lower-end phones is very cheap, since the margin cost is zero. Your argument that software is expensive only applies if a manufacturer decides to offer no models other than the basic ones (which would probably be market suicide even if there was interest in doing so).
I want a phone I can make calls with.
Great. Buy a phone you can make calls with and nothing else. All providers here in Japan, and in Sweden, at least, offer such models. If that is what you want, why haven't you bought such a one already? But as I argued in my parent post, chances are you're like everybody else and want a phone to make calls with - and one or two other simple fiunctions that differ from buyer to buyer.
The phone you argue for does exist. Multiple models, in fact, for every phone system out there. They don't sell very well, though.
I want a service that works. I want a bill that's predictable and reasonable. And I want as few strings as possible, to exercise my customer and citizen rights to walk if I'm not satisfied.
*shrug* get such a service. I've haven't had coverage problems either in Sweden nor here in Japan. I don't need to prepay minutes, I can change provider whenever I want while keeping my number, and I have never had any problems understanding my bill. You aren't happy with your service, walk away. Vote with your feet.
Problem is, manufacturers and providers are offering simple, stripped down, easy-to-use phones. And very few buy them. Just like simple, functional, easy DVD players; simple internet terminals and so on.
...". Just look at the other comments to this story. I want a simple phone - that can also do good email, since I in practice use email more than speech. Oh, and having a radio on it is essential, so I don't have to lug around a second device. For other people, real email is pointless and radio is a waste - but they really want that integrated camera since it's such a convenient way to communicate (was it this part you wanted me to buy or was that one?). For a third person, having a Java VM for a steady supply of small games to play during their commute is critical, though they have no interest in any other function.
One problem is, simple phones aren't appreciably cheaper to produce since most of the differences lie in software, so the simple phones don't get a lot cheaper (and especially so when the phone is offered as part of a package deal).
A second problem is the lure of features. We like long lists of features, _especially_ for technology we aren't too familiar with. After all, since we aren't familiar with it, we don't know what functions will turn out to be important, so better get as much ass possible.
Third, even among us that want a simple phone, there creeps in a "that can also
So, you could not make a simple telephone with mass market appeal. You would have to make a whole series of phones, all with different combinations of features. Which of course in practice means making one or two hardware designs, and selectively disable stuff in software. But then, of course, the users can simply refrain from using the features they don't want; they'r enot going to pay as much for the identical hardware but with less functionality, after all. Which brings us right back to where we are now.
On my phone, I have a web browser, music shop service, IR remote controller, OCR translation from English to Japanese, and probably a dozen other features I don't even remember. I simply don't use them, which suits me fine. It doesn't bother me that I have a set of icons I don't use, since the functions I do use - radio, email and sound player - are implemented well, and since I have them assigned on hotkeys, bypassing the need to ever delve into the interface itself.
We have been doing effectively this for a couple of years; I stay in a rented room close to work during the week and we see each other during the weekends (it's changing this month though). However, and that's the big one, we have no children and live in an apartment - running the household by yourself is thus no problem. With children and a house (and, I guess, a daily commute for your spouse as well) things are of course more difficult.
If you can, yes, you probably should move. But beyond the important issues of your spouses career and what moving will do for your total cost of living, you really do need to consider the possible downside: what happens if you lose your nice, high-paying job? If your spouse does not have a job at the new place, what would happen to your economy? If you need to borrow a large sum for a new home, what will happen with those payments? Is the area you move to filled with opportunities in your field so it's easy to find a new job, or do you need to budget for a possible second move if you lose this job?
I remember reading an article not to long ago where a company painted a fly onto each urinal in an effort to keep them peeing in the ideal spot to reduce mess.
It's pretty common today; you see some variation everywhere. It started, if I remember correctly, at Kastrup airport in Denmark. The idea is pretty sound too - give people somewhere, anywhere, to aim, and they'll prefer doing so (and no, the exit drain doesn't count because of the splashback).
Hmm, I wonder what this "preview" button is for? I guess I'll never know.
A couple of years ago this thesis was published at the CompSci department in Lund. It's 200 pages about component-oriented programming, segueing into almost a thousand pages about the moral and ethical ramification on computation in general. He did pass, but only just; many people thought it really was two theses in one, and that the philosophical part really should have been presented at the philosophy department, not in computer science.
It is both difficult to jail a corporation
I don't know if it's possible in the US, but here in Japan, a common range of punishments for corporation is to forbid them from bidding for public contracts for a period of time; forbid taking on new customers for some period; or, the most serious, forbid any business activity at all.
For instance, recently one consumer loan shark^H^H^H^Hcorporation was found guilty of breaching rules regarding non-payment of customers, and had their operations partially stopped for a couple of weeks (which becomes very expensive, especially since they still need to pay salaries and all other business costs). And PriceWaterhousCooper's Japanese office has been found guity of cooking the books on some large corporations and has been suspended for a couple of months, leaving clients like Sony scrambling to find a replacement (and quite possibly killing the accounting firm altogether here in Japan).
Could we perhaps see a Wii/DS-Lite combo pack for 40k yen? Either way, Nintendo has just sold me my new toy come winter.
Possibly the biggest problem working on this laptop is its small 12' screen. I wish I could see what kind of resolution that results in but I can't see the screen in any of these shots.
My current laptop has a 10.4' screen at 1024x768, and I actually use it as my main machine, both for writing and development. My plan was to complement this machine with a full-size desktop, but that purchase got delayed for various reasons and I found I don't need one after all.
Yes, the screen is small, but since I sit close to it (the whole machine being compact), it's not a problem for me in practice.
Well, it makes you wonder whether you have been to any conference that included even a small social-like part where no one causes some stir. Usually, with alcohol involved.
I've been to any number of conference dinners large and small, and you'd be amazed how often people do not start fights. I have never seen that happen, in fact.
I think that becoming more modular than now is probably not feasible. You have so tight constraints on heat dissipation, for instance, that adding a higher-performance graphics card, or higher clocked cpu could well end up killing your laptop. And with everybody wanting the smallest, lightest package possible within their other design constraints, I don't really see manufacturers adding "spare" capacity in any but the largest, heaviest desktop replacement machines.
You do have quite a bit of upgradeability with PC cards, USB2 and upcoming high-performance connectors. These connectors are easy to design for, in the sense that the manufacturer knows the highest allowable poser draw, heat dissipation and so on. I don't think you'll ever see real modularity beyond that.
Instead, there's been a pretty steady trend the past few years that the highest possible performance is no longer as important. It used to be you needed to upgrade your machine with every new high-impact game, or every new version of your word processing app. Purely anectotally, this does not seem to be the case anymore; a three year old machine is still perfectly able to run just about everything you want to throw at it. And for laptops, the upgrade cycle is definitively dampened by other constraints; the newest version of my (soon) two year old machine has an 1.3Ghz cpu rather than mine 1.1Ghz, and the integrated graphics are presumably a bit faster.
So, my feeling on this is that instead of becoming a lot modular, it's becoming steadily less important to be upgradeable in the first place. There's little point in being able to upgrade the CPU if the original one is still well in the game after three or four years, when you'd be thinking about replacing the machine anyhow.
Those who want to have all the latest and greatest are most likely to use a desktop in any case, since the absolute performance of a fast tower machine is going to kill any laptop, and at a lower cost. That's where upgradeability makes sense.
I have the same issue with ordinary mice. The problem I have, I think (this is anectotal, not researched), is that the mouse positioning is analog (pixel level positioning at least), while the object of interaction, the text, is digital (discrete secuence of characters). It is altogether possible that if the mouse driver code was written to only allow the marker to jump around in full character increments, that it would become a bit easier. Ideally, you'd have tactile feedback on the device itself to feel those discrete jumps as well.
And yes, I know about TOG's views on this - I have taught usability design - and I have three comments on it, basically:
First, his is one study on this, and one study does not a truth make. Second, it is demonstrably false in the particular case of myself - it is really, objectively slower for me.
And third - and most important - his study famously does not adress _why_ the keyboard feels faster: it feels faster precisey because of what I wrote above, in that you do not lose focus on your task to the same degree as switching input modality does. Measuring only the time from starting to mark to the time the text is moved is disingenious; what should be measured is the time from stop writing to the point you start writing again - or even better, total time to produce the text, thus fully accounting for the effects on task focus disruption.
This goes the other way too, of course: good professional graphics applications allow you to select all common operations by just touching particular spots on the graphics tablet so the user does not have to disrupt their workflow by going to the keyboard or other ancilliary device needlessly.
My distaste has nothing to do with the interaction style per se. For me, with a trackpad it is a real pain to position the pointer to within the accuracy of one character; I have to actually drop focus on what I was doing, look straight at the point I want to be and concentrate on the positioning, which is exactly opposite of what I should be doing (ie. focus on my writing, not on operation of the computer). How the editor uses the mouse is beside the point for me, since just having to use it means I've already lost my concentration and brought my writing to a grinding halt.
And since you're using the keyboard for text input anyhow, using it for movements and operations as well is no extra burden; or are you using the mouse rather than the keyboard for character deletion, cursor movement and new line as well? Perhaps an on-screen keyboard where you can click the characters with the mouse would work for you, so you don't need to use the keyboard at all?
...about 30 days of using acme to be sufficiently sold you'll never go back to vi.
Assuming you're not sitting on a laptop, where "chording" will be anything between an annoying pain and impossible.
In this I'm with other commenters - a large part of why I started using Vi is because I can use it very efficiently without ever having to touch the mouse. For me, what this editor promises is very close to hell on earth as far as editors are concerned.
and you highlight make debug and middle click(I don't remember exactly which button do what) for instance and it will run, making the debug build.
Or you could have that window open, higlight "make debug" and middle click in any shell window with that working directory and it will run the debug build. No special editor necessary.
putting up some kind of special signs - along the major roads, perhaps, or on buildings. Then you print some really _huge_ images to put on those sign things; some inspirational image, like the space shuttle and an astronaut against the earth seen from space. And then, to cap it off, print some short text, something kind of punchy and really easy to remember, on top. You know, something like "The Shuttle - Don't Leave Home Without It", or "Call NASA For a Good Time". Perhaps with an URL printed small so people can go find out more.
You know, I bet that if you paid a few magazines or newspapers enough, they'll be sure to agree to print the same images too. And maybe do the same for some television show - I bet _that_ will really make people sit up and take notice!
Now, tell a government inspector to take apart a Lenovo and verify that there are no spychips in it. They'll simply laugh and say, "It has spent time outside of this country, it cannot be used to store or process sensitive information." This isn't saying "Chinese bad," it's simply a fail safe security measure for them.
And why does this not go for the subsystems in any computer, not just the assembled whole? How do you for a fact know that the IC in that ethernet board or video card really is bog standard and not a "special" version? How do you know that the motherboard does not have a few "extras" implemented, in hardware or in the BIOS? They've all been manufactured abroad, after all.
With your logic, nothing that isn't built ground up within the US borders should be allowed - and good luck with that.
No, to paraphrase Freud, sometimes a xenophobix knee-jerk reaction is just a xenophobic knee-jerk reaction.
Well, neither definition strictly holds. IIRC, you can follow the spread of one seagull species eastwards from northern Europe, and it can (and does) interbreed all along the way. But by the time you come back around to England, it is a different species, no longer able to interbreed with the species you started with. There is a chain of fink species across Asia with a similar structure as well.
And having the same number and structure of chromosomes is not always a prerequisite to be able to interbreed either.
A tangential comment: You say a large part of your problem is a convoluted, complex architecture that's been growing for some years. That happens - in fact, it's probably inevitable to some extent, whenever you have a codebase that needs to change as requirements and use-cases do.
And to solve that problem, doing a redesign and rewrite (or a close analogue) is probably a good idea, no matter what language you'd be doing it in. You need to get rid of all cruft, strange corner cases and mismatches between the envisioned architecture and the reality. Look at any large, well established OSS project and you'll see that they've done that too, sometimes more than once. And if you're going to rebuild from the ground up, more or less, you might as well take advantage of the better tools that's become available as well. And from C++, any of the newer development languages - whether Java, C# or even Perl/Python/Ruby - would probably be a step up in development speed and maintainability.
Of course, OSS projects are also a showcase for how wrong it can go. You do need ample time and resources to do it - a rush job will just make the new system as bad as the old one, but with all-new problems in addition to the old ones. You also need serious constraints. Without them you'll inevitably succumb to feature creep ("wouldn't it be nice if we could..."), which will kill the system just as surely as a crappy reimplementation would.
For every OSS project out there who did a redesign and rewrite and came out stronger, faster and better for it, there is a project that started a redesign just to get rid of cruft, went off into the design neverland and never appeared again, suicided by the endless opportunities that rewrite gave them.
I think the use of Java is beside the point. The opportunities and pitfalls lie with the redesign and reimplementation. The tools are just an implementation detail.