parley

In a previous post (a little over a year ago) about the same engine I posted a link to a video with a Q&A with Elon Musk where he was a bit pessimistic about the idea.

I'm not a rocket scientist so I wouldn't know the first thing about it, but if anyone is interested in his (then) opinion it's after 48m55s in the video here: http://www.oxfordmartin.ox.ac.uk/videos/view/211

It may very well go that way, but I think unikernels (like MirageOS (http://http://www.openmirage.org/) are very interesting as well. A paravirtualized unikernel should be able to carry less overhead than regular virtualized OSs and be able to operate completely in ring0/kernelspace.

Pair that with all the hw acceleration for virtualization available these days and you may get some pretty lean and fast virtualization that also more easily support hybrid deployments (Container software needs to be built for specific container host OSs and libs(depending on how much is bundled in each container)).

Also, the security implications of containers vs (para)-virtualization are different, so I think my personal jury's still out on that one too.

But I do agree that these are interesting times, for sure. And containers may win, I just don't think it's a done deal just yet. :)

A really important (I think) point with regards to all the comparisons to Go and other similar languages that pop up in every Rust post:

Many seem to think that only Rust is suitable for kernelspace but are questioning whether Go or Rust is more suitable in userspace. A Go library will work in a Go process (due to the need for (shared) GC in the runtime, among other things), whereas a Rust library that avoids GC (which is idiomatic Rust) will (I think!) be able to expose an interface akin to a C library (similar calling conventions, internal data type layout like C, etc), making it usable from practically any language with C-FFI.

Personally, this is one of the things I look forward to the most. We can create drop-in replacements for C libraries, creating a safer (but just as fast) world one library at a time. And if so desired, all the functionality will be available to anything that can interface with C. Even Go. Your Go libs are stuck in Go's universe. Your Rust libs can be made available to anything that can bind to C.

Go eats the C/C++/Python/Ruby cake from the top, but it just can't go all the way to the bottom. Rust can eat the cake from the very bottom (bare metal/kernelspace and up), but just like Go, the sky's the limit - and for many reasons, like e.g. even better constraints on shared data than Go has, I personally believe it will go even "higher".

My two cents. And as always: More knowledgeable Rust people, if I'm wrong, please correct me.

I'm a meditation novice so take this with a grain of salt, but the only "For Dummies"-book I've ever enjoyed was "Meditation For Dummies".

It's not a heavy read like some meditation tomes can be but it's not very dumbed down either (IMHO), and it recognizes that some people are interested in the spiritual parts, some the philosophical, while some are only interested in the practical. The book has them all to a good extent, but helps you navigate to the parts that are of use to you.

I'm sure YMMV and different books suit different people, but this one worked well for me. I recommend it, but regardless of what resource you use: There is calm to be found, and it can feel great. Good luck!

Edit: Grammar.

Pardon a foreigner. I'd like to understand this.

Are you saying that there's law in California (i.e. something you can violate that the justice system has the authority to punish you over) that is not freely (as in freedom) available to any citizen (for whatever purpose, reading, distributing, etc)?

I don't usually complain about titles (and I know it's the original one from the article), but I came here with the fascinated (though admittedly skeptical) hope that someone had improved radically on botnet DDoS mitigation techniques. It would be better if the title contained words like perhaps "ad" and "fraud".

> A single, open, interoperable standard is coming

Do you have some more info about that, or is it a gut feeling prediction?

Nicely done! I remember getting the original game for Christmas one year as a kid, and it was lots of fun. This brings back memories. Kudos!

I too am very disappointed and agree with the other commenter who said they are big enough that they don't have to worry about closing it. When I realized I wanted an API key they had already stopped handing them out, and now the axe falls again. I don't argue it's not within their right, it's just sad.

I have upwards of 1200 graded movies in another service that I used for a long time and that has a public API. Nowadays, I use trakt.tv a lot (and pay for it, because I really want it to be around, like I pay for Netflix and Spotify) and they also have a public API that I can use to write a tool and migrate/sync my movie grades there. Netflix' recommendation engine could have learned more about me in 5 seconds than it will in 5 years, and any grades I put into Netflix will never leave it.

Yes, I know I'm an edge case. Yes, I know it doesn't make business sense to cater to me. I still need to gripe a bit.

I have a custom app for managing my music too that uses the Spotify C library (wrapped in Go). I love that I was able to do that, and the day Spotify EOLs that library (and doesn't provide an alternative) is probably the day I leave their service.

Enough ranted. Sorry. I just like to take my data with me when I go.

What kind of conflict resolution does the syncing perform? If it is done automatically by iCloud, what does it do when two notes are edited simultaneously on two or more devices?

Since I believe I may have the project managers attention for a brief moment, I might be so bold as to ask a few questions :)

