rian

hehe or "Deadlocks considered harmful."

Pure callbacks aren't universally useless. For instance, the qsort() API can use pure synchronous callbacks effectively: http://linux.die.net/man/3/qsort

The article doesn't advocate always requiring pure callbacks. It's just offered as one possible way to make it easy to reason about the correctness of using an callback API.

This is a good description of the state of hardware engineering but I think the implication is that this will never change is incorrect. Also the main point has little to do with open-source. By these arguments, even engineering practices for proprietary hardware are prohibitive to rapid development.

Before we had compilers, debuggers, code analysis tools, garbage collection, etc. building software was hard too! Some would argue that building software is still hard.

Hardware engineering clearly needs more accessible and easier to use tools, open source can actually help this. The best and most-used software development tools are open-source. An open landscape will encourage development innovation as more and more people become hardware developers.

With that in mind, I would actually title this article something like "Why hardware engineering needs to be open-source to advance."

Well, there are still some good reasons to write things in C. For one it's standardized. Two it's ubiquitous.

I agree that projects should have a way to verify with 100% accuracy the memory safety of their code. One way to do that is to rewrite in another language.

Another way to do that is to use a static analyzer that lists out all unsafe operations in your codebase. Here's one http://goto.ucsd.edu/csolve/. Adds an extra build step / precommit-hook but IMO the cost/benefit is much better than rewriting your project. After all, we can't just rewrite our code every time a new safe language comes out.

Agree that Rust is not a magical fix-all solution. Rust ensures memory safety and prevents data-races but there are still a whole universe of programming-error-induced vulnerabilities that Rust will happily compile and run.

Don't get me wrong, using a more restrictive language will help but it's not a fully-baked solution. We need more third-party tools to help us automatically verify the correctness of our programs. It shouldn't stop at compilers.

While modernizing and redesigning the Plan 9 UI is a valiant cause, it may not be the most efficient way to accomplish your goals.

I'd venture to say that Plan 9 was never meant to be a mainstream OS. It essentially served as a playpen for new OS/systems ideas and research at Bell Labs at the time.

A lot of those ideas were pretty influential: union mounts, per-process namespaces, user-space file systems, UTF8, human-readable protocols, rfork(), file-object interface ubiquity, concurrent programming model, etc. You can see how these ideas have pervaded our current systems landscape.

The implementation of Plan 9 itself is great, but I don't think success of the Plan 9 project should be limited to whether or not its specific implementation stays current and modern. The UX was never designed with the common user in-mind, and it arguably was never the core focus for the system. A greater success would be to see its actual core ideas spread out into other mainstream systems.

So instead of making the Plan 9 UX more modern, why not work on getting some of its missing features into Linux instead? Last time I checked, Linux still needs a union-mount implementation. This way, the world benefits.

BTW, you might like this: http://swtch.com/plan9port/

"Open Source" terminology emphasizes its technical superiority as a development method.

"Free Software" terminology emphasizes its ethical necessity to maintain a free society.

One is technical, one is political/ideological. Open source advocates don't care about politics, Free software advocates think technical superiority is unimportant in a non-free society.

Stallman's own words on this distinction in this video: https://www.youtube.com/watch?v=Ag1AKIl_2GM

If you're looking for actively developed cross platform free software alternative: http://www.getsafe.org/

if you guys think this is cool, check this out: https://en.wikipedia.org/wiki/Yonaguni_Monument

Unfortunately, any tiny edit within your TrueCrypt will cause Dropbox to re-read and re-hash the entire volume, and that can take a long time and drain a lot of battery. Safe fits more naturally with Dropbox.

For the WebDAV RAMDisk, Safe will not use more than 1/5 of your commit so you're limited by that.

Currently yes, but I've gotten a lot of the same feedback and I'll make it optional in the next release (within the week :)

