Slashdot Mirror

Your desire is reflected in this article:

http://queue.acm.org/detail.cf...

Personally I have no opinion about HTTP/2, but I have to say that this anonymous hit piece looks a lot like some IETF participant who didn't like how the process came out trying to create the appearance of consensus against it by pumping up the anger of the interwebs without actually saying what's wrong with the spec. When I see people making statements not supported by explanations as to why we might want to consider them correct, my tendency is to assume that it's hot air trying to bypass the consensus process.

It's also a bit annoying to see the IETF accused of having published a document advocating snooping when in fact someone floated that idea in the IETF and it was shot down in flames, and what we actually published was a document stating that snooping is to be considered an attack and addressed in all new IETF protocol specifications (RFC 7258).

What "anonymous hit piece"? Second link in the fine summary has a clear byline, Poul-Henning Kamp.

From the article:

HTTP/2.0 is not a technical masterpiece. It has layering violations, inconsistencies, needless complexity, bad compromises, misses a lot of ripe opportunities, etc. I would flunk students in my (hypothetical) protocol design class if they submitted it. HTTP/2.0 also does not improve your privacy.

I too would like more details, but I doubt he's just blowing smoke here.

This was written by Poul-Henning Kamp, and published in the ACM Queue.

Intosi

Was easier for me to read.

http://cacm.acm.org/magazines/...

The article would be a less onerous read if the web designer had a basic understanding of typesetting. I will give him a hint.

1. Use a serif font. Sans serif fonts are ok for captions not sentences.
2. Make your writing black on white since it's easier to read. Not grey on white
3. Have white space margins to the left and right of your web page. Again easier to read.
4. The PDF and Digital copies are ok but a little thought could make them much more readable. As an example do one column or if you really need columns then two. Having three columns smacks of trying to be "arty" or "newspaperish" and not in a good way.

To me it appears that the writer has gone out of his way to make the article difficult to read. However I do find the article an interesting read.

Was easier for me to read.

http://cacm.acm.org/magazines/...

Peer Name Resolution.

The problem is that it's patent encumbered, by Mickeysoft, so it's useless.

There is also something called Hierarchical DHT-based name resolution.

Abstract:

Information-centric network (ICN) architectures are an increasingly important approach for the future Internet. Several ICN approaches are based on a flat object ID namespace and require some kind of global name resolution service to translate object IDs into network addresses. Building a world-wide NRS for a flat namespace with 10^1^6 expected IDs is challenging because of requirements such as scalability, low latency, efficient network utilization, and anycast routing that selects the most suitable copies. In this paper, we present a general hierarchical NRS framework for flat ID namespaces. The framework meets those requirements by the following properties: The registration and request forwarding matches the underlying network topology, exploits request locality, supports domain-specific copies of binding entries, can offer constant hop resolution (depending on the chosen underlying forwarding scheme), and provides scoping of publications. Our general NRS framework is flexible and supports different instantiations. These instantiations offer an important trade-off between resolution-domain (i.e. subsystem) autonomy (simplifying deployment) and reduced latency, maintenance overhead, and memory requirements. To evaluate this trade-off and explore the design space, we have designed two specific instantiations of our general NRS framework: MDHT and HSkip. We have performed a theoretical analysis and a simulation-based evaluation of both systems. In addition, we have published an implementation of the MDHT system as open source. Results indicate that an average request latency of (well) below 100ms is achievable in both systems for a global system with 12 million NRS nodes while meeting our other specific requirements. These results imply that a flat namespace can be adopted on a global scale, opening up several design alternatives for information-centric network architectures.

http://dl.acm.org/citation.cfm...

--
BMO

Encryption is not very expensive. A single core without any hardware help encrypts at a rate of 1Gbit/sec. With hardware carry-less multiplication, the rate at least 6x higher and with aes specific instruction at least 8x.

The cost of encryption is insignificant in comparison of the available power. If your heavy loaded web site have to send at gigabit, you need to dedicate a core or 0.10 to 0.2 core with specific instruction. If your system need to handle gigabit, it's probably a >8 cores system. You have consequently from 1% to 12.5% (without specific instructions) of your system used by the encryption. Most new systems embed specific instructions to handle encryption, we are thus converging to the 1%.

Colossus absolutely was general purpose - it just wasn't stored program. You had to set it up fresh for each program.