* In the e10s-addon-docs etherpad, it says that you expect a solid browser (ignoring addons) in Q2 and then with complete addon support in Q4. Is this still the plan?

* Will e10s include a task manager for e.g. identifying resource heavy tabs? I couldn't see anything about it in the GDoc backlog spreadsheet.

Thanks for your hard work on this project! I know many who are rooting for its success.

Great work! Personally, I really hope Project Electrolysis will be successful, for both security and performance reasons. https://wiki.mozilla.org/Electrolysis

It may sound ridiculously obvious, but I think it's often a matter of being able to empathise with whoever you need to convince. Most organisations are in it to make money, and different people are different pieces of the puzzle of achieving that. If you can express the upside of the technology shift in terms relevant to, say, business developers or managers, things get easier. Whether you have closures or not doesn't matter, but time to market, time spent on bug fix releases instead of feature releases, etc do. Also, it will probably serve you best to thoroughly and honestly present both pros and cons. There's almost always cons (training, toolchain or workflow changes, building competence, talent availability, unclear longevity of technology being switched to) so if you're not upfront with the cons, people will wonder what they are and not knowing is scary, risking a higher susceptibility to scepticism. Also, if it's possible to use the new tech for a small project and you can show the upside with clear metrics, actions speak louder than words. My two cents.

I must second this. An excellent series with nice twists and dilemmas!

Some friendly typo notifications to improve visitors' first impressions:

* Under [what], "trasaction".

* In a citation below the video, "crytpocurrency". It is of course important to cite correctly, but perhaps it's nicer without the typo.

* Under [why] a repetition, "years years".

Copy is important. :)

Me too. I am quite reluctant to keep any data plaintext in cloud services, but I couldn't live without Workflowy. I asked them about the possibility of self-hosting, but unfortunately it wasn't in the cards at the moment. I'll keep using it anyway, because it goes with my mind like PB goes with J.

I must second WorkFlowy. I've tried lots of different managers, but WF is the only one that worked for me. It's flexible enough to support the simple, no-frills to-do list as well as the larger projects. I like information hierarchies and WFs free-form style and zoom levels are perfect for me. Not being happy with any of the other tools I tried used to make it a pain for me to keep things organized, but WF changed all that. Try it!

Congratulations on what looks like a really nice effort - I'm looking forward to trying it out. Out of curiosity, what are your main reasons for not making it a joint effort with RetroArch? I'm a modularity and reusability freak, but I know often there can be quite compelling reasons for not doing it.

You will probably get different answers from different people.

For me it's interesting partly because I hope to get a language where managed memory is non-idiomatic and largely unnecessary while manual memory management is quite safe, i.e. no GC needed.

This combined with what I've seen so far with regards to other language design choices makes me hope for something that can also approach C/C++ speeds together with broad portability - uc's (where a GC obviously is a no-no) to big iron nixes to OSX/Win to Android/iOS.

Also, skipping things like GC I hope to be able to write drop-in replacements for C-libraries in Rust, with the application using the library being none the wiser.

These are just a few reasons. If I am wrong to harbour any of these hopes, please correct me. Basically, I hope for good performance, portability and productivity. If I stalked the Rust github page any more often, they'd probably block my IP for DOSing...

EDIT: Forgot to mention that I also hope for a large and supportive community - something I think we can already see the beginning of. People in #rust are very friendly and interesting 3rd party libraries are being produced as we speak despite the language and stdlib still being in a bit of flux. Community is so important. Also, Mozilla backing it is a big plus for me.

There it was, thanks! That's commendable of them. While I hope everyone now disregards the specific example in my comment, I'm afraid it doesn't change my personal view of the involved companies and their intentions very much.

I have both the GMail and Chrome apps installed on my iPad, though I mostly prefer Safari. When I open a link in the GMail app, it opens it in Chrome. I can find no way to alter this setting.

One might argue that it's not the same situation, but it's quite clear that no player wants us to step outside their dome, and it's equally sad - however not surprising in any way.

Here's a similar one the Japanese DOD (?) showed off a few years ago, I think, so I suppose the single-rotor (or dual on same axis) flying sphere with flaps has been around for a while: http://www.youtube.com/watch?v=pF0uLnMoQZA

It's also supposed to be able to bump, roll and stuff, but it looks like the OP has improved on the idea quite a bit with the independent suspension/crash cage.

I think there's plenty of room for the larger discussion about how much we actually (ought to) trust a lot of our closed source software that runs free and non-jailed on our computers day in and day out - and recent events haven't affected that viewpoint very much in either direction. However, data synchronization software gets tougher love from everyone these days for apparent reasons.

