_Soulou

Overall, everything works pretty well for me (user for multiple years), except all apps which are too bound too Google Play Services as microG is not stubbing/implementing all APIs.

So all apps with premium subscription you can only handle through in-app purchase, usually won't work.

I've heard that some banking apps are not working correctly either as not "secured" enough device, in my personal experience, they all worked, it's really a case-by-case logics here.

For the upgrade, OTA upgrade around every month, and it has always worked smoothly

Something I have been wondering with Flatpak is about Ram usage. As sharing dynamic libraries allow loading it into RAM only once, while if I use Signal, Chromium and different others Flatpaks, all libs will be loaded multiple times (often with their own version). So maybe disk is cheap but RAM may be more limited, which looks kind of a limit in the generalization of this method of distribution. (You could tell me it's the same with containers)

Am I right to think that? Has someone measured that difference on their workstation?

Instinctively I would say, to have a direct authentication/authorization process you couldn't have if the client was communicating directly with a MQ.

Is there any plan for a European presence? (At least, for the storage part)

Interesting not really, someone in my family made some research about its past and return to the XVIIth century. From there, we can only make assumptions.

Currently, we are running multiple containers from different apps on the same host. These containers are running with unprivileged users and reduced capabilities but in the same network. It will probably change in the future for a higher level of isolation.

I think it's my real name, proof underneath :-)

http://i.imgur.com/onAPdMr.jpg

Remind me "The Three Stigmata of Palmer Eldritch" from Philip K. Dick. Selected (clever) people are sent as settlers on Mars, but everybody know it's crappy as hell and that people are surviving thanks to drugs which allow them to remind theirselves what Earth's like. People try to get crazy on Earth to fail tests and avoid being sent there.

Docker stats is not a solution since you can't configure it, it's a good effort but is not sufficient. Docker stats over hundredths of containers generates too much load, you can't configure anything. An external project is welcomed to fulfill this lack.

Actually, not so similar, acadock is much more a wrapper which transforms cgroups and namespaces data to a more accessible HTTP API.

Scalingo's CTO here, if you have any question, I'd be glad to answer them.

I don't want to say anything wrong on this and I don't have the knowledge on this, but it's possible than the OS is doing a lot of work on this to avoid cutting connections. Do you have any details on this?

For the argument, you can change them, i answered there:

https://news.ycombinator.com/item?id=8773176

So far, I haven't encountered any annoying edge case I can't handle, so if you have examples, I'll be glad to discuss them with you

That's because when you connect to your SSH, it forked and there is one process which is handling your connection, then when you restart the daemon, it only restarts the master, no harm done to the existing connections.

The less I rely on the operating system environment, the best it is. Go provides static binaries, easy to deploy. I don't want to get hooked to systemd. (even more if my server can handle the use case with a few lines of code.)

You're right, but in some cases, for example a 'git push' to deploy an application, we don't want the SSH connection to be cut when upgrading our SSH server, this is not an option. If the server crashes the current connections will be lost, but it should be the only scenario when this occures.

Hi finnh, post author here,

1. When the parent process has finished handling its connections, it just exits. The children are then considered as 'orphans' and are automatically attached to the init process. When you run your service as a daemon, that's exactly what you want, so you don't have a huge stack of processes. 2. I used syscall.ForkExec(os.Args[0], os.Args […]), but I could changed the string array os.Args by anything I want to change the arguments. 3. It could be a way to do it, it would also work, but it is not the choice we have done. 4. It may look a bit weird, but it's part of the language, you get used to it really quickly ;-)

Actually, we are not only using this for HTTP services, but also for our SSH server (the one I've introduced last week). This method was mandatory for us!

Edit: typo

Hi alexk, post author here,

The 'manners' package only enables graceful shutdown in a HTTP server, there is still work to be done to restart it gracefully, that's what I'm trying to show in the article.

Hi j_s,

By sensitive data, we meant part of the identity of all our users (there is quite often user@host at the end of the public keys sent by our users), and the second point is linked to the internal commands.

In the `command="ssh-handler" ssh-rsa....` the command doesn't receive the SSH public key as argument, so we would have to provide additional information like: `command="ssh-handler <user_id|username|key_id>" ssh-rsa....` So yes, if we have a way to avoid having a copy of that on all our servers able to authenticate users, we take it!

As jerf said, it's always difficult to see if an implementation of a protocol respects it completely. Most of us trust OpenSSH because of its background. It's old enough, the codebase is mature enough and maintained by the OpenBSD team. However it's quite a massive project, I don't know how they would be able that their implementation fits completely the 6 RFCs, I mean, more than the go implementation.

In our case, the SSH server is not for general purpose, but for something really specific, so it's really easier to test. What other feature? As I will explain next week, our SSH server is actually an authentication/autorization proxy which forwards connections to another server. By building our solution, it is now easier to control the logics for the load balancing etc.

Post author here, unfortunately no, after some time, we realized it was quicker to develop a complete SSH server than patching some legacy C code. It was really confortable to work with go to do that.

A PHPSESSID appears in the cookie.

I read that for some of you the Chef experience was painful. I'm using chef-solo with the chef-solo-search cookbook and everything is working pretty fluently. Each of my node owns the entire repository and apply chef-solo on itself. With a cron to periodically update the chef repository, it is really confortable.

I agree that using chef-server is a bit painful (that's why I don't), but otherwise there are a lot of cookbooks and it works well. What kind of bad experience did you get?

And more important:

https://github.com/mongoid/mongoid/blob/master/CHANGELOG.md

github.com/juju/errgo from Canonical is really great. 100% compatible with the error interface, allow you to get the source and the explanation of an error.

You can find it here : code.google.com/p/go.exp/fsnotify

http://meet.jit.si is alive since last year it's open source. It works well! Give it a try