No, it wasn't general purpose. It was designed from the ground up to solve a very specific class of problems. It would have been possible (as the linked article states) to put a bunch of them together to form a Universal Turing computer, but it itself was not general purpose nor Turing complete.

The linked article is poorly informed, not to mention full of typos.

Here is the official announcement, straight from the ACM.

BTW, this ACM Queue article was linked from the blog post I linked above. It's another good, somewhat relevant read, IMHO. It makes largely the same point, though: It's more the programmer than the language.

http://dl.acm.org/citation.cfm...

So far, I don't think I've seen a single comment here that got the point of the essay.

He's not talking about incremental "improvements" to existing languages, he's pointing out that the common attitude of "we'll make this language easy to learn by making it look like C" is a poor way to achieve any substantial progress.

This is true but everyone who's invested a substantial amount of time learning the dominant, clumsy, descended-from-microcode paradigm is reluctant to dip a toe into anything requiring them to become a true novice again.

I've long been a big fan of what are now called "functional" languages like APL and J - wait, hold on - I know that started alarm bells ringing and red lights flashing for some of you - and find it painful to have to program in the crap languages that still dominate the programming eco-system. Oh look, another loop - let me guess, I'll have to set up the same boilerplate that I've done for every other loop because this language does not have a grammar to let me apply a function across an array. You want me to continue doing math by counting on my fingers when I've got an actual notation that handles arrays at a high level, but I can't use it because it's "too weird". (end rant)

