sergiolp

For Mail/Calendar/Contacts/Tasks you should really consider Evolution. I've switched ~2 years ago, and it's amazing. Stable, sleek, and with tons of options.

It has a bad reputation because, back in the day, it was buggy and bloated. But I haven't hit a single bug over these years, and while it eats a significant amount of memory, it's on par with other options (and these days everyone has plenty of RAM).

I'd love to see more people giving it a second chance.

Centralization is a _huge_ privacy issue. Specially when combined with real world data, like a phone number.

Let's assume OWS is playing nice, and they really don't store any relevant metadata. How can we be sure that a third party is not eavesdropping their communications?

Even with end-to-end encryption, given enough time, an attacker can easily build a user relationship network, something _very_ dangerous in the wrong hands.

If you really care about privacy, you should consider options like BitMessage, Onion.chat, Ricochet, Tox or GNU Ring. Or, as a middle ground between those (which are quite mobile unfriendly, due to its P2P nature) and Signal/WhatsApp/Telegram, a federated service like XMPP (as the article suggest) or Matrix.

That comes from upstream's README.md. I've never payed any attention to it, but now that you've pointed it out, I'm seriously considering changing that paragraph, or adding a note/disclaimer somewhere.

After all these years and promises, server's code is still closed, federation is nowhere to be found, their update/commit policy for the official Android app is a joke [1] (they even closed its issue tracker), and I'm really tired of their "trust us, we're not evil" policy [2].

If you haven't switched to Matrix/Riot, do it right away.

[1] https://github.com/DrKLO/Telegram/commits/master

[2] https://telegram.org/faq#q-who-are-the-people-behind-telegra...

Telegram-FOSS (the FOSS friendly fork you can find on F-Droid, not the official app on Play Store) maintainer here. Telegram is NOT a "secure messaging app".

Three days ago, a Jolla C replaced an iPhone 5S as my main phone. To be fair, me using iOS was just a kind of an experiment. Before that, I was using a CM build without Google Apps using FDroid as unique app repository.

I must say that, while still needs some polishing, Sailfish OS (which is not 100% free, but is quite there, and provides a complete Linux experience), does the job. My Pebble works, my BT car kit works, and I have all apps I need. In fact, my biggest complain is about the hardware, being underpowered and with an atrocious camera. An official port from Jolla to some mid level device would make me _very_ happy.

In some countries, like mine, the FOSS mobile OS killer has a name: WhatsApp. Without official support for FFOS or Ubuntu Touch, and being very aggressive against third party apps (banning their users), most people can't even think of them as an option for daily usage.

Jolla goes around this bundling a commercial Android Dalvik emulator. Not the best solution, but one quite pragmatic.

At flexVDI, we use Xamarin for building our macOS client (Xamarin.Mac), sharing most of the code with the client for Windows, built with Visual Studio. Both of them, link against a shared library which implements core functionality, written in C.

I must say that, having its own quirks and nuisances (specially in Xamarin Studio, which was pretty buggy until version 6.x), it does the job pretty well.

In fact, when we wrote our iOS and Android clients, Xamarin was still pretty immature. But if we had to rewrite them today, it would be one our of first options, right after using the native frameworks (which ensures the best results, but drastically increases the costs).

I'm not talking about the efficency of the resulting binary, but the "distance" from what the programmer is thinking, to what the machine will really do.

Compiler optimizations aside, C does a pretty good job at this. It's way more efficient than writing assembly, but your still basically just moving memory around, while doing some arithmethic. Easy to understand in "machine" terms.

Of course, this is only relevant when you're doing low-level stuff, like kernel or drivers programming. For the userland, Rust really looks like a nice language (I've played with it just a bit), and I'd be really happy if it pushes C++ away ;-)

I can't help but think they're trying to fix something that isn't broken at all.

Adding new abstraction layers rarely helps when doing systems programming. You (as in "the developer") want to be as near to the machine as possible. C does this pretty well.

Perhaps I'm just getting old :-(

Sorry if I'm too harsh, but saying that ZoL is "rock solid" and "production ready" sounds like a joke to my ears.

ZFS is an extremely complex filesystem, and it took Sun _years_ of internal testing first, and hundreds of angry customers later (sadly, at some point, the only way to improve a product is through real world testing), to reach a milestone where it was really production ready.

I know that on these days of dockers and unicorns, "production ready" has very different meaning than years ago, but still...

