Catch up on stories from the past week (and beyond) at the Slashdot story archive

 



Forgot your password?
typodupeerror

Slashdot videos: Now with more Slashdot!

  • View

  • Discuss

  • Share

We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).

×

Comment: Re:It's quite simple really... (Score 1) 131

by Chris Katko (#49361269) Attached to: UK Licensing Site Requires MSIE Emulation, But Won't Work With MSIE
Though, this is really an arcane (read: 1995) way to write text posts. When I first started posting again on Slashdot I thought, "Wait, is this really the only way to post?"

You'd think everyone would use Markdown or some variation of it by now. Well, everyone does except Slashdot. And I still frequent a web forum designed in 1999, and it supports forum markup.

I wonder if they never changed because they think their system is better, or they just don't want to devote the resources. Or perhaps they like it worse as a natural barrier-to-entry to posting to keep out fifthly casuals and their signal-to-noise ratio. But I think that's giving them too much credit.

Next up in Slashdot Beta, all posts use a flash applet running in a java runtime that emulates VIM!

Comment: Re:One more view. (Score 4, Insightful) 280

Half the juriors were WOMEN. And ALL of the Asian juriors voted against her.

When you assume every women who loses a case is because of "male domination", then nobody takes you seriously when you have an actual case of discrimination.

Ars Technica just lost my respect and readership. If they can be this biased toward their agenda even when the facts are obviously to the contrary, they can't be trusted to report on anything.

Comment: The perfect summary of the case: (Score 5, Insightful) 280

"Ellen Pao gender-bias lawsuit is a setback for women"
http://www.cnbc.com/id/1025377...

Written by a female ex-CEO.

In a nutshell, the case is obviously frivolous, and if it had succeeded it would have been another barrier for women in the industry because companies would see a female applicant and go, "Is she worth the risk?"

Comment: Re:Results? (Score 1) 40

by Chris Katko (#49357907) Attached to: Hoax-Detecting Software Spots Fake Papers
Just because there's a way to scan papers (to help you trick the system) doesn't mean everyone is going to use it. The smart ones will, but that doesn't mean plenty of stupid people won't.

If tool can't stop every bad guy doesn't mean it's useless. Even a professional will miss some. It's about reducing the numbers that get through.

Comment: Re:A Bit Fishy (Score 1) 352

by Chris Katko (#49357657) Attached to: Modern Cockpits: Harder To Invade But Easier To Lock Up
Additionally, many emergencies have something wrong with the plane. Not all, like a misreported flight instrument sending you into the ocean... but clearly, there are differences between a healthy plane descending rapidly, and an engine exploding (engine temp sensors high or dead, fluid loss) and the same resulting loss of altitude. The drop is the same, but the instruments are wildly different.

Comment: Re:Personally? (Score 1) 273

by Chris Katko (#49357451) Attached to: Ask Slashdot: What Makes Some Code Particularly Good?
I think programmers should focus on making code that "isn't slow" more than they should focus on "is fast." Focus on not making stupid mistakes like running higher-order algorithms than necessary (ala using a for loop to search for a key when you could have been using a dictionary).

If you focus on fast, you should definitely do a profile-first-optimize-last approach so you're actually optimizing code that the computer spends most of it's time running.

If you're optimizing fringe functions, then it better be for a pet project and "because I want to." Because otherwise you'll be sacrificing maintenance and introducing bugs for something that isn't even affecting the user.

Comment: Re:Why??? (Score 1) 86

by Chris Katko (#49357395) Attached to: Rebuilding the PDP-8 With a Raspberry Pi
"Why?" is the goto card for people who don't achieve anything.

The things you learn re-inventing the wheel can be applied in various parts of your future projects.

It's like asking why solve a math problem? Obviously, to learn how to do math for the chance that you see a problem that you DON'T have an easy answer already available. Hell, that's what an entire engineering degree is. It's not "can you solve problem X" because problem X will almost never occur in real life in an isolated environment. The purpose is "can you solve these kinds of problems." And how do you learn to solve problems? By looking at ones people have already solved.

Comment: Re:A Bit Fishy (Score 1) 352

by Chris Katko (#49356109) Attached to: Modern Cockpits: Harder To Invade But Easier To Lock Up
Here's a thought. A modern car can tell the difference between driving and a jackass about to rear-end someone.

Can't we train some neural nets / other machine learning with flight data on two sets of data. One, emergency maneuvers, and two, with suicides. There is very likely a large difference in the mindset and controls influenced by that mindset between an emergency manuever and a suicide.

If a suicide is detected, at the very least POP the lock on the cockpit so the crew can do something about it. If it's an emergency landing but NOT terrorism, this won't be a problem. The only problem left is when pilot-is-crashing is falsely flagged, AND there are terrorists outside. But depending on how strong the correlation is, this might be an impossible scenario. The point is, we don't know until we actually try and run the numbers.

Comment: Re:Pilots must remain in control (Score 1) 352

by Chris Katko (#49356031) Attached to: Modern Cockpits: Harder To Invade But Easier To Lock Up
We're talking about probabilities here. We don't need to stop everyone, we need to make people less likely to do it.

Putting a second guy in a room with you absolutely makes you more aware of your legal and moral consequences. Even if they're your best friend. They don't want you killing yourself, or everyone on a plane. It prevents your mind from wandering into territory you know you shouldn't be in. We've all been in situations where we were thinking weird things and then someone came in and we suddenly realized how strange our thought-process was.

Putting a second guy in a room (and they can't be locked out because they also have keys) means you have to now outsmart and overpower a human being to do your craziness. It also means that if they notice you STARTING to get the point of crazy, they can DEFUSE IT before it becomes your urge to actually smash into a mountain.

We don't need a bunch of linebackers in a cockpit, but the fact that one pilot can easily lock out another pilot is pretty damned stupid if one of the pilots is the problem. And if you're worried about "the bad pilot getting back in" that's what the rest of the crew is force. A mile high gang bang.

Comment: Re:Perfect (Score 1) 180

by Chris Katko (#49348349) Attached to: GNOME 3.16 Released
I wonder how hard it would be to fork a file manager to add the functionality you are looking for. Someone else mentioned various filtering options.

I'm very much a fan of "it's easier to make the tool you need than it is to convince someone to make it for you."--even if it would be easier for someone to modify their own project than you having to learn all specifics, they're normally so resistant to ideas that it's almost impossible to get a dev to care about a feature you do.

The end of labor is to gain leisure.

Working...