Slashdot is powered by your submissions, so send in your scoop

 



Forgot your password?
typodupeerror
For the out-of-band Slashdot experience (mostly headlines), follow us on Twitter, or Facebook. ×

Comment: Re:Empower the pilot (Score 1) 785 785

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.

Comment: Re:Empower the pilot (Score 1) 785 785

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.

Comment: oh good, another huge waste of money (Score 1) 76 76

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.

Comment: Empower the pilot (Score 1) 785 785

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.

Comment: Re:Learn to preperly spec hardware (Score 1) 512 512

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.

Comment: Re:Learn to preperly spec hardware (Score 1) 512 512

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.

Comment: uhuh. (Score 1) 125 125

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.

Comment: Learn to preperly spec hardware (Score 4, Insightful) 512 512

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)

Comment: Perl, bootstrap C++ (Score 1, Informative) 296 296

you want everything -- memory, disk, network, speed -- and c++ will give you all of that just fine. And it'll give you the giant learning curve, and force you to take every hard road from start to finish.

Have you considered using perl -- which is pretty well cross-platform -- and writing the few granular components in c++, bootstrapped into perl?

That's pretty standard for i-want-to-use-perl-but-i-need-this-part-to-be-faster.

Without life, Biology itself would be impossible.

Working...