The OSF vs GNU Mach thing is not a problem. It was years ago, but I managed to run a Hurd translator statically linked against a slightly modified glibc on OSF Mach (the one bundled with MkLinux, you can see its code on my repo https://github.com/slp/mkunity).

In fact, if you look at Mach support code on glibc's code, you'll see build time conditionals for supporting non-GNU Mach versions.

The bootstrap server is not a problem either, but the lack of memory object would indeed break all libpager based translators, among other stuff.

As a PoC, I wrote a filesystem translator (https://github.com/slp/anonfs) which doesn't rely on memory objects, implementing conventional read/write semantics (no mmap() support, though).

A curious (and probably unintended) side effect, is that if its implementation of the Mach API is complete enough, this should allow to run Hurd user space server/translators on FreeBSD.

Not sure if useful, but would be cool (in a weird, nerdy way) anyway.

Communication would've happened, but probably between far less actors. So, you have a communication channel which is orders of magnitude slower, and bigger communication needs. Not good.

That said, about the reliability point, I agree with you. If you're building an specialized system, and reliability is your main concern, microkernels+multiservers are the way to go (or, perhaps, virtualization with hardware extensions, but this is a pretty new technology for some industries).

Probably you're going to need to add orthogonal persistence to the mix, to be able to properly recover from a server failure, or an alternative way to sync states, which will also have an impact on performance. But again, you're gaining reliability in exchange.

I don't know about the others, but at least both QNX and Minix3 cheated a little, i.e. allowing servers to write directly to other user space programs.

Also, the presence of microkernel+multiserver systems is still quite symbolic in comparison with the monolithic couterparts.

You've just hit the nail right on the head.

I don't know about other implementations, but I remember the original design of l4hurd (based on L4Ka), was even more complex. I'd same this applies to all "pure" multiserver designs.

Some years ago, I've spent a lot of time studying GNU Mach and Hurd (I've also made some small contributions). I think I can say that I now both pretty well. I even started a project to preserve OSF Mach + MkLinux source code (https://github.com/slp/mkunity), a very cool project for its time (circa 1998).

These days I prefer to do my kernel hacking on monolithic kernels, mainly NetBSD. I've stopped working on Mach, Hurd and other experimental microkernels (there're a bunch out there) because it was becoming increasingly frustrating.

If you'd ask me to define the problem with microkernels with one word, that would be "complexity". And its a kind of complexity that impacts everything:

- Debugging is hard: On monolithic kernels, you have a single image, with both code and state. Hunting a bug is just a matter of jumping into the internal debugger (or attaching an external one, or generating a dump, or...) and looking around. On Hurd, the state is spread among Mach and the servers, so you'll have to look at each one trying to follow the trail left by the bug.

- Managing resources is hard: Mach knows everything about the machine, but nothing the user. The server knows everything about the user, but nothing about the machine. And keeping them in sync is too much expensive. Go figure.

- Obtaining a reasonalbe performance is har... imposible: You want to read() a pair of bytes from disk? Good, prepare a message, call to Mach, yield a little while the server is scheduled, copy the message, unmarshall it, process the request, prepare another message to Mach to read from disk, call to Mach, yield waiting for rescheduling, obtain the data, prepare the answer, call to Mach, yield waiting for rescheduling, obtain your 2 bytes. Easy!

In the end, Torvalds was right. The user doesn't want to work with the OS, he wants to work with his application. This means the OS should be as invisble as possible, and fulfill userland requests following the shortest path. Microkernels doesn't comply with this requirement, so from a user's perspective, they fail natural selection.

That said, if you're into kernels, microkernels are different and fun! Don't miss the oportunity of doing some hacking with one of them. Just don't be a fool like me, and avoid become obsessed trying to achieve the imposible.

Of course, a virtualized Guest will have a performance penalty.

With that phrase I meant that, following this guide, you can make use of the Virtualization Extensions from the Cortex-A7 which powers the Raspberry Pi 2.

This is pretty useful for running multiple isolated services (such as a media server and an ownCloud instance), doing some kernel hacking, or testing a variety of ARMv7 distributions.

Sorry, we've underestimated the attention this post was going to get. We've just assigned more resources to that machine.

Let's hope that'll be enough to bear with the warm, warm hug of Hacker News ;-)

While reading "LINUX is obsolete (1992)", this relatively unknown article has come to my mind. It's a pretty good read about a real world implementation of a microkernel architecture, and the tricks they had to do to obtain a reasonable degree of performance (migrating threads, collocation...).

Here's a little background. In the 90's, the Open Software Foundation (OSF, now part of The Open Group) was trying to build a common foundation for all UNIXes (back then you weren't a cool IT company if you didn't have your own UNIX OS, ask Microsoft).

As OSF/1, the (supposedly) reference implementation of UNIX, didn't gain enough traction, they started working on OSF Mach. OSF Mach was intended to be a small layer between the hardware and the OS personality, so UNIX companies didn't have to waste effort porting their code for every architecture.

The idea was quite cool (you can think of it as an early form of virtualization), but the initial results were quite disappointing on the performance front (the paper talks about being 40% slower), so they started implementing some tricks that, essentially, broke the microkernel architecture while keeping the modularity. The most significant was collocation, also called in-kernel servers, which put the OS personality in the same, privileged space as Mach, so cross-space messages would become syscalls.

On 1995-1996, the OSF was asked by Apple to build a Linux version for their PowerPC based machines (go figure), and MkLinux, a Linux personality running OSF Mach (which the paper is talking about), was born.

Here's when history becomes a little confusing. We've all been told that modern Mac OS X comes from NeXTSTEP source base, which was a CMU Mach+BSD OS (while MkLinux was OSF Mach + Linux), but if you look at the early code from XNU (OSX's kernel), you'll find an almost unmodified OSF Mach.

I suppose they took OSF Mach, which probably at that point was far more advanced than CMU's, added the BSD bits from NeXTSTEP and finally complemented it with the FreeBSD based IOKit.

I did some small contributions to GNU Hurd years ago, but still, this made me giggle:

Of course 5 years from now that will be different, but 5 years from now everyone will be running free GNU on their 200 MIPS, 64M SPARCstation-5.

Nice, just a few weeks ago I finished my port of socz80 to DE0-nano (https://github.com/slp/socz80-de0_nano).

Apparently, the original socz80 is already supported on Fuzix, so it should run here too. More retro-fun!

On the linpack test, the KVM domain should have been configured for inheriting the CPU extensions from the host (or, alternatively, cherry picking the extensions relevant for such test).

For the rest, I think an updated KVM vs. Xen vs. VMWare comparison would have been way more interesting. If you don't need to run other OSes, process tagging (jails/zones/containers/whateveritscalledonyouros) will always give you better performance.