I'm pointing to this the next time someone thinks Hacker News is above celebrity tabloids.
“I'm now rocking an AMD Threadripper 3970x. My 'allmodconfig' test builds are now three times faster than they used to be, which doesn't matter so much right now during the calming down period, but I will most definitely notice the upgrade during the next merge window.”
AMD is Fender, Intel is Gibson
Also he should have got a AMD Ryzen™ Threadripper™ 3990X instead. 64 Cores / 128 Threads to compile the kernel in ~30 seconds.
- 22.48s, 3990X
- 23.64s, 3970X
- 27.54s, 3960X
But keep in mind that the 3970X is USD $2,000, while the 3990X is USD $3,990... can't speak for Linus but that extra 1.1s per compile isn't worth $1,990 to me.
https://www.phoronix.com/scan.php?page=article&item=3990x-th...
https://www.servethehome.com/amd-ryzen-threadripper-3990x-re...
s/sports team/company/g
[1] https://www.theverge.com/2016/10/18/13320664/bill-belichick-...
I think for the project leader of something like a kernel, which needs to care about the details of a CPU, it's entirely appropriate to set an example and remind people that they aren't building for a hardware monoculture.
With Linus I start to think of old writings he used to have about Alpha, or his prior employment at Transmeta (I know no details about it, would not be shocked if it was at least in part a PR move) ... If he's not willing to give some less common hardware a good sanity check, what example does that set for maintainers of various pieces?
Similarly, I remember the old stories about Stallman's free software MIPS rig. He ran that to prove a point that was important to him.
Mercurial should have won. And Plastic SCM is awesome, designed conceptually from the ground up to build on lessons learned from git (and by an Associate Professor in CS). In fact, the whole concept of DVCSs is ridiculous in 99% of corporate contexts where you can't use your laptop / desktop at home without logging in into the VPN. Why do we even need distributed version control in such a setting? Subversion is perfectly enough and even non-developer users can actually understand and use Subversion effectively. See https://svnvsgit.com/
Mind you, I'm not a blind hater: I love that Linus did well in life. I'd be thrilled if his net worth was a billion instead of just $150 million. Surely, he contributed much more than that.
I mean, many people had the exposure to bit git and hg at some point in their life - especially the kind of people who make decision which vcs to use. Celebrity endorsement may be good to convince me to try something, but it cannot convince one to use something over alternatives, if they had enough experience with both.
We looked at hg. I also dabbled in a few others. bzr, I believe was a popular one.
As said upstream. There are plenty of reasons that git "won." Most of them did seem technical. But, I could see things going many ways. For the most part, source control is not a problem most people think they have. Just look at how terrible the data science folks are? And management is stuck in whatever MS is doing in Word nowadays.
In particular, I have yet to see a successful collaboration that wasn't ridiculously ephemeral in data science or document creation, that wasn't backed by a much nicer format. (Where, ephemeral means that after it is done, it is referenced as PDF, but not directly anymore. Which, to be fair, is the majority of documents that exist in the world.)
I recently revisited an old Hg project. It was really nostalgic. Hg is easier to use and TortoiseHg is the best GUI for SCM bar none.
But Git is simpler. The simplicity is a mind-opener. Git deserved to win. When you want to do something in Hg that's not built-in - even something like rebase - all the 30+ included extensions are all marked as "EXPERIMENTAL" and you can only safely interact with the data model by writing a custom Python 2 script.
With Git you can go into the .git directory and delete a refs file. Filter-branch is a first-class feature. A few basic concepts underpin more functionality. There are genuine multiple implementations. This is radical transparency.
Originally I thought I would have missed having draft phases, embedded branch names, and ordinal commit numbers. But in practice I don't miss these at all. And in retrospect these all actively work against code-sharing in general, and the pull-request model specifically with its working revisions. Git is inherently more social-capable and will always have a stronger network effect. Hg does not have separate author + committer.
With Git you can stage individual lines, not just hunks. This alone should be reason to use Git over Hg (oh, you can enable the optional crecord extension and do everything from the CLI? that's not Hg's famed ease-of-use).
I once started to develop a Gogs/Gitea clone for Hg. For compatibility it had to communicate by IPC with a standalone Python process, then I hit a roadblock because the wireproto was undocumented for bundles. Hg developers were also not enthusiastic about my proposal to switch from full+diff storage to chunk storage.
I do miss some things. A central .hgtags file would definitely resolve some tag conflicts and issues with coworkers re-pushing deleted tags.
From spending half a day per branch copy, to releasing only a few times per year because branches are expensive, to never changing more than the minimum because can't branch-test a feature fast, to days of offline CI because bad merge on only dev branch, to keeping 3 copies of the entire repo to do backports because not easy to shift branch... SVN never again.
Yes, git “won” largely because it was “what the Linux guys are using” (and because github was better than bitbucket and other alternatives). It’s concepts can be painful to work with.
No, DVCS should not be ditched - the simplicity of repointing, rehosting, and working offline, that dvcs systems give us, should never be rolled back (and screw repo corruptions in svn and other crap). Just because a lot of people don’t rely on these features every day, it doesn’t mean they are not hugely beneficial to the ecosystem at large.
The hg command line options are far more sane than git. And TortoiseHg is the best gui ever
But I might switch eventually, when even bitbucket is dropping hg support. And many linux distributions stopped including a working tortoisehg.
In a world where "DVCSs is ridiculous in 99% of corporate contexts where you can't use your laptop / desktop at home without logging [sic] into the VPN", why (and what) should Mercurial, a popular DVCS, have "won"? (I don't mean in Mercurial vs Git)
DVCS isn't ridiculous. Especially in corporate contexts over a flakey VPN (like, say, if there were a global remote work experiment going on). Cheap local branching is an indispensable feature. So much so that if you're forced to use SVN, you can still get local branching via SVK or by using `git-svn`. SVN is still the right tool in a lot of places (anywhere there are binaries in play) though the overhead of being actively fluent in multiple VCSs at once isn't free.
The more people involved with building Linux use AMD hardware, the fewer AMD-only bugs find themselves into the kernel. It might also help with optimizing the software for higher core counts now that 32 cores without NUMA is feasible for workstations.
In the end I think parts of the core team switching to AMD will make the hardware platform more attractive for people browsing for workstations. AMD provides great value for money but if you want stability, you buy Intel. Now that probability of instability is decreased with major kernel developers testing out changes and encountering some of the same potential bugs, Threadripper becomes more attractive to certain groups of power users.
This is celebrity news that might affect a lot of people in their day-to-day business down the line, which is different from the typical "Paul Graham ate breakfast" or "Linus Torvalds flips off nvidia" celebrity news cycle.
Hopefully more people will purchase AMD as the result of this. Its financially figures are not good. ( As I have been saying in every AMD thread )