spahl's comments

Totally fair. It's a fine line we have to walk.

Makes sense! Thanks for the feedback.

And yeah OpenTelemetry is where lots of the industry is going and so are we. You can already do cool things with us and the collector but we plan on automating a lot and expand on that.

A little bit about that in this commment: https://news.ycombinator.com/item?id=25995424

Sorry I don't know what happened here is a new youtube link: https://www.youtube.com/watch?v=ooqBn1Q-y2Q

It's from this page: https://opstrace.com/docs/quickstart

It's definitely aspirational. With time and work the features gap (for the important ones) will narrow:-)

What we want to emphasize is that it is possible to build this and have the advantages of a Datadog without the drawbacks.

We are still experimenting with pricing and what can be open and closed. To be completely transparent we chose custom domains because we know companies care a lot. When we have more features on the commercial side we can start to chat about supporting it in the open version. Still early in our journey, happy to discuss anything, like a small plan with just custom domains. Would you pay for that?

We totally agree our website is way too wordy and we are working on explaining our vision through various ways. Screenshots of course, but also things like short videos. We actually just did one of our quickstart https://youtu.be/XkVxYaHsDyY. It’s not perfect but we will get there:-)

Thanks for the feedback, we appreciate it!

Yes that is frustrating indeed. On top of paying your external vendor, you are punished by the egress cost you have to pay to your infrastructure cloud provider. This is one of the problems we wanted to solve. Feel free to contact me [email protected].

Yes! We will be having features that you have to pay a subscription for. It starts with the usual suspects: custom SSO, custom domains, and authorization - things that we would be hosting as an ongoing service for customers. Most features will be open when we create them -- this is near and dear to our hearts -- it’s important our users can be successful with the OSS version. Over time, the commercial features will also flow into the open as we release new proprietary ones. Our commercial features will be public in our repo, under a commercial license.

We will also have a managed version where we deploy and maintain it for the customer in a cloud account they provide us.

Here it is: https://github.com/mesosphere/dcos-commons/tree/master/frame...

Not anymore.

Although it still supports lxc, docker now defaults to libcontainer (https://github.com/dotcloud/docker/tree/master/pkg/libcontai...), it's own container implementation.

Yes packages are built in a fresh container every time. It's has a lot of functionality in common with pbuilder.

Of course, building packages is just one of many use cases. You also want to test the installation of the new package, run integration tests...

Nobody said we gave up on continuous integration. Quite the contrary! We use jenkins and other CI tools on a daily basis.

Once we have tools to build debian packages easily in a controlled environment (containers), the CI server will be able to use the same tools to build and test the final package. The advantage here is that a developer can test the whole workflow and build local test/dev packages with the same tools and environment as the CI server.

But this was written in 2008. Storage capacity could/must have increased massively since then.

Programmers love their tools, everybody has had different experiences.

What is wrong with sharing them?

http://unbound.net/ Here is another lesser known but actively developed DNS server.

The cool thing is that you can hook into the resolving chain with C and/or python.

1. Ok so when is it appropriate/useful to use the power of embedded php (in html) instead of templates? Just for learning the first couple of hello worlds? In my experience it becomes a mess to manage when you start having more than one commiter and more than a couple of lines of code.

2. You don't have to be a command line expert to start using it. All the books at http://learncodethehardway.org/ show that command line can be integrated in the language learning process seamlessly. No reason to be terrified of it, on the contrary, new coders should embrace it as soon as possible.

You can always build things with at scale, even with flawed languages (look at javascript).

The thing is, why choose a flawded language when there are others less flawed (nothing is perfect) for new code?

Yes you can get up and running quickly with php, but my comment was mostly about the fact that it is not much slower in other languages (most of the time not slower at all).

And yes I did a lot of PHP but that was 5-6 years ago. I know things have changed a lot since then but the language still has a lot of the same flaws.

What advantages does this "direct conjunction with HTML" have over templating solutions? Why do most PHP frameworks implement templates then?

Also, if command line is a barrier for an aspiring (web) programmer, he/she should start looking for a new career path.

"gets shit done very very quickly"

In what way does PHP help to get things up and running faster than other languages?