QEMU should move from C to Rust - <AUTHOR> http://blog.vmsplice.net/2020/08/why-qemu-should-move-from-c-to-rust.html <comment><USER2> Is it worth the effort to write a "X should switch to Rust" post that ends with "but I personally don't have the appetite to do it"?

Migrations of this size aren't not done because they're technically bad ideas, but exactly because they're expensive, messy, and few people have the appetite or funding to do it. Proposing a solution to that is more interesting that just saying "switch to Rust!".

Also, I don't know much Rust (still on my PL bucket list), but usually when I dive into a more detailed analysis of such a migration the most relevant parts are around how much unsafe code will be required and whether or not integrating with the existing codebase has to be fine-grained or can be done in larger modules like Rust recommends.

I would naively guess that a VM would have lots of unsafe code. Are there any investigations on whether the recent vulnerabilities would have migrated to safe or unsafe code?

edit: mea culpa. I didn't read the second to last-paragraph closely enough, which at least proposes a modularized way of doing this with device emulation being written in Rust in separate modules.

<comment><USER3>
      Is it worth the effort to write a "X should switch to Rust" post that ends with "but I personally don't have the appetite to do it"?

he made it to the front page of HN, so I guess the answer is "Yes"

<comment><USER4> Entertainment value is separate from practical value and feasibility.

<comment><USER5> Maybe the practical value is traffic?

</comment></comment></comment></comment><comment><USER6> The blog post proposes an _incremental_ migration.

From the next to last section "How can we change programming language?":

> _The reason I am writing this post is because device emulation, the main > security attack surface for VMMs, can be done in a separate program. That > program can be written in any language and this is where Rust comes in. For > vhost devices it is possible to write Rust device backends today and I hope > this will become the default approach to writing new devices._

For all those criticizing the knee-jerk impulse to rewrite, you're arguing against the wrong post!

<comment><USER7> It seems that the controversies in the comments come from the inexact title. It should have been ,,Why QEMU should incrementally move from C to Rust'', or something similar, that reflects the content of the article better.

<comment><USER8> Or maybe people should read the post instead of reading too much into the title?

<comment><USER9> but the title is important, it claims that the article will give sufficient reasons for QEMU to stop using C in some natural sense and move to Rust.

if this is not the reflective of the content or it is a tongue in check exaggeration following a c common template (similarly to the "considered harmful" titles) it is reasonable to criticize the title

(it is less reasonable to criticize the article under the assumed content)

</comment></comment></comment></comment><comment><USER10> Whats with the treand of why X should move to Rust these days?

Not saying Rust is flavour of the week but this happens with a new language every couple of years. Everything doesn't need to be rewritten. You switch languages, you might fix some existing bugs but you open lots of other ones.

<comment><USER11> This blog post discusses specifically what would be gained by moving to Rust, and why Rust. The word "re-write" does not appear. It is actually suggesting that new work be started in Rust. It even suggests that re-writing what's there is a bad idea!

<comment><USER6> You'd never know that the blog post describes such an incremental strategy from all the top-level posts on this page rushing to argue against the straw man of a complete rewrite. :\

<comment><USER12> Like almost even those that claimed to read the article did so haphazardly.

</comment></comment></comment></comment><comment><USER13> All bullet points under "Why Rust?" actually suggest that it would be much better to gradually rewrite all critical parts of the project in ATS, thanks to it being a frontend to GCC. Firstly, it's a much more powerful frontend than the current Rust. Secondly, I'd expect it to be less disruptive than a complete compiler switch.

<comment><USER14> From a cursory search, it looks like ATS is implemented as a "compile to C code" language. This kind of implementation is actually quite concerning, because it means you're punting through a language which is notorious for its heavy reliance on undefined behavior, and there is no way to opt out of undefined behavior in some cases.

