Martin’s already in the list of maintainers for another subsystem; this is a territorial play by Hellwig. Any kernel developer would recognize this; you don’t seem especially familiar with kernel social dynamics either! Also please fix your formatting if you’re going to copy-and-paste rather than linking.
Whose arguments are you apologizing for? Read the thread backwards. Your claims about C and kernel policy were wrong, therefore @pressanykeynow@lemmy.world’s point about multiple languages was right, therefore your main defense of Hellwig acting in good faith is unevidenced. So, are you still so ready to insist that Hellwig is arguing in good faith? Would you say that this thread has adequately discussed the technical details and is ready to return to the overarching political point?
I would recommend looking at English WP’s style guide on weasel words. Rather than matching evidence and countering claims, you’ve set up a nest of strongly-held opinions with words like “basically”, “personal experience”, “I believe”, “an opinion of course”, “it isn’t just me”, and refused to actually directly engage with the evidence scrutinized. Given that it takes maybe five minutes to find even just one piece of assembly that has no justification for not being written in C, I think that it’s fair to characterize your position as inconsistent with actual kernel-hacking practices at best.
It’s also relevant to note that, most likely, nobody here has the “kwalifikashuns” to discuss this topic. Not even programmers - because odds are that nobody here is in a position to change anything about it.
Literally any kernel hacker can change the kernel. This is the root of why you shouldn’t be in the conversation; you aren’t such a hacker, and you therefore imagine that none of us are, either. You’re not skilled as a sealion either, for what it’s worth.
Similarly, I hope that your technical leaders know that ActiveState has a fork of CPython 2.7 which is still receiving security patches, and also that PyPy for Python 2.7 is actively maintained and can improve the diversity and performance of your backend.
Man, some folks around here really make it obvious that they’ve never been yelled at by Linus in-person.
Both of your technical claims are wrong. C isn’t high-level assembly; on e.g. x86, it has no way to express SIMD, control I- and D-caches, or encode certain efficient instructions for which there is no corresponding idiom like Hamming weight (popcount). Also, the kernel does not have any sort of policy mandating a minimum of assembly, and there are definitely many spots where writing a compilation unit purely in assembly is done instead of using inline assembly to make the unit shorter and more readable.
I am not a programmer. … I’m a random with a chimp avatar. … It’s just that [Hellwig] prioritises consistency (for the sake of maintainability)…
Pick a side and stick to it. You seem very keen to endorse Hellwig’s arguments despite not understanding them, and also to emit words on the topic despite not having a qualified opinion. It sounds like you want me to not take you seriously (so that I won’t reply to you) and also take you seriously (so that you are counted as part of the programming public.)
I’m docking you again, this time for listening comprehension. Quoting Gaynor:
The common thread here is that for each of [six listed vulnerabilities exploited by nation-states against vulnerable minorities], the vulnerability that was executed … was only possible because of the victim’s software being written in a memory-unsafe language. Put another way, if the relevant portions of these projects were written in a safe language, these vulnerabilities wouldn’t have been possible.
That was early in the talk, around 6:30. Later, around 19:40, he says:
The Rust-for-Linux project is working to make it possible for people to write Linux kernel modules in Rust.
So, if you had watched Gaynor’s presentation, you would understand that Rust-for-Linux is a significant and prominent part of a wider push by security professionals to improve the overall safety of common devices, like Android phones, that are in the pockets of millions of people already. And then you wouldn’t be talking about respectability politics while apologizing for reactionaries who oppose that safety.
God doesn’t exist. God logically, provably, observationally, and theoretically doesn’t exist. What do you like about religion, anyway? The hate? The lies? The violence?
Your position is entirely reasonable and an excellent example of how ignoring technical details leads to failures of technical leadership. C is one of several languages notable for extreme lack of memory safety. Its lack of safety has been repeatedly quantified; I like to recommend Gaynor 2021 for a high-level introduction. Rust was introduced primarily to replace C (and a relative, C++) and improve the overall security of computing systems.
The “merits of the project Rust4Linux” are simple and obvious: as code is translated from C to Rust, its overall characteristics (readability, performance, low-level modeling of machine behavior) will remain, but overall memory safety will increase. Opposition to it is reactionary, not well-grounded in technical merits; most of Linux is not well-proven to be correct, only believed to be correct under typical operating conditions as estimated by several dozen experienced programmers, and any technical options for improving our confidence in its correctness should be considered.
Also, finally, I have to dock you for reading comprehension. Martin was quite clear: calling Rust a “cancer” – a cute pun given Rust’s crab mascot, or a dehumanizing slur, who knows – was, to them, a violation of the Code. It is not difficult to read the Code and notice that, were it a slur, it would violate the prohibition on “insulting/derogatory comments, and personal or political attacks.”
I’ve hacked kernel and I’ve listened to you; I don’t really think that your comments address the actual needs of the kernel. Also, both Christoph and Hector are kernel maintainers already; anybody who wants their responsibilities is welcome to match their level of contribution.
Like @devtoi@feddit.nu I use plain-text accounting (PTA) to manage a few bank accounts, including small businesses. In my case, I’m using hledger. Every time I get a receipt, invoice, or statement, I type it into a text file. My bank gives me CSVs which are easy to import. Reports are done with a few commands; repeatable reports are done by saving commands to a shell script. hledger comes with builtin tools for monthly reports, BSE, currencies, pending invoices, closing/opening new years, and those are merely what I recall using recently.
A claim which is mostly true is false. Programmers should pay attention to details, since that is all computers know.
Nobody cares what you want, fascist.
As explained self-referentially in this Zeit article, photo and video of Musk’s actions is not publishable without alterations in Germany because it violates anti-Nazi laws. By German standards, Musk is a Nazi.
Your opinion doesn’t mean shit when you are this ill-read, this out-of-touch with politics, and this apologetic for an open fascist.
Open your mind a little; collective action has an impact but individual action may not. Paraphrasing Cloud Atlas, certainly an ocean is nothing more than a vast collection of raindrops, but each individual raindrop collectively acts as a body of water. This dissolves your false dilemma.
I don’t really like flake-parts or flakelight. I think that part of this is sheer brutalism (I don’t mind writing bare Nix) but part of it is a desire to not rely on flakes which don’t carry their own weight, following Wirth’s principle for compilers.
That said, github:numtide/flake-utils does carry its own weight by managing multiple system values, especially in flakes that support more systems than upstream nixpkgs, and I’ve found myself using it in nearly everything; flake-utils makes it fairly easy to have leaf packages that are e.g. supported on both amd64 and aarch64. I know flake-parts does this too, but not in a way I enjoyed.
I just noticed that you said “my configuration.” A machine, perhaps? My NixOS configuration is split into over a dozen NixOS modules and each machine has a list of included module files. I’m not using any flake-management tools for that flake; each machine has a hardcoded system and (like sibling comment from @algernon@lemmy.ml) they’re all crammed into one big flake.nix so that the machine hostnames line up correctly when using the flake in argv:
$ sudo nixos-rebuild switch --flake git://git.example.local/one.big.flake.git
Seems facetious at first, but it facilitates automatic updates via flakes, just like with classic channels.
There are a lot of programming languages. Also, features can often be hacked onto or off of a language. It’s therefore important to be able to quickly reject a language based on undesirable features. It’s also important to recall the big picture: to maintain a large amount of instructions or transformations which have been proven correct. Anything which gets in the way of that big picture should be quickly rejected.
Self’s descendants are not well-understood in our popular culture. The two most popular (Turing-complete) languages, ECMAScript and Python, are both Self grandchildren, and Java is also a child of Self; yet, the article’s author incorrectly believes them to be ALGOL descendants because of surface syntax as well as the Java/ECMAScript focus on performance. Note also that the author doesn’t mention E (WP, esolangs), which is akin to Erlang in making message-passing explicit but descends from Self, unlike Erlang which descends from Prolog. (I will give them partial credit for noting that Smalltalk is an ancestor of Java.)
So, the exemplar should be a message-passing everything-is-an-object language designed for JIT with no Prolog influence. The earliest such language in the family tree is Self!
INTERCAL is an ALGOL descendant. A holistic timeline of esoteric languages shows that esoteric languages don’t form a family; however, there are several families not mentioned in the article, notably cellular automata and string/wire diagrams.
Your argument is completely specious. Re-read that list. Assembly is a second language in the kernel already, and really it’s multiple languages, one per supported ISA. Perl and Python scripts are used to generate data tables; there are multiple build-time languages. eBPF is evaluated at runtime; the kernel contains bytecode loaders, JIT compilers, and capability management for it. The kernel has already paid the initial cost of setting up a chimeric build process which evaluates many different languages at many different stages.