I read the updated FAQ and saw the note about blocking network I/O for the closed source process. If the closed source process in your client were locked down in such a way that it was only ever invoked from the open source process and had no way of doing any I/O whatsoever (network or otherwise) except with the open source process (where what goes in and comes out can be audited), then I'd agree this sounds quite interesting.

I'll be waiting as well, and sincerely hope you deliver something nice!

> Client code will be open source.

On the link you provided I found the following:

"Parts of the programm relevant for security and networking actions will be open source."

"Parts of the program" might not do it for everyone (me included). Will anyone be able to audit the full source code of the client and compile it themselves, like e.g. tarsnap? Otherwise I fear the usual trust issues arise.

If I missed some information at your linked site which says the entire client will be open source, then please correct me.

A comment on another article the other day (can't remember which or I'd link) noted that no-one will magically know your passcode when you sleep or nap, but it might not be too hard for them to gently put your thumb on your phone. One would do well to remember that involuntarily "surrendering" login information doesn't necessarily require hoses or wrenches...

No worries, I was actually referring to the automagically translated article. :)

Google can't really know which is which, so the article seems to use a mix of both english words in different places, which ends up being a little confusing/inconsistent.

Security is one of my interests and I work with people who have been in the safety industry, so sometimes we have our little linguistic bouts. :)

I will confess to not reading the entire article (neither in Swedish nor "Engswish" ) so I might be mistaken, but if anyone is wondering why the word "security" is used when "safety" probably would be better suited, it is probably because they are commonly described using the same word in Swedish ("säkerhet").

It often gets as Lost in Translation as Bill Murray in a big, strange city. Also, it complicates many discussions between Swedes too because of the ambiguity and the fact that people seldom add qualifications to indicate which is intented.

Edit: Grammar.

Thanks for the paper link, it looks interesting.

Yes, factoring software into different processes and enforcing proper sandboxing and resource restrictions is definitely one aspect of it. Hierarchies of such processess where resource allocation can be delegated makes it even more interesting.

Another aspect is composing any one process of - where possible - shared, audited modules that haven't changed for a good while and that you're able to verify individually before building your binary. It requires proper code signing and delegates the problem to the domains of who to trust (and of course issues like Thompson's famous Trusting Trust) and once again I'm not kidding myself about the difficulties of that either. But that shouldn't stop us from working towards such a goal if we find it desireable.

This of course helps closed source software production, but even more important is for any individual or FOSS organisation to be able to build their own system of (a myriad of) components that can be cryptographically verified to not have changed since some specific audit event, provided that these signatures of single modules and signatures of compositions of modules can be kept by a public and decently trustworthy actor or preferrably actors, like Linux distributions or FSF or whoever. In a world where the loyalties of individuals are easily purchased we need to keep each other honest.

This extends from Joe building his own doubly-linked lists and red-black trees to crypto modules that take side-channel attacks into account to kernels and drivers and everything. Many will argue that layers and abstractions can kill software with complexity. I certainly agree that they can if used poorly (or, quite frankly, if not used with great skill) but they are also one of the only things that can make complex problems manageable, and - as you say - our systems are now hilariously complex.

Every time these issues come up for discussion, my mind always returns to some sort of imagined utopia where our software is much more modular, composable and compartmentalizable (grammar?) than todays "mainstream" platforms.

It could enable several different things, like running systems where most modules have access to much less resources of different kinds, allowing less mischief (microkernels, hierarchical resource mgmt frameworks like GenodeOS, etc).

Greater modularity would also mean that basic or common modules would need less changes, requiring new audits less regularly, thus decreasing that load on the community. Of course many vulnerabilities are the result of unexpected interactions between modules, but then a certain composition of certain modules could be audited and hopefully not require any changes for some time.

Being a software engineer I'm not kidding myself with regards to the huge software engineering problems inherent in achieving that, and of course the open source community already performs a lot of code reuse. Many will argue that an argument for more reuse is an argument against fragmentation and thus an argument against experimenting and forking. I guess that's true, but I still feel that more could be split and shared while still experimenting on many other things. There will also always be politics, personalities and the will to reinvent wheels for many reasons, like self-education or implementation pet peeves.

Also, different languages and/or runtimes/VMs and their differing suitability for different environments affect fragmentation greatly. We probably won't ever end up with a single "winner", no matter how much many C/C++/JS/Go/Rust/Haskell/ATS/theorem provers we go through, and for reasons (only some of which are mentioned above) we probably don't want to.

Dreaming is nice, though.

In another thread, you mentioned bup. Quickly skimming bup's readme on github, I seem to only find references to the backup use case - not sync. Am I mistaken and bup also supports syncing, or did you bring up bup for another reason?