-- 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 Oct 06, 2022
> The CHERI architecture is the product of a research program to extend common CPU architectures in a way that prevents many types of memory-related bugs (and vulnerabilities). At the 2022 GNU Tools Cauldron, Alex Coplan and Szabolcs Nagy described the work that has been done to bring GCC and the GNU C Library (glibc) to this architecture. CHERI is a fundamentally different approach to how memory is accessed, and supporting it properly is anything but a trivial task.
> Qt for MCUs 2.2.2 has been released and is available for download. As a patch release, Qt for MCUs 2.2.2 provides bug fixes and other improvements, and maintains source compatibility with Qt for MCUs 2.2.x. It does not add any new functionality.
> This week is the last week of my GSoC period. Other participants may have ended earlier, but I got an extension of the deadline to one month later. Here’s some random words for my summer.
> My whole GSoC period was very hurried and busy. Most of my contributions were not done during the summer, because I got a one-month training for ICPC during my summer holiday. Before the training started, I was thinking that I might be able to do both training and GSoC at the same time, but I was completely wrong. The eight-hour training left me with almost no spare time. Trying to do some contribution in the tiny gaps in my schedule, I was very stressed that month, and in the end, I did not make too much progress also. If there’s not an extension of the deadline, I would be facing a huge pile of unfinished work at the end of August, when training ends. So this is a lesson for me, and also a piece of advice for any GSoC contributors who come after me, that a GSoC project needs some time to finish, and having a well-planned schedule in advance is important.
> I work on OpenJDK backports: taking a patch that was committed to a current version of JDK, and adapting it to an older one. There are four main OpenJDK versions that I am concerned with: the current version ("jdk"), 8, 11 and 17. These are all maintained in separate Git(Hub) repositories.
> It's very useful to have access to the other JDKs when working on any particular version. For example, to backport a patch from the latest version to 17, where the delta is not too big, a lot of the time you can cherry-pick the patch unmodified. To do git cherry-pick in a git repository tracking JDK17, where is in "jdk", I need the "jdk" repository configured as a remote for my local jdk17 repository.
> Maintaining completely separate local git repositories for all four JDK versions, with each of them having a subset of the others added as remotes, adds up to a lot of duplicated data on local storage.
> For a little while I was exploring using shared clones: a local clone of another local git repository which share some local metadata. This saves on some disc space, but it does not share the configuration for remotes: so I still have to add any other JDK versions I want as remotes in each shared clone (even if the underlying objects already exist in the shared metadata)
> Then I discovered git worktree. The git repositories that I've used up until now have had exactly zero (for a bare clone) or one worktree: in other words, the check-out, the actual source code files.
> Recently Herb Sutter published cppfront, which is an attempt to create C++ a new syntax to fix many issues that can't be changed in existing C++ because of backwards compatibility. Like with the original cfront compiler, cppfront works by parsing the "new syntax" C++ and transpiling it to "classic" C++, which is then compiled in the usual way. These kinds of source generators are fairly common (it is basically how Protobuf et al work) so let's look at how to add support for this in Meson. We are also going to download and build the cppfront compiler transparently.
> [...]
> The compiler itself is in a single source file so building it is simple. The only thing to note is that we override settings so it is always built with optimizations enabled. This is acceptable for this particular case because the end result is not used for development, only consumption. The more important bits for integration purposes are the last two lines where we define that from now on whenever someone does a find_program('cppfront') Meson does not do a system lookup for the binary but instead returns the just-built executable object instead. Code generated by cppfront requires a small amount of helper functionality, which is provided as a header-only library. The last line defines a dependency object that carries this information (basically just the include directory).
> As part of ongoing work on governance, Rust leadership jointly established a group, "leadership chat", consisting of the Core team, leads of all teams on the governance page, the Moderation team, and the project directors on the Rust Foundation board. This group has been serving as an interim governing body while efforts to establish the next evolution of Rust project-wide governance are underway.
> The next version of the Linux kernel will include support for popular programming language Rust, it has been confirmed.
> As reported by The Register (opens in new tab), Linus Torvalds, the creator of Linux, has now accepted a pull request that will bring Rust support to the kernel with version 6.1.
> The idea is not to rebuild the entire kernel in Rust, but rather to complement the existing C codebase with new components written in the secondary language, helping to reduce the likelihood of memory bugs that lead to security vulnerabilities.
-- Response ended
-- Page fetched on Sat Jun 1 08:01:12 2024