There have been any number of studies - widely ignored in the CS world - going back decades (see this http://cacm.acm.org/magazines/...) - pointing out how poorly dominant programming memes mesh with the way most people think about problems and processes. Meanwhile, the 1960s called - they want their programming languages and debugging "techniques" back - "printf", anyone?

2006 ACM Programming Contest Poland 2nd and 7th in field of 12 http://it.slashdot.org/comment...

FROM THE RESULTS POSTED ON THE FRONT PAGE, FINAL SCORES/PLACEMENTS:

1. Saratov State University (Russia) - 6 problems
2. Jagiellonian University - Krakow (Poland) - 6 problems
3. Altai State Technical University (Russia) - 5 problems
4. University of Twente (Netherlands) - 5 problems
5. Shanghai Jiao Tong University (China) - 5 problems
6. St. Petersburg State University (Russia) - 5 problems
7. Warsaw University (Poland) - 5 problems
8. Massachusetts Institute of Technology (USA) - 5 problems
9. Moscow State University (Russia) - 5 problems
10. Ufa State Technical University (Russia) - 5 problems
11. University of Alberta (Canada) - 4 problems
12. University of Waterloo (Canada) - 4 problems

*AND*

Iirc, it was even BETTER for them in 2005 in the same contest.

2007 too -> Polish Students won ACM Programming Contest http://pbarut.blogspot.com/200... + Polish students prove best programmers in the world http://www.naukawpolsce.pap.pl...

Recently (2012) same deal "Russian, Polish Universities Take Top Spots in ACM ICPC Programming Contest" http://www.acm.org/press-room/...

TOTAL STATS FOR THAT PROGRAMMING CONTEST ARE HERE -> http://en.wikipedia.org/wiki/A...

APK

P.S.=> Yes, "I have a dog in this hunt" (I'm polish by descent, but 1st generation U.S. Citizen) & regarding Object-Pascal itself, I most *definitely* do (for great technical reasons shown here (yes, "shameless plug") http://developers.slashdot.org...

... apk

I wrote an article about long-term storage *hardware* in CACM -- "The Forever Disc". My favorite musing had to do with writing the data into a population's genetics, and letting redundancy correct errors/mutations..

Okay, but we're dealing with C and even in C++ you have to deal with null-terminated strings. Here's a case that is not extreme at all: copying a 100-byte string to another. Read below how inefficient the null char makes this very common and very basic operation.

One example is FreeBSD's libc, where the bcopy(3)/memcpy(3) implementation will move as much data as possible in chunks of "unsigned long," typically 32 or 64 bits, and then "mop up any trailing bytes" as the comment describes it, with byte-wide operations.

If the source string is NUL terminated, however, attempting to access it in units larger than bytes risks attempting to read characters after the NUL. If the NUL character is the last byte of a VM (virtual memory) page and the next VM page is not defined, this would cause the process to die from an unwarranted "page not present" fault.

http://queue.acm.org/detail.cf...

This is a real pity for the TM community. This is not the first chip with transactional memory support in hardware: The Sun Rock was announced to have hardware TM support, and the IBM Blue Gene/Q Compute chip also supports it. Unlike other proposals for unbounded transactional memory, all these systems employ Hybrid Transactional Memory (ref, ref, ref), in which restricted hardware transactions are designed to correctly coexist with unbounded software transactions, so a software transaction can be started in case a hardware transaction fails for some unavoidable issue (such as lack of cache size or associativity to hold speculative data from the transaction, not because of a conflict). Note that, in any case, very large transactions should arguably be very uncommon, since they would significantly reduce performance (similar to very large critical sections protected by locks).

The problem with the hardware implementation of transactional memory is that they are not simply a new set of instructions which are independent from the rest of the processor. HTM implies multiple aspects, including multiversioning caching for speculative data; allowing for the commit of speculative (transactional) instructions, which could be later rolled back (note that in any other speculative operation such as instructions after branch prediction, the speculation is always resolved before instruction commits because the branch commits earlier); a tight integration with the coherence protocol (see LogTM-SE for an alternative to this very last issue, but still...); a mechanism to support atomic commits in presence of coherence invalidations... From the point of view of processor verification, this is a complete nightmare because these new "extensions" basically impact the complete processor pipeline and coherence protocol, and verifying that every single instruction and data structure behaves as expected in isolation does not guarantee that they will operate correctly in presence of multiple transactions (and non-transactional conflicting code) in multiple cores. There are some formal studies such as this or this, and the IBM people discuss the verification of their Blue Gene TM system in this paper (paywalled).

As some others commented before, the nature of the "bug" has not been disclosed. However, since it seems to be easy to reproduce systematically, I would expect it to be related to incorrect speculative data handling in a single transaction (or something similar), rather than races between multiple transactions.

Regarding the alternatives, Intel cannot simply remove these instructions opcodes because previous code would fail. I assume that the patch will make all hardware transactions fail on startup, with an specific error (EAX bit 1 indicates if the transaction can succeed on a retry; setting this flag to 0 should trigger a software transaction). In such case, execution continues at the fallback routine indicated in the XBEGIN instruction, which should begin a software transaction. Effectively, this will be similar to a software TM (STM) with additional overheads (starting the hardware transaction and aborting it; detecting conflicts with nonexistent hardware transactions) that would make it slower than a pure STM implementation.

The government would get screwed in the deal. The most effective exploits would somehow be left out of the deal.

Worse. The proposed program would encourage the software vendors to deliberately place bugs into their code — so as to sell them to government later. It would not even be illegal for them to do so, it seems, not under the current laws.

I am a long time member of the ACM, and I've always thought the value for money was excellent. I'm not an academic and I don't go to conferences. The Safari and 24/7 Books Online subscriptions, plus the skillsoft training is where I see most of the value.

That peaked my interest quite a bit. However, after looking into it, that gets you a custom collection from each of those book places (700 safari books online, and 500 books 24x7, and 150 morgan kaufmann and syngress books). Safari, for example, offers far more books on their cheapest plans (which includes over 200 publishers).

ACM also offers a discounted Safari Pro upgrade: http://learning.acm.org/books/...
The ACM price is 20% off list. The Safari Pro package is $39/month or $399/year. So you save either $93.60 or $60 a year.
If you wanted to get the Safari Pro already, then you might as well join ACM and do the pro upgrade... it's almost a wash, and you get the other ACM benefits.
I was hoping for a bit more of a free ride :-) Still not a bad deal, but thought others might want to know.

Yep. Their Code of Ethics says:

1.5 Honor property rights including copyrights and patent.

Violation of copyrights, patents, trade secrets and the terms of license agreements is prohibited by law in most circumstances. Even when software is not so protected, such violations are contrary to professional behavior. Copies of software should be made only with proper authorization. Unauthorized duplication of materials must not be condoned.

I don't pirate software. I pay for the stuff I use when required. However, I damn sure don't respect software patents or nebulous "terms of license agreement" EULA bullshit. I'll honor them as mandated by law to keep me and my employer out of trouble (although every programmer reading this has probably violated 3 stupid patents today in the course of their job). And while the RIAA doesn't "authorize" me to rip CDs I've bought, I'm legally entitled to do so and will at my convenience.

I think my views are pretty mainstream among programmers. If the ACM wants me to join, they need to remove the requirements for me to worship pro-corporate, anti-citizen, rent-seeking behavior. I can't ethically consent to support their unethical Code of Ethics.

Mostly this Committee. They pushed their own agenda too hard for most ACM members.

There is as an academic. Apparently being a member of the ACM has a negative value, because in exchange for the $99/year membership fee I typically get a $100-150 discount on attending ACM conferences. If you go to a couple of conferences a year then that's a good deal. For people outside academia, there's less relevance. ACM Queue, which provides material for 'practitioners' section of Communications of the ACM, generally has some good material, but it's all free whether your an ACM member or not.

I like the ACM as an organisation, but they're hard pressed to justify the cost of membership.

The problem is that Korea requires use of their own national encryption standard, which has a governmental back door (and for which exploits have already been demonstrated at BlackHat) in order to "secure" banking transactions from snooping by foreign powers (guess they called that one correctly).

[citation needed]

Can you provide a link to the paper/presentation in which the exploit and/or backdoor has been shown?

A quick search doesn't turn anything up, but "seed" is a bit of a generic term (and is also used in reference to RNG in crypto) and so there's a lot of noise.

http://dl.acm.org/citation.cfm... (search for "SEED encryption", with the quotation marks to get similar results).

Here's another algorithm indicating identity exposure (SEED's keying system is specifically designed to *always* expose identity, which means that a lot of sites aren't very secure, since they can know who the culprit was, they don't figure they need to secure them):

