pnutzh4x0r

Yes, this nifty workflow wonder is finally able to automatically tile newly opened windows based on the currently active tiling layout (and as you may sick of me re-emphasising: you can switch between different layouts ad-hoc, and create and save your own).

Windows auto-tile to the best vacant slot in the layout. But what’s ‘best’? Tiling Shell developer Domenico Ferraro says this will be the ‘vacant tile nearest to the center of the screen’.

With the addition of automatic tiling you no longer need to tile windows manually.

I saw plenty of efforts that aim to create a Linux distribution for non-enthusiasts, for people who just want to use their computers, and not care about the details - A Desktop for All on the GNOME blog, most recently. While I commend the effort, my own experience is that these efforts are futile, and start off from a fundamentally wrong premise: that people are willing (let alone wanting) to manage their own operating systems.

...

My family is using Linux because that’s the system I can maintain for them. Apart from my Dad, they never installed Linux, and never will. They don’t install software, they don’t upgrade, they don’t change settings either. All of that is something I do for them. And to do so effectively, I need a distribution I am familiar with, one that is also flexible enough to fine-tune for every member of the family, because they prefer fundamentally different things!

...

The common pattern between all these three is that neither of them maintains their own systems. I do. As such, how beginner friendly the distribution is, is meaningless. The users of the system don’t care, they’ll never see those parts. They’ll have a preconfigured system maintained by someone else, and that’s exactly what they want. To make this work, I’m using distributions I am familiar with. For my parents, that’s Debian, because I was a Debian person when their systems were installed. For my Wife, it is NixOS, because I’m a NixOS person now. For the Twins, it will likely be NixOS too.

A new patch series posted today to the Linux kernel mailing list would block kernel modules/drivers from TUXEDO Computers from accessing GPL-only symbols in the kernel.

TUXEDO Computers maintains a set of kernel drivers currently out-of-tree for their various laptops for additional functionality around power profiles, keyboard backlight controls, WMI, sensor monitoring, the embedded controller, and other functionality. They have said they want to eventually mainline these drivers but in the name of allowing for rapid hardware support they maintain them out-of-tree and ship them with their Ubuntu-based TUXEDO OS and also have the driver sources available via GitLab.

The issue at hand though is that these kernel drivers marked as GPLv3+ and that conflicts with the upstream Linux kernel code licensed as GPLv2. There was a commit to change the driver license from GPLv3 to GPL(v2) but was reverted by TUXEDO Computers on the basis of "until the legal stuff is sorted out."

Update: TUXEDO Computers Relicenses Some Of Their Drivers To GPLv2

As of yesterday, TUXEDO Computers has now been able to re-license their driver consisting of fully in-house code from GPLv3 to GPLv2+. These are the TUXEDO Computers drivers where it's all written by TUXEDO employees and not having to worry about code from any third-party developers or other vendors.

The gxtp7380, ite_8291, ite_8291_lb, ite_8297, stk8321, tuxedo_compatibility_check, tuxedo_nb02_nvidia_power_ctrl, and tuxedo_tuxi drivers are the initial ones able to be moved to the GPLv2+ licensing for satisfying upstream Linux kernel developers. Moving the other drivers to GPLv2+ will take longer due to needing to check with the associated parties that contributed to those drivers.

Whether you just downloaded Firefox, or you’ve been with us since the beginning, you are a vital part of helping us make the internet a better place. Here's a sneak peak at what's coming next!

Community driven applications and extensions written to extend the power of the COSMIC™ Desktop made by System 76.

COSMIC Utils Projects are all open source and as such welcome the spirit of open collaboration. Head over to the source code of any of the projects listed above and help however you feel necessary!

This is a collection of third party utilities designed for COSMIC. The organization is open to welcoming new projects and contributors.

Runescape has been a game near and dear to my heart since I was a child. Though I do not actively play anymore, it still functions as an interesting programming project substrate. Most recently, I created a bot that automatically executes trades on the Grand Exchange in order to conduct market making via common machine learning techniques. This blog post will explain the individual components of the bot, the various trading algorithms used, and the results of an experiment comparing the various trading algorithms' performance.

A while back COSMIC entered its Alpha 1 and then Alpha 2 and now we have the CEO of System76 Carl Richell back on the show to talk about the project.

