I think the problem is rather ignorance. People send a letter and expect to be secure in their persons and papers, but don't understand that e-mail is (and I'm not saying it shouldn't be) neither.

End to end encryption is quite secure. But not for the ignorant. Free markets are fair, but not for the ignorant. Democracy is good, but not for the ignorant.

It's almost like ignorant people are a drain on any system. As the technocrati, we can establish security and privacy. But we can't protect the ignorant without asking them to select particular tools. A read-only OS which reboots in between almost every action, installed behind a router with an open hardware design, behind another open hardware firewall. Rotating external storage which is quarantined like backup tapes are rotated.

It's not impossible, it's just difficult. Ignorance, and mistakes on the side of convenience, are the enemy, if you consider everyone as a suspect.

On the other hand, if I like an author and the same audience chose that and another author, I'm likely to at least not consider the second author a waste of time.

How do you choose your authors? By their cover? By listening to people who do read awards lists? By ignoring popular culture until you're reading leftovers?

I am aware of literary awards, and when I choose between one or another book, I choose because I vaguely recognize the author. If the first chapter stinks I consider it an attempt, not a read.

Do you consider reading the first chapter to be reading? Reading the back cover? About the author? The cover?

I bet you just made the decision subconsciously and were not aware, to be redundant. As for who cares? The people standing to lose or gain - the authors, the publishers, and those readers who feel loyalty to an author. As well as those who might not otherwise have heard of the author - certainly they care?

I read for these fuckers too much to be arsed trying to figure what a notably inflammatory submitter intimates.

Test scores mean shite, and the relation to improving education is obviously null. It persists for the same reason the war on whatever exists. We can solve the problem of drugs, or prostitution, or terrorism, or education, if we understand it. If we refuse to understand and rely on what we believe, we can just expect to spend more money with no results.

This much was obvious to me before 2000. Your post has been said repeatedly by actual teachers since then.

I maintain my objection that theodp remains on the minus side of being informative, precisely because of this context shifting. Wouldn't another cheating scandal have been more appropriate? Because take your pick. In fact, that is probably the actual story here - cheating ongoing after nearly 20 years. But I don't write this shit, don't edit this shit, and only read this shit because most people apparently are incapable of such.

I'm used to theodp putting things into selective context so they sound better or more usually worse than they are, but WTF is up with this one? Would higher teacher salaries somehow have something to do with a culture of fear and retaliation? Do well paid people not feel this kind of pressure?

Would have been a lot more clear to say "the redacted bits are from patents approved by the USPTO." I hate having to go on easter egg hunts to confirm if this is something I should care about.

And for Cassini2 specifically, it's not an issued patent vs. rejected patent. Both were issued, the point being that the new one was issued after the first was invalidated by a district court. And about 5 months after Alice. And the second was a continuation of the first, not a new patent. That's why they are so similar, and probably why they didn't halt the process and re-evaluate it.

USPTO wanted comments on the guidance, not pointing out where they are failing to meet the guidance. This is where the EFF probably overstepped.

I have a problem with this part. The Alice decision was basically "adding a computer doesn't automatically make it novel" - the court did not agree that "adding a computer automatically doesn't make it novel" - those are two distinct ideas. And what the EFF pointed out in the chart was that two allowed patents were basically the same, which is what a continuation patent implies, and has nothing to do with Alice.

It's one thing to have a point, but the EFF was protesting the similarity of two patents, not illustrating how the second fell short of the Alice test, and it really had nothing to do with comments on the guidance itself, which is what the USPTO was asking for. Including protests in consideration of feedback on guidance is not how things work. I won't go into that, but there's a place for such things and this isn't it.

And I agree, EFF has a legitimate point. But this was not the way to point it out.

Legally, this is what I read:

Q: "How can we do our jobs better?"
A: "You aren't even doing your jobs, idiots."

A better version of Linus' Law would be the original one.

So, if rapid releases and leveraging the Internet medium to the hilt were not accidents but integral parts of Linus's engineering-genius insight into the minimum-effort path, what was he maximizing? What was he cranking out of the machinery?

Put that way, the question answers itself. Linus was keeping his hacker/users constantly stimulated and rewardedâ"stimulated by the prospect of having an ego-satisfying piece of the action, rewarded by the sight of constant (even daily) improvement in their work.

