> The amount of work in mining is way higher than is required to prevent another party from being able to overwhelm the Blockchain.
Isn’t that exactly the point? Bitcoin incentivized wasting resources. It is, according to your own comment, unnecessary to use so much computing to keep bitcoin going. But it’s being used.
If Bitcoin were worth much less the network would still be secure even though the mining reward would only be enough to pay for a fraction of the current processing.
If Bitcoin does not double in value every four years, the mining reward will reduce in real world terms.
Claiming the mining resources required will be at the current level or higher perpetually requires also making the claim that you think that the value will increase exponentially forever.
As an example, what about a divide instruction. A machine without an FPU can emulate a machine that has one. It will legitimately have to run hundreds/thousands of instructions to emulate a single divide instruction, it will certainly take longer.
Thats OK, just means the emulation is slower doing that than something like add that the host has a native instruction for. In ‘emulator time’ you still only ran one instruction. That world is still consistent.
? That's not how Windows on ARM emulation works. It uses dynamic JIT translation from x86 to ARM. When the compiler sees, e.g., lock add [mem], reg presumably it'll emit a ldadd, but that will have different semantics if the operand is misaligned.
How will you ever get the network effects needed to get sustained users with a commercial tool?
Given Git was created because BitKeeper, a commercial tool, pulled their permission for kernel developers to use their tool aren’t we ignoring a lesson there?
Literally true if it's that one guy you're talking about.
Also, you should hear Linus talk about building git himself, what he built wasn't what you know as git today. It didn't even have the commands like git pull, git commit etc until he handed development over.
Uhh, to be fair, if the goal was only to recreate git from 2005, it probably wouldn't cost $17M. I'd hazard a guess that they're recreating modern git and the emergent stuff like issues, PRs, projects, etc. I've also heard that the core devs for git are essentially paid a salary to maintain git.
I'd be 1,000x more interested in a project with the official git maintainers' buy-in to leverage the alleged power of LLM development to bring all git's features into libgit2 (or whatever, but that's a starting point) and switch git itself over to using that as its backend.
I've twice in my career found reasons that git being (officially; I have no interest in dealing with another implementation with its own missing features and distinct bugs) a library instead of a messy ball of scripts and disparate binaries, would have saved me tons and tons of time. You can look at the stories of how Github was designed and built, or look at the architectures of other similar software, and see folks struggling with the same issue. You'll run into frustration on this front pretty much instantly if you try to build tooling around Git, which turns out to be such a useful thing to do that I've ended up doing it twice in ~15 years without particularly looking for reasons to.
(While we're at it, how about some kind of an officially-blessed lib-rsync with a really pleasant API?)
Thinking it for bit it comes to "what comes after Git" and what does "Git" mean there.
To build better tool than git, probably a few months by tiny team of good developers. Just thinking of problem and making what is needed... So either free time or few hundred thousand at max.
On other hand to replace GitHub. Endless millions will be spend... For some sort of probable gains? It might even make money in long run... But goal is probably to flip it.
No he didn’t. He built a proof of concept demo in 7 days then handed it off to other maintainers to code for real. I’m not sure why this myth keeps getting repeated. Linus himself clarifies this in every interview about git.
His main contributions were his ideas.
1) The distributed model, that doesn’t need to dial the internet.
2) The core data structures. For instance, how git stores snapshots for files changes in a commit. Other tools used diff approaches which made rewinding, branch switching, and diffing super slow.
Those two ideas are important and influenced git deeply, but he didn’t code the thing, and definitely not in 7 days!
Those were not his ideas. Before Git, the Linux kernel team was using BitKeeper for DVCS (and other DVCS implementations like Perforce existed as well). Git was created as a BitKeeper replacement after a fight erupted between Andrew Tridgell (who was accused of trying to reverse engineer BitKeeper in violation of its license) and Larry McVoy (the author of BitKeeper).
I agree and that’s the point I was trying to make.
Linus’s contribution is a great one. He learned from prior tools and contributions, made a lot of smart technical decisions, got stuff moving with a prototype, then displayed good technical leadership by handing it off to a dedicated development team.
That’s such a good lesson for all of us devs.
So why the urge to lie and pretend he coded it in a week with no help? I know you’re not saying this, but this is the common myth.
He did what needed to be done. Linux similarly has thousands of contributors and Linus's personal "code contribution" is almost negligible these days. But code doesn't matter. Literally anyone can generate thousands of lines of code that will flip bits all day long. What matters is some combination of the following: a vision, respect from peers earned with technical brilliance, audaciousness, tenacity, energy, dedication etc. This is what makes Linus special. Not his ability to bash on a keyboard all day long.
The parent comments are arguing that 17million for git 2.0 is insane because Linux wrote the original in a week.
Except that’s not true. He sketched out a proof of concept in a week. Then handed it off to a team of maintainers who worked on it for the next two decades.
It’s also not pedantic because Linus himself makes this distinction. He doesn’t say he coded Git and specifically corrects people in interviews when they this.
Specifically, VHS had both longer recording times and cheaper VCRs (due to Matsushita’s liberal licensing) than Betamax did. Beta only had slightly better picture quality if you were willing to sacrifice recording length per tape. Most Betamax users adopted the βII format which lowered picture quality to VHS levels in order to squeeze more recording time onto the tape. At that point Betamax’s only advantage was a slightly more compact cassette.
Also to correct another common myth, porn was widely available on both formats and was not the cause of VHS’s success over Betamax.
It depends which definition of "better" you use. VHS won the adoption race, so it was better there. While Betamax may have been technologically superior, in hindsight we can say it apparently failed to address other key aspects of the technology adoption lifecycle.
So perhaps this is a regression specifically in the arm64 code, or said differently maybe it’s a performance bug that has been there for a long time but covered up by the scheduler part that was removed?
Turns out the amd machine had huge tables enabled and after disabling those the regression was there on and too. So arm vs amd was a red herring.
Of course not a nice regression but you should not run PostgreSQL on large servers without huge pages enabled so thud regression will only hurt people who have a bad configuration. That said I think these bad configurations are common out there, especially in containerized environments where the one running PostgreSQL may not have the ability to enable huge pages.
That should be obvious to anyone who read the initial message. The regression was caused by a configuration change that changed the default from PREEMPT_NONE to PREEMT_LAZY. If you don’t know what those options do, use the source. (<https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...>)
Yes, I had a good laugh at that. It might technically be a regression, but not one that most people will see in practice. Pretty weird that someone at Amazon is bothering to run those tests without hugepages.
I doubt they explicitly said "I'll run without huge pages, which is an important AWS configuration". They probably just forgot a step. And "someone at Amazon" describes a lot of people; multiply your mental probability tables accordingly.
The number of people at Amazon is pretty much irrelevant; the org is going to ensure that someone is keeping an eye on kernel performance, but also that the work isn’t duplicative.
Surely they would be testing the configuration(s) that they use in production? They’re not running RDS without hugepages turned on, right?
> The number of people at Amazon is pretty much irrelevant; the org is going to ensure that someone is keeping an eye on kernel performance, but also that the work isn’t duplicative.
I'd guess they have dozens of people across say a Linux kernel team, a Graviton hardware integration team, an EC2 team, and a Amazon RDS for PostgreSQL team who might at one point or another run a benchmark like this. They probably coordinate to an extent, but not so much that only one person would ever run this test. So yes it is duplicative. And they're likely intending to test the configurations they use in production, yes, but people just make mistakes.
True; to err is human. But it is weird that they didn’t just fire up a standard RDS instance of one or more sizes and test those. After all, it’s already automated; two clicks on the website gets you a standard configuration and a couple more get you a 96c graviton cpu. I just wonder how the mistake happened.
No… I’m assuming that they didn’t use the same automation that creates RDS clusters for actual customers. No doubt that automation configures the EC2 nodes sanely, with hugepages turned on. Leaving them turned off in this benchmark could have been accidental, but some accident of that kind was bound to happen as soon as the tests use any kind of setup that is different from what customers actually get.
You're again assuming that having huge pages turned on always brings the net benefit, which it doesn't. I have at least one example where it didn't bring any observable benefit while at the same time it incurred extra code complexity, server administration overhead, and necessitated extra documentation.
It is a system-wide toggle in a sense that it requires you to first enable huge-pages, and then set them up, even if you just want to use explicit huge pages from within your code only (madvise, mmap). I wasn't talking about the THP.
When you deploy software all around the globe and not only on your servers that you fully control this becomes problematic. Even in the latter case it is frowned upon by admins/teams if you can't prove the benefit.
Yes, there are workloads where huge-pages do not bring any measurable benefit, I don't understand why would that be questionable? Even if they don't bring the runtime performance down, which they could, extra work and complexity they incur is in a sense not optimal when compared to the baseline of not using huge-pages.
> Yes, there are workloads where huge-pages do not bring any measurable benefit
I really doubt it, except of course workloads where you just use a trivial amount of memory to begin with. In systems I've seen, anywhere from 5% to 15% of the CPU time is spent waiting for TLB misses. It's obvious then that huge pages can be hugely beneficial if properly used; by definition they hugely relieve TLB pressure.
You can of course end up in situations where transparent TLB scanning is worse than nothing, but that's exactly why I pointed out there's a variety of ways to use huge pages.
You don't seem to understand the idea that CPU spending time on TLB misses and at the same time seeing no measureable effects in E2E performance because much larger bottleneck is elsewhere can be both valid simultaneously. In database kernels with large and unpredictable workloads, high IO and memory footprint, this is certainly easy to prove.
Isn’t that exactly the point? Bitcoin incentivized wasting resources. It is, according to your own comment, unnecessary to use so much computing to keep bitcoin going. But it’s being used.
reply