http://privacy-pc.com/articles...

I'm pretty sure the demo was by Chae Jong Bin, if that helps.

CSTA K-12 CS Standards: Mapped to Common Core State Standards. BTW, Google recently hired the Executive Director of CSTA as a Computer Science Education Program Manager.

The corrected link also didn't work for me, but I can fetch the PDF from this site (also linked above): https://dl.acm.org/citation.cf...

The full link above does not work, but this one works for me

It's not a direct help, but I can tell you that it's certainly possible these days to communicate and control external actuators using brain activity only. What they're doing (AFAIK) is record the 2D electrical activity on the brain's surface (using EEGs on the scalp or -- for even greater accuracy -- below the skull bone), analyze it statistically and deduce what the person is thinking of doing, e.g. move a mouse pointer in some direction and choose which of several buttons to press. It requires a learning phase, but then the accuracy is quite high. I'm not sure about the actual bandwidth that you can achieve when communicating using this method only, but it's much better than what was possible only a few years ago, and it's improving further.

Brain-Computer Interface-The HCI communication channel for discovery

brain-controlled Pinball

(the links refer to a Berlin-based research group -- but that's just a coincidence because I live there a saw a presentation a few weeks ago. I'm sure there's even more research on the subject in the US).

See IEEE Code of Ethics (a simple, yet succinct and to-the-point code), and ACM's Software Engineering Code of Ethics and Professional Practice. Even reading section 1 of the ACM code, it is abundantly clear it is not being legally enforced. In particular 1.03 & 1.06 jump out at me.

Problem is, professional ethics codes are generally not legally binding unless you are professionally licensed in a discipline by the state, and the licensing indicates the code of ethics that must be followed. Additionally, the ethics code might only apply if you are officially acting within your licensed capacity. (I error on the side of caution in that I assume everything I do professionally falls subject to my licensed discipline - just in case). Some states refer to professional organizations for the code of ethics (i.e. for Electrical Engineers, the IEEE code may be referenced), some states may provide their own code of ethics. I'm also unaware of any US states that professionally license software engineers.

I personally had one instance at my previous employer where my boss asked my to do something unethical, and illegal. I stalled for two weeks while I debated resigning or blowing the whistle to HR on my boss (and also possibly resigning). In the end, I didn't have to do either, because my boss was fired in that time for unrelated things and I was never asked by another manager to do the same action.

We also have a comment from the FreeBSD developer Poul-Henning Kamp.

He starts by saying "The OpenSSL software package is around 300,000 lines of code, which means there are probably around 299 bugs still there, now that the Heartbleed bug — which allowed pretty much anybody to retrieve internal state to which they should normally not have access — has been fixed." After that he notes that we need to ensure that the compiler correctly translates the high-level language to machine instructions. Later Kamp rants a bit about the craziness of CAs in general — would you trust "TÜRKTRUST BLG LETM VE BLM GÜVENL HZMETLER A.."? Then he lists some bullet points about things that are wrong in OpenSSL:

- The code is a mess
- Documentation is misleading
- The defaults are deceptive
- No central architectural authority
- 6,740 goto statements
- Inline assembly code
- Multiple different coding styles
- Obscure use of macro preprocessors
- Inconsistent naming conventions
- Far too many selections and options
- Unexplained dead code
- Misleading and incoherent comments

"And it's nobody's fault. No one was ever truly in charge of OpenSSL, it just sort of became the default landfill for prototypes of cryptographic inventions, and since it had everything cryptographic under the sun (somewhere , if you could find out how to use it), it also became the default source of cryptographic functionality. [...] We need a well-designed API, as simple as possible to make it hard for people to use it incorrectly. And we need multiple independent quality implementations of that API, so that if one turns out to be crap, people can switch to a better one in a matter of hours."

In most places "Software Engineers" meet no accreditation requirements, have no requirement to belong to any society which regulates ethics, experience or training.

I've worked with real engineers, ethics was more important than their education.

There is no requirement to belong, but at least there is a society that promulgates ethics.

In most places "Software Engineers" meet no accreditation requirements, have no requirement to belong to any society which regulates ethics, experience or training.

I've worked with real engineers, ethics was more important than their education.

There is no requirement to belong, but at least there is a society that promulgates ethics.

Last August the ACM had a whole issue on detailed technical aspects of all parts of trading. I dont recall talk a part on front-trading. But how to shave off yet another few microseconds. Fascinating.

Paul Stachour describes fixing this (and other problems) back in the Mainframe era in the article http://cacm.acm.org/magazines/...

Whether the companies in question can read is a different question...

Too many developers with CS degrees, too few with SE degrees, and nearly none with IS degrees. See http://www.acm.org/education/c... for more details on the differences.

According to the ACM (you know, the experts in this topic), there are five basic courses of study:
Computer Engineering (making the hardware)
Computer Science (designing the algorithms)
Software Engineering (release processes, patch management, etc)
Information Systems (translating business processes to code)
Information Technology (putting all the pieces of the system together an maintaining the whole lot).

You can read more at the ACM (Association for Computing Machinery) at http://www.acm.org/education/c...

This is a fallacy. If you take a look at the kind of presentations you see at top-tier computer graphics conference (i.e. SIGGRAPH -- shameless plug [paywalled] and another one), you will see that using all the fancy features of today's presentation software really can help in delivering the content of the presentation in a nice and intuitive way. The problem is that most people aren't willing spend one week on a presentation (except for top-tier computer graphics conferences).

Only like the criminals the news likes to call hackers.

Blurred lines that requires the clarity of ethics to make sense.

I submit the thought that there are more than one type of 'hackers'. In a classroom or in a setting where the effects can be reversed, then hackers can be beneficial, ala the recent article Teach hacking in high school. Even Mitnick's extreme actions had the benefits of highlighting the ineffectual.

But this thought has been common. Affecting the hacker's morality with something like the Association of Computing Machinery's Code of Ethics is a tough challenge, but worth it.

A wider question is why is not there any liability for programming errors? All end-user licenses (both free and otherwise) explicitly renounce any such — and we accept it. Maybe, we should not...

I saw the same idea showcased at a conference last year by a a japanese team led by Mitsubayashi. They had succesfully done this in rabbits. Their paper from 2012 http://dl.acm.org/citation.cfm?id=2230586 and 2005: http://onlinelibrary.wiley.com/doi/10.1002/elan.1140070110/abstract

Poul-Henning Kamp is probably best known for his phkmalloc used in FreeBSD, and Varnish http cache. He's one of the few who understood that virtual memory under stress essentially behaves like a block device, so he writes software to exploit that.

Let's start with the premise of TFA, which cites the article on Ars that was covered here a few days ago and was complete nonsense about the new random number infrastructure in FreeBSD. We are not moving away from using the hardware random number generator directly, we have never used the hardware random number generator. The new code that the Ars article was talking about is to allow the PRNG to be easily switched. In 10 we're shipping both Fortuna and Yarrow and the infrastructure allows more to be added. The code has been reviewed by two cryptographers that I know of and possibly others. Neither the old nor the new implementation is vulnerable to the attack against random number generators that was published a couple of months ago (Linux was the subject of the paper, not sure if OpenBSD was vulnerable).

If Theo is going to make such remarks as this, he should think more carefully first:

"Basically, it is 10 years of FreeBSD stupidity. They don't know a thing about security. They even ignore relevant research in all fields, not just from us, but from everyone."

He'd be advised to take a look at the transactions for the IEEE Symposium on Security and Privacy over the last 10 years and see how many papers are describing techniques that were both originally implemented on FreeBSD and are now part of the default install. Let's take a look at the two systems, from a security perspective. Both FreeBSD use SSP and non-excutable stack by default, so I'll skip those. To begin with, OpenBSD features missing on FreeBSD:

W^X enforcement. Definitely a nice idea, but it breaks some things (JITs mostly). The default memory map in FreeBSD is W^X, but it is possible to explicitly mmap() memory both writeable and executable. It's generally considered a bad idea though, and we don't ship any code that allows it. We permit third-party code to shoot itself in the foot if it really wants to and provide mitigation techniques to reduce the risk.

Then there's ASLR. This is a pretty nice technique, which is currently not implemented on FreeBSD. We do support PIE, so it would not be a horrendously difficult thing to add, but current implementations (including OpenBSD) use a surprisingly small amount of entropy in the address layout and so don't provide as much mitigation as you'd hope (which, of course, Theo knows, because he's very familiar with 'relevant research'). This is especially true on 32-bit systems.

