Slashdot stories can be listened to in audio form via an RSS feed, as read by our own robotic overlord.

 



Forgot your password?
typodupeerror
Transportation

TSA Has Record-Breaking Haul In 2014: Guns, Cannons, and Swords 276

Posted by samzenpus
from the return-you-rifle-to-a-upright-and-locked-position dept.
An anonymous reader writes The TSA has gathered an impressive pile of confiscated weapons this year. In early November the agency had already discovered 1,855 firearms at checkpoints. In addition to guns, they've also collected machetes, hatchets, swords, giant scissors, brass knuckles, cannonballs, bear repellent and, this past October, an unloaded cannon. "Maybe someone has a lucky inert grenade they brought back from some war, or a nice cane was given to them and they forgot that the thing is actually a sword," said Jeff Price, author of Practical Aviation Security, "It's the people that are carrying stuff like chainsaws that make me wonder."

Comment: Re:Your bed, lie in it. (Score 1) 204

by nyet (#48095411) Attached to: Ask Slashdot: Dealing With an Unresponsive Manufacturer Who Doesn't Fix Bugs?

Suing likely will cost more than just eating the remainder of the service contract, AND has no guarantee of success.

This is why the whole "proprietary software is supported so it has a lower TCO" is often a myth.

Lockin always has risk, and to that extent, presents a very real cost.

Comment: Re:Your bed, lie in it. (Score 1) 204

by nyet (#48095383) Attached to: Ask Slashdot: Dealing With an Unresponsive Manufacturer Who Doesn't Fix Bugs?

He has a choice.

Pay lawyers to get out of the contract (and run the risk of paying lawyers and STILL being on contract).

Eat the remainder of the support costs, learn from his mistakes, and move on.

Guess which probably costs less and has a better EV?

Either way, somebody made a poor decision, and it is going to cost money and time.

Comment: Re:Your bed, lie in it. (Score 1) 204

by nyet (#48095313) Attached to: Ask Slashdot: Dealing With an Unresponsive Manufacturer Who Doesn't Fix Bugs?
I doubt it does. In fact, I'm willing to bet it does not, because every time I see this complaint (and I see it all the time), it is because an idiot PHB made a stupid, uninformed, technically clueless decision. Standards compliance is never on the RFP of a PHB. And if it is, it disappears as soon as the PHB gets distracted by something shiny. If it is something PHBs love, it is vendor lockin.

Comment: Re:Idiots and their "BSP"s (Score 1) 141

by nyet (#47660763) Attached to: Study: Firmware Plagued By Poor Encryption and Backdoors

Absolutely. The situation is not sustainable.

Even worse, because every SOC is a haphazard pile of random and arbitrarily buggy peripherals, there is no deterministic way (at run time) to enumerate all of the peripherals, and thus which various driver variants (and even worse, binary blobs) are required to make them work.

So by definition, none of this can EVER go into the mainline. Every kernel fork is its own disconnected universe, dedicated to a single snapshot of a single SOC and its particular collection of peripherals.

But if you try to explain this to a PHB (or, say TI), you'll get nothing but blank stares. There is nobody home.

Comment: Idiots and their "BSP"s (Score 2) 141

by nyet (#47659679) Attached to: Study: Firmware Plagued By Poor Encryption and Backdoors

The reason embedded device kernels never get updated is because the source code for them is on some SOC vendor's way out there fork of some ancient kernel that nobody with a clue actively develops for anymore.

And the vendor (say, TI) had hired a bunch of clueless interns to write the "BSP"s (old acronym from the binary blob obsessed asshats at vxworks et al) for their SOCs and the cluster of shoddily designed peripherals crowbarred into the SOC.

And those interns wrote code so toxic and broken that no sane kernel developer would ever have accept any of their garbage into any mainline kernel tree.

So there are all these embedded devices out there with kernels from the 90s, and it would take time (and expertise) that none of the vendors have (including the SOC suppliers, like TI) to merge the changes into something even remotely contemporary.

All of this because the requirements for these embedded projects (dictated by clueless PHBs) is only "linux support" not "mainline kernel support", so SOC vendors (like TI) just don't have the incentive to develop SOC peripheral driver code suitable for mainline inclusion.

Comment: Re:Linux, a miracle (Score 4, Insightful) 739

by nyet (#47545441) Attached to: Linus Torvalds: "GCC 4.9.0 Seems To Be Terminally Broken"

Because if you aren't incompetent, you won't get yelled at.

Unlike a corporate structure, where you don't get yelled if you play the game right.

If you are incompetent, please don't develop linux kernel code. Go work for a corporation.You'll find you're a better fit, and if you play your cards right, you won't get yelled at no matter how bad you are at your job.

Comment: Re:So SSL is nothing more than an honor system? (Score 1) 107

by nyet (#47425337) Attached to: India's National Informatics Centre Forged Google SSL Certificates

It's a shame that browsers have such freakouts over self signed certs, because there is really little difference between them and officially signed certs

Exactly. Especially since you can get a "real" cert from one of many, many, free cert signing services. What is the point?

FORTRAN rots the brain. -- John McQuillin

Working...