Linus was directly aiming to maximize the number of person-hours thrown at debugging and development, even at the possible cost of instability in the code and user-base burnout if any serious bug proved intractable. Linus was behaving as though he believed something like this:

        8. Given a large enough beta-tester and co-developer base, almost every problem will be characterized quickly and the fix obvious to someone.

Or, less formally, ``Given enough eyeballs, all bugs are shallow.'' I dub this: ``Linus's Law''.

My original formulation was that every problem ``will be transparent to somebody''. Linus demurred that the person who understands and fixes the problem is not necessarily or even usually the person who first characterizes it. ``Somebody finds the problem,'' he says, ``and somebody else understands it. And I'll go on record as saying that finding it is the bigger challenge.'' That correction is important; we'll see how in the next section, when we examine the practice of debugging in more detail. But the key point is that both parts of the process (finding and fixing) tend to happen rapidly.

http://www.catb.org/~esr/writi...

-1 redundant

So we should view bug bounty programs as an additional angle of attack, another aspect of "defense in depth", perhaps optimized a bit more for commercial projects where there is ample money. And that's OK.

That's from the fucking article. You're not helping.

The problem is, Jeff is uncomfortable with the idea. That's the whole of the foundation in the linked article. But there is this point:

The incentives feel really wrong to me. As much as I know security is incredibly important, I view these interactions with an increasing sense of dread because they generate work for me and the returns are low.

Not all reports of security issues will be real issues, and if you offer bounties some people will be looking for an easy payout.

Most of the article is useless junk:

If your focus is the payout, who is paying more? The good guys, or the bad guys? Should you hold out longer for a bigger payday, or build the exploit up into something even larger? I hope for our sake the good guys have the deeper pockets, otherwise we are all screwed.

And variations. If we stop paying bounties, what happens? A few people unconcerned with legal aspects will sell bugs to the bad guys, and the people concerned with legalities will just report bugs for free. One bad assumption by Jeff is that people will (or can) sell security problems to the bad guys with no ethical qualms, that it is perfectly fungible and only depends on who can afford to pay.

I'm guessing Jeff spent an hour chasing a bad report, got emotional, and wrote this as a result of that experience. That doesn't help.

A shallow bug is one that can be fixed, or at least understood and described, quickly, easily, or simply.

That doesn't mean the bugs will be found, it characterizes what happens after they are found.

I don't believe Linus' Law has anything to do with the number of bugs *found*, rather bugs *fixed*.

It is the open source community that says more bugs will be found because anyone can read the source - but then no one reads the source. And then people (mis) understand that Linus' Law somehow means that all bugs will be *found*.

Your first paragraph is sensible, and then you fell into the trap in the second paragraph. It is still true, and OpenSSL is not an exception - as you said, it did not have enough eyeballs, so it is exactly the point that Linus was making.

The question is, how? I'm not going to reveal personal details, but it sounds like you should.

Have you surveyed my potential employers?

Because if not, fuck you. If I need a job, "all I need to tell them" relies on how many dollars I would like to earn in the next 3 months.

Change your name to "employed optimist" while you still can.

Alternatively, the old ways of networking still work.

It is good advice to have a linkedin profile just in case. If for no other reason, then to own your identity.

Facebook can be explained by being in contact with the people you care about in person, by phone, by email, or not at all. Old school.

Or, seek employment with people who don't care about your FaceBook profile. Easier said than done, but that's on you, not me.

they aren't all captioned

Well, they all look the same to me.

"And because these JavaScript APIs"... does that mean that the idiotic and uninformative anonymous coward with the initial reply was correct?

If so, these two things do not go together. And I need to nerd rage on social.msdn.microsoft.com instead of here.

• C#, Visual Basic, F#, C++, Python, Node.js and HTML/JavaScript
• Build for iOS, Android, Windows devices, Windows Server or Linux

For iOS, supporting PhoneGap and random WebKit for Linux makes sense.

With open sourcing of the .NET framework, Linux C# makes sense.

I'm not sure how the Javaness of Android might be tamed, other than processing .NET bytecode to Java bytecode.

I'm not sure how C++ would work. Considering Corona uses Lua to Objective-C, and Marmalade is kind of an anything goes, there are possibilities way beyond an uninformed anonymous coward.