mort96

I mean yeah, but other languages don't make it quite so easy to make this mistake. Once your Go project gets to a size where it makes sense for different files to live in different folders (which, given Go's folder-based module system, often happens at just a couple hundred lines of code), the most straightforward way which the tooling nudges you towards means putting GitHub URLs (or URLs to whatever git host website you happen to use) in your source code.

I mean "input files, a build step, output files" is the trivial part of this. I've made my own build systems which work the same way, it's not especially hard. But if you wanted to use my build system to make a Linux rootfs you'd find that to be a monumental effort since you'd have to do everything yourself.

It's everything built around the build script language that's relevant. How easy is it to make a Nix config which produces a rootfs with systemd, glibc, coreutils, an OpenSSL server, pam, a dbus broker, the necessary getty services, etc etc etc which makes it a Linux system? That's the question I'm asking.

The huge boon of Yocto is that it solves the Rockchip-proprietary parts. And the Qualcomm-proprietary parts. And the IMX-proprietary parts. It has BSP layers which you can add, you can use either e.g Rockchip's official Yocto BSP which focuses on doing things their way + using a vendor kernel or you can use the Yocto project's community Rockchip BSP which focuses on doing things the Yocto way + using upstream.

Even devices which are supported by mainline Linux + uBoot have their own ways you have to do e.g partitioning or what needs to be in Flash. Lots of Rockchip devices are perfectly supported upstream, but their boot process expects to find a tiny loader at a particular flash offset which can then jump to uBoot. Nothing in the ARM SBC world is standardized so everyone does things like this (tho some have partitioning schemes you need to follow instead of using offsets). That's stuff you can't really ignore if you want to be relevant in this space.

Is Nix really appropriate for building a complete rootfs? Could I start from scratch and write a nix build script or whatever and end up with a rootfs I could run on some aarch64 SBC or SoM?

And how is the Nix story for going from a rootfs to a bootable image? On e.g Rockchip you need to make an image where there's some firmware blob in one are of the flash which jumps to a uBoot in another area which loads the kernel/initramfs/devicetree, how does that look in Nix land?

How does it handle building vendor kernels or carrying kernel patches instead of mainline?

What political system do you propose where wealth doesn't confer some political power?

I mean that's probably a perfectly nice solution too, it doesn't all have to be as physical controls on a center console. It just needs to be easily accessible physical controls which I can interact with through feel without taking my eyes off the road. As long as it's not on a touch screen and not those shitty haptic capacitive buttons I don't care whether it's on a steering wheel or on a center console

That's the entire modern, Tesla-inspired design ethos: remove all knobs, remove all buttons, remove all levers, remove the PRNDL, remove all the gauges, replace it all with controls on a big iPad in the center, and call the spartan interior "high-tech"

It's not even "concept car from 2035", it's "concept car from 2015 trying to look like a car from a sci-fi story set in 2035"

And I agree. People like normal cars, people like normal door handles, people like A/C and heater knobs, people like PRNDL levers. None of that has changed just because the drivetrain uses a different kind of engine. Why is it so hard to make that, but electric? Why does "electric motor" somehow mean "all controls must be on the iPad"?

I hope it's just a phase that's about to reverse. Maybe they felt the need to go all futuristic design to cash in on how electric drivetrains used to feel futuristic. Maybe, as electric drivetrains just become "normal, boring" technology, we get options with normal designs too.

"Consumers don't want EVs" is an absolutely insane take. You're disqualified from this discussion.

Because obscene levels of wealth disparity makes everyone worse off. Power is a zero sum game.

If I were offered to double your real wealth but also double Bezos's real wealth, of course I would take that deal! I would benefit from it. But if you offered to double the real wealth of everyone, what would that even mean?

You were trying to argue in favour of Georgeism weren't you? If not .... what point are you trying to make exactly?

I believe they described a system in which only natural resources are taxed. That's how I read "Georgeism but applied to all natural resources, not just land value". Income is not a natural resource which is why I asked them how they think it should be taxed, if at all.

I don't have exact numbers for what "a reasonable level" is off hand, but "a heck of a lot lower than now" would be a great start.

Again, the onus is on you to describe a mechanism by which abolishing most forms of taxes will drastically reduce wealth discrepancy. I'm not arguing against LVT, you're the one who's arguing against everything that's not LVT.

Then they can clarify which other taxes they support.

The comment advocates for Georgeism. If they disagree they can say so and elaborate on which non-LVT taxes they support. They haven't because my read on them is correct.

"Fixing" means reducing economic disparity to some reasomable level.

What if your only relationship with land is that you rent an apartment, but from that apartment you build a $10M/year revenue social network? How should that be taxed? Should it at all?

I never said communist. But yes, you can pick and choose ideas from different thinkers. That said, what Nevermark wrote fits squarely within orthodox Georgeism.

They're free to prove me wrong by saying that they're in favour of sales tax or income tax or capital gains tax. That would prove to me that they're just taking the idea that "land value tax is good" without buying into Georgeism as a whole. But I'm confident we'll never see such a comment.

My understanding is that Georgism opposes the kinds of tax you mention.

If I start espousing the great ideas of economist Karl Marx in a long comment I will forgive you for assuming that I may be a bit of a Marxist unless my comment has clear caveats to the contrary.

I don't mind land value tax! Like you, I think it's one of many valid kinds of tax that a government can put on its citizens to achieve various social goals. Hence, I am not a Georgeist.

That's what Georgeism is?

The onus is on you to describe some mechanism by which abolishing almost all taxation will magically fix wealth discrepancy.

We're in a situation where it's already "too late". We can't go back 100 years. How do you propose we fix it, assuming time machines won't get invented soon?

Design bugs are still bugs

You don't think MercadoLibre has job postings open all the time just to replace the people who are leaving? They're around 120 000 people, is each of those people hand-picked for a particular position and not just hired because they know they need to replace some percentage of workers who'll leave?

This depends a ton on if we're talking about a company's own website's job listings or if it's on some dedicated job listing site.

> At a large enough company you continuously lose people for natural reasons, like retirement, moving for a spouse, moving to be closer to family. Past a tipping point you're just always hiring.

As an analogy it's kinda like hard drives: when one of my hard drives dies, it's An Event which I need to deal with specifically; I need to order a replacement for that specific drive. At Google's server farms, hard drives dying is just a statistic, you continuously buy hard drives just because you know existing drives are gonna die at some semi-predictable rate.

It's not really like that, it's more that it slurps up individual instructions, executes some of them just in the front-end via register renaming and dispatches the rest to available execution units, then retires them as the execution units are done. Sometimes it fuses together a couple of instruction (macro-op fusion) but my understanding is that that's much more limited, like fusing "compare then conditionally branch" sequences into single compare-and-branch μops

It's clearly an unintended interaction. Nobody intended for the telemetry switch to control whether it reads AGENTS.md (hence mpoteat's apologetic response). Whether you consider that to be a "bug" or not really wasn't the point of my message.