For every bytecode compiled language, the most interesting part of its implementation is its virtual machine (also referred to as the bytecode interpreter) where the bytecode execution takes place. Because this is such a crucial part of the language machinery, its implementation has to be highly performant. Even if you are not a compiler engineer, learning about such internal implementation can give you new performance tricks and insights that you may be able to use in other places of your job. And, if you are a compiler engineer then you should always look around how other languages are implemented to pickup implementation details that you may not be aware of.

In this article, we are going to be discussing the bytecode instruction format of CPython, followed by the implementation of the bytecode evaluation loop of the interpreter where the bytecode execution takes place.

cross-posted from: https://lemmy.ndlug.org/post/1050940

In practice, the Linux community is the wild wild west, and sweeping changes are infamously difficult to achieve consensus on, and this is by far the broadest sweeping change ever proposed for the project. Every subsystem is a private fiefdom, subject to the whims of each one of Linux’s 1,700+ maintainers, almost all of whom have a dog in this race. It’s herding cats: introducing Rust effectively is one part coding work and ninety-nine parts political work – and it’s a lot of coding work. Every subsystem has its own unique culture and its own strongly held beliefs and values.

The consequences of these factors is that Rust-for-Linux has become a burnout machine. My heart goes out to the developers who have been burned in this project. It’s not fair. Free software is about putting in the work, it’s a classical do-ocracy… until it isn’t, and people get hurt. In spite of my critiques of the project, I recognize the talent and humanity of everyone involved, and wouldn’t have wished these outcomes on them. I also have sympathy for many of the established Linux developers who didn’t exactly want this on their plate… but that’s neither here nor there for the purpose of this post, and any of those developers and their fiefdoms who went out of their way to make life difficult for the Rust developers above and beyond what was needed to ensure technical excellence are accountable for these shitty outcomes.

...

Here’s the pitch: a motivated group of talented Rust OS developers could build a Linux-compatible kernel, from scratch, very quickly, with no need to engage in LKML politics. You would be astonished by how quickly you can make meaningful gains in this kind of environment; I think if the amount of effort being put into Rust-for-Linux were applied to a new Linux-compatible OS we could have something production ready for some use-cases within a few years.

...

Having a clear, well-proven goal in mind can also help to attract the same people who want to make an impact in a way that a speculative research project might not. Freeing yourselves of the LKML political battles would probably be a big win for the ambitions of bringing Rust into kernel space. Such an effort would also be a great way to mentor a new generation of kernel hackers who are comfortable with Rust in kernel space and ready to deploy their skillset to the research projects that will build a next-generation OS like Redox. The labor pool of serious OS developers badly needs a project like this to make that happen.

Follow up to: One Of The Rust Linux Kernel Maintainers Steps Down - Cites "Nontechnical Nonsense", On Rust, Linux, developers, maintainers, and Asahi Lina's experience about working on Rust code in the kernel

Even before the Bcachefs file-system driver was accepted into the mainline kernel, Debian for the past five years has offered a "bcachefs-tools" package to provide the user-space programs to this copy-on-write file-system. It was simple at first when it was simple C code but since the Bcachefs tools transitioned to Rust, it's become an unmaintainable mess for stable-minded distribution vendors. As such the bcachefs-tools package has now been orphaned by Debian.

From John Carter's blog, Orphaning bcachefs-tools in Debian:

"So, back in April the Rust dependencies for bcachefs-tools in Debian didn’t at all match the build requirements. I got some help from the Rust team who says that the common practice is to relax the dependencies of Rust software so that it builds in Debian. So errno, which needed the exact version 0.2, was relaxed so that it could build with version 0.4 in Debian, udev 0.7 was relaxed for 0.8 in Debian, memoffset from 0.8.5 to 0.6.5, paste from 1.0.11 to 1.08 and bindgen from 0.69.9 to 0.66.

I found this a bit disturbing, but it seems that some Rust people have lots of confidence that if something builds, it will run fine. And at least it did build, and the resulting binaries did work, although I’m personally still not very comfortable or confident about this approach (perhaps that might change as I learn more about Rust).

With that in mind, at this point you may wonder how any distribution could sanely package this. The problem is that they can’t. Fedora and other distributions with stable releases take a similar approach to what we’ve done in Debian, while distributions with much more relaxed policies (like Arch) include all the dependencies as they are vendored upstream."

...

With this in mind (not even considering some hostile emails that I recently received from the upstream developer or his public rants on lkml and reddit), I decided to remove bcachefs-tools from Debian completely. Although after discussing this with another DD, I was convinced to orphan it instead, which I have now done.

Last night Adam Mosseri, Head of Instagram, quitely announced the next step in the integration of Threads into the Fediverse. In addition to being able to follow Threads accounts from Fediverse/Mastodon accounts, we can now reply to and like Threads posts. Threads are taking a quiet, incremental approach to Federation, but seem genuinely commited.

From About Threads and the fediverse

If you turn on sharing to the fediverse, users on other servers can search for and follow your profile, view your posts, interact with your content, and share your content to anyone on or off their server. On Threads, you’ll be able to see the number of users on other servers who liked your post. You'll also be able to see and like their replies to your post.

Wedson Almeida Filho is a Microsoft engineer who has been prolific in his contributions to the Rust for the Linux kernel code over the past several years. Wedson has worked on many Rust Linux kernel features and even did a experimental EXT2 file-system driver port to Rust. But he's had enough and is now stepping away from the Rust for Linux efforts.

From Wedon's post on the kernel mailing list:

I am retiring from the project. After almost 4 years, I find myself lacking the energy and enthusiasm I once had to respond to some of the nontechnical nonsense, so it's best to leave it up to those who still have it in them.

...