And that's it for OpenBSD. Well, unless you want to count , but since that's vulnerable to a timing attack (still not fixed), which was published in the USENIX Workshop on Offensive Technologies, and Theo is aware of all 'relevant research' in security then it can't really still be there.

Now let's look at FreeBSD security mechanisms:

First up, jails. Jails are somewhere between a chroot and a VM: a shared kernel, but all of the global namespaces (filesystems, IP addresses, users) are separated and so you can completely isolate a service, such as a web browser, from the rest of the system. Scripts like ez-jail in the ports tree make it easy to set up lightweight service jails.

Then there's the MAC framework, which allows modular access control policies. This is used by a couple of FreeBSD derivatives: JunOS uses it to implement code signing, OS X and iOS use it for application sandboxing. You can also use it for traditional type enforcement policies, as in SELinux and a variety of other things.

And then there's Capsicum, which adds a capability model on top

Let's start with the premise of TFA, which cites the article on Ars that was covered here a few days ago and was complete nonsense about the new random number infrastructure in FreeBSD. We are not moving away from using the hardware random number generator directly, we have never used the hardware random number generator. The new code that the Ars article was talking about is to allow the PRNG to be easily switched. In 10 we're shipping both Fortuna and Yarrow and the infrastructure allows more to be added. The code has been reviewed by two cryptographers that I know of and possibly others. Neither the old nor the new implementation is vulnerable to the attack against random number generators that was published a couple of months ago (Linux was the subject of the paper, not sure if OpenBSD was vulnerable).

