I thought the point of the charge was to make the "wooly" side-fibers of the strands wrap around the prey's limbs and/or the microscopic irregularities in the exoskeleton, tangling to it. "Tying" the fibers to the prey would have a similar binding effect to gluing them to it, without the need for glue, and lots of little fibers could make a very strong attachment.

(Stretching fibers made of long chains makes them stronger by aligning the chains along the direction of the stretch.)

And AAA vendors don't. Adobe products are simply shady back-alley freeware as proven by their installer. Java too, of course.

Youtube just switched to HTML5 video by default, so perhaps we can uninstall Flash for good now!

But can it play "Badger Badger Badger"?

Why are they still using C to deal with network protocol? Is the performance so critical that it's worth all the troubles?

Also, because there's a lot of C code that has been in heavy use, and tested for correctness, for decades, suitable for reuse with substantial confidence that it's correct (though you check it anyhow...).

Let's see you find code like THAT for a language that hasn't been AROUND for decades. B-)

Why are they still using C to deal with network protocol?

For starters, because it's transparent. The "K&R compliant assembly laguage", as one of my former colleagues once characterized it, translates to object in a clearly understandable way (especially if you turn optimization down or off). Though it gives you more opportunities to create bugs, it makes it hard for the bugs to hide from inspection.

The "higher-level" the language, the more it takes over and inserts its own stuff between you and the metal, and the more opportunity for that to inject an invisible vulnerability - which you might have trouble removing even if you DO discover it.

Meanwhile, many of the things "higher-level" languages protect you from can also be detected and flagged by both modern C compilers and code examination tools - starting with the venerable "lint".

Slashdot supports too few entities to do this right, and forget about UTF8. But you can get sorta close.

  *
* *

Unless someone can do better?

For lack of mod points let me just say: beautiful!

It's like this in any engineering discipline:
* The apprentice doesn't do things by the book, for he thinks himself clever
* The journeyman does everything by the book, for he has learned the world of pain the book prevents
* The master goes beyond the book, for he understand why every rule is there and no longer needs the rules

Or put another way - the apprentice thinks he knows everything, the journeyman known how little he knows, the master knows everything in the field, and still knows how little he knows.

It's a problem when the default ASSERT macro expands to code with such #ifdefs (no joke - that was the norm everywhere I worked with C/C++). At one place it got so bad that we made using the ASSERT macro a firing offense (not sure why we couldn't just fix the macro, some corporate thing no doubt).

And I've been there and done that with the "no resource leaks" in C++. When you provide library code that's easier to use than doing it the wrong way, it's easy to enforce the standard in code reviews (since then it's only the new guy who hasn't seen how easy the tools are yet).

For example, if you have a good FileHandle class, it's simple to educate people to write FileHandle foo = fopen(...); instead of FILE, and then that's it, the file closes when you exit scope. Works perfectly as a member variable as well - no need to remind people that the destructor isn't called if the constructor throws, as members are always cleaned up.

I can guarantee you that if the Govt. left it up to drivers to get the proper training and instruction on how to operate vehicles safely, people wouldn't do it.

Interesting claim - since it doen't work that way for guns.

Where the government requires training, most gun purchasers take the minimum required, then stop. Where it doesn't, most people start with the course recommended by the gun stores (which is far more comprehensive - and more focussed, with less time spent on political indoctrination B-) ) and also do substantially more range time, until they feel adequately competent. (Then there are those that get interested in shooting as a hobby...)

A similar effect is the reason police normally don't shoot at private ranges simultaneously with civilians. Most police are embarrassingly HORRIBLE shots and pistol-handlers - because they do only the minimum training and practice required by the department (which has lots of other stuff for them to do while they're being paid for their time), and almost never have to actually fire their gun during their work.

Ford F150 Lariat.

For the 5 1/2 ton towing capacity (which also translates to "won't blow the engine head gasket towing a loaded trailer up CA 88 like the van did" - turns out they designed that vehicle's engine with the cylinders too close together so this one pair had a very thin piece of gasket between them,..).

(No time to get the GVR before I have to get to work...)

I'm going on what the dealer told me. If I was led astray the cost of the vehicle has been a couple grand higher than it otherwise would have been.

We've seen a web server running on a Commodore 64. Wasn't that a 12 kB OS? It's been a while, but IIRC the OS was in memory from D000 to FFFF.

I've worked on mainframes where the "recovery OS" fit on one tape block - a hard 32 kB constraint (used for disaster recovery - it would load a program that also had to fit in 32 kB which would restore a system from backups). The normal OS wasn't much bigger. Most device drivers weren't memory resident, for example, and shared 4 kB by swapping in and out, which could lead to some mighty odd behavior by today's standards.

Oh? You check for errors in code that gets #ifdef-ed out in a production build? What could possibly go wrong with that plan? (Or do you mean first the check, then the assert, following every function call, further hiding the few lines of business logic in a huge function).

It's quite easy to write "all exception safe all the time" code in C++, in ways that even the junior guys can't screw up. It's not obvious what that coding standard looks like. That's the big problem with C++. Many have never even seen it done right - it's very understandable why business largely moved to managed code.

People see RAII and think "oh, instead of allocate at the top and free at the bottom, I'll allocate in the constructor and free in the destructor". No, you're still doing it wrong if you have any non-trivial destructors outside of a bit of well-reviewed library code.

If you're doing it right, the only avenues for screwing up resource management are adding stuff to a global object and forgetting it there, as with every language.

Asking myself the same question, I went with MDisc technology, in the BluRay capacity, in addition to my hard drive backups. MDisc uses an inorganic pigment as opposed to the organic dyes that are common on CD/DVD/BluRay recordables (and degrade over time).

I'll do an MDisc burn every year and move it offsite, to keep with the 4TB ZFS drive I rotate offsite weekly. The MDisc won't get my mp3 or mp4 files, but the stuff I can't recreate.

My best idea currently is to write PAR files of loop-back mounted LUKS volumes and include the PAR software source and ISO of the distro on the disc, in case I need the data in 20 years (emulators should be readily available for 2015 hardware).

I needed a BluRay writer anyway, so I went with this LG and it's been a great drive so far, and at the right price point for me.