I truly believe the future of kernels is with memory-safe languages. I am no visionary but if Linux doesn't internalize this, I'm afraid some other kernel will do to it what it did to Unix.

Lastly, I'll leave a small, 3min 30s, sample for context here: https://youtu.be/WiPp9YEBV0Q?t=1529 -- and to reiterate, no one is trying force anyone else to learn Rust nor prevent refactorings of C code."

As part of a massive migration campaign, LinkedIn has successfully moved their operations to Microsoft's Azure Linux as of April 2024, ditching CentOS 7 in the process and taking advantage of a more modern compute platform.

As many of you might already know, back on June 30, 2024, CentOS 7 reached the end-of-life status, resulting in no new future updates for it, including fixes for critical security vulnerabilities.

...

The developers have gone with the high-performing XFS filesystem, which was made to work with Azure Linux to fit LinkedIn's use case. In their testing, they found that XFS was performing well for most of their applications, except Hadoop, which is used for their analytics workloads.

When they compared the issues that cropped up, XFS came out as a more stable and reliable choice than the other candidate, Ext4.

...

Additionally, LinkedIn's MaaS (Metal-as-a-Service) team has developed a new Azure Linux Image Customizer tool for automating image generation, that takes an existing generic Azure Linux image, and modifies it to use with a given scenario. In this case, a tailored image for LinkedIn.

LinkedIn Engineering Blog: Navigating the transition: adopting Azure Linux as LinkedIn’s operating system

Remember, for every paid SaaS, there is a free open-source self-hosted alternative. Let's take a look at 10 FOSS tools designed to replace popular tools like MS Office, Notion, Heroku, Vercel, Zoom, Adobe, and more.

...

⭐ Repos mentioned

• LibreOffice
• Mattermost
• Nocodb
• Plane
• Appflowy
• Jitsi
• ERPNext
• Coolify
• Dokku
• Instant

CircuitPython is an open-source implementation of the Python programming language for microcontroller boards. The project, which is sponsored by Adafruit Industries, is designed with new programmers in mind, but it also has many features that may be of interest to more-experienced developers. The recent 9.1.0 release adds a few minor features, but it follows just a few months after CircuitPython 9.0.0, which brings some more significant changes, including improved graphics and USB support.

CircuitPython is a fork of MicroPython (previously covered on LWN) with several changes designed to make the language easier for beginners to use. CircuitPython has a universal hardware API and is more compatible with the CPython standard library, for example. CircuitPython has some limitations compared to MicroPython, particularly with respect to concurrency, but is otherwise just as powerful.

...

This difference in APIs make sense when looking at the main goals of each project. MicroPython describes the language as ""a lean and efficient implementation of the Python 3 programming language that includes a small subset of the Python standard library and is optimised to run on microcontrollers and in constrained environments"". In contrast, Adafruit's "What is CircuitPython?" page says: ""CircuitPython is a programming language designed to simplify experimenting and learning to program on low-cost microcontroller boards."" Adafruit recommends CircuitPython for users who ""want to get up and running quickly"" or ""are new to programming"".

CircuitPython supports most of the core language features of CPython, although some features are missing due to the limited resources found on microcontroller boards compared to the much more powerful computers on which CPython typically runs. Many of those missing features will be the same as those on a comparison between CPython and MicroPython reports. In addition, as CircuitPython's main README explains: ""Modules with a CPython counterpart, such as time, os and random, are strict subsets of their CPython version. Therefore, code from CircuitPython is runnable on CPython but not necessarily the reverse.""

cross-posted from: https://lemmy.ndlug.org/post/1040526

A judge has dismissed the majority of claims in a copyright lawsuit filed by developers against GitHub, Microsoft, and OpenAI.

The lawsuit was initiated by a group of developers in 2022 and originally made 22 claims against the companies, alleging copyright violations related to the AI-powered GitHub Copilot coding assistant.

Judge Jon Tigar’s ruling, unsealed last week, leaves only two claims standing: one accusing the companies of an open-source license violation and another alleging breach of contract. This decision marks a substantial setback for the developers who argued that GitHub Copilot, which uses OpenAI’s technology and is owned by Microsoft, unlawfully trained on their work.

...

Despite this significant ruling, the legal battle is not over. The remaining claims regarding breach of contract and open-source license violations are likely to continue through litigation.

cross-posted from: https://lemmy.ndlug.org/post/1040526

A judge has dismissed the majority of claims in a copyright lawsuit filed by developers against GitHub, Microsoft, and OpenAI.

The lawsuit was initiated by a group of developers in 2022 and originally made 22 claims against the companies, alleging copyright violations related to the AI-powered GitHub Copilot coding assistant.

Judge Jon Tigar’s ruling, unsealed last week, leaves only two claims standing: one accusing the companies of an open-source license violation and another alleging breach of contract. This decision marks a substantial setback for the developers who argued that GitHub Copilot, which uses OpenAI’s technology and is owned by Microsoft, unlawfully trained on their work.

...

Despite this significant ruling, the legal battle is not over. The remaining claims regarding breach of contract and open-source license violations are likely to continue through litigation.

A judge has dismissed the majority of claims in a copyright lawsuit filed by developers against GitHub, Microsoft, and OpenAI.

The lawsuit was initiated by a group of developers in 2022 and originally made 22 claims against the companies, alleging copyright violations related to the AI-powered GitHub Copilot coding assistant.

Judge Jon Tigar’s ruling, unsealed last week, leaves only two claims standing: one accusing the companies of an open-source license violation and another alleging breach of contract. This decision marks a substantial setback for the developers who argued that GitHub Copilot, which uses OpenAI’s technology and is owned by Microsoft, unlawfully trained on their work.

...

Despite this significant ruling, the legal battle is not over. The remaining claims regarding breach of contract and open-source license violations are likely to continue through litigation.