ignorant q: does Messenger still hold much of market share? over the last few years almost all of my contacts transitioned to WhatsApp, Telegram or Signal. Messenger is just way too bloated.
what a strange point. "the obvious" is not that there's concentration of power but that farming is hard? what about small farms where many people are happy to continue working because they find it fulfilling?
im providing a counter-example to the OP's point, and saying that people choosing not to remain farmers is not a sufficient explanation for decline in the number of small farms. the author clearly proposes many other reasons. see other responses to the message.
The "obvious" is that operating a family farm as a profitable business is hard. Harder than three of the four adult children in the article are willing to work.
That doesn't mean there aren't people who want to do it, that means that a lot of family farms are going out of business because there aren't enough people who want to do it, regardless of external pressures.
that conclusion doesn't necessarily follow though. the proposed thesis by the article author is difficulty of having enough cattle to break even. you need to make enough to grow your operation, which is difficult given that you rely on external factors like creameries. the only reason you only have your family's labour to rely on could also be the difficulty of scaling up.
I think the article writer is glossing over the difficulty of keeping a farm in business without the external factors. My experience, growing up in an farming area, is that the kids of farmers are relieved when the farm is sold to a big conglomerate.
If the author cared so much about the farm, nothing stopped him from going back and dedicating his life to keeping it running.
apologies if i'm coming across condescending or am missing your point but i'm having difficulty comprehending how the author staying on the farm would've fixed anything about the trend towards monopolization fuelled by corporate subsidies and other forms of preferential treatment coupled with those larger actors facing limited responsibility for any of the consequences to surrounding communities and environment?
> But then digital happened and both lenses and sensors outgrew anything analog.
maybe if you can afford an 80MP digital back with MF lenses? i still prefer 35mm compared to full-frame sensors but i'm more after latitude and colour rendition than sharpness.
if you live 35mm film you'll love medium format. It's much more forgiving due to less enlargement when printing, the trade off is that the equipment is large (although some of the fuji rangefinders aren't that much bigger than modern 35mm SLRs).
i work with MF too. im just saying the argument of "digital came and made analog irrelevant" doesn't really apply for me where I personally prefer 35mm over digital, let alone MF where you have "megapixels for days"
really cool resource for learning but a lot of these have nothing to do with k8s, beyond the company in question having k8s as part of their stack (i'm addressing the possible perception of the post title suggesting k8s horror stories).
A lot of them do have things to do with k8s, though. Admission webhooks, Istio sidecar injection, etc.
The CPU limits = weird latency spikes also shows up a lot there, but it's technically a cgroups problem. (Set GOMAXPROCS=16, set cpu limit to 1, wonder why your program is asleep 15/16th of every cgroups throttling interval. I see that happen to people a lot, the key point being that GOMAXPROCS and the throttling interval are not something they ever manually configured, hence it's surprising how they interact. I ship https://github.com/uber-go/automaxprocs in all of my open source stuff to avoid bug reports about this particular issue. Fun stuff! :)
DNS also makes a regular appearance, and I agree it's not Kubernetes' fault, but on the other hand, people probably just hard-coded service IPs for service discovery before Kubernetes, so DNS issues are a surprise to them. When they type "google.com" into their browser, it works every time, so why wouldn't "service.namespace.svc.cluster.local" work just as well? (I also love the cloud providers' approach to this rough spot -- GKE has a service that exists to scale up kube-dns if you manually scale it down!)
Anyway, it's all good reading. If you don't read this, you are bound to have these things happen to you. Many of these things will happen to you even if you don't use Kubernetes!
I have an environment variable to set process count for a nodejs service because everyone is finger pointing at who should be the one to sort out the fact that cgroup cpu limits and nprocs disagree most of the time. Our stuff is fine, those other guys should fix their stuff.
i dont think anyone submitting an unsolicited PR should be expecting it to be merged in. it's a way to convey a complete idea, not a guarantee of merging.
I do that. I sometimes prefer PRs to discuss my improvements. By the time I answer questions such as "how intrusive would this change be", "what exactly needs to be changed", "how would I test my change", I'm already halfway through the PR.
I agree that sending a PR should not be considered a guarantee of merging. Rather an issue that is discussed with a mixture of prose and code.
No, they shouldn't be expecting anything, but a lot of people will. And that's just how it is. If we don't want people to waste their time and potentially get upset, we should write out up-front what our contribution policy is.
Note that I'm not talking about how the world should be. I'm talking about how it is. I agree that people shouldn't just write up a PR without any prior communication with the maintainer and then expect it to get merged. But people do; that's just reality.
