That is a good point. OS X is indeed Unix, officially certified. I've run all Linux for many years. When someone handed me a Mac Pro I thought I'd dislike it, based on my experience with iOS. I was surprised how comfortable it was to use, just like my familiar Linux for day-to-day work at a bash shell. For coordinating with my coworkers, I also have all the Microsoft Office, all of the Adobe developer products, etc. Not bad at all.

Whenever I mention I'm a Linux guy who actually likes OS X, someone goes "no true Scotsman" on me. Open the Linux kernel changelog. See my name, Ray Morris. Look around at some of the Linux storage stack. You'll notice I'm the maintainer for Linux::LVM, for example. So yeah, I'm a real Linux guy - perhaps more so than any other regular commenter on Slashdot.

You think a 2048 bit key makes a cipher secure? Most SSL implementations vulnerable to POODLE are using 2048 bit key with DES encryption in cipher block chaining 3 mode. So unless you're going to argue that POODLE doesn't exist ...

There's actually a reason those of us who do this stuff for a living haven't all retired, saying "we're done", the algorithms are secure.

>. cryptologists have gotten much, much better at creating incredibly secure algorithms as well.

The evidence indicates otherwise. In fact, we're currently proving that most material which is currently encrypted can be readily decrypted by quantum comouters. We thought MD5 was secure, until it was broken. We thought SSLv1 was secure, until it was broken, we thought SSLv2 was secure, until it was broken. That goes back to the Caesar cipher. Caesar thought it was secure - until it was broken.

We have some new algorithms which might be reasonably secure against quantum computing, maybe. We don't know what people will do with quantum computers. Remember ten years ago when CAPTCHAs were reasonably secure, computers couldn't solve them efficiently?

I've written some of those "heat death of the universe" computations - as part of my marketing material. I compare the time since dinosaurs and the time since the birth of the solar system to the time required to brute force Strongbox. It would take MUCH longer to brute force Strongbox than the time the solar system has existed. That's explained on my sales pages. On our R&D systems, we're making constant improvements because we know the actual time frame before we get owned is more likely to be in the next few years, if we don't keep constantly improving. We pitch "billions of years", and we've had two urgent security updates because there have been issues that black hats could exploit right away.

>. You obviously do not understand encryption. Unless a weakness in the underlying algorithms is found, "a faster computer" will never be sufficient to break modern encryption.

Indeed you seem to be completely ignorant of the subject. The whole science of encryption is all about finding operations that a) can be done quickly by a smart phone yet b) cannot be undone slowly by a cluster. That's far from a solved problem. In fact it's funny you mention "modern encryption" because ALL modern methods of encryption have been broken within about 10-30 years. The ONLY unbreakable encryption is an old method, the one-time-pad. It's unbreakable because the key is at least as long as the combined total of all of the messages it will ever encrypt. That makes it not particularly useful in most cases. Any and all other methods of encryption are subject to at least brute-force attack, which means they can be broken almost instantly, given sufficient computing power.

  A strong cipher is one which takes a lot of computing power to break. That can calculated as (resources required to brute force) / (shortcuts known). Both of those factors always get less secure over time. The cost of the computing resources required to break it drops quickly, while at the same time new methods are discovered to break it with smaller amounts of resources.

It seems you've stated two facts, then managed to draw the exact opposite conclusion than the one the facts point to.

Fact 1: The big auto makers have been messing up automated systems for many years, decades in fact.

Fact 2: After decades, they haven't managed to get very far.

Let me add fact 3: In just a few years, Google has driven the state of the art forward at least as much as Detroit had in the previous 20 years.

Your conclusion: Detroit is better at this kind of R&D than Google, and will beat Google (rather than licensing Google's software and other technologies.)

It seems to me that if Detroit hasn't achieved much progress in the last 30 years, that suggests they'll probably continue that trend. Whereas Google has became a major player, perhaps the leader, in just a few years, we'd expect them to continue with the same successful approach to R&D.

>. has failed to turn many of its innovations into new moneymakers.

It doesn't matter how many don't end up bringing major revenue. It only matters that a few do. Of Google+ is a complete failure and Android has 75% of the market, Google wins big. Their newsgroup site shuts down while Gmail huge is a huge success, Google does quite well.

They can well afford to invest $10 million each into trying ten different things if just one those goes on to make $250 million.

If Google becomes THE autonomous car company, it doesn't matter that they also experimented with ten other things that didn't bdo great - and even the ones that don't do great sometimes make a little money.

And after all that, he planned to upgrade his speakers, from his current 4" titanium drivers to 6$. :)

I'd rather replace a cable than a motherboard or 10Gig NIC.

> The idea that prisoners should be relied upon and expected to met out additional extrajudicial punishment to other prisoners.

The fact is that a corrupt judge spending 28 years in prison probably WILL have some hard times. That doesn't say what SHOULD happen. It's a statement of what DOES happen. No "should" or "should not" about it, it's simply fact.

I've noticed this type of confusion also comes up every single time I post what the law is on a subject. I post "the maximum sentence under section 215.13 is 5 years" and I get a couple of people replying saying "you're wrong, that's not right, it shouldn't be a crime at all". Well, whether it SHOULD be a crime or not, it IS a crime, and the maximum sentence IS 5 years. Barak Obama IS president, whether he should be or not, and felons tend to hurt people, whether they should or not.

> The idea that prison rape is "ok" because it's happening to other prisoners.

Pretty sure I didn't say anything about rape. I said he may not live to the age of 85.

You're saying that someone choosing to work in order to get paid is what slavery is. That's got to be the most ignorant and offensive post on Slashdot. Slaves don't get a choice, and don't get paid. GP's suggestion is "if you want to get paid, work".

  Go read a paragraph about what slavery actually is, you entitled little whiny prick.

  >. public is blaming the poor for being poor. Well, the rich can't have it both ways. Either they're The Job Creators, and they are failures at creating jobs,

Or in my town of 150,000, there are over 200 jobs listed in the want ads, and a few people who choose not to work a legitimate job since their needs will be met by other people, while they spend their "under the table" money on stupid play things.

I just read a bit about that. I'm glad to know the judge got sentenced to 28 years in federal prison, which actually means 28 years (unlike state time). He won't get out until he's 85, if he lives that long. Being a corrupt judge in federal prison, I suspect he'll be dead long before he gets out. Federal inmates tend to dislike corrupt judges, and federal inmates sometimes do bad things to people.

>. Why the FUCK would you ever want to keep an explicit stack? Did your language implementers have brain worms? Stack and Heap are the same, it's just RAM

Granted if you're doing it explicitly you'll more likely use a queue than a stack. But not necessarily. For example, you might process all children in parallel if you're working on a GPU or cluster. The parallelization library will then need an explicit stack.

Note to "it's just RAM" isn't always true. If you're crawling the web, your list of links to be visited will be in a database, not in RAM.

Not quite. The UNICODE APIs and NTFS support up to 32,768. Other APIs are still limited to 260 at least as of Windows 7. Explorer can't handle larger than 260, or at least recently couldn't. So long as the older APIs remain, the maximum safe length is 260. Longer paths may work sometimes, but behavior is undefined in general.

Windows defines MAX_PATH as 0x00000104 I'm sure someone will correct me if I'm remembering incorrectly.

You should of course decide how to handle symlinks. In most cases I've come across, a symlink is just a file - not something to be followed. Rsync's default behavior is an example of this - it by defaults copies the symlink, rather than recursing into wherever the symlink points. As I recall, tar is the same.

You need to handle symlinks and perhaps bind mounts based of application requirements.