If Theo is going to make such remarks as this, he should think more carefully first:

"Basically, it is 10 years of FreeBSD stupidity. They don't know a thing about security. They even ignore relevant research in all fields, not just from us, but from everyone."

He'd be advised to take a look at the transactions for the IEEE Symposium on Security and Privacy over the last 10 years and see how many papers are describing techniques that were both originally implemented on FreeBSD and are now part of the default install. Let's take a look at the two systems, from a security perspective. Both FreeBSD use SSP and non-excutable stack by default, so I'll skip those. To begin with, OpenBSD features missing on FreeBSD:

W^X enforcement. Definitely a nice idea, but it breaks some things (JITs mostly). The default memory map in FreeBSD is W^X, but it is possible to explicitly mmap() memory both writeable and executable. It's generally considered a bad idea though, and we don't ship any code that allows it. We permit third-party code to shoot itself in the foot if it really wants to and provide mitigation techniques to reduce the risk.

Then there's ASLR. This is a pretty nice technique, which is currently not implemented on FreeBSD. We do support PIE, so it would not be a horrendously difficult thing to add, but current implementations (including OpenBSD) use a surprisingly small amount of entropy in the address layout and so don't provide as much mitigation as you'd hope (which, of course, Theo knows, because he's very familiar with 'relevant research'). This is especially true on 32-bit systems.

