I wasn't very impressed by the reporting quality in this article, but it seems as though there are some other reviewers of the book were much more thorough in their critique. Emi Nietfeld writing for Mother Jones has more detail and actually contacted some experts for comment: https://www.motherjones.com/media/2024/12/trauma-body-keeps-...
In short, most peasant farmers must sharecrop at least some of their land, and on sharecropped land, extraction rates are on the order of 50% (for basically nothing in return).
Not quite, there was social spending on things like (simple) roads and temples (which could double as schools), but obviously nothing close to today's (wealthy) standards.
Yet I have to wait 2 months (literally) to have an orthopedic doctor look at my broken foot, by that time whatever could have been improved will be long fucked, or I have to go private and pay 100% out of my pocket. I don't own a car, can't afford kids, can't move out of my old contract: it would triple my rent to get an extra room, as for the pension I'll see when I'm 75 or whatever age they decide to make us slave until.
There are lots of countries with roads and hospitals that don't take that much, when I go to poland or other central european countries it feels like a upgrade, most people own their place, working pays in a way that your encouraged to work more, not less, hospitals are fine and much more accessible than in germany or france
Basix protection and basic law? Sure, far from an ideal model we would have in mind today, the comparison is against a completely "free" society as in much much longer ago.
> must sharecrop at least some of their land, and on sharecropped land, extraction rates are on the order of 50% (for basically nothing in return).
Uhm... so half of an unknown number? That's also an unknown number then, and the very concrete "50%" means nothing.
I'm only complaining about the TL;DR, the original article is great. After reading it, I think there is no good TL;DR possible. There is too much to consider, actually reading that link seems and unavoidable if one actually wants to know. Would someone in two hundred years looking at average income in the US today as the one or two sentence TL;DR have a useful picture of what life is like in the US today?
This reminds me of Zobrist hashing [1] in chess engines. In fact, if you split the sum into 256 columns (instead of 8) and set the prime to 2 for each column, I think it's essentially the same. I'd be curious to see some quantitative benchmarks and their results on performance + collision rates.
You can still draw arcs without sideways slipping. If you do out the math, you’ll see that a skater traveling in a circle has no sideways velocity, but does have sideways acceleration.
Thanks for making this! I got an invite to contribute some time ago but didn't have the time to put something together - it looks amazing though; I'll have to figure out something good next time.
I did think about that! However, I didn't like the idea of making the client side do work to make up for my own poorly-managed website. Forcing users to run code just to render some boring text seems like a waste.
> However, I didn't like the idea of making the client side do work to make up for my own poorly-managed website.
If you set the bar to "0% JS at all costs" then you can't very well complain about how hard it was to maintain HTML.
Part of the standards, whether we like it or not, is JS. A sprinkling of JS (say, 60 lines?) to do client-side includes does not in any noticeable way increase the workload of the client, nor deteriorate the experience of the user.
After all, you provide a CSS file, right? The JS to do client-side includes using a custom element (so that `<client-side-include remote-src="...">` works) is unlikely to surpass a modest CSS file in terms of size.
The argument is not to never use JS. The argument is that you shouldn't unnecessarily use JS in a way that breaks core functionality if it is disabled.
There is no actual need solved by using client side include to load a nav bar. Doing so will break navigation on your blog for people without Javascript enabled.
Even though it isn't talked about as much these days, progressive enhancement is still a really good idea.
There is no actual need solved by using client side include to load a nav bar.
i am maintaining a site by hand right now. i am fine with copying from a template to get the structure. styles and formatting should be CSS anyways. navigation is the only thing that is a problem. i'll either figure out if i can do navigation in CSS or i'll end up having to use javascript. client side include in html only is the very thing missing here.
> There is no actual need solved by using client side include to load a nav bar.
I disagree: this[1] was such a dealbreaker that it caused the developer to literally switch stacks to get back the same feature.
When you find yourself switching stacks to get some feature, trust me, it's really needed.
> Even though it isn't talked about as much these days, progressive enhancement is still a really good idea.
Sure, and in this specific case all the dev had to do was include a link in each blog post to the root of the site `<a href='/'>home</a>`.
So when the JS is turned off the user can still navigate.
Once again, I am going to point out that plain HTML+CSS+JS is conformant to the relevant specifications; when a user wants to to, for whatever reason, deviate from the specification, they already know that most things won't work for them anyway!
IOW, you're not dealing with a clueless user who will wonder why the page has no navigation, you're dealing with someone who spent extra work and effort to get into the state they are, so they're already aware that most things don't work for them anyway!
But you responses throughout this thread is working on the assumption that megabytes of JS is required if you want client-side includes, and you coupled that with an implication that only incompetent developers would go down that route.
I can assure you, as a competent developer, that adding client-side includes with graceful degradation is maybe 60 lines of JS, cached, with no noticeable delays for the user.
If you think that the only options are a) Doing a full SPA with megabytes of JS, or b) No Javascript whatsoever, then I think that you're in no position to be calling other developers incompetent or lazy.
> this was such a dealbreaker that it caused the developer to literally switch stacks to get back the same feature.
Client side includes would have solved a small part of the pain points that were listed in the article.
This is a developer who explicitly didn't want to add javascript. Compromising a design goal, especially for a hobby project, to only partially solve your pain points, doesn't seem like a good trade off.
> Once again, I am going to point out that plain HTML+CSS+JS is conformant to the relevant specifications; when a user wants to to, for whatever reason, deviate from the specification
Disabling javacript is not a deviation from any specification.
> But you responses throughout this thread is working on the assumption that megabytes of JS is required if you want client-side includes, and you coupled that with an implication that only incompetent developers would go that route.
I never said either of those those things. I said "lazy" and I never implied anything about the size of javascript required for client side includes.
I never used "SPA" in my response to you I used it in response to this:
>> Personally I think it's better to distribute the workload across clients. We'll probably see purely client driven UI's dominate the future.
This is not advocating for thin client side include. This is arguing for a world where everything is an SPA.
> If you think that the only options are a) Doing a full SPA with megabytes of JS, or b) No Javascript whatsoever, then I think that you're in no position to be calling other developers incompetent or lazy.
Not only did I never say such a thing, but it is pretty darn clear that I don't hold such a view since you quoted me in your comment as advocating for progressive enhancement, which generally isn't a SPA but uses some javascript.
You should take a breath and try reading things more than once. You've repeatedly put words in my mouth and done so with some oddly aggressive language
Hmm - what is the actual cost incurred by the users here? Mostly battery right? Is that not virtually inconsequential to each individual?
I mean you could sum it all up and compare it to human-hours or something but that's not a useful metric because it's distributed.
Personally I think it's better to distribute the workload across clients. We'll probably see purely client driven UI's dominate the future. Imagine users being able to display data (because fundamentally that is all a blog [or any site] is) in a way chosen by each user. That would probably be worth the extra cycles on device.
> Not to mention the issues you create for battery life, network traffic, caching, etc just because you are too lazy to develop properly.
This is a very uncharitable take.
It's because I know how to develop properly that I want to send the repeated content of the site to you just once; the header, topnav, lhs-nav and footer will be cached if JS is enabled. The cost of that JS is less than the common elements anyway!
It's funny. Further up in this discussion is someone sharing their demo of using XSLT to dynamically assemble a page from parts. This process properly caches the fragments as well. No JS required, just the default rendering process for the browser. But XML+XSLT is the "red-headed stepchild" that everyone seems to hate.
Writing a SPA just to recreate the built-in functionality of rendering a static page on the client side is overkill IMHO. If it's an actual application (the A in SPA), then fine. But for what is essentially a static website... why?
I mean, I've used XSLT plenty in my career and I honesty don't have any issues with it at a high level. It's essentially just another templating format with the added benefit of being a markup language itself and being rendered directly by browsers without adding any JS.
So, I think perhaps you are confusing me with the person further up in the thread. They said "don't use a SPA". You replied with a counter argument about JS. Then *I* pointed out someone else in the thread demonstrating using XML+XSLT to to client-side rendering and I called out people using SPAs to dynamically render what is essentially a static website. So "Your take is getting more and more uncharitable" seem to assume that the GP and myself are the same, and we are not.
Your last line seems overly aggressive and confrontational. I have zero desire to engage with that.
You need to quantify before you say it's an issue. Eg. if the battery cost is 0.001% vs 0.0011% it's not actually an issue, despite technically being more expensive.
In this case, users with JS disabled would miss out on loading, what, a navbar and footers?
And fuck off with "too lazy to develop properly." I am so tired of HN users constantly talking shit about JS. There are times to fight for efficiency but this is just part of a tired crusade.
>what is the actual cost incurred by the users here?
Time.
Every bit of JavaScript is more time to download, execute, and then render the page. Time is a valuable resource, users appreciate not being told to waste it.
>I think it's better to distribute the workload across clients.
The bulk of such loads should and ideally must be on servers, not clients. Use PHP, not JavaScript.
Also worth noting, the biggest motivator for JavaShit by far is the website owner(s) cutting costs. More load on the clients is more idling of the servers, the consequences of this will be homework left for the readers.
Cargo currently has `cargo tree`, which prints out a dependency tree. There's an extension to cargo which also shows how many people have the ability to push to your dependencies, titled `cargo-supply-chain`.
The problem is not YouTube, but the law. The DMCA requires that online service providers (YouTube, Reddit, etc.) comply immediately with any takedown request and without question, so long as it meets sufficient conditions.
YouTube's copyright system has little to do with DMCA. Music right holders managed forced YouTube to implement a copyright claim system that explicitly didn't involve DMCA takedown requests. As a result any protection that DMCA provides to recipients of takedown requests don't apply to YouTube copyright claims.
In effect, the YouTube copyright system is a purely "voluntary" system for taking down copyright content, that goes way beyond the DMCA. It's basically designed to ensure theres no possible repercussions for issuers of copyright claims, even claims clearly made in bad faith.
You’re conflating the two systems. YouTube does have the Content ID system, which does automatic detection and is mostly used to monetize (not take down) copyrighted content. But this case is a copyright strike, which means there was a DMCA takedown filed.
YouTube’s “three strikes” policy is their implementation of the DMCA’s “repeat infringers” requirement:
> has adopted and reasonably implemented, and informs subscribers and account holders of the service provider's system or network of, a policy that provides for the *termination* in appropriate circumstances of subscribers and account holders of the service provider's system or network who are *repeat infringers*
> dancing really connected people. I hope it becomes a thing again.
Social dancing’s demise has been greatly exaggerated! If you live in any moderately large city, there is almost certainly a swing dance scene, and you can find people doing social Latin (salsa, bachata) pretty much everywhere. My city’s swing dance club has a social every Sunday, with events on most Saturday evenings too.
I'm quite surprised by the impression in the first place, since "dancing events" as a way to meet others and connect seems more ubiquitous than ever to me.
It may not look much like typical social dances performed with a partner, but I'm definitely thinking of clubbings, raves and festivals as happenings were "dancing connects people" - and it's one of the primary ways almost anyone I know has been socializing, at least throughout their 20s and 30s.
Is it just me, or does the README have the ChatGPT accent? For instance:
Whether you're looking to replicate your hometown, explore urban environments, or simply build something unique and realistic, Arnis offers a comprehensive toolset to achieve your vision.
I don’t have a lot of issues with people using LLMs to generate documentation, but it does seem to have a lot of nothing-sentences.
A legitimate question for me would be is documentation made to be read or to be written and what is the appropriate trade-off in energy invested? I might write a one off email to an individual, a email to a big audience or a presentation to the board. All three get different levels of attention. From little, to there are layers to this text nobody would expect (perhaps mostly for my enjoyment).
You’re right, and this is unfortunately becoming very common on GitHub, even for otherwise great projects.
Good technical writing is concise and tells you what you need to know as directly as possible. ChatGPT written documentation always reads like bad marketing copy.
Arnis uses OpenStreetMap data and Rust to generate Minecraft worlds based on real-world geography and architecture.
It processes large-scale data to create accurate cities, landmarks, and natural features in Minecraft, making it easy to replicate real places or design realistic environments.
That sentence just doesn't need to exist at all. The nature of the tool is already covered. I don't think there's a reason to tell people that they could use it for this, that, or the other thing.
