tjfontaine
While it's far from the only app that offered a reader mode, its implementation handled some of the more esoteric news sources (with disruptive layouts) better than the others I've tried. But the feature I will miss the most is title rewriting ("mark as clickbait") which I now hope to see as a feature on all my "reader" class apps (news, email, etc).
Great work, and kudos to the team.
That being said, I went to look[0] and it turns out it wasn’t a lie. [0]https://github.com/illumos/illumos-gate/blob/master/usr/src/...
It’s difficult to find and diagnose these types of issues, so anyone looking into RAII style leaks, or long lived closures, need tools to help them understand their allocations and their life cycle to be able to solve their problems.
I am not sure what exactly you mean by “does not allow host level access”, the benefit of linuxkit is you can configure the software that needs to run in the root namespace, or not, aside from every process generally having a mount namespace.
The real benefit (imo) of LinuxKit is the familiar declarative manifest model for image definition, and container configuration. As a by product, it’s really straight forward to have reproducible builds.
However, I’m not sure what the difference is here from say https://github.com/linuxkit/linuxkit which also has an example for how to use LinuxKit to build Kubernetes environments https://github.com/linuxkit/kubernetes
But I see CNAB falling into the same trap as Helm, and many of the package managers before them (including newer variants with things like charm/juju), an archive with some notion of lifecycle events is not enough. Even though it's cute that lifecycle events are encapsulated in containers making it easier to manage their runtime dependencies.
What I think makes Crossplane's model more attractive is the notion of building on top of Kubernetes design and leveraging things like the operator pattern[2]. Now application stacks can do more interesting actions during their lifecycle, which can work to preserve availability during an event (like upgrading your application stack). Crossplane is about expanding the management of resources beyond just containers running in your cluster, but to any resource you can model in the K8s control plane and writing software that can react to events related to those resources.
[1] https://blog.upbound.io/introducing-crossplane-open-source-m... [2] https://coreos.com/operators/
You could use the resulting container from a buildpack in an image built by LinuxKit.
Good news regarding any trepidation on the differencesa between the runtimes — recently we announced that there will no longer be a difference between OpenJDK and OracleJDK [1]
To quote: “The Oracle JDK will primarily be for commercial and support customers once OpenJDK binaries are interchangeable with the Oracle JDK (target late 2018)”
[1] https://blogs.oracle.com/java-platform-group/faster-and-easi...
How do you (a for profit company built on open source) enable your community, to build and sell (their own) products, as well as enforce your trademark? If anyone (everyone?) can build and distribute and call their build `docker`, it becomes really hard to protect your investment (as a company and their fiduciary responsibility to their stock holders) from dilution of TheBrand(tm).
This is not cynicism and I don't fault Docker (the company) at all, it's just the reality of doing business. It's why Canonical requires a contractual relationship for infrastructure clouds to distribute Ubuntu images, it's why you have things like Firefox and IceWeasel, so on and so forth.
Great work everyone.
http://blog.delphix.com/matt/2015/03/25/resumable-zfs-sendre...
For instance Bryan Cantrill (full disclosure I worked for/with Bryan while at Joyent) was at Sun for the development of SMF, he's had experience using SMF in production, and more recently from his LX Brand work he's been exposed to the facilities that Linux has created to deal with the same sorts of issues.
Bryan is a superior technologist and a hell of a story teller, I'm sure I would enjoy reading/hearing his telling of why things like libproc and contracts were created and how they evolved over time, and if that as any relationship to why SMF is designed and behaves the way it does.
Note, Bryan is just an example -- there are many other people in the community that were there and could tell the stories. He's just the first person I thought of.
The point is that [re]creating interfaces/subsystems is ok, so long as we do that with the full view of history, such that we avoid that repeating cliche.
(I prefer run on sentences)
I would love to see a (series of?) blog post(s) about SMF. This wouldn't be a missive against systemd, but given that SMF has seen 10 years of production use, it would be a valuable history lesson. Why was SMF needed for Solaris, what was scope of responsibility, why were the abstractions picked, why were its boundaries where they were, and finally what has and hasn't worked for it?
It seems like the technical community would eat that kind of content up.