you've cut your costs 50%. So you'll be working 50% less. So you're commuting less.

You shouldn't need modern science to tell you that working all day every day, especially in your older years, is bad for you. Standing, sitting, laying, bending, reading, writing, seeing, listening, . . .it all doesn't matter. If you're concentrating on anything -- mentally or physically -- to the exclusion of all else, it'll be bad for you.

But you really ought to be thankful that you'll die sooner, since you're just working your life away.

Instead of trying to work in a healthier manner, you might want to try working less. Move thirty minutes farther from down-town, drop your cost-of-living by 50%, and start enjoying the kinds of hobbies that are effectively free.

I run a company, a tech company, and I actually insist that most passwords be easily sent to clients in plain text.

I'm not talking about credit card information, obviously, nor control of any nuclear facilities. We're usually talking about invoices, business-administrative panels, business reports, and even financial reports. And, believe it or not, even e-mail passwords.

It's certainly not more secure. Especially those last two.

But I drive very fast on highways with other cars driving very fast, and the only thing separating us from 50-car pile-ups and massive death is a yellow line of paint.

In all of these cases, no one dies, and no one directly loses large sums of money.

But it's more than just convenience alone. It's business. Business often comes down to service. And when a client forgets their password, nothing beats just telling them. Yes, telephone's a little bit better, but not always the better business solution.

In the end, you know something, it's up to the person paying the bills. If my client doesn't care about the security risk, then I'm not the one to force them onto the long road.

The front door to my house has a lock that is easily picked -- which doesn't matter because right next to the door. . . is a window. I don't want bars on my windows either.

So let's you and I try to come to a consensus here and now as to the next effort to be undertaken in this regard.

I think you've pointed us in the best direction with that current HUD article. It is this: what's with all of the focus on visual information?

A human being is way more than floating eyes; in fact, the eyes are the most cognitively expensive feature. Overlosading it is easy to do, even by accident.

The thing is, a human pilot doesn't need to see most of the gauges. Most of them show numerical information with far greater resolution than is usually necessary. For example, altitude to the foot is not necessary outside of landing scenarios. Being able to see through the plane is completely useless when nothing is there.

But I see a human being sitting in a chair. Not walking, not running, not smelling, not tasting, not feeling a temperature, not being hugged, not being caressed by a loved one. There are so many human faculties -- most of which are wired directly into the human spine, and one wired directly into the human brain -- going almost completely unused. Why not tap into those?

A pilot could easily know where the bandit is by a simulated caress (or vibration) on the relevant part of the body -- upper back, lower back, left shoulder, right shoulder, et cetera. Visual HUD information can be the detail upon request. Here's a thought, how about a gentle pull of the neck towards the bandit. Easily felt, easily overcome.

I've got one of those non-fan heat dishes for my grandmother. It's basically an IR heat-ray. Altitude could certainly be conveyed by the localized temperature in the cockpit, or in the helmet. A ten degree range would be easily understood, and a twenty degree change even more so. Colder at high altitude makes sense.

There are myriad tactile sensory inputs to be used, including a gently squeezing of the upper arm as a fuel gauge. The really amazing thing about any such system is how the brain adjusts memory as a result - with different memory banks for high vs low altitude because of temperature sensation -- something a numerical altimiter can never provide.

In any event, to summarize, I see a few dozen inputs into the human brain, and I see only the visual cortex being used.

Interesting. But my point surrounds situational awareness without invasive technology. I doubt any crop-dusting biplane pilot has any trouble with situational awareness -- it's all wide open. It's the enclosed jet, and the crazy number of jet systems that remove the mind from the situation. That's what I'm saying needs to be addressed -- technologically.

So, it's been thousands and thousands and thousands of years since the last asteroid strike of any consequence, and there's currently zero no reason to believe that another one is coming any time soon.

And we have diseases, and earthquakes, and deserts, and insufficient water, and insufficient food, and terrible economies, and wars, and we work way too much. But let's start spending money and time on risks we know nothing about.

I'm in full support of spending money and time to research the risks, but not to solve the unknown problem. Let me know when you know what the problem is. For all you know, asteroids are intentionally and maliciously guided by aliens. Let me know when you find out.

