TechNom (nobody)

Choosing Rust instead of C or C++ for new projects is a rather light decision. But introducing it into or outright replacing legacy codebase with it is a rather phenomenal undertaking. Fish shell was completely rewritten. Linux is introducing it in no trivial way. I wonder if the woes with C/C++ is that bad.

Is there an article I can refer to? This isn't an easy topic to search for.

Until you start seeing its reviews. Or else, you should try using it for data you can afford to lose (unimportant or backed up) - which is what reviewers would be doing anyway.

It's still missing the send and receive features from btrfs. And while they say it's more stable than btrfs, it's yet to prove itself (through widespread use), and is marked as experimental in the kernel config.

This is an old post and a lot has changed since then. Many of the points in that article are no longer true. Drew himself started a language - hare, for which he is considering Rust style borrow checker to ensure safety. It's a bit wrong to bash anything based on a half a decade old opinion.

I’m curious, what tools are you talking about?

My fav ones are b4 and lei - both backed by a system called public-inbox. Linux kernel Lore is a public-inbox instance. There are other tools too - like patchwork. B4 and Lei, for example make working with patch series a breeze. You can also do things like compare different versions of the same branch - something that Github PR model is sorely lacking in.

What is happening here? Where is the patch?

That's what public-inbox and patchwork are for. Lei is especially useful with public-inboxes. If you are a bit more established, there are tools like notmuch and aerc that can make it even more easier.

Is each email a commit?

Yes, that's the idea. But more specifically, each email is a patch. Usually, a single patch is a refined commit with a full feature that you get after proper rebasing to weed out experimental code, mistakes, etc. A single submission is often just one or a handful of patches.

Where at the comments on the patch?

You don't deal with patches and emails manually that deep. You only need to have a rough awareness of the location of the patches (lei, notmuch, etc help you with this awareness). Code review mails and discussion mails are often threaded and intertwined with a series of patches. Threading actually helps you to follow the correct flow of discussion. Think of mailing lists as PR, Issue tracker and discussion forum rolled into one. You wont be hunting patches in this haystack. That's the job of the tools - they extract the correct series of patches in the right order, ready to be applied. Some can even alert you to the presence of newer revisions of the patch series. (I'm not even sure how far this goes - I haven't tried patchwork yet). There is actually a lot of automation involved.

but mailinglists are even worse

Even if they decided to keep mailinglists, they could at least put on a better UI

Frankly, here is the problem! All the other problems you mentioned boils down to this. The thing is - Github and Mailing lists deal with the same kind of data - with the latter being more transparent. But the mailing list interfaces are god-damn awful. But honestly, it doesn't have to be like that. I believe that with some proper UI design, mailing lists can offer an experience that's at par or even better than GH PRs. All the noise and clutter you mentioned doesn't need to be there. The tools make all the difference. Webmail clients like Gmail just butcher the mails. But it's already much better when you have a text-only threaded mail client. I believe people hate email workflow just because of how badly its interface is designed.

Mailing lists aren't that hard if you have the right tools. For most people, it's just a few lines of configuration. But there are a lot of hidden tools for emails that you simply don't get with PR workflow. You'll get very attached to them once you start. That's the reason why many kernel devs are so attached to emails.

Torvalds indicated in a recent interview that they're struggling to find young maintainers. Many people contribute, but few stay around to become proficient enough and take on the responsibility of maintainership. I believe that the email comment was made in this context.

However, I don't think that many kernel devs including Torvalds are in favour of the Github workflow. He once indicated his strong dislike for it. So the replacement for email won't be Github - but something just as easy, without sacrificing the quality that the kernel devs need.

Finally, a word is kernel development. Contrary to popular belief, they aren't hostile to new contributors. Kernel developers have high quality intro material for newbies - including for email workflow. They're also very considerate and patient with newbies. Even Torvalds who was known for his abrasive style in the past really took that only on experienced developers doing the wrong thing.

I mean, if it's a one time payment then he has no reasons to regret the decision even if the users dropped off. On the other hand, if he was expecting a recurring royalty from the buyer, then he didn't think it through.

PS: I'm not justifying his actions in any manner. If a sale without a heads up is deceptive, his last reply was outright indignation. I'm just trying to understand whether he actually regretted it or not.

I thought it was a one-time payment.

But calling that doff is misleading.

Git actually uses diffs behind the scenes a lot - 3-way diffs/merges to be more accurate. Merging, rebasing, cherry picking and even reverting are all 3-way diff-merges.

