as if that wouldn't be bad enough, but you would have the RIAA and MPAA charging you for thinking of a song or rememberinga scene from a movie.

If anyone ever figures out how telepathy can work, I predict WW III will be between advertisers and a very angry public.

Ah, trains, a safe haven for travelers for decades, now the science of pushing crap on people who don't want it has invaded your vestibules.

I road on Amtrak years ago and could not for the life of me understand why the bar car had an announcer, who broadcast throughout the train, in a voice not unlike a Harley Davidson exhaust tube by your ear, what wonderful deals they still had on drinks ... at 10 PM.

Maybe we already have the materials, but the convention is to stick (ha) with what works.

Perhaps also a little static generator could polarize dust so it is more attracted to the asteroid than a craft.

When actual 3D displays become commercially available at consumer prices, you'll see 3D programming and support all across the spectrum, no pun intended. Stereovision is a cheap, headache-inducing hack, and one thing it isn't is "3-D."

So you just take along a little compressed air and repel the stuff before it gets there. This would be one very, very slow avalanche.

And it doesn't exist on mobile phones.

That's a problem with mobile devices; not with Qt. Mobile phones are still pretty weak computing platforms; but give it time, and we'll be doing more and more serious things with them. We'll have higher resolution (and probably projected to holographic) displays, more compute power, more power supply available, better charging regimes, lots more memory of all kinds (working RAM and longer term storage), better input mechanisms (speech, for one) and so forth.

Mobile devices started out as pretty much weak platforms -- Palm, etc. Today, they're much more powerful, but they're not even *close* to a desktop, and pretending they are does no one any good. More to do; more to come. And that's a good thing, really.

it's not a bad thing, but it's not even accurate. .NET isn't going to produce cross-plaform apps. Qt will (with some limitations, but it's like 98% there. I write some *big* apps in Qt, and have been fairly successful at the cross-platform thing, though I do all my development under OSX.)

Mr. Troll is, to be blunt, bewildered.

I use Qt extensively, and while there are numerous reasons to sing its praises, the project has a severe problem in the form of not fixing bugs (like file open dialogs dumping huge amounts of console errors) or limitations (like a windows audio sample rate of 48 khz) before proceeding to new versions.

What that causes is applications that are unstable either because the existing bug hasn't been fixed, or unstable because they get moved to an arbitrary new version with many changes -- and very few applications are as extensively tested against the new version as compared to the old during the initial design and implementation phase.

On the one hand, Qt has enabled me to make apps that (mostly) work the same using the same code under Windows and OSX. But it also causes me a lot of angst trying to explain to my users why the OSX version works so much better than the Windows version. It's not that I want it to; the OSX version of Qt is simply better.

Qt isn't the only project or organization guilty of wanting to make new versions before fixing the existing version. The lure of new APIs and such is strong, and the urge to fix bugs apparently not so much, right across the software spectrum. Apple does it; bugs persist for many OS revisions while APIs come (and go... Apple is not shy about telling you to stop using something.) Microsoft does it: I remember the glyph rotation bug (CW on some platforms, CCW on others) and the how-many-files-you-can-multi-select bugs managing to survive over not only OS revisions, but different OS platforms when the MIPS and Alpha versions were being offered. In the interim, Microsoft changed a great deal about window metrics across various OS levels, affecting all manner of interface issues, while OSX inflicts such obnoxious "favors" as not supporting new cameras except with a new OS level (while still happily selling you a version of their image editing that will work on your older OS), and breaking such *NIX components as cron. UDP sockets still don't work correctly under OSX (broadcast reception sockets where only one can exist on a machine... yeah, that's a good idea... not.)

Basically what I'm bitching about and advocating is that if you produce software, you shouldn't somehow magically get to ignore the fact that it doesn't do what you told the end user it would do just because you've released a new version you want them to buy, or even just use. I have NO problem with charging for new features. I don't even have a problem with adding new features to the current version while also fixing bugs, as long as you take care to not break pre-existing functionality. I have a HUGE problem with charging to fix something that was supposed to be working in the first place, or even, as is the case with Qt, not charging, but simply abandoning in place software that is significantly less than it was purported to be. I find adding new features to be insufficient cause to excuse leaving known bugs in place.

And frankly... if we would just seriously commit to fix the stuff we have before we move on, moving on would be a much better experience overall; the codebase would be more stable, the customers happier, and if we could couple that with a sense of responsibility that left existing APIs in place (once you tell someone to use an API, I think it's just awful to tell them they have to stop), I think we'd have a better process, a better end user experience, and a great deal less agonized tech support. When your "it's-our-fault" buglist hits zero, that's when you should start thinking about changes that might involve moving on from the previous version. I see it as an obligation to the end user. Unfortunately, at least thus far, Qt does not.

Kids? No, around here it's the fucking adults with their quarter sticks of dynamite. They sure aren't using the M80s and Cherry Bombs I had as a kid.

Nice try, but with all the fireworks "testing" by my asshole neighbors, that's impossible. I also have to work in the morning, so getting a full nights sleep is going to be a challenge.

Not to worry, we're spying on everyone. Equal opportunity, y'know.

It would be ride share if his response was "Nah, I was going to Bruno's".

No, it wouldn't -- because YOU are going to Brunos, and so you wouldn't go with him, you'd get your paid service from someone willing to provide it. There are plenty of taxi situations where the driver will tell you "no, I don't go there."

The distinctive element here isn't what doesn't happen; it is what does happen. As I said, I'm not arguing for regulation (nor am I claiming any one way is better than another... that strikes me as highly situational); but in terms of the common element here, it's that (a) transport costs money, (b) you don't have transport, (c) you pay someone to provide it, (d) they do so.

It's Uch Daikaij Dogora!

No, the distinctive thing is that you're paying for a ride. That's a service.

Not saying that the city/state whatever needs to be involved, but I *am* saying that to pretend this isn't a paid service to the rider is disingenuous.

Suppose a taxi driver was thinking of going downtown to Bruno's for a good pizza slice. Turns around, heads down Broadway, there you are, waving your hand. You get in and tell him, Bruno's, please! Did that suddenly turn the taxi ride into not-a-taxi-ride? No, of course not.