x0rg

Wow that's great, I'm definitely going to try it. This guy knows what he is doing.

This all makes sense to me, thanks for the comment. I am aware of the --command option, but I didn't manage to do everything I wanted with it, but honestly that was a while ago. I was discouraged by people telling me that this wasn't the "right way" because tons of things in nix-shell assume bash, but honestly I don't know the details and I should try again.

> But the purpose of shells like this isn't to protect you from running `rm -rf /`, if that's what you're after. It doesn't protect you from dogecoin miners in your `npm install` hooks, if you're just using Nix to provide `nodejs` and then running `npm install` as usual.

This is absolutely fair. I was mostly saying what I wish I could have: isolation (as in can't write outside of the current directory) together with the ease of getting packaged without installing them that nix-shell provides, without the overhead of docker or a vm. I don't think it's impossible to build although I appreciate that it may be out of scope for this particular project.

I run nix in a vm all the time. The point of this project seems to be to avoid this approach and use local dev natively, which would be a godsend. I am pointing out that there are a bunch of things that are not really supported or ideal with the chosen nix-shell based approach.

I have been using nix myself quite a lot, but mostly in already isolated environments, both a vm and GitHub codespaces.

Yeah I know, my whole comment was about nix-shell and about this project posted here, not generally on nix.

This is shelling out to nix-shell (https://github.com/jetpack-io/devbox/blob/97c19c370287e203bb...) which means that it will only support bash AFAIK. I've seen a lot of discussions around using nix-shell for dev environments, but read somewhere that is not really made for this purpose originally, rather for just building packages, bash being only one of the limitations.

I tried to experiment myself with nix-shell, but I think it doesn't provide separation on the machine on which you run, it's not a chroot nor a docker container. If you are interested in some level of separation to make sure that a dev environment is "safe" to run on your machine without making side effects to things external to the project, then I'm not sure nix-shell would be able to help, but I would be happy to learn there is an option to do otherwise.

Do you have a more real world example of a darwin-configuration.nix? I want to see how this looks like and maybe hear about experiences with it longer term.

I can tell you my story: I tried for years to stay in Italy and work there (it's my home country). As a software engineer I had to work 70 hours per week with no way to get a decent job for a salary between 20-30k euros (gross). When I severely burned out, I found the strength to leave the country and found a completely different work culture in Germany.

This to say: I'm not sure Italians will ever turn it around, still I sometimes think it would be nice to come back and try to change things, but it is incredibly hard given that most of the young people there either leave, they accept shitty jobs or have the same mentality of their parents.

Disclaimer: this is all AWS related as this is the cloud I'm using. I haven't tried Google Cloud Functions or the Azure equivalent.

I've been working with Lambda a lot more lately and it is not so bad... but also not great. I'm saying this cause I found it hard to have a git-first (or git ops) workflow that is good in AWS: it looks like everything is made to be changed manually. CloudFormation is a slow with some resources (if you need CloudFront it will take tens of minutes) and CodePipeline has a pretty terrible UX and user experience. CodePipeline is cheap and it works for sure, but it's not a good system for pipelines as restarting, terminating steps and getting the output of steps just don't work in a decent way (I want to see the output in the steps, not jump to CloudWatch). Pretty much every other system outside of AWS is better than that, but the integration with Lambda and APIGateway is not as good unfortunately. If you know of a better system for CI/CD with AWS Lambda outside of CodePipeline, I'd be interested to try it.

In a similar way, most of the serverless frameworks I've tried are written for a workflow that is executed from CLI which is great to start and attractive for developers but not good enough for a company that aims at full reproducibility of setups and "hands off" operations. Source code change should trigger changes in the Lambda/API Gateway setup all the time and it would be great if devs don't have to trigger changes manually.

Apart from those steps, I think Lambda is definitely promising and I see the company I'm working for right now using it more and more. The developer experience is still lacking IMO but I'm confident we'll get there at some point.

But does it still make sense to have conferences so big? re:invent is so big it is extremely hard to actually attend sessions and there are logistics problems like sessions being in different far away locations. Small conferences seems usually more useful to actually connect with people that those kind of massive events.

True, it is not too much of a sales pitch, but still something that really can't be seen as impartial, for natural reasons (it comes from the company behind Mesos) and it looses a bit of clarity (Java doesn't equal legacy, you can run Stateful workloads on Kubernetes) towards the end.

From my point of view, the benefits of the two level scheduling are actually quite limited with respect to how the whole story is usually told. Some Mesos framework always use all the resources from the clusters and it might get tricky to really have multiple frameworks to run at the same time on Mesos. Also, sometimes those frameworks don't really offer so many additional features to justify changing the way you are already using Spark, Cassandra and so on.

Those kind of articles are not so useful, Mesosphere is the company behind DC/OS and Mesos and they have all the interest in the world to say that Mesos is the best. Things like "... are willing to get your hands dirty integrating your solution with the underlying infrastructure" when talking about Kubernetes is unfair, especially if you compare Kubernetes to Mesos and not to Mesosphere DC/OS for which they provide paid services.

It is true that Mesos works on a different level, but, most of all, the two level scheduling is just a different take at the problem of abstracting physical/virtual resources. In the end, both Mesos/Marathon and Kubernetes aim at the same goal: allow developers to stop thinking about servers.

Kubernetes' great advantages is the community (which is unbelievable) and the extensibility it proposes: Third Party Resource or Custom Resource Definition, pluggable webhooks in the API Server and a number of other things that are simply not there in Marathon or any competitor which allow companies to make Kubernetes work best for their use cases.

I was wondering how to make this automated through some sort of pipeline that needs a human to click "go on with the next X % of the rollout and how I would do it with kubectl without too much pain.

I'll definitely do it, too bad for the 50 nodes limitation that can't fit my use case.

Plus, kube-aws doeesn't really allow of easy maintenance of the cluster (i.e. cluster updates) as far as I know.

Is there a way to do this properly in AWS without nginx? It would also be great to have features to switch only percentage of the traffic to an app when doing blue/green deployments.

Great stuff, happy to see this, especially the part that concerns the setup of the cluster, but still too much in early stages. Currently I'm learning a lot on how to get started on AWS and it is still a bit too painful... after using GKE you just don't want to deal with the manual setup.

We (https://tech.zalando.com) also made some work to use Helm to deploy Patroni (https://github.com/zalando/patroni), our solution HA PostgreSQL. We have a PR open, if you want to have a look: https://github.com/kubernetes/charts/pull/57 ... comments are always helpful.

I hope the future of cloud will really be managed OSS as service. Google is doing a great job with Kubernetes and GKE and I hope the other providers will understand that. Microsoft is on the right way with DCOS as service, Amazon is just not there yet.

In zappr (https://github.com/zalando/zappr) you can, check it out. An example: https://github.com/zalando/zappr/blob/master/.zappr-example.... .

Another tool is https://github.com/zalando/zappr . We built this and we are currently quite happy with it and open to suggestions, issues, PRs.

For those interested in a comparison between Spark and Flink, a recent article from our blog here: https://tech.zalando.com/blog/apache-showdown-flink-vs.-spar...

Great, the docs are a bit bad for that, I'll have a look at the code :-)

Sure, even though having multiple schedulers support (for different type of workloads) would be great to increase the cluster utilization, which is one selling point of such systems. I understand that Kubernetes is developed in the open and with the community but the heavy marketing as the "solution you can use now, directly from the creators of Omega" makes some people think it's ready, perfect and will fix all of their problems, but that's simply not true.

Isn't Netflix using Mesos (see http://techblog.netflix.com/2015/08/fenzo-oss-scheduler-for-... )? I don't understand what role it plays here.

I'm living this nightmare. If people thinks that renting here is easy they're just wrong. Laws are just trying to fix a situation that is about to get much worse.

For yosemite, I have a macbook pro that came with the OS and another macbook pro (nearly identical) upgraded from mavericks. No significant differences. I don't see why it should be like that this time and I would love to read a technical explanation.

Wait, feeling that this update is better is OK, but I don't really understand how formatting could improve thing is such a significant way.

I did something similar, the worst part is that my employer never understood how crazy it was to work 70 hrs/week. Really, I tried very hard and with a lot of honesty to explain it, but I couldn't stop this.

What do you mean by "minor performance hit"? Could you provide some data?