Mercurial took an interesting approach here. It stores commits as diffs with occasional snapshots in between. This is similar to how video codecs store frames as deltas with occasional full 'keyframes' in between. This is the way Mercurial blunts the diff-replay problem you mentioned.

Git AFAIK, stores each file modification as full snapshot, until it is packed at some stage. Mercurial doesn't need this work around. Mercurial diffs are also format-neutral. It works fine with binary data.

Git is a lot of things at once:

1. A tool to record development history - warts and all
2. A tool to create a logical sequence of changes
3. A tool to communicate intent and ideas to a maintainer

Meaningless messages like minor and . don't suit any of these roles - not even 1. Even when recording development history with all mistakes, you'd still need context when you look back at the history. Matklad is a well respected developer. I wonder why he's make such a bizarre claim.

You might want to have a relook at your own statement here. It's got a load of paranoia. Paranoia beyond common sense and realistic threat assessment is unhealthy.

As for the NSA, it's like they have a split personality (which I think is true for anyone in their position). Their job isn't all about stealing information. They also have the mandate to secure their own and their allies' assets. After all, who knows what's more vulnerable to thievery than an experienced thief? Their job is as much to harden security as it is to compromise.

Finally, their statement is to move to a safe language - one of which is Rust. For your apprehensions about their backdoors to be true, they'd have to compromise every memory safe language out there - Rust, Go, Swift, Nim.... There's reason to be suspicious if they recommend only one language (that is more or less what happened with the NIST pseudorandom generator algorithm). But that isn't the case here.

And you need to assess statements on their own merit - not based on who says it. What they say is true even in our personal experiences. It's been shown statistically that people write much fewer bugs (memory safety bugs are a huge class) with safe languages. I'm not even confident of writing correct C programs these days. Honestly, if your paranoia is true, then it's easier for the NSA to recommend everyone to write in C or C++. That way people will write careless mistakes that they can exploit. And C/C++ usage is way more than for Rust or anything else. They'd target C/C++ compilers and standards to increase their impact.

It could in theory, be a faster way to checkout a different branch. Switching branches is a lengthy operation that involves a lot of deletions and replacements in the working tree. A fuse mount would simply be a rendering of the tree object. It doesn't need to do anything until something is accessed. Even then, it would simply be a rendered view of a blob in the repository.

I don't think you mean 'merge' - that's a specific operation. I think you mean 'squash', which combines multiple commits into one. 'Fixup' is also something similar.

Git allows you to edit history in any way you like. The hardest is probably splitting a commit into multiple smaller ones. It requires you to edit a commit by resetting the HEAD and making multiple smaller commits before continuing with the rebase. Though it sounds complicated, it becomes easy enough after you try it a couple of times. You should check out git-rebase.io - a site dedicated to editing git history. You can learn to craft proper commits of high quality.

Once you get familiar with rebasing, you could try out stacked git. Interactive rebasing looks weak in comparison to what stgit can do. Stgit allows you to edit history like rebase. But that's the least of it. It allows you to create proper commits from the start, rather than by editing at the end. In some ways, stgit gives you multiple staging areas - giving you incredible flexibility.

I use both separately. But the Linux kernel developers seem to use both together. I don't know what criteria they use for each.

All the companies that recently switched their products from open source licenses to non-free source-available licenses (like BSL and SSPL) were companies like this that offered hosted services. Their argument was that the big cloud companies were using their product to make money and causing them to lose business. Should we worry about a similar future for gitea?

It may be premature. But this is the gitea's second move in that direction, after transferring the project's control to a crypto-based for-profit company. Was Codeberg e.V (the nonprofit behind forgejo fork and Codeberg) justified in doubting gitea?

The realization that Windows was stealthily making dozens of internet connections. I don't know what they were for and there was no reasonable way to disable it.

I'm an evangelist so far as to recommend people to switch to Linux or BSD. But people always find some reason to stay on Windows - "I will switch when Linux starts doing ". (Not gaming). It often feels like they're searching for a problem to justify not switching. I don't bother fighting with such people.

I'm obsessed with modifying Linux to my liking. Programming was another one of my reasons for switching. These days, I program components of my desktop to suit my needs.

Facebook for all its nastiness was very much incompetent in influencing the direction of the web. Look at their failed attempts like free basics.

Google on the other hand has the web tightly in its dirty grip. At this point, they aren't even pretending to be nice. Even those plans that cause them reputational damage are brought back in some other name.

The only way to stop Google is for the regulatory agencies to put their foot down hard. They should be divided into at least a couple dozen companies that are not allowed to do business with each other.