Follow us on Twitter (http://twitter.com/safe_app) or GitHub (http://github.com/safeapp/safe) to be notified when it happens.

(If you can't wait, you can always edit the source and produce your own build. Those system changes aren't necessary for Safe to function.)

Hi! Author of Safe here.

This is explained here: http://www.getsafe.org/about#howissafedifferentfromtruecrypt. Here is a quick summary:

1. You can use your existing EncFS encrypted data on Mac/Windows.

2. 1:1 File encryption is much faster on network storage you don't control, like NFS, SMB, Drobo, Space Monkey, Dropbox, Google Drive. Most of their drivers/protocols are file-based. TrueCrypt is block-based, i.e. all data is stored as a single potentially giant file. This affects the performance of algorithms focused on caching and deduplication.

3. I designed Safe to be much easier than TrueCrypt to use. Try making a new encrypted disk with TrueCrypt, then do the same process with Safe and you'll see what I mean. TrueCrypt is very intimidating to set up for people who don't intimately understand how cryptography works. Safe just chooses the most secure defaults.

As for your second concern about caching. I can guarantee that no data is cached to the local disk unencrypted when using Safe. Don't just take my word for it, verify yourself. See http://www.getsafe.org/about#system_changes_more_info

Safe is not a competitor to TrueCrypt. They are different tools for different situations. I use both depending on the nature of the data I'm keeping private. Safe is another tool in this ecosystem and the main goal is to help more people take control of how their data is stored and transmitted and hopefully bootstrap mainstream digital privacy awareness.

It can be. We want to move away from IV-based encryption primitives to tweak-based primitives for each individual file. This is just so more people understand how it works, especially since now XTS is a recommended standard. Right now we use a custom solution, which made sense in 2004 but now that XTS exists we can switch over.

You're correct. If you want plausible deniability, you should definitely use TrueCrypt. Safe was not meant for this.

Safe is mainly for making it difficult for casual snoopers to view your data. For instance, if your computer or external hard drive gets stolen.

Safe and TrueCrypt form an ecosystem of encryption tools. Safe is a bit more user-friendly but it's for casual use. For special circumstances TrueCrypt is a better tool. Compare butter knife to swiss army knife.

thanks for the feedback! i don't disagree with you.

i designed the splash page to be very sparse because i wanted to minimize distractions and make it simple to just get started using the app. i figure most people don't like reading as much as they like looking at pictures.

for those who like to read (and have a discerning eye) the "about" link has all the gory details you're looking for.

it was a trade-off and there definitely could be a better result but this is what developed in the end. the splash page may change as more feedback rolls in.

Safe might be a better fit if you need to access your data from Windows as well as Mac OS X. Also Safe is open source so you know what it's actually doing.

If you don't care about cross-platform or open-source then encrypted sparse bundles are great!

we're actually in the process of updating encfs to use XTS. also, that particular audit was done quickly and some of the analyses weren't done considering the threat-model that encfs is designed for (so it makes encfs look worse than it really is).

it's free software, more info can be found here: http://www.getsafe.org/about

i also wrote one, check it out http://rianhunter.github.io/threes-solver

Ah, I don't think ref counting is generally considered GC. It's more like RAII and used in C++ elsewhere via shared_ptr.

I'm a bit skeptical of the results of that paper without the seeing the source code and in what contexts they are performing the comparison. One can always find situations where one scheme is faster than the other but I'm not totally sure if micro benchmarks are representative of the real world. In long-lived servers, ref-counting can be preferable because it avoids random pauses. Maybe it's a latency vs throughput performance dichotomy. But yeah, thanks for posting that.

Weak ptr/reference.

Also I would say that it's very uncommon to do/need something like this so it shouldn't be cited as an reason for cycles to be generally handled.

My point is that, what GCs do at runtime (discover garbage) can be done statically in all of these cases. The sole reasons GCs do that work at runtime is because of cycles.

Cycles aren't common at all and the answer shouldn't be "let's create a huge complex GC that handles all cases, then down the road we'll optimize for the common case" the answer should be "let's do the sane reasonable thing that handles the common case and push the problem of cycle-management to the programmer"

Yes I think you would use a ref counted resource in that case. For your tangled mess of database connections I can't imagine ref counting not being adequate in those scenarios as well.

1. Can you give an example of some of these systems?

2. Designing your code in such a way that requires it to invoke the GC seems counter-productive. If your algorithm is producing a bunch garbage that is statically known, why not just release that memory explicitly? Invoking the GC is way more expensive than necessary here.

3. New/delete will always be used in performance critical code but I think the point is that in general it's not a good practice.

Classic RAII in C++ is a limited form of ref-counting (only one ref).

I have to disagree with your second statement, ref-counting is extremely fast. If you consider it a GC then it's the fastest GC. It's also deterministic and does not pause.

Examples of a situation where you don't want a resource associated with a variable/storage location?

Global variables exist and can be used to hold resources. If you have a resource that's not associated with any single function context you can move it into the global variable.

Naked New/delete have been taboo since auto_ptr hit the scene.

This is totally on point. Ref-counting / RAII is the only sane way to do resource management. It's super lightweight and easy to understand.

The vast majority of resources are short-lived and don't create cycles. Our garbage collections "systems" should be designed for this case.

Cycles are a special case required for few data structures. They are not the norm and we shouldn't ship a huge heaping mess of a garbage collection system and make everything else slower to account for this rarely used special case.

Anyway people programming today shouldn't be thinking in terms of pointers and references. We should be thinking in terms of VALUES. Finite values have no cycles! The Haskell and C++ community have already embraced this, everyone else is still catching up.

Yet another reason why Java is a horrible language holding people back and the JVM is basically a hamster wheel keeping itself busy.