• 1 Post
  • 55 Comments
Joined 2 years ago
cake
Cake day: June 14th, 2023

help-circle
  • And here we see the self-Godwin in the wild. Masterful play, sir.

    Neither the CFO nor CEO are saying that Google ought to be not broken up. They are saying that Mozilla existentially depends on Google. This is actually more of a central point in the lawsuit than you think; in the original complaint, part 6 of the background is about revenue-sharing agreements (RSAs) between Google and various other companies who would normally compete in search, browsers, and other venues. That is, nobody is disputing that:

    Today, Google has RSAs with nearly every significant non-Google browser (other than those distributed by Microsoft) including Mozilla’s Firefox, Opera, and UCWeb. These agreements generally require the browsers to make Google the preset default general search engine for each search access point on both their Web and mobile versions.

    If Mozilla did want to petition the court, then they are welcome to file as amici, but they haven’t! Nor have any court filings included a reference to the CFO’s testimony so far, although to be fair the testimony isn’t yet available to read. There is no evidence that Mozilla will stand in the way of whatever the court decides to do with Google. Rather, in their post, the CEO is asking lawmakers to figure out some way to ensure that the browser market remains competitive:

    Mozilla calls on regulators and policymakers to recognize the vital role of independent browsers and take action to nurture competition, innovation, and protect the public interest in the evolving digital landscape.

    Courts aren’t regulators or policymakers. The complaint before the court is not the same as the underlying principles of antitrust which motivated the complaint. A request to improve the future is not the same as a request to forestall the present.


  • The author would do well to look up SGML; Markdown is fundamentally about sugaring the syntax for tag-oriented markup and is defined as a superset of HTML, so mistaking it for something like TeX or Word really demonstrates a failure to engage with Markdown per se. I suppose that the author can be forgiven somewhat, considering that they are talking to writers, but it’s yet another example of how writers really only do research up to the point where they can emit a plausible article and get paid.

    It’s worth noting that Microsoft bought PowerPoint, GitHub, LinkedIn, and many other things—but it did in fact create Word and Excel. Microsoft is, in essence, a sales company. It’s not too great at designing software.

    So close to a real insight! The correct lesson is that Microsoft, like Blizzard, is skilled at imitating what’s popular in the market; like magpies, they don’t need to have a culture of software design as long as they have a culture of software sales. In particular, Microsoft didn’t create Word or Excel, but ripped off WordPerfect and Lotus 1-2-3.



  • Well, here is a very funny one-off commit, but my biggest effort was probably substantial parts of a couple AMD/ATI GPU drivers, well-summarized here. As usual, that was a team effort, with particular credit to Deucher (AMD), Glisse (radeon maintainer), and Airlie (DRM/DRI maintainer). So, put up or shut up. Or, to paraphrase the sentiment that you seem to not grok: talk is cheap; show us your code.

    Let me make it clear. I call out brigading because it is useless noise that distorts and obfuscates the kernel development process. I don’t care that you’re salty that I’m pointing out that your “absolute crickets” comment is not only incorrect, but empty in the sense that your lack of perception is not a substitute for the actual process of kernel development. Additionally, in this case, it seems like you’re still focused on personalities rather than the underlying computer science; I expect “absolute crickets” when asking you about the topic of memory safety.






  • 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.







  • 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.



  • 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.”