Also, from what I can tell of its mailing list, ATS is a pretty dead project: [https://sourceforge.net/p/ats-lang/mailman/ats-lang- users/](https://sourceforge.net/p/ats-lang/mailman/ats-lang-users/) shows only announcements post-2015.

<comment><USER15> A language that compiles to C does not inherit all of C's problems, and doesn't "punt" on it for undefined behavior. I mean, after all, Rust compiles to Assembly, which is even unsafer than C, but Rust is still considered safe.

A compiler has greater ability to enforce invariants that make the resulting code safe. The issues with C result from faulty humans; running through a program gives an opportunity for those issues never to occur to begin with.

<comment><USER16> How is assembly less safe than C? C is full of undefined behavior which might be interpreted differently by different compilers, whereas (maybe with the exception of some unusual circumstances) the behavior of assembly language for major instruction sets is 100% documented.

<comment><USER17> I see that you have not coded in assembly language.

<comment><USER16> I haven't; I've only read it a bit. I could be wrong about a relative lack of UB compared to C - do you have examples?

<comment><USER17> When you code in assembly language, you discover how incompletely documented every chip is. Any detail of behavior not documented might change in a later chip, and is thus UB.

Makers of compatible chips are obliged to keep a collection of systems with all the extant chip designs to run experiments against, and to maintain their own documentation of discovered but unspecified commonalities that users' code may have come to depend on.

Each released chip, and each stepping of each release, has its own unique set of bugs-- deviations from documentation, from observed behavior of previous chips, and of chips yet to be released.

Writers of assembly code need a compendium of behaviors, documented or not, that cannot be relied on for the set of release platforms. Many such bugs depend on an ill-characterized history of processor states, making them, often, (more or less) reliably reproducible only with a particular program that was discovered to evoke each. Often the behavior noted is seen only once in a million runs.

An example on Intel is the popcount instruction that runs very slowly, sometimes, in chips released up to a few years ago. The instruction appeared along with ...SSE3?, and had the bug until it was noticed and fixed in a subsequent chip. The bug is the reason Gcc uses the same register for source and destination when it emits this instruction. Intel's ISA manual does not mention this behavior.

<comment><USER16> Thank you for the details. I guess I had an overly rose-tinted view of the quality of Intel documentation.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER18> What's the status of the Rust project after recent Mozilla layoffs? How much does Rust depend on Mozilla?

<comment><USER19> The message in Mozilla laying off the Servo team, for me, isn't so much that Rust is dying as it's about a team making their programming language a priority can't at the same time focus on their actual task ie developing a browser. What a missed opportunity to specify web layout in a constraint formalism (and I hate to always be right).

<comment><USER20> Evidently they can. The Servo parts are the only things that are fast in Firefox.

<comment><USER19> The Servo parts in FF is a CSS "engine" right? My expectation is that at some point it gets rewritten to C++ like the rest (layout, RT, API, fonts, parsing, JS, UI) because having a minor part written in Rust (with an extra build system, test framework, API bindings to maintain) is only a hindrance to building a team able to pickup work of other members. Especially when that other language has failed to deliver, and not even demonstrated the feasibility to develop a competitive JS VM, nor fast-enough binding to eg FreeType.

<comment><USER11> Stylo, the component you're talking about, was written in Rust after multiple attempts to write it in C++, which all failed. So, I would hope that that isn't what happens. It sounds like a waste of time.

> having a minor part written in Rust

"every single CSS bit touches this code" isn't a minor part, and it's not the only part. [https://4e6.github.io/firefox-lang- stats/](https://4e6.github.io/firefox-lang-stats/) is a sorta flawed metric but it reports nearly 10% being Rust.

</comment></comment></comment></comment></comment><comment><USER21> The following justifications are given:

-Use-after-free, double-free, memory leaks, and other lifetime bugs are prevented at compile-time by the borrow checker where the compiler checks ownership of data.

-Buffer overflows and other memory corruptions are prevented by compile-time and runtime bounds-checking.

-Pointer deference bugs are prevented by the absense of NULL pointers and strict ownership rules.

-Uninitialized memory is prevented because all variables and fields must be initialized.

These are all only true in _safe_ rust. A hypervisor has to do low level things like translate memory addresses, move stack pointers around, etc. Nearly all the buggy C code, if implemented in Rust, would be wrapped in 'unsafe' and would be just as buggy.

I recommend everyone interested in Rust to take a look at how the standard library Vec is implemented[1]. The code is littered with `unsafe` - There is just no way to avoid it and do something useful at the same time.

This isn't really a shortcoming of the language, but of modern computers. It is fundamentally an unsafe operation to read or write memory, to communicate with a disk, etc. Every computer program is fundamentally unsafe. Rust does a fantastic job of making this explicit and controlling it as much as possible, but the idea that Rust code is bug free for free is just wrong.

[1] [https://doc.rust- lang.org/src/alloc/vec.rs.html#300-303](https://doc.rust- lang.org/src/alloc/vec.rs.html#300-303)

<comment><USER22> I think the Vec example makes the opposite argument from the one you put forth. Vec uses unsafe internally in order to have the desiref API and performance characteristics, but it exposes a safe API. If there are bugs in the unsafe blocks that can cause UB all over the place, but it also makes it easier to audit.

> There is just no way to avoid it and do something useful at the same time.

I don't think that's true. Your code might have to rely on code down the abstraction layers that uses unsafe, as interacting with the hardware is inhere you unsafe, but that doesn't mean that any code you want to write won't be able to leverage the safe abstractions. The argument you're making sounds to me, and please correct me if I'm misunderstanding, that trying to create safe abstractions is sheer folly so we might as well not do so.

I've been writing Rust code for years now and I've never had to write unsafe code myself other than when interacting with C code and when doing so I've found issues with the way the API the C libraries were exposing having fundamental issues.

<comment><USER21> > Your code might have to rely on code down the abstraction layers that uses > unsafe, as interacting with the hardware is inhere you unsafe, but that > doesn't mean that any code you want to write won't be able to leverage the > safe abstractions.

This is the point I was trying to make by linking to the vec code. Any useful Rust program _will_ run unsafe code. That code might just be hidden in a library. Ultimately, you are trusting that the code author did not write any bugs - in this regard you are not much safer than using the C++ stl.

> The argument you're making sounds to me, and please correct me if I'm > misunderstanding, that trying to create safe abstractions is sheer folly so > we might as well not do so.

On the contrary! I think what Rust is doing is a big step forward. But it is very important to keep in mind the limitations of a system.

The authors attitude of "This is written in Rust, so it must be free of memory bugs!" is dangerous. The key benefit of Rust is to isolate and explicate the dangerous parts of your program (because there are dangerous parts!!). This should make you _more_ vigilant of bugs, but the "Eh, the borrow checker will debug for me" attitude can often lead to programmers being less critical of their own code.

Of course, none of this really applies if you are doing higher level stuff. But QEMU would definitely have to write their own 'unsafe' code.

<comment><USER23> Here's the thing these arguments always miss: writing C/C++ is like writing your _entire_ Rust program using unsafe. Sure, unsafe Rust code will always exist and can cause memory safety bugs. It's a lot easier to verify a few unsafe blocks in a Rust program than it is to keep all of your C++ program's invariants in your head and manually make sure you don't violate them.

</comment></comment></comment></comment><comment><USER24> For the Rustaceans in the thread, I've been wondering - What's the current state of affairs of Rust for non-x86_64 targets? I know it's in flux, and that documentation isn't always up to date.

What architectures can rustc target? Can it cross-compile? Can I cross-compile rustc itself, or do a Canadian-cross (where I cross-compile a rustc that wants to target a different architecture than the one that hosts the compiler)?

Speaking as somebody who does a ton of system programming for embedded Linux systems, this is basically C/C++'s biggest advantage over Rust - the extreme flexibility of the available toolchains.

<comment><USER11> Every Rust compiler is a cross compiler. There can be some issues on some combinations of cross compiling, that is like, you can't run link.exe on a Mac so cross compiling from a Mac to Windows only works if you don't use the msvc target, stuff like that. I personally work on embedded ARM stuff on Windows, so I'm cross compiling from x86_64-pc-windows-gnu to thumbv7em-none-eabihf all the time. No need for a special build or setup, just a "rustup target add thumbv7em-none-eabihf && cargo build --target=thumbv7em-none-eabihf" and that's it.

ARM themselves are committing to getting the various ARM targets to Tier 1 support. AVR support landed in nightly recently. Other targets have less support, but that's mostly due to lack of people power, not a lack of interest from us.

<comment><USER25> I know you know this, but just to clarify for other people, "Every Rust compiler is a cross compiler" is only true for pure Rust code. You'll still need a C cross-compiler toolchain to link your final binary, and any Rust libraries that are bindings to external libraries and expect those libraries' C headers / link objects to be pre-installed [1] will need said external libraries' C headers / link objects to be available for the target architecture.

So the availability of a C cross-compiler toolchain can affect your ability to compile Rust code for foreign architectures. As a concrete example, at $dayjob we need to compile our code for CentOS 7 armv7 and aarch64, but CentOS 7 does not have a usable cross-compiler toolchain in its repos [2], so we have to run the build process in a centos7 arm container running under qemu.

[1]: Eg openssl-sys is bindings to openssl and expects you to have installed the equivalent of your distro's openssl-devel package. In cross-compilation scenarios, this means installing the openssl-devel package for the foreign arch. For debian you'd do something like `dpkg --add-architecture armhf; apt install libssl-dev:armhf`

[2]: What it has is only for cross-compiling the kernel, so there's no cross glibc available to link the final binary to.

<comment><USER11> Ah yes, thank you. I should make sure to clarify that better in the future :)

</comment></comment></comment></comment><comment><USER26> Discussions on reddit:

[https://www.reddit.com/r/linux/comments/i56gzj/why_qemu_shou...](https://www.reddit.com/r/linux/comments/i56gzj/why_qemu_should_move_from_c_to_rust/)

[https://www.reddit.com/r/rust/comments/i4rpyc/why_qemu_shoul...](https://www.reddit.com/r/rust/comments/i4rpyc/why_qemu_should_move_from_c_to_rust/)

</comment><comment><USER27> I think the real benchmark is a large "C" project writen fully in Rust and to compare the issues on the long term, not sure it's safe to asume that Rust would fix all the security issues with all the unsafe code that would be?

What a 1.5M LoC Rust low level kind of project looks like?

<comment><USER28> Honestly, I think anyone who has written Rust, even low level Rust, intuitively understands that it wouldn't even be close. It's not really worth measuring - like measuring C vs Java, no one really needs to do it because it's so obvious that C will have many times more memory safety issues.

<comment><USER29> Bad science.

Rust code does have unsafe at times, so it can still have memory safety issues.

It may not matter that your program is memory safe if it was written by people who don't understand the problem domain and doesn't work correctly. E.g. for qemu, it's perfectly possible to be absurdly vulnerable -- giving target code control of the host -- without any memory safety bug at all.

<comment><USER28> In fact it's not science at all. I didn't claim it was science, I claimed it was so obvious and intuitive that science was unnecessary.

> without any memory safety bug at all.

Most QEMU escapes I have seen are memory safety issues in emulated devices.

</comment></comment></comment></comment><comment><USER30> Telling QEMU to move from C to Rust is bad idea imo. QEMU Devs are probably well versed in Source code of QEMU and C. Telling them to learn new language and rewrite QEMU would be a joke. It would give lot of new problems than solving the current issues.

Probably, RUST Devs who are well versed in emulation can start another project in RUST which has same goals of QEMU but telling existing software to rewrite is a big JOKE to be laughed at.

This has nothing to do with RUST but "Rewrite in New language" syndrome.

<comment><USER31> Hello.

I'm not a QEMU developer. I used to be pretty active in Apache HTTPD, APR and related projects. They are large user space code bases written in C - with, overall, a relatively OK security record.

I think Apache should be on a path to be rewritten in Rust. Here's why...

Every new line of C has a chance of a remotely exploitable vulnerability. No matter the precautions taken, no matter the developer who writes it. HTTPD has a long history, precautions like memory pools from APR and uses "safe" string functions, but it still has issues.

Apache's core C code doesn't change much, so yes, many remotely exploitable memory corruption bugs have been fixed over 20+ years, but new code, new code still has bugs. And they can be bad.

Look at the recent known vulnerabilities in httpd: [https://httpd.apache.org/security/vulnerabilities_24.html](https://httpd.apache.org/security/vulnerabilities_24.html)

Vulns that are largely fixed by Rust are concentrated areas like HTTP/2 support and the Proxy - areas under active development. Vulns around logical errors are still there, and more widespread, but largely have a lower impact.

So, I emphasize with QEMU developers. I'm in the same boat. I have a full time job, and that job is not to work on Apache HTTPD. It would take a full time job to incrementally adopt Rust. The outcome would be in 24+ months, no more remote memory corruption bugs. Is it worth it to fund this? Can you put a price tag on this for the dozens of "core infrastructure" software projects written in C?

<comment><USER32> No offense, but rewriting httpd in rust won't make it any better. There's no excuse for thread-per-connection in 2020.

<comment><USER33> Good thing Apache has mpm_event [https://httpd.apache.org/docs/2.4/mod/event.html](https://httpd.apache.org/docs/2.4/mod/event.html)

<comment><USER31> in a hilarious turn of events (to me at least), I was one of the primary developers of the event mpm.

<comment><USER32> Alright, so please correct me if I'm wrong then.

I cannot perform a non-blocking operation (querying redis for example) from within my module's handler function because as soon as my handler returns httpd sends a response. i.e. there's no 'NOT_DONE_YET' return code?

And while I'm anonymously ranting on the internet...

\- being able to control response headers completely would be nice. In our case, the Date and Server headers cost money to send and our clients don't care about them. It's not for security reasons, it's about traffic egress costs on the cloud

\- having a way to hook a worker thread's init would be useful

\- there must be an easier way to get a request body other than the bucket brigade stuff?

<comment><USER31> 1) You return SUSPENDED instead of OK from your handler. See also [http://svn.apache.org/viewvc?view=revision&revision=1593860](http://svn.apache.org/viewvc?view=revision&revision=1593860)

2) You can control all response filters at the byte level with an Output Filter.

3) Hooks already exist for this: [https://ci.apache.org/projects/httpd/trunk/doxygen/group__ho...](https://ci.apache.org/projects/httpd/trunk/doxygen/group__hooks.html)

4) No. Bucket Brigades is the API for this. It's an efficient linked-list of future-data. It's a good API IMO, just needs some understanding, and because its in C, its full of macros (there are more alternatives to making it cleaner if we weren't using C)

<comment><USER32> 1) potential gamechanger. Thanks for pointing it out

2) yes, but there's a config directive for the Server header too that could just allow people to turn it off

3) for child_init, but nothing obvious that maps to a worker_thread_init

Are there plans for httpd to avail of io_uring if the kernel provides it?

I will admit, I've struggled with configuring httpd for years. A single threaded redis server can handle more connections than a full httpd install.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER34> Rust is the new silver bullet...

<comment><USER35> And an easy way to tell is there is no section in the post on what the downsides are to picking Rust.

<comment><USER11> There may not be an explicit section, but the post certainly talks about how it would be a mistake to rewrite the code, and gives reasons.

<comment><USER35> IMHO that is just a soft touch, it's just saying there might be some areas where Rust isn't a good fit. What the article doesn't address is what the intrinsic costs of switching are, as opposed to what the article does address is that there are probably places where it doesn't have a good fit.

In short the article doesn't address what new costs Rust might bring that are intrinsic to using Rust (as opposed to costs that are inherent in making a change to _any_ new language).

</comment></comment></comment></comment><comment><USER36> I find it odd that for the solution proposed for solving problems with C that are explicitly solved by C++ is not to move the code-base to C++ but to an incompatible language, like Rust. Nothing against Rust, but sounds more like someone who wants to work on Rust.

<comment><USER37> Wrong thread, fyi.

<comment><USER38> We've moved it. Comment was originally posted to [https://news.ycombinator.com/item?id=24133146](https://news.ycombinator.com/item?id=24133146).

I always wonder about the specifics of how these happen!

<comment><USER39> > I always wonder about the specifics of how these happen!

Once I read someone saying they where blind and had forgotten the context or navigated back or something without noticing. I think there were some interesting follow up questions as well.

<comment><USER38> Exactly—I bet the reasons are often surprising.

</comment></comment></comment></comment></comment><comment><USER40> What's the current state of compilation times of Rust? How many times slower than C does it compile? Any links to statistics? I know it's hard to compare, but I am interested in developing a gut feeling of what to expect.

<comment><USER11> > What's the current state of compilation times of Rust?

Still slower than we'd like. Some folks are putting in a heroic amount of effort to improve this significantly, but it's going to be a long time before it really happens. Smaller stuff is helping all the time, but has less dramatic impact.

> How many times slower than C does it compile?

Really impossible to say, because it varies along so many different factors. C will almost always compile faster though, it's true.

> Any links to statistics? I know it's hard to compare, but I am interested in > developing a gut feeling of what to expect.

The closest we have is a few bits of basically anecdotal evidence; we have projects demonstrating that rustc got about 3x faster since 1.0, and we have had at least one (in my mind) pretty reasonable C++/Rust comparison that showed them as being roughly equal. But it's just really hard to get good data here.

You should expect something roughly C++-like.

</comment></comment><comment><USER34> Well, that would be a nice benchmark ;)

I would be very curious to compare speed, size and compilation time of the two versions.

</comment><comment><USER41> _" Talk is cheap, show me the code" \- Linus Torvalds_

The author applies the same standard reasons for moving from C to Rust for the QEMU project which are valid reasons. However, I would take the author more seriously if they have done a proof of concept first and then later made their case for this.

Otherwise, it is another "rewrite it in rust" post which is yet to materialise into a real project.

<comment><USER42> > Otherwise, it is another "rewrite it in rust" post which is yet to > materialise into a real project.

I'm not sure you can reasonably said that "it is another 'rewrite it in rust' post..." if it's coming from a QEMU maintainer.

Besides, before starting a large engineering project like this, it's worthwhile to write a high-level proposal _then_ write code. Saves you a lot of wasted effort!

</comment></comment><comment> GuB-42 Haha, good luck porting QEMU to Rust.

For those who don't know, the original author of QEMU is Fabrice Bellard. This guy has several winning entries in the IOCCC. One of them is a C compiler, that once de-obfuscated, forms the basis of TinyCC.

QEMU C code makes heavy use of macros and gcc extensions. It really pushes C to the limit, it even broke my syntax analysis tools.

Now, if the Rust community wants to write a new emulator in Rust, why not, but starting with QEMU may not be the easiest way.

</comment><comment><USER43> > Eliminating C programming bugs does not necessarily require switching > programming languages. Other approaches to reducing bug rates in software > include:

> \- Static checkers that scan source code for bugs.

Does QEMU use a sound static analyzer (like IKOS [1])?

[1] [https://github.com/NASA-SW-VnV/ikos](https://github.com/NASA-SW-VnV/ikos)

<comment><USER44> No. Coverity scans QEMU regularly but it is not sound.

The challenge with static analyzers is that false positives make people not want to deal with the analyzer reports.

I will check out IKOS, thanks!

<comment><USER43> One of the cool things about that particular analyzer is that you can choose how accurate it is in exchange for how long it takes.

</comment></comment></comment><comment><USER45> Could the effort be bootstrapped by using a C to Rust translator, like [https://github.com/immunant/c2rust](https://github.com/immunant/c2rust), preserving the existing semantics prior to updating the code to remove the "unsafe" tags.

</comment><comment><USER46> C11 has safer version of those bad boys(strcpy_s etc) and gcc/clang is more powerful about static checking and runtime checking these days, make existing c code better/safer might be more realistic than rewriting code size of qemu in rust.

</comment><comment><USER47> Seems a bit silly to rewrite working software in a relatively new language. I like Rust, but it has its own trade-offs. The big one for QEMU being that QEMU developers and users tend to know C already and not be familiar with Rust.

<comment><USER28> Rewriting the device drivers would be huge. Having been tasked with "Make a QEMU environment safe against advanced attackers" memory safety issues in device drivers were _by far_ the most concerning issue, and the hardest to mitigate.

<comment><USER47> Rust definitely has that advantage. The downside is most device driver programmers know C, not Rust. So if you want other people to work on your driver you either have to expect them to want to work on it badly enough to learn Rust or to already know Rust.

</comment></comment></comment><comment><USER48> I've heard from different sources that QEMU's code is one of the best C code base available in terms of quality and clarity (and smart tricks!). Tough call.

</comment><comment><USER49> Too bad the C beer-goggles have lasted so long that other great languages didn't take hold. Don't know about that theorem proving stuff in ATS, but with some application of hygiene like "if denom <> 0 then" and compile time prechecks on structures that like every Wirthian language ever has offered, maybe the computational arts would be further along right now.

Nah, too much trouble. I'd rather not check if denom = 0. Back to writing autonomous car code!

</comment><comment><USER50> How big is a device emulation mentioned in the article? How many of them are necessary?

</comment><comment><USER51> If people are really serious about writing virtualization in Rust, they should just contribute to firecracker: [https://github.com/firecracker- microvm/firecracker](https://github.com/firecracker-microvm/firecracker)

<comment><USER52> Firecracker is a really nice project, but the scope really isn't the same as QEMU, and they are not mutually exclusive projects

</comment></comment><comment><USER53> maybe they can recruit the remacs team

<comment><USER54> Maybe _remacs_ can recruit the remacs team, frankly

<comment><USER53> is remacs looking for itself these days ?

</comment></comment></comment><comment><USER55> Start porting some device emulators, otherwise this is just a waste of time.

</comment><comment><USER56> The best way for QEMU (or anything) to keep improving is to have it written using the languages and tools that the actual maintainers are the most comfortable with.

People suggesting rewrites in X/Y/Z are usually not people maintaining these projects. This is evangelism, but it doesn't help with anything.

<comment><USER44> Article author here. Thanks for mentioning it, I have updated the article to clarify that I'm a QEMU maintainer. The article was intended for the QEMU community but now that it's being discussed more widely it helps to be explicit about my involvement in QEMU.

</comment></comment><comment><USER57> Be the change you wish to see in the world. Otherwise, posts like that are mostly people asking others to use same toys as they like.

<comment><USER44> Article author here. I am already working on Rust code for QEMU :).

The goal of the article is to start a wider discussion in the QEMU community and encourage others to do the same. I will post more about the things I have been working on when they are ready.

<comment><USER57> Happy to hear that, and I support your effort. If you can show people that Rust actually works and is better, it will help advance QEMU. It'll be much more productive discussion, when you have actual data and code to back you up.

</comment></comment></comment><comment><USER58> Yes. Let's make things less accessible to everyone. People with less resources have had it too good for the last decade or so, and our double digit core, double digit gigabyte memory computers no longer make us feel special, so let's move software to something even bigger and more bloated than anything we've ever seen before.</comment>


Flood Maps: Interactive map of rising sea levels - <AUTHOR> http://flood.firetree.net/ <comment><USER2> Interesting, if you look at the Florida with +60m enabled then you get this weird diamond. This is a bug or does Florida have some weird landmass I've never known about before?

<comment><AUTHOR> Looks like a rendering bug to me; there is a similar diamond in South Carolina.</comment></comment>


Ask HN: What was the hardest part about being a first time manager? - <AUTHOR>

What was the most surprising thing to you about becoming a manager? What was the hardest thing you had to learn? What helped? <comment><USER6> There is very little available advice on starting out in management.

Start by valuing everyone who reports to you. Give them all respect - and that can be hard when someone is not performing OR you misunderstand their position and thus get the idea they are not making the right contribution.

Look for talent and encourage it. This is very hard. Too often you judge people by the job they are doing now rather than try and gauge how they might tackle the next job (this will happen to you as well).

Catch your people "doing things right" and praise them for it - way better than catching them doing the wrong thing and telling them off.

Stand by all of your team - no matter how big the foul up - take the blame up front. Sort out what went wrong afterwards.

Never be too afraid to say sorry - I messed up - it is not easy but the worst managers bluff their way through when all of their team know then blew it!

Good luck - and learn from your best people.

<comment><USER7> while i agree with much of what bdfh42 said, there's one glaring mistake above:

> There is very little available advice on starting out in management.

i disagree. there's a shitload: go to any bookstore, real or virtual, and go to the business section. TONS of stuff on being a manager. the trouble is finding USEFUL, WORTHWHILE stuff. most of it - the vast majority of it - <USER2> drivel and derivative. find the gems.

myself, when i first became a manager i studied hard, i read tons of material and haven't stopped because it's a constant learning process. i studied three major subjects: managing people, managing projects, and leadership. they're all core skills to being an effective manager. a fourth one - <USER3> yourself - is often overlooked, but don't skimp on it. self discipline and management will help you and the people who report to you immeasurably.

management is not about command but about responsibility: to the organization, to your boss, and to your staff. bdfh42 gets much of that right in his nutshell above. communication is a core concept, learn it and continually work on it. learn to delegate, learn to train, learn to plan, learn to trust - <USER5> earn trust. learn to lead.

a lot of my leadership lessons have come from military books lately, and one lesson i learned a long time ago from that field has stayed with me: complaints go up. never let your team hear you complain. you set the tone, you keep a positive attitude about things and people even if you're grinding your teeth when you do. your example reverberates with your team, never forget that. it's part of the responsibility.

harvard business review has a press and they have tons of books on management essentials worth studying. myself, i recommend their "essentials" books. they cherry pick articles from their magazine (which is also worth subscribing to) and put them together in a book. well worth it, and you can often find them cheap and used on amazon. here's one example:

[http://hbr.org/product/harvard-managementor-management- essen...](http://hbr.org/product/harvard-managementor-management-essentials- package/an/7103BN-BUN-ENG)

i read a ton of peter drucker - and recommend his books wholeheartedly - <USER5> here's his books i suggest:

\- The Effective Executive: The Definitive Guide to Getting the Right Things Done - just because you're not (yet) an executive doesn't mean you can't learn how to manage like one. this book taught me tons, and i recommend it to nearly any and all new managers i can.

\- Managing Oneself - learn how to manage yourself, your time, your projects and everything else will come naturally.

\- Management: Tasks, Responsibilities, Practices - this is a tome but is the premier book of his, well worth the time you spend on it.

as for common pitfalls on being a first time manager they include failure to delegate, being too "hands on", and not setting expectations right. a lot of this is covered in "The Leadership Pipeline" by Ram Charan, Stephen Drotter and James Noel. while a book about big orgs building succession pipelines, for a manager it's really valuable because it teaches you what's expected of you by your superiors, and common pitfalls - and how to avoid them.

one of my favorite early books on leadership was "It's Your Ship" by D. Michael Abrashoff, a former navy captain. tons of great stuff in there that dovetails with the above well.

these are just some of the things i've read and shared with people over the years, and they've been extremely valuable. i spent my own money to read these and hours every night on my own and it has helped me become effective and grow. none of us are born knowing how to manage people, so study it like you would anything else new.

finally: ask for training. if your org has promoted you, ask for management training for yourself and the others around you. a couple of two day seminars will do wonders for your organization. the price is pretty reasonable, too.

> Stand by all of your team

too true: be a shit umbrella, not a shit funnel. when things happen, be the shield between your part of the org and the problem. follow up - with the individual(s), the team, and yourself - to see what went wrong and what you can learn. but never forget you should be a shit umbrella and shield your org from crap above.

<comment><USER8> I agree with all that you said except the lesson from the military about never complaining down - depending on how how you define "complain". For example, if you've been "given" a very agressive development schedule, my experience has been that it's fair - even appreciated by your team - that you state, succinctly and matter-of-factly, that you believe that the schedule is more agressive than is optimal and that you either 1) argued unsuccessfully against it or 2) argued with partial sucess against the original, more agressive schedule, so there is a partial win. And then comes the positivity. . ."we need to work together to figure out how to meet this schedule with minimal risk". This is what I did as a manager, when applicable, and what I appreciated as a team member listening to my manager.

And I worked for the military for a while - as a civilian - and I observed various leadership styles among the officers and various levels of receptiveness among those they were leading. They knew that they needed to salute and carry on with the job, whether they agreed with the plan or not, but they still appreciated the _acknowledgement_ that the plan they were about to carry out was not perfect but was the best that it could be, given the constraints.

<comment><USER7> good point. that's not grousing, like i was originally thinking, but is a valid point. it expresses sympathies with your team, and in doing that you can make sure you set them up to succeed: clearing obstacles, gathering materials, resetting expectations, etc. "welcome to the suck."

</comment></comment></comment></comment><comment><USER9> The hardest thing was listening. I'm still working on active listening. That meant shutting up and actually synthesizing what your direct reports are trying to tell you. I used to always complete other people's sentences and it took an honest friend to tell me that was annoying.

The best resource that's helped me for management was a class called Business Management for Electrical Engineer and Computer Scientists ([http://www.stanford.edu/class/ee353/](http://www.stanford.edu/class/ee353/)) Check it out here if you have the time. All the important business topics like strategy, accounting, pricing, marketing, managing - it's all there condensed in a quarter.

Here's what I found surprising: Management allows me to multiply my technical skills with the team's help. You'll find that you can accomplish far more with a solid team than just by yourself.

Similar to the other posters, go the extra mile for your direct reports by genuinely caring for them. In a professional manner, ALWAYS set them up to win. Never throw them a project knowing that it's a sinking ship. They'll know.

For books, another one that's helped is "How to Win Friends and Influence People." A fun one to read is "The Witch Doctors" by exposing management "gurus". You'll realize management theories change every day and everyone's scrambling to defend or find the next theory that encompasses the essence of management. I find it very similar to programming language worship. That's not entirely a bad thing since that means the field will keep evolving. That also means what works for me might not work exactly for you.</comment>


China's children buckling under the pressure of their parents' deferred dreams  - <AUTHOR> http://www.psychologytoday.com/articles/index.php?term=pto-20080623-000004&print=1 <comment><USER2> Almost exactly the same as in India. That's why people here in US think that everyone in India is smart _and_ hardworking. Well, the truth is that they encounter only those people who have survived all this. There are countless millions who suffer.

<comment><USER3> Very true. When i see the kids in India today and the parental pressure they have, it is scary. They have schools, tution's(so that they don't forget what they study in Schools)then study time after they come home, this all happens in a day. They take memory pills, so that they don't forget what they read. I don't know, what will happen to this kids but I am sure they won't be creative enough to create anything.

</comment></comment><comment><USER4> "These kids have the same dreams as all middle-class kids: to go to college, to get white-collar jobs, to own their own home, to have Nikes and name brands,"

Wanting white-collar jobs and their own homes, I understand, but name brands? Well, that's the problem. The whole purpose of name brands are to create artificial scarcity. if the goal is to have a good life, that is definitely achievable, but if the goal is to be better than everyone else, only some will meet that goal.

</comment><comment><USER5> _"They've worked hard for it, and it's what their parents have focused their lives on. But the problem is that the country can't provide the lifestyle they feel they deserve. Only a few will get it."_

Ah, such economic ignorance! What is this "country" that "can't provide" if it isn't the people themselves who are to be provided for. People both take and create jobs.

 _the national college entrance exam—China's magnified version of the SAT_

The SAT is (or was) a covert IQ test. If the Chinese test is the same, then these kids are wasting the vast portion of their energies.

 _At one top Beijing kindergarten, students must know pi to 100 digits by age 3._

Why would you send your kids to a "top" school in order to destroy them intellectually? Who in the world thinks that such insane tasks could be valuable?

<comment><USER6> I don't know why this is being upmodded. These kids are NOT wasting their energy. In China you can't drop out and move to the valley and start a company with your computer savvy.

The system in China is simple: To even have a CHANCE of successful, professional, middle class (by Chinese standards) life, you MUST get a university degree. To get a university degree, you MUST score in the top Nth percentile of the college entrance exam.

Students get sent to top schools because top schools produce results on this exam, as absurd as the actual exam may be. You have to consider that despite the fact that for the country as a whole these things may not be ideal, for any individual student you would be stupid not to put everything you can towards that test.

And if you don't get a degree, you end up as a laborer of some sort. And in China these people work their asses off and are poorer than a homeless jobless American. It's a different world.

The country has so many people there is far more competition for jobs and resources, and because of the government the current rules are the only way up through the system. Obviously there is a problem with the system, but it should be abundantly clear that it would not be in your best interests to rebel against it before getting through it--you would only hurt yourself turning down the best schools and the entrance exam, and you would not be in any position to effect any changes.

<comment><USER7> Ironically, I have heard quite a lot of people say that many Chinese tertiary courses are not actually very difficult.

<comment><USER8> Sounds kind of like Harvard here... you have to kill yourself getting there, but once you're in grade inflation is your friend.

</comment></comment></comment></comment><comment><USER9> You know how only children have a reputation for being a little... ah... selfish? (I am one).

Now, imagine a nation of only children.

</comment><comment><USER10> Some stats are ridiculous! A monthly salary of RMB45 ?That might be true 30 years ago.

<comment><USER7> I think they might be talking about 20 - 30 years ago. Wang (the child) is 29.</comment></comment>


Stupid NES Tricks – Screen Wrap Detection - <AUTHOR> http://www.dustmop.io/blog/2015/05/20/stupid-nes-tricks-screen-wrap-detection/

<comment><USER2> > However, the carry flag produces false positives because nearly any negative > delta will cause a carry to happen.

Correct me if I'm wrong, but I think that when going to the right, the carry flag indicates that it wrapped, while when going to the left, the carry flag indicates that it didn't wrap. So the flag is still usable when going to the left, just interpret it the opposite way. Do you think that's correct?

<comment><USER3> That would work, but that means branching to handle the left/right difference. The author mentioned that he wants to avoid branching to maximize performance.

Avoiding branching is still relevant on modern machines when optimizing hotspots, and even moreso as cpu instruction pipelines get longer.</comment></comment>


How to generate content without users? - <AUTHOR>

The chicken or the egg? Which came first? We need users to generate content, but users want content to sign up! Recommendations? Igobubble is a new iphone app that allows virtual digital content to evolve as users interact with it. <comment><USER2> broad question. what have you considered?

you can use datasets for initial content and see how it evolves with your new users.

<comment><AUTHOR> If you can take a minute to watch our video i would highly appreciate it, maybe at that point, advice can be a bit more relative. Our iphone app lets users leave photos, videos, messages and more inside what we term living bubbles at any location. When they leave, their bubbles remain behind for others to discover. Bubbles can be cloned, modified, stored, carried, or moved elsewhere. These bubbles grow, divide, multiply and spread with interaction and shrivel and shrink with negligence. Basically, popular bubbles prosper and spread and unpopular bubbles pop and die. So these bubbles basically evolve. Now we started creating content and we have a drop tool that enables us to leave content at different locations on a map using the google maps api. But is that a good idea? Should we just create a bubble or two in everyone's bag that they find once they download the app? I hope that's a bit more specific to get some help on the topic. We just applied to TC startup battlefield in San Francisco and we're hoping that the event will give us somewhat of a boost!

</comment></comment><comment><USER3> I've participated in a few discussions about this. I also once posted one and in it I had gathered a few links to previous discussions on the topic. I am only posting it here because, since it is my own submission, I am aware it exists and I can find it readily. Hopefully, it is a place to start.

<http://news.ycombinator.com/item?id=2126209>

A search of the site will turn up other discussions on this topic. I mention that because this type question often does not generate good new discussion so a look back is sometimes your best hope of getting some insight. You might also search on my user name and "chicken and egg", since that might lead you to a few posts with lots of links gathered where I commented but was not the submitter.

<comment><AUTHOR> Thanks for the references.</comment></comment>


Hawking backs interstellar travel project - <AUTHOR> http://www.bbc.com/news/science-environment-36025706 <comment><USER2> Comments moved to [https://news.ycombinator.com/item?id=11480840](https://news.ycombinator.com/item?id=11480840).</comment>


Warner Music Pays $14M to End 'Happy Birthday' Copyright Lawsuit - <AUTHOR> http://www.hollywoodreporter.com/thr-esq/warner-music-pays-14-million-863120 <comment><USER2> As far as I'm concerned, I'd have been happier if the case were fully litigated with a precedent set, and damages against Warner Music being as disproportionate as what the music industry wants against random file sharers.

$14M? They got off too easy.

<comment><USER3> So did the settlement not open Happy Birthday for everyone?

<comment><USER4> Unclear. What is clear is that Warner/Chappell don't have a valid copyright claim, but due to the history of the song/lyrics/tune other claimants could come forward and claim to own the copyright.

Happy Birthday will DEFINITELY be in the public domain in 2030, because claims of ownership seem to end in 1935, however as the Warner/Chappell claim has been debunked it might be public domain as early as 2022.

Keep in mind that "unknown owner" and "public domain" aren't the same thing. At the moment Happy Birthday isn't old enough to be public domain, there just may not be a known or established owner, so it could be "de facto public domain."

<comment><USER5> > Happy Birthday will DEFINITELY be in the public domain in 2030

Unless the law changes between now and then.

<comment><USER4> In concede that. And I'd love to say "that could never happen" but if they want to keep Mickey Mouse out of the public domain then they need to extend the 1928 copyright yet again...

</comment></comment></comment></comment></comment><comment><USER6> > Last week, in announcing its quarterly earnings, Warner Music Group partly > blamed an operating loss on expenses related to the "Happy Birthday" > settlement.

Good for them. Well deserved!

Warner Music has clearly been wearing The Wrong Trousers.

[https://www.youtube.com/watch?v=jOw7AwG-2Gs](https://www.youtube.com/watch?v=jOw7AwG-2Gs)

Happy Birthday dear Gromit!

<comment><USER7> How much do you need to spend on a single law suit to be in an "operational loss" when you're a 3 bln dollar yearly revenue company?

<comment><USER8> Included in that loss may be all future revenues that could be attributed to the 'Happy Birthday' song though, in the form of a write-off of the value of the asset.

<comment><USER7> Well if the wrote it off they actually might end up making more money on it because depending on the original asset value it can reduce their taxable income to nothing.

</comment></comment></comment></comment><comment><USER9> >> Warners was expecting to have "Happy Birthday" under copyright until 2030.

At which time Disney would have extended copyright another 30 years.

</comment><comment><USER10> The best discussion of the "Happy Birthday" copyright brouhaha is by the wonderful Vi Hart:

[https://www.youtube.com/watch?v=AVo0Q8G8tS8](https://www.youtube.com/watch?v=AVo0Q8G8tS8)

Not only is her biting commentary on the insanity in copyright law succinct and direct, her _musical_ analysis of the differences between the original "Good Morning To All" and the modern "Happy Birthday" is _very surprising_.

Did you know the song modulates to 4/4 time for one measure? Even though the song is always notated as never leaving 3/4?

<comment><USER11> I think she's got it slightly wrong. It's not that one of the 3/4 bars gets an extra beat - it's the previous bar that loses a beat.

[https://www.youtube.com/watch?v=AVo0Q8G8tS8&feature=youtu.be...](https://www.youtube.com/watch?v=AVo0Q8G8tS8&feature=youtu.be&t=9m22s)

Listen to the bit after she says '4' \- it sounds syncopated in her counting. (Actually - 'syncopated' might not be the correct word - what I mean is that the '1' ceases to sound like the start of the phrase)

<comment><USER12> It's a fermata on the second beat of that measure. Holding a note doesn't mean you're changing the time signature.

[https://en.wikipedia.org/wiki/Fermata](https://en.wikipedia.org/wiki/Fermata)

<comment><USER13> It's definitely a fermata.

Arguing otherwise is like saying the national anthem changes to 15/4 when singers hold "land of the freeeeeeeeeeeeee."

<comment><USER14> It's definitely a fermata.

The fermata overrides the time signature temporarily. There is no need for a time change.

</comment></comment></comment></comment></comment><comment><USER15> Income: $50m Cost: $14m settlement, $6m lawyers (guess) Result: $30m profit

Nice business model.

<comment><USER16> You've forgotten bribes... uh, I mean, "campaign contributions", to politicians* who enable this asinine system of practically perpetual copyright.

*(google "senator disney")

</comment></comment><comment><USER17> Excellent, now we'll finally be able to legally sing a song that everybody has already been singing for almost 100 years. It's a good thing we got this in under the wire before the next Mickey Mouse extension.

Copyright is stupid.

</comment><comment><USER18> Yay. Looking forward to the new versions of the song. At least it's where it belongs now.

</comment><comment><USER19> Interesting to know that Apple is sometimes behind stuff like this [https://medium.com/startup-study-group/steve-jobs-made- warne...](https://medium.com/startup-study-group/steve-jobs-made-warner-music- sue-my-startup-9a81c5a21d68#.jr89smslj)</comment>


Show HN: Twoogle – If Twitter and Google Had a Child - <AUTHOR> https://twoogle.info/?q=g20 <comment><USER3> Interestingly, the original incarnation of tweets in Google (circa 2010) was fully real-time, with new tweets on a query coming in and getting displayed on the SRP as soon as they were posted. My friend spent a significant portion of his tenure doing a custom scrollbar so that if you scrolled up, it would pause the scrolling while you read the tweets, and then if you returned to the final scroll position, you'd see what you missed.

Ultimately the feature was discontinued over contractual differences, and then when they brought it back a couple years ago (after I left Google), it looks like they went with a fully static page. I think that real-time webpages has been one feature that every techie thinks is really cool and just around the corner, but the general public just finds annoying.

<comment><USER4> > I think that real-time webpages has been one feature that every techie > thinks is really cool and just around the corner, but the general public > just finds annoying.

Ain't that the truth. Granted, I still think it - like many features - <USER2> great in concept, but very difficult to get "right". It's really hard to beat static pages for simplicity. Nothing is changing on the user, the scroll bar isn't jumping around in size, they know exactly where they left off, etc etc.

</comment></comment><comment><USER5> Can work great for sales. I wish there were filters by country.</comment>


Norwegian backup provider promises NSA-free data storage using Norwegian laws  - <AUTHOR> http://www.jottacloud.com/its-your-stuff-guaranteed/ <comment><USER2> As a Norwegian, let me just say:

Yeah, right.

1\. The Norwegian security services have a long history of violating Norwegian law (and when, for example, extensive illegal politically motivated surveillance of mostly left wing politicians was uncovered in the 90's they then had the gall to place an MP and member of the committee investigating them under surveillance while he was working on the report about their illegal surveillance), and have always been extremely cosy with the US.

2\. Most bandwidth to Norway goes via Sweden. Sweden is not a safe country to pass data through if you want to avoid surveillance. See the FRA law: [http://en.wikipedia.org/wiki/FRA_law](http://en.wikipedia.org/wiki/FRA_law) ; unless they guarantee that they get their bandwidth via alternative means, this is a risk. Sure, you can encrypt the data, but if you trust that this is sufficient, then hosting your backups in the US should not a problem either. If you think Sweden's neutrality means a shit in this case, consider that Sweden has admitted to having been complicit with renditions of political asylum seekers to the CIA in direct violation of Swedish laws, so clearly they do not worry about cooperating with US intelligence agencies. To hand your data over to the NSA would not even require them to break any laws, and they've already demonstrated they don't have the moral backbone to stand up to far worse requests.

3\. Norway is subject to the EU data retention regulations, and otherwise likes to bend over backwards to comply with EU directives despite not being an EU member (we're a member of the EEA, which means we get all the directives, but don't have a say - how anyone thought that was a better alternative is beyond me). In fact, Norway is "best in class" when it comes to implement EU directives - ahead of most EU countries... This doesn't impact this to a great extent, except it means all your communications with this company will be subject to retention laws, and if you consider it important enough to avoid the reach of the NSA for your hopefully encrypted backup data, this is worth keeping in mind too.

In other words: If you encrypt your communications and backup files well enough that you believe it is safe from the NSA in Norway, they'll likely be just as safe from the NSA in the US.

<comment><USER3> Is there a jurisdiction on the planet where data is safe from domestic wiretapping _[1]_ (i.e. international espionage not withstanding)?

Serious question.

 _1\. Clarification: I mean warrantless wiretapping._

<comment><USER4> No. Job #1 for a national government is national security, and governments inherently have the power to intrude upon privately operated companies.

I think that in the long run, the U.S. is still a good place to keep data.

U.S. citizens have an instinctual distrust of government that Europeans often mock, but in this case I think is an advantage.

In addition the U.S. has some of the strongest protections for freedom of expression in the world, which means that everyone can learn and argue openly about intel programs and other sub-topic of freedom vs. security.

<comment><USER5> > Job #1 for a national government is national security, and governments > inherently have the power to intrude upon privately operated companies.

I would say that job #1 of a government is establishing and enforcing domestic property rights (to allow an economy to function); and job #2 is building public-good infrastructure like roads.

"National security" is job #1 of an _organism interested in its own survival_ \--but there's no reason a government needs to be such a thing; the only reason I can see for it is the precedent set by monarchies, where each current king wants the government to persist in its current form so that they themselves will stay in control of it. A government _could_ run a country perfectly capably while leaving itself undefended from being "eaten" by a foreign government (or populist coup) at any time.

<comment><USER6> National Security is intrinsically about enforcing domestic property rights. It covers issues like terrorism but also foreign hostilities. Don't be a doof and pretend that National Security doesn't at least _start_ with the interests of the citizens in mind. Seems like it gets awfully lost in the woods, but you can't pretend that if people just had the right ideals things would be fine.

</comment></comment></comment></comment></comment><comment><USER7> If you want to have data storage that's secure from the NSA then you are going to need to do client side encryption. Moving your data to a company/country that promises not to access it isn't going to cut it.

<comment><USER8> I have to agree. The user needs control over their encryption.

Taking advantage of Norway's laws is fine, until the day that those laws go sour on you.

<comment><USER9> Don't you need a combination of encryption AND no law forcing you to reveal the key?

<comment><USER10> The law that might force you to reveal the key depends on where _you_ are, not where your hoster is.

<comment><USER11> Good luck, I have terabytes of random data. I can always provide you OTP key, and create what ever content I want you to see. (Malleable encryption)

<comment><USER2> Stay away from the UK - here a judge can throw you in jail for failure to provide keys, even if there's no evidence you still have the keys, and said judge would pretty much be guaranteed to believe that you did not hand over the correct keys if the result is garbage.

<comment><USER12> If you claim the encryption was done using a One Time Pad, you can pick any result you want, generate the corresponding key, and hand that over.

[https://en.wikipedia.org/wiki/One- time_pad](https://en.wikipedia.org/wiki/One-time_pad)

<comment><USER10> Unfortunately, the OTP is always as large as the encrypted data. So strictly speaking, this is not really "encrypted data + password" but more of a "split data into two random-looking parts". In particular, this is nothing you can keep in your head or print on paper.

You'd have to keep it on a separate storage medium. And if you have to hand out the done medium, what's preventing them to get your second medium? And if you are able to keep that second medium secret and safe, why don't you store the whole unencrypted data on it in the first place?

Either way: OTPs are really cool, but I don't think they have any relevance here.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER13> "In Norway, privacy stands firm like the mighty mountains of Jotunheimen.".

Let's not flatter ourselves _too_ much: [http://no.wikipedia.org/wiki/Datalagringsdirektivet](http://no.wikipedia.org/wiki/Datalagringsdirektivet) (in Norwegian, [http://translate.google.com/translate?sl=auto&tl=en&js=n&pre...](http://translate.google.com/translate?sl=auto&tl=en&js=n&prev=_t&hl=no&ie=UTF-8&u=http%3A%2F%2Fno.wikipedia.org%2Fwiki%2FDatalagringsdirektivet&act=url)), or the less detailed [http://en.wikipedia.org/wiki/Data_Retention_Directive](http://en.wikipedia.org/wiki/Data_Retention_Directive)

<comment><USER14> I don't think DLD/DRD is conflicting with the statements given in the post, as DLD only concerns itself with metadata (and yes, that can be harmful), and the article talks about the actual data. Both are important, but different, topics.

<comment><USER15> Well, after reading Snowden's comments about what is available (everything) - it would seem that DLD goes hand in hand with storing all traffic for a limited time -- you would need help searching that to actually recover something.

<comment><USER14> > DLD goes hand in hand with storing all traffic for a limited time

Nope? From the linked translated wikipedia page:

> Data that reveals the content of the communication must not be stored

<comment><USER15> I meant - if you already, illegally store everything - that everything is problematic to search, and to store permanently. If you also, legally, through DLD store metadata, then that makes your illegally collected data more useful.

</comment></comment></comment></comment></comment><comment><USER16> This is nice. But I think that the long term solution needs to be based on something that does not depend on the ability of your host to protect your data. The US is strong enough to pressure (almost?) any country to jump through hoops for them (we have seen leaks about their pressure on Sweden [1] or Spain) so just being out of their jurisdiction is not enough.

1\. [http://falkvinge.net/2013/01/06/banana-republic-justice- behi...](http://falkvinge.net/2013/01/06/banana-republic-justice-behind-the- scenes-of-the-pirate-bay-trial/)

<comment><USER17> I agree 100%. Your country or company isn't going to make a difference when the people maintaining it are threatened or bribed by a force that can and does leverage power outside their jurisdiction. Honestly, the problem has to be addressed at the source, not with bandaids applied by the hopeful or naive.

</comment></comment><comment><USER18> From the article "U.S. law enforcement could use the USA PATRIOT Act on a U.S.-based organisation, like Microsoft, Google, Dropbox or Amazon, for example, to force its local subsidiary companies across the world into handing over user data to U.S. authorities."

Exactly how? By my understanding a company in EU operates under EU law and US parent company is only stock owner. Stock owner can not by my understanding force the company to do anything if the company does not want. Lets assume that US company does not want to force daughter company, how can NSA to make them?

EDIT: I'm fully aware that by harassment or blackmail anything can be done, no question here. What I meant to inquiry, out of curiosity, is, is there a legal way to _force_. I know that parent company can control and fire board etc, but can they be forced to do so. Or more broadly, can some US agency take full control of US company and run it like they please. Can f.e. NSA if they really-really wan't to rise McDonalds burgerflippers salary by twofold? Does Patriot Act or something allow that?

<comment><USER19> Your understanding is false. A sole stockholder (for example, the parent of an independent subsidiary), always has control, even if not by specific direction.

They can, after all, fire the entire board, and elect a new one that will direct the company to do what they want.

Not to mention in most cases, parent companies do in fact, maintain control over subsidiaries (IE they are not independent subsidiaries), and thus can directly control activities.

<comment><USER20> The way company law is set up in Norway, you cant as a board member do anything else than what is best for the company you are board member in. Doing something different would mean you could be held responsible. They could fire the board, but the next board have the same rules to go by.

<comment><USER19> "What is best" is of course, a matter of opinion. I'm not sure this is as concrete as you seem to think this is, though i'll admit i'm not familiar with the details of norwegian law, what you say is true of most countries in terms of duties.

</comment></comment></comment></comment><comment><USER21> This might become a major trend in the EU if hosting/storage providers play their cards right. Sure the low prices, performance and flexibility of US providers are very tempting but surrendering your data to US intelligence agencies and god knows who else might no longer be a viable option, especially for government agencies and major corporations that might be targets of industrial espionage.

<comment><USER22> It is already a trend, but until last week it was the realm of huge companies, bureaucrats, weapon manufacturers and other security-industry types. Now there's potential for going mainstream.

This said, I wouldn't trust a French provider or an Italian provider with anything too sensitive: their police forces have a history of being incredibly heavy-handed when dealing with data. I remember one occasion in mid-00's when the Italian police investigating G8 riots (or something like that) raided a data centre, took home all disks they could find, cloned them all, then went through them with a fine comb, all because _one mailing list_ hosted on _one_ of those servers _might_ have been tangentially related to whatever they were investigating. I'd be surprised if things were much better in other European countries, to be honest, but I guess Norway is one of the best bets (with UK/Ireland being among the worst, of course).

</comment></comment><comment><USER22> The whole computer security business couldn't have paid billions for the sort of free advertising they got this week...

</comment><comment><USER23> The link should be updated to point to their own English version

[http://www.jottacloud.com/its-your-stuff- guaranteed/](http://www.jottacloud.com/its-your-stuff-guaranteed/)

</comment><comment><USER14> I thought that the NSA surveillance was at least partially illegal. Laws (Norwegian or US) don't stop TLAs doing what they want.

Also in a related note I find the following fairly unconvincing:

"We will not hand over user data to authorities unless a warrant issued by the Norwegian court of law is presented"

Warrants are in my view more about providing a paper trail than actually preventing abuse.

Ultimately I think the only protection against surveillance is well-employed cryptography. Especially if the law offers some protection for encryption keys and/or passwords.

</comment><comment><USER24> I'm moving away from Dropbox today. Thanks for this jensen2k.

<comment><USER25> If you crypt, Dropbox is fine. People need to use encryption. Every popular computer language has encryption routines, scroll through the source code until you find something accessible, twiddle something to personalize it while keeping it functional, perhaps convince yourself it will remain secure, etc, of course be cautious about that. Or simply, there's double encryption, fold it again. Know big 100 meg, gigabyte file size encryption, becomes vulnerable. Wikipedia is the best general crypto introduction I've see.

<comment><USER22> The main selling point of Dropbox is cross-platform support for umpteen platforms, so you'd need to find an encryption tool that will work on all platforms; say bye to iOS...

<comment><USER26> Check out boxcryptor, works in the OS's that you probably care about.

</comment></comment></comment></comment><comment><USER27> "Vi vil ikke overlevere brukerdata til myndighetene om vi ikke mottar en kjennelse fra norsk rettsvesen"

meaning

"We will not hand over user data to the government if we do not receive a ruling from the Norwegian judicial system"

which is pretty much the same thing as the Patriot Act in the US...

But as far as PRISM goes - that's a whole other matter!

<comment><USER14> Well for better or worse you can not really escape that. Best to my knowledge most (western) countries have the concept court orders/warrants or equivalents.

</comment></comment><comment><USER28> If you are in EU, Norway is pretty much transparent from a legislative pov. For example: [http://www.autistici.org/ai/crackdown-2010/](http://www.autistici.org/ai/crackdown-2010/)

</comment><comment><USER29> United States Government:

-We are serious about creating jobs and supporting great American companies. -Makes the most lucrative young companies in the US unusable in the name of spying on their own citizens.

What in the actual fuck?

</comment><comment><USER30> Encrypt all you like. It boils down to this: Will a government make you prove a negative, and if you don't, will it lock you up?

If you have encrypted files, there must have been or still be a key to decrypt it. You will be asked for the key. You will either given them the key, say no, or say you don't have it. The first two are no good, so all you have is the denial that you have the key. If government cant find the key, you will be asked to hand it over.

And that's the crux.

What then does the government do? All it can then do is make it an offence to withhold a key. How do they prove you have the key, if they themselves can't find it? You then have to prove the impossible, that you do not have the key, a negative. Which, even if you are telling the complete god's truth, you can never, ever, prove.

So, having an encrypted file, that you cannot or will not decrypt on demand is or will become a criminal offence. All encryption does, in the eyes of government, act as evidence of guilt. The suspect has an encrypted file, we can verify its contents, she wont give us the key, there for she has "something to hide", and there for must be guilty.

I can well imagine encrypted files being stored like athletes blood samples, waiting to be tested or decrypted by future methods.

We can not win unless we accept so risk and stop expecting our governments to do _everything_ to stop the bad people. If a bomb goes off in Whatevercity, we must not be angry if it happened because the NSA were NOT collecting mass data, or something similar. We must make it clear to government that we are prepared to trade the risk of being blown up for our privacy and freedom, and that if that freedom contributed to the attack, we _MUST_ accept that, and not suddenly switch and blame government. And the NSA, and the likes, must be allowed to say, "look we could have acted, here is the evidence, but we had to respect freedom and privacy", and not be lambasted for it. We have to reply, "OK, fair enough, we understand and accept that." Equally, of course, we need to know they did everything else legally and morally possible.

Question is, are we as a people able to do that? Or do we expect zero risk lives?

And all that is assuming there is zero risk from the powers government wants. Such laws and thinking creates a whole new avenue of risk.

Which is why I for one am quite prepared to say to government, cool it down, back off, set some limits, respect those limits, and if you fail because of that, I both accept it and forgive you, because I want to be free.

BTW, one of the few countries I have been to is Norway. Beautiful, stunning, country and fantastic people. If I wanted to or had to leave the UK, it would be one of the first places I would consider. I'd love Norway to be the savior of privacy and freedom, but I sadly cant see it.

<comment><USER31> > You will either given them the key, say no, or say you don't have it.

There's a 4th option: give them a key that decrypts innocuous material.

[http://www.truecrypt.org/hiddenvolume](http://www.truecrypt.org/hiddenvolume)

</comment></comment><comment><USER32> The US has a great deal of influence in the west, especially NATO members. They will readily comply to avoid complications. No country wants to find itself on the US "terrorist" list.

</comment><comment><USER33> The memory stick under my pillow is pretty NSA proof too. Well unless someone in combat gear rocks up at my house...then all bets are off.

</comment><comment><USER34> Spideroak...

</comment><comment><USER35> What is the best country that you know of to store data safely in?

<comment><USER36> In the developed world? Your own. Hopefully then the data doesn't come in contact with any other jurisdiction with different laws and there are much fewer hops between you and the place data is stored, thus limiting the chances that it is intercepted along the way. However, there is the issue that if you store data with a local company, they may be forced to comply to the local law enforcement while a foreign company may or may not comply.

</comment></comment><comment><USER37> erm, isn't this assbackwards?

intelligence agencies, aka spies, _exist_ to spy. that's their entire purpose. now there are some laws to protect their own citizens, at least in the US.

once it's a foreign entity, it's fair game. zero fucks about legality given - see any info ever about clandestine services. so if you store your data in a non-US entity, you're _more_ likely to be monitored.

do you think STUXNET was LEGAL?

the NSA, CIA, MI6, BND, KGB, Mossad all ignore the laws of the countries they are acting in. or what do you think a spy is?

</comment><comment><USER38> NSA.no!</comment>


Updates to Amazon EKS Version Lifecycle - <AUTHOR> https://aws.amazon.com/blogs/compute/updates-to-amazon-eks-version-lifecycle/ <comment><USER2> A cadence like this is nice for the k8s developers but goes to show that to run on Kubernetes one needs either (or both!):

\- a dedicated engineering budget to keep up with changes and prepare your applications for migration between clusters

\- modern infrastructure provisioning and end-end-testing system: something that can build a new cluster and deploy your applications to it without affecting your production users or your developers.

<comment><USER3> Yes, I was thinking that the benefits of k8s must be huge to invest in this upgrade cycle. That or the upgrade pains must be small.

AWS is very good about avoiding premature deprecation (you can still use simpleDB as far as I know) so for them to have this policy means that k8s deprecation is very prevalent and that customers must be prepared for the move. Because I am sure they spoke to customers.</comment></comment>


Job losses could total 47M, unemployment 32%, St. Louis Fed president says - <AUTHOR> https://www.cnbc.com/2020/03/30/coronavirus-job-losses-could-total-47-million-unemployment-rate-of-32percent-fed-says.html <comment><USER2> Bullard has always been extremely bearish, and is consistently a dissenter in FOMC meetings FYI. While his number is very high, I would take it with a grain of salt. It will be high, but not that high

</comment><comment><USER3> "During a CNBC interview last week, Bullard said the jobless number "will be unparalleled, but don't get discouraged. This is a special quarter, and once the virus goes away and if we play our cards right and keep everything intact, then everyone will go back to work and everything will be fine."

Nothing is going back to business-as-usual after this event.

1\. Companies that successfully transition to work form home will shed tens of millions of commercial real estate square footage.

2\. The online shopping/home delivery will accelerate the collapse of the retail shopping environment. The U.S. has too much already, see [https://www.statista.com/statistics/1058852/retail-space- per...](https://www.statista.com/statistics/1058852/retail-space-per-capita- selected-countries-worldwide/)

3\. This will accelerate online learning, especially in higher-ed. We are already planning our summer courses to be fully taught online as of this point in time.

4\. Tying healthcare to employment in the U.S. will likely become unthinkable as a public health hazard.

EDIT: spelling

<comment><USER4> This pandemic has an amazing ability to make everyone more confident in their personal preferences and pre-conceived notions.

Is it safe to assume that before this pandemic, you:

1\. Preferred WFH to being in an office. You wished more jobs would accept remote employees like you.

2\. Preferred online shopping wherever possible. When visiting retail stores, you wished a tech company would disrupt that industry so you wouldn't have to visit a store.

3\. Prefer to learn on your own, at your own pace

4\. Assumed that anyone who disagreed with your political leanings was just misinformed or morally bankrupt.

What's fascinating is that my social media feeds are full of people who are convinced that this pandemic is proving their pre-conceived beliefs to be more correct than ever. It's making it more difficult for people to see differing viewpoints, or understand why someone could have differing personal preferences.

The dust hasn't even settled yet, but my friends are either declaring WFH to be the way of the future or wholly untenable. I have numerous friends with children at home who are more eager than ever to return to their offices and go back to normal. My manager friends are all fretting the productivity drops as people struggle to get work done amid a 24/7 news cycle of impending doom. Yet the WFH champions are convinced this will prove WFH to be superior.

Personally, I think the long-lasting changes from this pandemic are far harder to predict than people are suggesting.

<comment><USER3> Let's see how accurate YOUR predications are:

1\. I teach in higher-ed. In a classroom. Working from home is the last thing on my mind as it would be detrimental to the teacher-student relationship.

2\. I enjoy shopping. I browse bookstores, record shops, try on clothes at the mall, enjoy selecting my own produce and wine at the grocers.

3\. I prefer learning in seminars and I use the socratic method with students. I do not let them use technology in the classroom unless they have a demonstrated need.

4\. Not sure how you inferred this from my statement. It is reasonable to assume that persons in the U.S. who are unemployed or have limited access to healthcare will make less use of it, thus contributing to conditions that allow pandemics to spread. That is not a political statement.

Thanks for your input.

</comment></comment></comment><comment><USER5> For comparison, a quick Google shows the unemployment rate in the US during the Great Depression was around 25% and during the 2008 recession was around 10%.

If this situation lasts too long, we'll all be saying hello to Great Depression v2.0.

<comment><USER6> > For comparison, a quick Google shows the unemployment rate in the US during > the Great Depression was around 25% and during the 2008 recession was around > 10%.

> If this situation lasts too long, we'll all be saying hello to Great > Depression v2.0.

The most troubling is that there is no analysis being performed to determine what a proportionate response is, and I tend to think most people do not understand how interconnected the economy actually is.

At this rate, the deaths from draconian government responses will far outweigh the deaths from the Corona virus across all age demographics.

<comment><USER7> > At this rate, the deaths from draconian government responses will far > outweigh the deaths from the Corona virus across all age demographics.

A reminder money is a paper money game and in contrast to the 30s, we easily produce more resources, food and abundance than we need to live with 30% unemployment.

<comment><USER8> But that's exactly why people are scared of the recovery. The phenomenon underpinning the economy isn't money flowing through accounts; it's networks of trade and service provision, and most of those networks are being snipped by the lockdown. We won't starve and we won't lose Netflix, but those networks can't be restored solely by financial stimulus and we can't recover our standard of living without them.

<comment><USER9> There's a simple solution to that. Just remove regulations. Remove lockdowns.

<comment><USER10> You really think the rabble will continue working as the infection rate rises into the double digits.

</comment></comment></comment></comment></comment></comment><comment><USER11> No worries, the Fed just printed 4 Trillion dollars, that they'll hand out to the rich companies.

The stock market will go into super drive. It will double in another 10 years. So load up on stocks as soon as this crisis is over.

And get a house and property if you can. The value of your dollar is going to get cut in half.

The rich oligarchs wins again.

</comment><comment><USER12> My argument is that the national security mechanisms of western nations are not so fragile to be brought to their knees by some people eating bats and snakes.

In WW2 the Japanese threatened to destroy key infrastructure using biological agents. the militaries of the world have had almost a century at the very least to prepare for this contingency. I don't buy how unprepared they are.

I am curious to hear the thoughts of some smart people who hang out here.</comment>


We the People Cell Phone unlocking petition needs 10K sigs - <AUTHOR> http://petitions.whitehouse.gov/petition/make-unlocking-cell-phones-legal/1g9KhZG7

<comment><USER2> One thing I, as a non-american, haven't quite understood: do you have to be an American for your vote to count on this website?

<comment><USER3> Hey, petition starter here. As far as I can tell - no.

<comment><USER4> That's... odd. Truthfully, I have distinctive knee-jerk reactions in both directions about that.

On one hand, US policies often have global ramifications (although I'm cynical enough to think that nothing a petition here will affect will have enough importance to matter in that respect). Also, it's often useful to get the perspective of people _in general_ , wherever they are in the world, in case there's some sort of general consensus (although it would be a consensus of educated internet accessing elites in many parts of the world...)

On the other hand, it's a site for the US government to solicit information from US citizens. People from other countries registering their opinion doesn't really fit all that well with that goal.</comment></comment></comment>


Why you stayed in that unhappy relationship for too long – CNN - <AUTHOR> https://www-m.cnn.com/2018/11/23/health/bad-relationship-unhappy-sex-kerner/index.html <comment><USER2> In the modern era marriage has become cheap and disposable, a product of the sexual revolution. So you are unhappy, get a divorce! There is even a website to help the ladies find a partner before the switch. Completely legal even. Why would anyone even think it not ought to be legal to base a business on adultery?</comment>


Functional programming and the death of the Unix Way - <AUTHOR> http://newcome.wordpress.com/2012/03/06/functional-programming-and-the-death-of-the-unix-way/ <comment><USER2> The gist—as I understand it—is that Unix programs are essentially all equivalent to functions : ([String], TextStream) -> (TextStream, TextStream) which limits how one can tie them together and causes a proliferation of text- processing tools (awk, sed, grep, cut, &c &c) which is not as elegant as functional programming. There are already some Unix command-line tools that work on structured data as mentioned, e.g. jsawk[1] is a tool inspired by awk whose scripting language is JavaScript and which works on JSON.

As an aside, I'd like to see people experiment with these concepts on an OS level while consciously targeting Xen or other virtualization systems. Already, Haskell can run barebones on Xen using HaLVM[2] and the successor to Plan 9, Inferno[3], _was_ a virtual machine that could run either on bare metal or inside another OS. I can imagine an entirely new OS would meet some resistance—like Plan 9 did—but supplying an OS _intended_ to be virtualized would let people experiment freely within their existing OS.

[1]: <https://github.com/micha/jsawk> [2]: <http://halvm.org/wiki/> [3]: <http://code.google.com/p/inferno-os/>

<comment><USER3> Not really sure how you jumped from structured data in Unix to a bare metal OS, but this project came up a few weeks ago, OCaml programs on Xen with no OS:

<http://www.openmirage.org/wiki/papers> (down now, doh)

Seems to have some similarities to halvm.

<comment><USER4> It's back up now; the ML TCP stack was running a pcap dumper for debugging, which didn't cope well with a hackernews link.

Hacking is going pretty well on Mirage. The longer-term plan is to generalise the support libraries to work with other languages (particularly HalVM and GuestVM for Java), but it's far simpler to work with just OCaml for getting the first cut out. The Xen Cloud toolstack (also written in OCaml) is currently being adapted to support low-latency microkernel establishment, which will remove much of the hassle of coordinating multiple Mirage 'processes'.

Another interesting performance-related aspect has been the heavy IPC workloads that result from using many VM-VM interconnects. Some early benchmarks in <http://anil.recoil.org/papers/2012-resolve-fable.pdf> .

</comment></comment></comment><comment><USER5> Often times I'll want to grab just one part of a command's output to use for the input of another command. Sometimes I can use grep to do this, and sometimes grep isn't quite flexible enough and sed is required. The regular expression required to get sed to do the right thing is often complex on its own, and of course the flags need to be set appropriately. If the data format is in columns, sometimes cut can be simpler.

Master Foo nodded and replied: "When you are hungry, eat; when you are thirsty, drink; when you are tired, sleep."

Upon hearing this, the novice was enlightened.

\-- <http://catb.org/~esr/writings/unix-koans/shell-tools.html>

<comment><USER6> Don't koans generally _cast off_ preexisting notions? It seems the philosophy espoused by that story is "don't think too much about the design of your tools".

<comment><USER7> I read it as "there are many ways you could solve a problem; rather than obsess over which is The One True Way in All Situations, choose whichever is the simplest path to scratching your itch".

</comment></comment></comment><comment><USER8> TermKit[1] was a proposal that tried to fix some of those problems by adding two new channels (separating terminal in/out from stdin/stdout data pipes) and using MIME-types (particularly JSON) to the latter.

It got a lot of flack, and I don't agree with everything the author proposes, but I think that part could definitively be improved.

The problem, of course, is backward compatibility: even if you can reimplement and/or wrap the core utils, what about the thousands CLI programs in each distro's repository? You'll end up with an hybrid beast that doesn't really do anything well.

[1]: <http://acko.net/blog/on-termkit/>

</comment><comment><USER9> So basically the author is saying:

The UNIX shell pipeline is really just a functional programming language whose functions can only operate on strings. Think how much more powerful, concise, readable, etc. it would be if other data types were supported.

I agree. I don't even think this requires changes at the OS level. Newlisp and Racket's shell attempt might be clunky, and Clojure certainly isn't ready for quick-and-dirty scripts, but it shouldn't be too hard to implement such a language if shell replacement is its main purpose.

<comment><USER10> Unix pipes are about octet streams not strings.

<comment><USER9> In most hackers' idiolect, the term "string" refers to an implementation- dependent representation of characters. An octet stream or byte stream is the abstraction that UNIX files and the standard I/O streams happen to be instances of. So it wouldn't be wrong per se to use "octet stream" here, but I'm treating each phase of the pipeline as a hypothetical function that operates on text. With less indirection, you could certainly view them as functions operating on streams, but I abstracted that away in my mental picture.

</comment></comment></comment><comment><USER11> I had an idea to write Clojure parsers for the standard unix command line tools that translates the output into s-expressions.

I got too frustrated - on the one hand, Clojure's slow start up time meant it was no fun to use in a simple pipe

and on the other hand, even the simplist unix util has surprisingly complicated behavior. Like `wc` - it outputs three columns of numbers, right? Well, unless it knows filenames, which go in a fourth column. Or unless you pass it flags, which can turn any set of the number columns on and off. And then I thought, wait, what happens if you make a file which has leading whitespace in the name - it turns out it only outputs a single space in front of the filenames, so any whitespace after that is part of the name.

Which lead me to the conclusion: unix tools aren't actually simple - they are actually really complicated, but you can construct a happy-path of simplicity for most use cases

and functional languages are still monolithic when it comes to interacting with the outside world. Maybe someone will make a service I can run in the background that will run my command-line clojure scripts in a pre-warmed JVM, but that's not a piece of technology that _I_ want to try to write.

<comment><USER12> Not all functional languages run on the JVM or anything similar. In fact, most don't. See: Haskell, *ML, most Lisps and Schemes, ...

<comment><USER11> yeah, it's true. But I still think it's much harder to compose two functional programs running in separate processes than to write one monolithic program composing functional libraries.

Compare to perl, where piping text is so simple that chaining perl scripts with pipes is no harder than writing functions.

</comment></comment></comment><comment><USER12> > I'm not advocating a return to Lisp machines here. We tried that and it > didn't work. Symbolics is dead, and no one even gave a eulogy at that > funeral.

The hell? Lisp machines were awesome. I thought it was well known that they failed partly for political reasons, and partly because Symbolics was absolutely horrendous at business.

The only failing I'm aware of was the lack of multi-user support, which wasn't particularly unusual for era, and even now we don't have anything which can compare to their high points.

</comment><comment><USER13> Dataflow environments like PureData, Max/MSP, Quartz Composer and vvvv are very much like 2D GUI-driven shells that handle various data types. Max/MSP was, at least, explicitly conceived as a sort of UNIX for multi-media. After working with such tools for years, I must say that the tools the professional programmers use seem comparatively quite primitive in many ways (though much more advanced in others). A graphical environment that utilized the same sort of dataflow model, but with a more general intended audience, more extensible architecture and some concepts from functional programming would have the power to really change how programming is done.

</comment><comment><USER14> The Unix Way, but piping python objects instead of text: <http://geophile.com/osh>.

<comment><USER15> It's not the Unix way if it's restricted to one programming language.

</comment></comment><comment> why-el Steve Yegge's The problem of emacs goes over some of issues discussed here, although it focused on text processing.

<https://sites.google.com/site/steveyegge2/the-emacs-problem>

</comment><comment><USER16> It sounds like the OP wants scsh (The Scheme Shell): <http://www.scsh.net>

</comment><comment><USER17> Try Powershell / Monad for Windows. It even solved Haskell's problem of Monad needing a name change :-) <http://en.m.wikipedia.org/wiki/Windows_PowerShell>

</comment><comment><USER18> ... and the evolution can continue along the same lines as Unix. I think I'll write a Haskell function that takes two strings and returns a string. The first string is a program in a new language I'll invent. The second is the input to the program, and the return value is the output of the program.

Maybe I could call it "herl".

      herl :: String -> String -> String

</comment><comment><USER19> This article reminded me of something I read about the Unix model vs the lisp model. I managed to track it down, it's a comp.lang.lisp posting by Erik Naggum.

[http://www.xach.com/naggum/articles/3245983402026014@naggum....](http://email@example.com)

The interesting part is the 3rd paragraph of the answer.

</comment><comment><USER20> I wonder, does this mean we actually want types as metadata on our shell commands? Type of args, type of stdin, type of stdout, or whatever we decide to call them?

All apps would have to speak a single, more complicated language and we would have to do more explicit translation but it might work out better.

<comment><USER21> Aren't Go channels similar to typed pipes?

<comment><USER20> I guess, but they're not exactly cross-language inter-process communication. Maybe you could work something like them into the OS, though.

</comment></comment></comment><comment><USER22> Conal Elliott did something like this with Tangible Functional Programming.

</comment><comment><USER23> True. However, about the issue that triggered this chain of thought, did you consider using the `cut` utility along with `grep` ?

</comment><comment><USER24> Further reading: <http://pinboard.in/t:functional/t:unix/></comment>