And that's it for OpenBSD. Well, unless you want to count , but since that's vulnerable to a timing attack (still not fixed), which was published in the USENIX Workshop on Offensive Technologies, and Theo is aware of all 'relevant research' in security then it can't really still be there.

Now let's look at FreeBSD security mechanisms:

First up, jails. Jails are somewhere between a chroot and a VM: a shared kernel, but all of the global namespaces (filesystems, IP addresses, users) are separated and so you can completely isolate a service, such as a web browser, from the rest of the system. Scripts like ez-jail in the ports tree make it easy to set up lightweight service jails.

Then there's the MAC framework, which allows modular access control policies. This is used by a couple of FreeBSD derivatives: JunOS uses it to implement code signing, OS X and iOS use it for application sandboxing. You can also use it for traditional type enforcement policies, as in SELinux and a variety of other things.

And then there's Capsicum, which adds a capability model on top

The only way to truly prevent bitrot is by maintaining at least three complete copies of the data, and regularly compare between them.

There you go again. Acting like you know what you're talking about, but you don't.

ZFS and BTRFS have a much more efficient way to ensure correctness: CRC of everything written. That is what is checked when you do a zpool scrub or a btrfs scrub. Random errors are very unlikely to produce the same checksum, so then you only need a second copy that doesn't produce CRC errors.

Hard drives are nowhere near as reliable as their manufacturers claim. Modern drives don't store the bits that you feed them exactly as you give them. Instead, they use CRC and error correcting codes, so they only need most of the data to be correct. Usually, if the data doesn't match the CRC, and it cannot be corrected by ECC, then you get a read error instead of corrupted data. Which, I guess, is better than getting a corrupted picture. Ideally, a RAID would be able to recreate the missing block, but I can't find any reference to a RAID doing that.

But I've seen enough errors that I suspect something else is going on. It surely doesn't help that modern computers have many gigabytes of memory, but almost none have ECC on that memory. Your computer can be corrupting your data, and you have no warning that it's happening. In addition, hard drives lie. I'm not optimistic about the long-term storage of electronic data.

The only way to truly prevent bitrot is by maintaining at least three complete copies of the data, and regularly compare between them.

There you go again. Acting like you know what you're talking about, but you don't.

ZFS and BTRFS have a much more efficient way to ensure correctness: CRC of everything written. That is what is checked when you do a zpool scrub or a btrfs scrub. Random errors are very unlikely to produce the same checksum, so then you only need a second copy that doesn't produce CRC errors.

Hard drives are nowhere near as reliable as their manufacturers claim. Modern drives don't store the bits that you feed them exactly as you give them. Instead, they use CRC and error correcting codes, so they only need most of the data to be correct. Usually, if the data doesn't match the CRC, and it cannot be corrected by ECC, then you get a read error instead of corrupted data. Which, I guess, is better than getting a corrupted picture. Ideally, a RAID would be able to recreate the missing block, but I can't find any reference to a RAID doing that.

But I've seen enough errors that I suspect something else is going on. It surely doesn't help that modern computers have many gigabytes of memory, but almost none have ECC on that memory. Your computer can be corrupting your data, and you have no warning that it's happening. In addition, hard drives lie. I'm not optimistic about the long-term storage of electronic data.

Not so sure how good this is. From what I can see, the equal error rate of palm identification is 0.17, compared to 0.01 for fingerprint identification.

The short answer is no. The long answer is no ... and a very long list of reasons why.

Start with reading Goldbergs classic paper "What Every Computer Scientist Should Know About Computer Arithmetic" Sun's floating point group made some improvements to the paper and paid for rights to redistribute. Oracle continues to do so. http://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html

If that isn't depressing enough, and you use trig functions, read http://www.scribd.com/doc/64949170/Ng-Argument-Reduction-for-Huge-Arguments-Good-to-the-Last-Bit you can get the source from netlib for "fdlibm" which is under a BSD flavor license.

If the purely software issues haven't made you realize that you haven't got much of a prayer, please note that different revs of the same intel chips sometimes provide slightly different results (sometimes intentionally, sometimes as a result of tweaking the order of execution in the out of order execution engine). Older x87 arithmetic was 80-bit, newer x64 arithmetic is pure 64-bit, providing no end of fun. Using the SSE instructions provides more variation.

