I think I'd rather use a test that just asks me to click on the hot women real quick.

http://bettercgi.com/images/face-turing-captcha.png

It's been an interesting conversation, thanks.
I believe I do understand your point, I just have a different view.

I understand you to be saying that a CD "is" a bunch of numbers.
That's true, whether it's a music CD or a software CD.
However, I'm of the opinion that it's myopic to view the contents of the CD as "a bunch of numbers". Mozart isn't a bunch of numbers. To say that's what music IS, one misses the essence of the thing.

Similarly, my wife IS a pile of hydrogen and oxygen. She's defined mostly by her DNA, a mathematical sequence. To look at it that way is to be absolutely blind to what my wife truly is, in my opinion.

Anyway, thanks again for an interesting conversation. I look forward to reading your thoughts on the next topic.

That's a good point and I retract my comment in the context of console servers.

The point I had in mind is that although I use CLI for almost everything, sometimes a GUI is much nicer. The CLI for LSI RAID cards comes to mind.

That made me chuckle. Can I mod down my own GP comment?

My comment would have made a lot more sense if the URL was Slashdot.org/logo.png

Ps - you're independent weak encryption is not hard to figure out. Let's say you use it for some PHP script on your web site. Well, it's on a publicly accessible web server, and it's friggin PHP, so I'll have the source code in ten minutes. As soon as I see the source, not only do I know what weak algorithms you're using, but I can also see the common flaws in your particular implementation.

A case in point -
A common "do it my own way" idea is to stack hash algorithms. Take a sha256 of the data, an MD5 of that, and RC4 that or whatever. Well, stacking hashes results in a hash that's provably WEAKER than the weakest hash in the chain. Each step you take to make it stronger actually makes it weaker.

I'm a total DIYer. I'd even DIY stitching a cut. There are two things you shouldn't DIY - high explosives and information security. (But low explosives are fun.)

The best way to deal with strong encryption is to go around it, to use the back door. Those are the flaws an audit would reveal, issues not with the actual encryption, which is a fairly small part of the software, but with the other 90% of the code .

The encryption itself has been analyzed, and will continue to be analyzed, outside of Truecrypt, which is just one of many packages that use the same encryption.

We know that the current version of GCC doesn't have the "Ken Thompson" trojan. The original version could have, theoretically a but it couldn't survive so many versions. Also, gdb would have revealed it long ago.
Maybe gcc also trojans gdb? And ptrace, and ...
You have to imagine that the author wrote specialized trojans for a bunch of programs that hadn't been created yet, and hid them all in a few kilobytes. That's beyond impossible, even for the best programmer in the world.

I agree with most of what has been said.

As nasty as that is, I'm pleasantly surprised Slashdot (Dice) ran this. Somebody has character to approve this story. I hope it doesn't get them fired for telling the truth.

> I am saying that the PRODUCT is math, not the thought process that goes into it.

A PRODUCT is something people buy.
I suggest that one of the greatest software makers of all time*, Steve Jobs, would tell us that the product is anything but math.
The math behind Mac is mostly the same as the math behind FreeBSD. The difference is the artistic aspects - design, etc. They are the same math, are they the same product? One is a bestselling product, the other hasn't even become a product at all.

Steve Jobs did a lot of stuff that annoys me, but he did it very well.

Try running some random executable from a thumb drive on a hotel computer and tell me how will that works.

Then the next person you see, ask them if it's okay for you to install weird "hacker" apps on their phone

Many coders who work in high level languages don't know what an "algorithm" is, so I disagree with the idea that they are professional algorithm designers.

A naive implementation of an interpreter is "algorithms" - generic functions for converting any pattern of type A into type B. As you said, long ago someone did the math, just as long ago someone designed the (mathematical) musical scale. Today's musicians and developers don't do a lot of math.

Designing a user interface that's beautiful, simple for beginners, and powerful for power users isn't a mathematical equation, it's an art, left-brain activity. If it were a math I could do it. My development team consists of me (the algorithms guy) and three people with art degrees. I can't do their job, not even a little bit. They can't do fractions, that's how mathematical they are. To make software requires all four of us - one math person and three people who have no math skills at all.

My 25% of a project is to take their art and manipulate it mathematically.

> not invented by humans, not the product of human activity. It's like saying the earth or the sun or Newton's laws of gravity should be patentable.

A = A is like the law of gravity, and not patentable.
An elevator is an invention based on gravity, and is patentable. An entirely new type of spam filter is a new invention, based on math.

It seems to me that the laws of physics and the laws of mathematics should be treated the same.
That also happens to be current law.

New inventions which make use of those laws similarly should be treated the same.

You say people could "disguise the laws" in a patent.
You could just as easily disguise Newton's laws.
There's no difference there between a machine built of wood and a machine built of pits in an optical disk. You're pretending there is a difference where there is none.

Since the laws of physics are not only similar to the laws of math, but in some cases the exact same laws, there are two arguments one can logically make:
invalid patents should be reduced (such as by allowing punitive damages in a counter-claim against a crap patent).
Nothing based on physics, and therefore nothing at all, should be patentable.

For me, I prefer option #1. If you sue on a patent and the court rules your patent is frivolous because it's obvious or whatever, you have to pay treble damages. That would reduce dumb patent suits and the motivation to file for dumb patents.

I see you didn't bother to read one word of my post before replying.
Does the computer in the hotel business center have ssh installed? No. Does a borrowed phone have ssh? No.

Ssh is great, until I run out of battery.

A web UI means I can handle an issue from any device - a computer in a hotel, grandma's cell phone, whatever.

Also, with many systems, a UI to navigate groups of systems can be handy.

That's an interesting choice of words, "toggle". Pull up a Google image search for "toggle".
For "toggle", you get a bunch of levers of various kinds, and some jackets.

> There is a difference. A lever says apply force at this vector and this physical object will produce X result.

The lever itself doesn't "say" anything, nor does it care about any result. As the Google result indicates, a lever is something that toggles -
a toggle switch is a switch with a lever.

> An X86 instruction, which is just an abstraction of machine code, simply toggles 0 and 1s and is completely generic.

Yes, it "simply toggles". Exactly the same thing a lever does. Just as a lever is a lever and doesn't care what other parts are
around it, the same with the instruction. They have precisely the same attributes. Interesting, isn't it.