-- Leo's gemini proxy
-- Connecting to gemini.tuxmachines.org:1965...
-- Connected
-- Sending request
-- Meta line: 20 text/gemini;lang=en-GB
Tux Machines
Posted by Roy Schestowitz on Mar 17, 2023
> While there are many developers, though, there are few technical authors to translate all this glory into immortal prose — or at least into a decent how-to guide. In fact, large teams of 20 or 30 developers often depend on just one writer to produce all of their documentation. This seems like an unbalanced workload: many features, many developers, one technical author — and yet, it’s a very common practice.
> Beginning with the present open call for proposals, the ISC will award grants for projects to improve the documentation of “essential” R or Bioconductor packages. By essential, we mean packages that help to form the backbone of R’s capabilities in some area of statistical or computational analysis and are important to an identifiable segment of the R Community. It is likely that a significant proportion of the packages in CRAN Task Views and on Bioconductor will meet these criteria.
> Daniel Lemire's recent post "runtime asserts are not free" looks at the run-time cost of assert statements in C and shows that a simple assert in a frequently executed loop can cause significant overhead.
> My own opinion on assertions has shifted over the years, from "I don't see the point" to "use them sparingly" to "use them as much as possible". That last shift is largely due to Rust having two kinds of "assert" statement – assert and debug_assert – which has allowed me to accurately express two different kinds of assertions, largely freeing me from performance worries. If you come from a language that only has one kind of assert statement, this distinction can seem pointless, so in this post I want to briefly explain why it helped shift my thinking.
> Based on the previous few posts, we now have lots of things we can do with the SSD1351 display. One additional thing we can play with this time is drawing shapes. There are a few tricks to doing this quickly. As with previous posts, this will work on other displays with minimal effort to convert it.
> What distinguishes successful and sustainable projects from those that disappeared into the void? Spoiler — it's community. Community is what drives an open source project, and documentation is one of the foundational blocks for building a community. In other words, documentation isn't only about documentation.
> Establishing good documentation can be difficult, though. Users don't read documentation because it's inconvenient, it goes out of date very quickly, there's too much, or there's not enough.
> The development team doesn't write documentation because of the "it's obvious for me, so it's obvious to everyone" trap. They don't write because they are too busy making the project exist. Things are developing too fast, or they're not developing fast enough.
> But good documentation remains the best communication tool for groups and projects. This is especially true considering that projects tend to get bigger over time.
> As was discussed earlier, the way PDF handles fonts and glyphs is arcane and tedious. It takes a lot of boilerplate and hitting your shins against sharp stones to get working. However once you do and can turn to the higher level text functionality, things become a lot nicer. (Right-to-left, vertical and calligraphic scripts might be more difficult, but I don't know any of those.)
> In late 2022 and early 2023, Project Zero reported eighteen 0-day vulnerabilities in Exynos Modems produced by Samsung Semiconductor. The four most severe of these eighteen vulnerabilities (CVE-2023-24033 and three other vulnerabilities that have yet to be assigned CVE-IDs) allowed for Internet-to-baseband remote code execution. Tests conducted by Project Zero confirm that those four vulnerabilities allow an attacker to remotely compromise a phone at the baseband level with no user interaction, and require only that the attacker know the victim's phone number. With limited additional research and development, we believe that skilled attackers would be able to quickly create an operational exploit to compromise affected devices silently and remotely.
> The fourteen other related vulnerabilities (CVE-2023-26072, CVE-2023-26073, CVE-2023-26074, CVE-2023-26075, CVE-2023-26076 and nine other vulnerabilities that are yet to be assigned CVE-IDs) were not as severe, as they require either a malicious mobile network operator or an attacker with local access to the device.
-- Response ended
-- Page fetched on Thu Jun 13 16:22:05 2024