fatherlinnux

9 ms·

31.
by fatherlinnux 8y ago
I agree that developed companies are doing what is described, but that is a completely separate thing than starting from scratch. People have hurriedly forgotten why Linux distros exist: https://opensource.com/article/1
32.
by fatherlinnux 8y ago
The OCI standards make it so that it doesn't matter if you switch or not. Your images will work anywhere with any tool (aka Cloud Providers, Kubernetes, Podman, Buildah, etc.) Everybody has OCI compliant tools, even Docker - Docker fou
33.
by fatherlinnux 8y ago
1. GitHub was struggling badly. They had lay-offs, etc. 2. Google still makes the lion's share of it's money from search/ads. Google Compute is struggling and being subsidized by search/ads. IMHO, Docker's only exit
34.
by fatherlinnux 8y ago
Exactly, when will Silicon valley investors understand that Open Source: 1. Doesn't grow revenue at the speeds they want returns 2. Isn't "free marketing" (dear God I have seen this one too many times, CTOs even write it
35.
by fatherlinnux 8y ago
We get this question all the time, and I totally understand the frustration. In a nutshell, here's the breakdown. I will highlight this in blog entries as RHEL8 comes out and emphasizes podman, buildah and skopeo, so you will see more
36.
by fatherlinnux 8y ago
LOVE to hear this! The podman team thanks you for your feedback ;-)
37.
by fatherlinnux 8y ago
Yeah, basically the "sudo" commands all over the Internet are just legacy. Historically, root was required (like docker - most people don't understand they are talking to a daemon which has root), but recently we added runnin
38.
by fatherlinnux 8y ago
Yeah, it's called Red Hat Enterprise Linux ;-) It's available on all the cloud providers and has a better API/ABI guarantee as well as very, very well defined commitments to patching and lifecycle :-)
39.
Containers Don't Run on Docker(crunchtools.com)
4 points by fatherlinnux 8y ago|0 comments
40.
by fatherlinnux 8y ago
In Fedora, there is the Fedora Tools container [1], in RHEL, there is the RHEL Tools container. I don't envision either of those going away because they allow you to do all kinds of fancy stuff including things that require kernel comp
41.
by fatherlinnux 9y ago
We are building a lot of tools to simplify run/build move [1][2][3]: [1]: Run within Kubernetes: https://github.com/kubernetes-incubator/cri-o [2]: Run Standalone: https://github.com/projectatomic&
42.
On Unikernels – Which Is Heavier – VMs or OSes?(crunchtools.com)
3 points by fatherlinnux 9y ago|0 comments
43.
Kubernetes Is a 10 Ton Dump Truck That Handles Pretty Well at 200 MPH(crunchtools.com)
2 points by fatherlinnux 9y ago|0 comments
44.
Why the Open Containers Initiative Is So Critical(crunchtools.com)
2 points by fatherlinnux 9y ago|0 comments
45.
by fatherlinnux 9y ago
Really good background from Dan Walsh who has lived through this entire journey for the last 5ish years. Many times, people don't understand all of the moving pieces, but this article explains it well...
46.
Containers: Why Portability and Compatibility Are Not the Same(crunchtools.com)
3 points by fatherlinnux 9y ago|0 comments
47.
Remember WTF Is a Container? Really Just Fancy Files and Fancy Servers(sdtimes.com)
2 points by fatherlinnux 10y ago|0 comments
48.
Building a Secure and Manageable Container Software Supply Chain(rhelblog.redhat.com)
2 points by fatherlinnux 10y ago|0 comments
49.
Workload Characteristics and Candidates for Containerization(rhelblog.redhat.com)
1 points by fatherlinnux 10y ago|0 comments
50.
by fatherlinnux 11y ago
This is again, getting to the right answer for the wrong reason. You could keep these code bases separate whether they run in the same JVM in one container or in separate JVMs in different containers. As long as you enforce communication ov
51.
by fatherlinnux 11y ago
My argument is, if two different processes are doing completely different things in the same JVM, I am skeptical that they will share memory pages well, etc. I simply don't know without testing, but I don't have any reason to beli
52.
by fatherlinnux 11y ago
Read the email thread that inspired me to write it and it will become obvious. In the original email, a user asked if they should split an application that was almost exactly what I describe in the blog post, into multiple containers becaus
53.
by fatherlinnux 11y ago
Nginx, Apache Prefork, Apache MPM, and PHP FPM all have multiple processes, and I would NEVER try to split up subprocesses of any of these into multiple containers. It's quite simple if something communicates through shared memory, it
54.
by fatherlinnux 11y ago
This was exactly why I chose the workload I did. I think independent scaling and possibly enforcing decoupled behavior in the development teams are the only real reason TO decouple.... The rest are all descriptions of things that "migh
55.
by fatherlinnux 11y ago
Fair point, but it's an existing application. I sort of assume it has low coupling already. But, if it already has low coupling, one might fairly ask, why do I need to enforce it? For some future optimization?
56.
by fatherlinnux 11y ago
I would argue, service, not process :-)
57.
by fatherlinnux 11y ago
I tend to agree :-) Hopefully, you guys read my comments in the comments section of the article. Quite honestly, I am skeptical how often it makes sense to "force" splitting up an application. I hope that was clear in my article..
58.
by fatherlinnux 11y ago
I actually regretted not mentioning the organizational advantage. Basically, scaling and organizational split are really the major two business drivers for splitting an application up!
59.
When Should I Break My Application into Multiple Containers?(rhelblog.redhat.com)
90 points by fatherlinnux 11y ago|57 comments
60.
by fatherlinnux 11y ago
@ilsivka: check out: https://github.com/projectatomic/oci-register-machine and https://github.com/projectatomic/oci-systemd-hook Also, ping Dan Walsh as he is leading work on our (Red Hat) end to

More ›