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.

With the recent release of Ubuntu 24.04, we at Snyk Security Labs thought it would be interesting to examine the latest version of this Linux distribution to see if we could find any interesting privilege escalation vulnerabilities.

...

During our research, we successfully identified a privilege escalation from the default user on a fresh Ubuntu Desktop installation to root. To achieve this, we chained one small bug in a privileged component together with a number of features, which all work as expected, to achieve arbitrary command execution as root.

This blog post will outline the journey of our research, discuss how we identified these vulnerabilities, and, we hope, show that you can keep it simple when it comes to exploitation and achieve the same results without needing a very complex (although extremely cool) kernel memory corruption vulnerability, for example.

2023 had been a slow year, so we skipped on our traditional annual update, but it is back this year. here’s a summary of everything that’s been happening since Nov 2022. Most of the progress these last two years have been around making chathistory more suitable for the real world, and reducing bandwidth usage for mobile clients.

The Ubuntu Mainline Kernel PPA is great for quickly and easily fetching new upstream Linux kernel builds assembled for Ubuntu/Debian systems. It's a big time saver for grabbing the latest stable or daily development kernel on Ubuntu. It's also great for having them publicly and readily available -- one of the reasons I prefer it as well is for that transparency into the kernel builds and prefer using them so when a vendor or user asks about my kernel configuration or if I can supply the kernel used for testing, it's darn simple to just cite the Ubuntu Mainline Kernel PPA.

But it hasn't been producing any new kernel builds since the middle of September... All of the Linux 6.12 release candidates and daily builds have not been producing. Presumably due to a broken Kconfig change or something else failing from the Linux 6.12 merge window changes.

Similar to last year the Ubuntu Mainline Kernel PPA being broken for over a month. Frustrating that such a useful feature and one maintained by the Ubuntu Kernel Team can remain broken for weeks on end. It's been an annoyance on my end for a number of weeks, but at least last time when calling out the broken state for more than a month, it wound up being fixed shortly thereafter. Hopefully that happens again to restore this great feature of Ubuntu Linux particularly for hardware enthusiasts, kernel testers, etc.

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.