That is simply not true! Use of mechanical farming and fertilizers/pesticides can be beaten in productivity by permacultural practices. One example in France that has been followed by researches (and has produced several papers [1]) is the Ferme du Bec.
It is able to produce multiple times more and more qualitative (organic), for the same area than the national average mechanized production in France.
The pesticide industry and mega farmers want you to believe that what they are doing is to produce more food, but that does not stand the fact check of initiatives like permacultural ones.
The real challenge here is that people simply don't want to farm anymore. We built ourselves a vicious cycle with mechanization and chemicals that allowed farms to produce more per acre, leading to fewer people farming and further dependence on oil and chemicals. Even worse, food systems are so centralized and complex that there's very little left to even pay the farmer by the time the rest of the supply chain makes it's cut.
Local food production may go a long way as it reduces the steps between the farm and the end consumer. That still may not be enough though, rewiring higher food prices regardless of how it's produced.
In one of the linked studied the result was that one person working 43 hours per week could profit €900-1600 per month. The same article mentions a minimum wage of €9.61/hour, so even on the high end the farmer is working all that time and owning the risk of a bad harvest to make less than minimum wage. They didn't mention any holdback on the crops to feed the farmer, so they might be separately paying for food out of that income. People just aren't going to do that in large numbers unless they have to.
You raise some crucial points regarding the challenges faced by farmers and the complexities of the modern food system. The mechanization and chemical-intensive practices that have boosted productivity per acre have inadvertently contributed to a decline in the number of people engaged in farming. This has led to increased dependence on external resources such as oil and chemicals, further entrenching the cycle.
The issue of centralized and complex food systems is also significant. As the supply chain becomes longer and more convoluted, the farmer often receives a diminishing share of the final price paid by consumers. This creates financial strain and makes it difficult for farmers to earn a sustainable income.
Promoting local food production can indeed help mitigate some of these challenges. By reducing the steps between the farm and the end consumer, local food systems can create opportunities for farmers to receive a more equitable share of the value generated. However, as you mentioned, even with local production, there may still be limitations in overcoming the underlying financial pressures.
The example you shared about the farmer's income compared to the minimum wage highlights the stark reality faced by many agricultural workers. Working long hours and taking on the risks associated with farming, while earning less than the minimum wage, is not a sustainable situation. It's important for society to recognize the immense value farmers provide and ensure fair compensation for their hard work.
To address these challenges, a comprehensive approach is needed. This includes supporting policies that promote sustainable agriculture, fostering local food systems, and advocating for fair pricing and compensation for farmers. Additionally, exploring alternative models such as community-supported agriculture and direct-to-consumer sales can help create a more viable and rewarding environment for farmers.
One big hurdle to jump will be the need for fundamental change in government regulations for food production.
The requirements are ridiculous particularly with meat production. I can't sell cuts of meat unless the animal walks off the trailer at a state or federally regulated processing facility. Getting in line at the processor is not easy and though lead time isn't as bad as it SAS during the pandemic response, it can still require planning months ahead on exactly when you will process one animal.
Beyond that, there are very real animal welfare concerns if you ever look into how those facilities work. Animals walk of the trailer and spend their last hours extremely stressed, stuffed into concrete holding pens and chutes with other animals they don't know in a building that must smell unmistakably of death.
The meat is processed in very specific ways, including spraying it with bleach. There's no way around that, and may stamped USDA has been treated that way.
I do understand how we ended up with so many regulations and health concerns, but they are all byproducts of an over-centralized system that attempts to produce an entire country's worth of meat in one place and distribute it nationality so that every store shelf looks the same. Those regulations have grown so l large that is nearly unsustainable to attempt to raise meat on a smaller, more local scale.
The real underlying issue here is that good farming practices require hands.
If we don't value back farming related work and allow people to invest a lot of there time and energy into sustainable practices we cannot have the amount of people required to do what is done at la ferme du bec at a much bigger scale.
In the US currently industrial and smaller scale farms use heavy amounts of effectively slave labor / indentured servants with fake/stolen papers, bussed to unknown remote locations, company housing and company towns with local sheriff in kahoots with the owners, routine ICE raids to force compliance and break up organizing. We’re quite far from kindness to labor. Many modern liberal countries like SKorea, Italy have similar. Our most democratic nation states run on slave labor.
It is laughable talk about "Don't Repeat Yourself principle" on a strongly biased towards Golang article. A language that took 13 years to add a simple method (Index) that helped the programmer to find an element in an array (slice). Before that you had to write a for loop every time you wanted something from an array. Talk about "DRY" ... That is everything but "simple" as described in the article.
An amusing aspect of DRY is that the moment you think "great, with that last patch I'm no longer repeating myself," you now have an opportunity to look around and really just take in how much repetition happens everywhere, at multiple levels.
You are still repeating yourself, and will likely continue to repeat yourself, forever.
(Phew, look at that word "everywhere", it should just be "vrywh")
> But there's nothing wrong with repetition in itself. I say again, there's nothing wrong with repetition in itself: a task we do many times is probably an important one. And if we find ourselves creating new abstractions to no purpose other than avoiding repetition, then we've gone wrong somewhere. We're making the program more complex, not more simple.
> Before that you had to write a for loop every time you wanted something from an array.
How often do you do that? I mean, it comes up - but if you're linearly scanning every time you want to select something from a list, that sounds like a surefire way to write slow code to me. Is there a reason you aren't using a map?
Maybe. That depends on the map implementation. In javascript I’m pretty sure small maps are implemented as lists anyway. I wouldn’t be surprised if Go is the same.
Searching through a list is definitely more complex to write, and it carries the danger that your list will grow and you wont change your code.
The speed difference will only matter at scale - so if you have a lot of small lists with items you’re searching for. That happens, but it’s uncommon that it’s the best approach. I probably use find() / indexOf() about once every thousand lines or so.
The commenter above implied it’s a very common operation in their code. (So much that they’re angry about Go not having it in the standard library). I don’t know about the commenter above, but I’ve certainly seen a lot of novices at programming massively overuse lists not because they’re performance experts, but because they don’t yet understand when a map might be a better choice.
So I must say I understand Go’s choice here. Go is a paternalistic language where the obvious choice should usually be the right choice. Go is actively against clever optimizations philosophically. I can imagine rob pike being quite pleased that slow, linear scans of lists are awkward in his language. This sort of judgemental paper cut is sort of Go’s whole thing.
If you don’t like being looked down on by the compiler, use a different language. Or use maps in your Go code. Go isn’t designed to be microoptimization friendly.
(Source: I sat about 2m away from Rob Pike for nearly a year while he worked on Go, before it hit 1.0. Go isn’t designed to be a language for people who think about cache lines.)
At sizes/number of items, where this holds true, maybe the choice of data structure is not as important. It becomes important, once the number of items in that collection increases and then always linearly scanning the whole array will become a problem. Just use the appropriate data structure and be safe in the future, taking a negligible hit for small input sizes.
This is my experience as well. GitHub Copilot has been very efficient at generating variants of boiler plate code. It allows you to efficiently repeat code so you can delay code abstraction or generalisations until you are confident a generalisation makes sense.
Having worked as a developer for many years I now much prefer to repeat code a bit to making the wrong abstractions to early. The tedium of writing out code is now reduced thanks to well performing language models.
Thanks! Internally we use more sophisticated system required by larger scale to support higher volume and concurrent connections from multiple clients, but for smaller scale limited to one person or a small team, everything described on our blog should be enough.
I wonder how this will be sorted in the future: what if Stability comes with a newer version, on top of Runway's one? I forecast a never ending battle of versions numbers as both teams have the same trunk of work.
Virtualbox 6.0 had PCI passthrough on Linux hosts. I was using it. Then I have updated to 6.1 to discover that they have removed it. I am afraid of going to 7 and see that other things are missing too :-)
reply