The best of both worlds is somewhere in between. The vendor should provide optimizations for whatever they can, given time and budget, but they should also provide a mechanism for the user to tweak settings for non-vendor-optimized software. It's my perception that this is what both Nvidia and AMD do, through their respective control panels.

The vendor that doesn't try to optimize anything on their own isn't going to look good enough in benchmarks to make any sales, but the vendor that doesn't allow the end-user to experiment with their own settings won't do well in the PC gaming market, where a lot of users like being able to experiment with settings to find the ones that they're happy with.

Well, yes, either we'd have spent the time to write something in-house or gotten it from other businesses that have those components as their products. We'd either lose the extra dev time or the extra money; either way, the business would function less efficiently, we'd have fewer resources to build the "real" functionality of the product, and we'd have a less-capable product. I see that as a net detriment.

Someday, perhaps we'll have to come to the time where all necessary software has been written. We're a ways off from that. Just within the products that I'm involved in, we've got plans for thousands of people-years of development.

I think a more comparable situation would be another company paying a bunch of foreign coders from a cheap (but not free) labor market to write a clone of the product and sell it for cheaper than my employer does (due to flouting some kind of legal requirement). And in that situation, I'd probably feel about how the taxi drivers do right now.

No. Front pocket = front pocket on a pair of pants/trousers (as opposed to the back pocket, where many people would keep their wallet).

It'll be just one more step toward, "People don't need to work, because everything that's necessary for human survival can be done by something that isn't a person". I think that we'll end up getting to that point eventually, whether or not we want it. It'll either be an opportunity for a post-scarcity economy or for the ultimate artificial-scarcity economy.

It's not clear to me how that would be a "no true Scotsman" argument. You made a statement that says (paraphrased) "the U.S. economy flourished under regulation". TheMightyYar stated (again, paraphrased) "Yes, but in spite of the reason that you stated, not because of it". You would be right if they said something more like "That's not real flourishing, [example] is real flourishing!"

In theory, those coders are increasing overall efficiency of software development (including commercial sw dev) by reducing duplication of effort among different companies. They do work on their pet project, and that work can benefit whoever wants to use it (barring difficulties with the code license). It's not clear to me that there's a comparable benefit in the situation with cab drivers. Pulling work from the pool of available clients decreases the amount of work that needs to be done at a given time. As far as I can tell in software, the pool of work that needs to be done is nearly infinite.

No, I work for $0 an hour on projects that interest me, but which don't seem to have potential as money-making products.

If public transportation could fill my needs as well as a car on a day-to-day basis, then of course I would. It would be reasonable to rent a car a couple times a year for longer family trips, where we might want to go further off the beaten path, or something.

The problem I see: Where I live is spread out. The nearest grocery store is several miles away, other major stores and restaurants are a similar distance (or more), and family and friends are located in a half-dozen similarly-spread cities nearby ("nearby" being 30 minutes to 2 hours by car). I like my current lifestyle. Whatever theoretical mode of transport I'd be using needs to accommodate itself to how I want to live; that's the great benefit to me of using a car. I'd accept up to a 15 minute wait time, but require that the transit time would be less than or equal to what I can currently do in a car. The only technology I know of that could provide that would be a fleet of auto-driving cars that act as a kind of automated Uber service.

Why do you need a $35 full Android device if you can already buy a $15 full Android device? The Chromecast does things for me that my other Android devices don't, and that has value for me. Just another Android stick? Meh, I don't need it. If I want something like that, I'll hook my old phone up to TV with MHL and control it over VNC from my newer phone.

Apple notebooks also don't have separate buttons. They click, but they're also integrated into the touchpad. Other than that, they're very nice.

The confusion may have come in because that's the exact opposite of what the original article is about (that is, you mention the users that require change, rather than the ones that require stability). That brings up the point that there are dueling requirements; some users implicitly require the interface to stay exactly the same, even at the cost of not introducing new functionality. Other users explicitly require new functionality to be added, even at the cost of relearning a new interface. We need ways to serve both demographics.

Well, Firefox allows a fair amount of UI customization. Some websites do, as well. I also like the idea of a "basic", "lite", or "classic" interface, where the most common functions are easily available and don't change around much, along with an "advanced" (but less stable) interface that gives easier access to all the bells and whistles.

Because a project thrives when it has users interested in it and (more importantly) using it. Projects that don't give users what they want, or which start doing things that users *don't* want will lose their mindshare to another project. Now, if it's just a case of developers scratching an itch and having users doesn't matter, then that's different, of course.

386 is supported up to the 3.7 kernel, and the 3.8 kernel was widely announced (and designed) to break 386 support. I've got an ARM system with 128MB of RAM, and it runs GCC 4.2 just fine. I can't imagine that an X86 version would be *that* much heavier that it wouldn't run. Of course, if I try to compile large, modern projects (with output binaries in the hundreds of MB, sometimes), it goes to swap *really* darned fast, but what did you expect? If I'm compiling the size of project that will actually run in the amount of RAM available on the system, without swapping, it works just fine.

Because it sucks when you realize that you don't have enough USB ports to plug in the full variety of external hardware that you might want to use in the system, and that'd be a goofy requirement anyhow. Either you have to plug in all the hardware you want to support, or you're back to enabling hardware one piece at a time manually in the kernel configuration.

Basically, it's a neat concept, but it might not be practical, and if you're at the point where you want/need to compile your own kernel, then it's reasonable to assume that you *will* know what hardware is in your machine, that you'll do the research to figure it out, or at least that you'll discover it by trial and error.