If the pretty much (in principle) "simple" and potentially deterministic software issues aren't enough consider the reality of hw. Chessin has a very good, yet amusing, explanation of the key problems http://queue.acm.org/detail.cfm?id=1839574

Lest you think they only apply to a particular generation of boutique processor, most HPC ensembles are now built out of standard server motherboards and chips.

http://www.csm.ornl.gov/srt/conferences/ResilienceSummit/2010/pdf/michalak.pdf The issue of undetected soft errors is big and growing, as can be seen from the activity in the literature. SC13 "ACR: Automatic Checkpoint/Restart for Soft and Hard Error Protection" (which has lots of good citations of earlier work, including field data such as 27 soft errors per week leading to fatal node failures (that is, wrong enough results that while the hw didn't detect any problem, the issue caused the node to crash) on just one ensemble (ASC Q). its going mainstream in that HPCwire caught wind and in 31 Oct 2013 had a nice tabloidesqe writeup entitled "Addressing the Threat of Silent Data Corruption"

Neutron's don't only disrupt memory elements, but can hit logic as well. See the upcoming issue (already available via IEEE xplorer for member/subscribers) JOURNAL OF SOLID-STATE CIRCUITS, VOL. 49, NO. 1, JANUARY 2014 The 10th Generation 16-Core SPARC64 Processor for Mission Critical UNIX Server" which details the lengths some (but not many) go to ensure that there are no undetected errors (wide range of techniques, ranging from where wires are placed on the chip, ECC, parity, residue arithmetic, automatic retry, etc.). No doubt there are some good (similar) papers in the IBM Technical Journal.

No doubt a good literature search would turn up dozens of other papers, and circuit design textbooks cover some of the territory.

In principle, interval arithmetic could provide a solution (you might not get the same interval, but if the intervals nest, you have consistent results and if they are disjoint you have a bug ... and if they nest, the narrower one is "sharper" which is better). In practice, most algorithms haven't been reworked for good interval implementation, languages don't provide very good support, nor does most hardware. All fixable in principle, but unlikely to be the solution you seek for todays off the shelf virtual systems available cheaply.

Actually, the Curry-Howard correspondence means that every proof can be translated into a program (and vice versa as long as you're working with the right computational model).

Of course the programs you get when translating the proof of a normal theorem won't be things like "use the machine add instruction to add two native floating point numbers" - instead they'll be e.g. some lengthy computation in a typed lambda calculus with extra control instructions, which you can run on a computer with the right interpreter. Not necessarily the best, as you say, for communication about the theorem.

1. Python. I thought all the quants liked C, assembler, and even VHDL for their high frequency stuff.

Not necessarily. For example, an HFT company Jane Street Capical uses OCaml, claiming it makes code reviews go a lot faster and Knight-style errors a lot less likely. https://queue.acm.org/detail.cfm?id=2038036

Not exactly traditional science but I suspect my comment may have influenced the "bufferbloat" and network people barking up the wrong tree to instead make something like codel.

They were saying oversized buffers were the problem:
http://queue.acm.org/detail.cfm?id=2071893

So I commented there (excerpt of full comment):

In my opinion the actual solution to latency is not a reduction in buffer sizes. Because the real problem isn't actually large buffers. The problem is devices holding on to packets longer than they should. Given the wide variations in bandwidth, it is easier to define "too high a delay" than it is to define "too large a buffer".

Not long after that the Taht guy who replied to me implemented codel.

Perhaps they were already working on it, but it's not even obvious that they were from Van Jacobsen's 2006 rant on queues: http://www.pollere.net/Pdfdocs/QrantJul06.pdf

Because while they were definitely complaining about the problem for a long time it still looked up till then like they were missing a key factor for the solution - time spent in queue by packets.

Unix was about minimalism, and sometimes GNU seems like it's about stuffing everything possible into every tool.

I take it you've read A Generation Lost in the Bazaar?

Warning: pdf
http://wpcme.coverity.com/wp-content/uploads/2012-Coverity-Scan-Report.pdf
explains much if not all that you ask

For a good article and a fun read that goes into the background of Coverity and what it does, see
http://cacm.acm.org/magazines/2010/2/69354-a-few-billion-lines-of-code-later/fulltext
it's written by some of the developers and founders