Like so many other "tools" these days, this one attempts to provide advantages via some form of automation -- be it in terms of the structural aircraft, or the features within it. Every time anyone ever focuses on such a goal, they reduce the required expertise of the user -- in this case the pilot -- substantially.

Everyone always thinks that's a good thing -- if it can be operated with less learning, then it can be operated by more users. They always forget that every advantage is a sacrifice of some other advantage. If it can be operated with less expertise, then there is less expertise that can be learned.

The end result is almost always the same. A rookie pilot can operate better, sooner, and an expert pilot can do less.

That's fine with self-assemble furniture. It sucks with military applications like this one. I'm always for tools that empower the operator into a god. Imagine a fighter jet, requires many many more hours of learning to master, but that allows the expert pilot to do so much more.

In my head, that's a very lean aircraft, bordering on ultralight. It's also an aircraft with guns that point backwards -- one day someone will explain to me why we love dog fighting so much that we insist on being unable to kill the enemy right behind us. I digress.

I'm confident that an expert pilot doesn't want a fancy helmet HUD at all. He just wants to be able to see -- gauges, backwards, what's going on. And I'm certain that an expert pilot knows most of what's going on without his eyes -- I'm sure his left buttock gives him more information than any HUD ever could.

maybe yours, but not mine. spec it properly, and it won't.

I did answer the question. In my plentiful experience, it's not windows, it's the compenent combination. That was the question, and that is the answer. Learn to read, then learn to think.

Care to introduce yourself? If not to me, then to the other AC here? If you're going to support her, you should say hi.

are you the same AC as before? Or someone new?

I'm sure you can some up with some token identification, it needn't match your company's identifier.

But your company is likely just trying to parent you, if you're so stupid as to live this long without ever hearing of an alias. There've been hundred of years of gangsters, yet you have trouble with a technical conversation.

And hey, if your company won't let you stand behind your own words, then still your own words are meaningless. It's not what you say, it's the fact that there is no name behind what you're saying. That's how reputation works.

AC means someone whose opinions aren't signed. If you aren't willing to put your own name to your arguments, then they aren't worth spit -- because you aren't willing/able to stand behind them.

As for proof, way to be consistent in your world views. You don't know what the word "proof" means. I said that I've got decades of real-world trials. That's what "proof" means. Same like vodka, and watches, by the way. I offer you decades of experience. That's far better than most analyses -- because it can't be incorrect. My scenario may or may not match yours, but it's proven correct -- because it's already happened.

I think you're speaking about "evidence", which isn't proof at all. Evidence is merely suggestive, and hence required analysis, and conclusion -- each of which can be in error.

What I've offered is historical fact (you'll want to look up "fact" as well, because I'm willing to guarantee that you have no idea what it means either.) based on observation. Unless you doubt my eyes or my honesty, there's no denying direct first-hand observation.

that a coward would consider learning a skill to be a wasted time, isn't too surprizing.

so mob programming is better than merging. that's not hard, since merging is by far the all-time worst part of most programming companies.

The solution, of course, that I implemented in my programming company over a decade ago, is to build platforms that don't require merging in the first place.

The benefit of mob/pair/multi programming is that everyone knows what's going on because everyone was there to see it happen. Nothing more.

things like this have been said about windows for decades. It's never been true. I know because I've had operational business machines at each version of windows running for over ten years each.

These types of problems happen *and are henced resolved with brand new way-more-powerful hardware) when multiple components aren't spec'd together.

Any given component has many bins. You can get any cpu at six levels of l3 cache, for example. Drives can be 5'400, 7'200, etc.

The trick is not to get the most possible performance (which is akin to buying a new machine a few years later). The trick is to match the performances across the various components, so a single component doesn't become the bottleneck.

Especially because some components, when acting as the bottleneck, can create serious slow-downs. Often actually making something else SLOWER will make the over-all machine much faster.

An over-simplified example is that a slow hard drive can create disk-thrashing scenarios -- one of the worst slow-downs common across the board. But a slow cpu will remain slow and steady, and never wind up thrashing the disk.

Learn to balance the vital components of a system, and it'll stay consistent for a decade.

(this was written on my 8-year-old vista machine, still working, still business, still gaming, still full-speed)