Open devices will be way costlier too. That's the price of letting these demagogues get away with such abuses. Should have rubbed it in their faces.

... and adding docker-compose for running dev DBs/services ...

If you're into that sort of setup, you might appreciate testcontainers.

I looked at the post again and they do talk about recursion for looping (my other reply talks about map over an iterator). Languages that use recursion for looping (like scheme) use an optimization trick called 'Tail Call Optimization' (TCO). The idea is that if the last operation in a function is a recursive call (call to itself), you can skip all the complexities of a regular function call - like pushing variables to the stack and creating a new stack frame. This way, recursion becomes as performant as iteration and avoids problems like stack overflow.

The egregious part in this is that Google presents RCS as an open standard to get carriers to adopt it. But then they retain enough control to exert their power over users like this. The same happened with Android. I don't know how long such exploitation is tolerated before such aggressors are split up into a thousand competing businesses.

Peter Thiel is insolent enough to say out loud what these companies practice - 'competition is for losers'. These quasi-monopolies aren't here to provide the best value - quite the opposite. They want to kill all competition by any dirty tactic and then use the diminished choice to wring the customers of every penny they have. They want to extract maximum revenue by making sure that their inferior solution is the only option customers have.

This problem isn't solvable by market regulation alone. The world has enough a*****es around who will climb to the top of successful companies and find ways around the regulations. They're being as bad as they can, while skirting the limits of what's illegal. My main gripe is with the engineers, programmers, technicians and all technical creators who enable these scumbags. It's not hard to see that supporting a proprietary solution amounts to yielding the consumers' bargaining power to a monopoly. Despite that, they keep making these choices. For example, it's not uncommon to hear senior engineering managers or technical-lead level employees saying, "I know that Chrome is spyware and I want to quit it. But this works only on Chrome". I feel like screaming at them that if they're too incompetent to demand a change at the level they're at, they're in the wrong profession.

If you're a technical creator, your choices matter. It affects a lot more people than you alone. But more often than not, I see such creators surrendering principles in exchange for convenience. They hold as much responsibility as the market-abusers in making the world the way it is now.

We don't ask for forums because we don't want features of Discord. We ask for forums because we want features that Discord does not offer:

1. Ability to search the discussions from a web search engine
2. Proper segregation of threads - a question followed by related replies (similar to github discussions, issues and PRs)
3. Ability to back up the discussion history, so that it doesn't disappear if the server goes down.
4. Ability to operate unimpeded if the silo operator decides to monetize the information by holding it hostage.

Note: Privacy is not what we need here. We need the solutions to open source problems to be public - especially, searchability.

Linus does that only to experienced guys - not beginners. People who should know better.

Just dump Google's browser and all their services. They are not necessary to make use of the internet.

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.

The danger is the same as WEI or Play Integrity. Apps may refuse to work if the attestation fails. What do they gain from it? I don't know. But what is the purpose of banking apps checking if the device is rooted or not? They work without it on laptops.

Exact same story here. Bash -> Python -> Rust.

Generally speaking, people should settle on a compiled language if they can. They can iterate as fast as interpreted languages these days.

Edit: If you want to try something different in scripting, try the execline language. Its interpreter processes the script and exits immediately even before the script execution begins. Traditional shell interpreters (like bash) stay active till the entire script is finished. Execline achieves this by a clever chaining of Unix execs, forks and variable substitutions. This makes execline scripts lighter (useful in embedded systems), more secure and less error-prone than traditional scripts. The downside is that writing them will feel a bit weird - since the fundamental paradigm is different from regular shells. However, that will be a refreshing change if you're someone who likes to experiment and try new things.

Git is a hack that was created by a bunch of kernel hackers with a UI that wasn't originally meant to be the final user-facing UI. If you have done what the kernel devs do, you would understand git. That includes:

• Taking snapshots of the source tree (perhaps as a zip or tar), along with a file that indicates what snapshot was for, you understand trees.
• Applying patch queues (with something like quilt), you understand commits, rebasing and cherrypicks.
• Reversing a patch - you get reverts.
• Modifying a patch - you get commit amends.
• Do a 3 way merge - that's a git merge.

There were a whole bunch of ad-hoc kernel dev operations that got consolidated in git. Honestly, a similar tool should rethink the design to be more intuitive, orthogonal and have fewer concepts that cover all use-cases. (No. xkcd doesn't apply here. Git does everything. It just needs a better design).