One notable comment (around minute 49) by Carl is that there will "soon" be a development option available for Pop!_OS 22.04 users to upgrade to 24.04 where some GNOME applications will be replaced by their COSMIC equivalents.

Also, Carl says he hopes Beta 1 will be released in January 2025. Until then, there will be a new Alpha every last Thursday of the month.

If you love exploit mitigations, you may have heard of a new system call named mseal landing into the Linux kernel’s 6.10 release, providing a protection called “memory sealing.” Beyond notes from the authors, very little information about this mitigation exists. In this blog post, we’ll explain what this syscall is, including how it’s different from prior memory protection schemes and how it works in the kernel to protect virtual memory. We’ll also describe the particular exploit scenarios that mseal helps stop in Linux userspace, such as stopping malicious permissions tampering and preventing memory unmapping attacks.

Memory sealing allows developers to make memory regions immutable from illicit modifications during program runtime. When a virtual memory address (VMA) range is sealed, an attacker with a code execution primitive cannot perform subsequent virtual memory operations to change the VMA’s permissions or modify how it is laid out for their benefit.

...

mseal digresses from prior memory protection schemes on Linux because it is a syscall tailored specifically for exploit mitigation against remote attackers seeking code execution rather than potentially local ones looking to exfiltrate sensitive secrets in-memory.

...

From the disallowed operations, we can discern two particular exploit scenarios that memory sealing will prevent:

• Tampering with a VMA’s permissions. Notably, not allowing executable permissions to be set can stop the revival of shellcode-based attacks.
• “Hole-punching” through arbitrary unmapping/remapping of a memory region, mitigating data-only exploits that take advantage of refilling memory regions with attacker-controlled data.

...

There are likely many other use cases and scenarios that we didn’t cover. After all, mseal is the newest kid on the block in the Linux kernel! As the glibc integration completes and matures, we expect to see improved iterations for the syscall to meet particular demands, including fleshing out the ultimate use of the flags parameter.

Drivers passing through San Francisco have a new roadside distraction to consider: billboards calling out businesses that don't cough up for the open source code that they use.

The signs are the work of the Open Source Pledge – a group that launched earlier this month. It asks businesses that make use of open source code to pledge $2,000 per developer to support projects that develop the code. So far, 25 companies have signed up – but project co-founder Chad Whitacre wants bigger firms to pay their dues, too.

Over the past 3 years the pace of development in APS has steadily fallen off as maintainers including myself have moved on to other things. I no longer have time and motivation to dedicate to this project, and in the absence of significant external contributions there is no-one else I can offer the project's stewardship to.

To that effect, I will be archiving the repository on Monday, October 14th 2024 at 7AM GST. In the situation that a serious and viable fork emerges, I will help them as much as I can with the transition. The criteria for what counts as "serious and viable" is entirely vibes-driven for now, and may become more specific in the future. In case I determine that a fork does not live up to my made up standard, they will have to come up with a slightly more creative name than "Android Password Store" and watch low 4 figures of cash wither away in OpenCollective's bank account.

Pull request #10974 introduces the @bitwarden/sdk-internal dependency which is needed to build the desktop client. The dependency contains a licence statement which contains the following clause:

You may not use this SDK to develop applications for use with software other than Bitwarden (including non-compatible implementations of Bitwarden) or to develop another SDK.

This violates freedom 0.

It is not possible to build desktop-v2024.10.0 (or, likely, current master) without removing this dependency.

We are excited to announce the launch of a dedicated fund aimed at providing financial assistance to Free/Libre and Open Source Software (FOSS/FLOSS) projects globally, with an annual commitment of $1 million. I will use the FOSS acronym in this post hereafter.

...

For us, FLOSS/fund is about hacker goodwill, reciprocity, and common sense business strategy. We invite you to apply for funding. If you would like to understand the motivations behind this, a bit of storytelling lies ahead.

...

To initiate and give this experiment a serious shot, FLOSS/fund will accept funding requests from projects through a publicly accessible funding.json file hosted on their respositories or websites. This file is not meant to convey everything there is to know—an impossible task—but to solicit interest and communicate enough to ensure discoverability which would not be possible otherwise. Refer to the funding.json docs to know more.

Applications that come through to the FLOSS/fund will be indexed and published on the dir.floss.fund directory / portal, making them publicly discoverable by anyone interested in supporting projects. This is going to be an interesting experiment. Fingers crossed!