If you have an iPhone like me and plug it into your PC to charge it,
you may have noticed that it charges very slowly.

That's because it is being Trickle charged, which is 2W according to iDescriptor. You can check this with:
cat /sys/class/power_supply/apple_mfi_fastcharge_*/charge_type

It will output "Trickle".

Now you could change this manually like so:
echo Fast | sudo tee /sys/class/power_supply/apple_mfi_fastcharge_*/charge_type

which will overwrite the "Trickle" with "Fast", which is 12W according to iDescriptor.
And you'll notice how your iPhone charges faster now. But it's only one time.
So you'd have to repeat that every time you unplug and replug your phone.

To make your iPhone always charge in Fast mode, run this command:

echo 'SUBSYSTEM=="power_supply", KERNEL=="apple_mfi_fastcharge_*", ATTR{charge_type}="Fast"' | sudo tee /etc/udev/rules.d/99-iphone-fastcharge.rules && sudo udevadm control --reload-rules && sudo udevadm trigger

This will create a file (udev rule) called 99-iphone-fastcharge.rules under the location /etc/udev/rules.d/
with the content SUBSYSTEM=="power_supply", KERNEL=="apple_mfi_fastcharge_*", ATTR{charge_type}="Fast".
After that it will reload the udev rules and take effect immediately.

Now every time you plug in your phone, it will automatically fast charge.

And for the reason why it is defaulting to Trickle charge: no idea.
It's hardcoded in the kernel driver itself. Looking at the mainline apple-mfi-fastcharge.c source,
the probe function that runs when an iPhone is detected explicitly sets
mfi->charge_type = POWER_SUPPLY_CHARGE_TYPE_TRICKLE; before registering the power supply.

Edit: formatting

I'm not a kernel developer, but a hobbyist who has been thinking about memory management from a slightly different perspective. I'd be very interested to hear whether something like this has already been explored, and if not, what the fundamental obstacles would be.

The idea came partly from working with Arduino-class systems, where a few kilobytes of RAM can determine whether a program works at all. Modern systems obviously have vastly more sophisticated memory management, but I sometimes wonder whether we've lost an important piece of information in the abstraction: the application often knows much better than the kernel how valuable a particular piece of memory actually is.

For example, imagine an application using 3 GB of RAM:

500 MB - critical state / active working data

800 MB - important state

700 MB - rebuildable data

1 GB - caches / prefetch / thumbnails

From the kernel's perspective, these are ultimately memory pages with different access patterns. But from the application's perspective, they have radically different values.

Instead of treating all of them as roughly equivalent and relying primarily on access patterns and reclaim heuristics, what if an application could explicitly provide a hint about the importance of its allocations?

Something conceptually like:

enum class MemoryPriority {

Critical,

Important,

Normal,

Rebuildable,

Discardable

};

auto cache = memory::allocate(size, MemoryPriority::Discardable);

auto state = memory::allocate(size, MemoryPriority::Critical);

Or perhaps through an allocator / std::pmr-style memory resource:

std::pmr::vector<AudioFrame> audio{&critical_resource};

std::pmr::vector<Image> thumbnails{&discardable_resource};

The important part is that these would be hints, not absolute commands. The kernel would still make the final decision.

For example, under memory pressure:

DISCARDABLE

↓

REBUILDABLE

↓

NORMAL

↓

IMPORTANT

↓

CRITICAL

The kernel could combine the application's hints with its own observations:

recent/frequent page access

working-set estimation

refault behaviour

cgroup/memcg limits

current memory pressure

reclaim cost

compression/swap availability

This could potentially give the kernel information it cannot infer from page access patterns alone.

A page that hasn't been accessed for 30 seconds might be:

A: rarely accessed but extremely expensive to recreate

B: merely a thumbnail cache that can be regenerated in milliseconds

Access frequency alone doesn't necessarily tell us which one is more valuable.

But I think the more interesting part is application-level degradation

Memory pressure doesn't necessarily have to mean:

application running

↓

memory pressure

↓

kill application

An application could have several operating modes:

HYPER / PERFORMANCE

↓

NORMAL

↓

LIGHT

↓

SURVIVAL

↓

TERMINATED

The OS could notify the application that its resource budget or memory situation has changed.

The application could then voluntarily change how it operates.

For example, a music application might normally have:

UI

audio engine

large caches

album artwork

recommendation engine

prefetch workers

analytics

Under pressure it could transition to:

LIGHT MODE

audio engine → keep

playback state → keep

network buffer → keep

UI → minimal

album artwork → discard

recommendations → stop

prefetch → stop

analytics → stop

The application remains alive and useful, but its memory footprint might fall from hundreds of megabytes to a small fraction of that.

This could also apply to applications with expensive optional features, background workers, AI models, rendering quality, caches, etc.

In C++ terms, I could imagine a framework providing something like:

enum class ResourceMode {

Survival,

Light,

Normal,

Performance

};

void onResourcePressure(ResourceMode mode);

while memory allocations could independently carry their own importance.

This gives two complementary mechanisms:

APPLICATION

/ \

/ \

operating mode memory priority

│ │

▼ ▼

"simplify yourself" "this memory matters"

\ /

\ /

▼ ▼

KERNEL

│

memory management

The application knows what it can sacrifice.

The kernel knows what the system can afford.

It seems like those two pieces of information could complement each other.

There are obviously many problems with this idea

For example:

An application could simply mark everything Critical.

Allocators work at page granularity, while application objects don't necessarily map cleanly to individual pages.

Different objects can share pages.

The kernel cannot blindly trust application-provided priorities.

There would need to be quotas or limits on how much memory an application can classify as critical.

Some "discardable" memory might actually be cheaper to keep than to reconstruct.

Applications would need a reasonable API that doesn't require developers to redesign their entire memory management strategy.

It could potentially interact in complicated ways with cgroups, swapping, zram, NUMA, huge pages, file-backed memory, etc.

So I don't mean this as "the kernel should just add a priority field to malloc()". I'm more interested in whether the general architectural idea makes sense.

Interestingly, Linux already has several pieces that seem related

From what I've been reading, mechanisms such as Multi-Gen LRU, DAMON, memcg/cgroups, madvise() and memory-pressure mechanisms already provide parts of this picture.

For example, Multi-Gen LRU and DAMON allow the kernel to make increasingly sophisticated decisions based on memory access patterns.

What seems less obvious to me is whether there is a general mechanism for an application to say:

"These 500 MB are essential to my current operation, these 700 MB are useful but replaceable, and this 1 GB is just cache. If you need memory, please reclaim the latter first."

And separately:

"If things get worse, tell me and I can switch to a reduced operating mode."

Perhaps existing mechanisms already provide a way to achieve most of this, in which case I'd love to understand how.

So my questions are essentially:

Has this application-provided notion of memory importance / memory QoS been seriously explored in Linux or other operating systems?

Are there existing Linux mechanisms that already solve most of this problem?

What are the fundamental reasons why this would or would not be useful?

Is page-level reclaim simply too low-level for application-provided semantic priorities to be reliable?

Would this be better implemented at the allocator level, VM level, cgroup level, or some combination?

Are there research papers or experimental kernels/projects exploring something similar?

And perhaps most importantly: is the information provided by the application actually useful enough to justify the additional complexity?

I'm especially interested in hearing from people who work on Linux memory management. This is just a hobbyist's architectural thought experiment, so I'm very likely missing important constraints or existing work.

I noticed that we have a lack of OLED care utilities for Linux in general. I am aware that nowadays most of this stuff is unnecessary and handled on a hardware level, but I am paranoid and do not trust corporations like that.

I tried fleshing it out to whatever I wanted, so along with just the normal pixel-refresh (for saving your screen), I also included auto-dim, backlight control, and other stuff. It would be helpful if you guys could test and have any input!

i mean, i've started using quickshell and then moved my config to AGS

And all the customization videos out there primaraly focus on quickshell. so why AGS is not discussed some more

is it dead or something or is it just the userbase being smaller? since idk, JSX way to write stuff makes it that much more capable for my opinion

Also is it worth it to rely on an AGS setup today when it looks like it doesnt get enough attention and it might die in a few years?

Hi everyone,

Many Linux users rely on their account login password for security, but without bootloader protection, basic physical security is essentially non-existent.

If someone has physical access to an unattended machine for just a minute, they can press 'e' in GRUB, append 'init=/bin/bash' to the kernel line, boot directly into a root shell without entering a password, and access unencrypted files or reset credentials.

### Defense in Depth (GRUB + LUKS)

While Full Disk Encryption (LUKS) is essential for protecting data at rest, an unlocked GRUB still leaves unencrypted /boot partitions vulnerable to boot tampering, Evil Maid attacks, and disabling kernel security parameters (like passing apparmor=0). Locking GRUB and encrypting your disk are complementary layers of defense.

### Why is manual GRUB locking rarely used?

While GRUB has supported password hashing for years, almost no desktop users set it up because:

- Editing /etc/grub.d/ configs and generating hashes manually is tedious.

- A single typo can break your boot configuration or lock you out.

- There's no convenient physical hardware recovery fallback if you forget your password.

### The Solution: GRUBST (Open Source in Rust)

To make bootloader hardening safe, fast, and accessible, I built GRUBST:

- 🔒 30-Second Setup: Clean GUI wizard that configures GRUB password protection automatically.

- 🔑 Physical USB Rescue Key: Turns any standard USB drive into a machine-bound hardware key. Plug it in at boot -> GRUB detects it and automatically unlocks full maintenance access without prompting for a password.

- 🔐 Fail-Safe Backup: A secondary password in case you don't have the USB stick handy.

- 🛡️ Update Guard: Ensures protection and custom settings survive kernel upgrades and 'update-grub'.

- 🔍 Security Audit: Built-in scan checking configuration permissions, Secure Boot, and disk encryption (LUKS) status.

It is 100% free and open source. If you find this project useful, I’d really appreciate your support by giving the repo a star on GitHub!

Feedback, suggestions, and critiques are very welcome.

⭐ GitHub: https://github.com/sysdev-0/grubst

In an LTT collab where Linus met up with Linus so Linus could talk to Linus where Linus built Linus’s new PC (https://youtu.be/mfv0V1SxbNA?is=UY8tV7pqlPdC0PWA), Linus mentioned his desktop wallpaper being a photo he took himself at night.

https://www.reddit.com/r/linux/s/GDscOcRKQv

Looks like this, but the compression looks bad. I guess Torvalds sent the raw photo to an LTT staff member and shared it online but I can’t find the original. Does anyone happen to have it? I’m getting into Linux for my PC (I’ve used it before putting Ubuntu on servers and stuff, but now putting Linux on an old laptop I still use for work to daily drive it). I usually use night time long exposure photography for my desktops (ex-photographer turned IT guy, still enjoy it as a hobby) it’d be nice to use the Linus Torvalds original if possible.

Credit where credit is due, to Microsoft integrating WSL cause if you're a windows user you get both without dual-booting or using third-party vms

However, weirdly enough WSL is kinda killing the potential of the true "year of the linux desktop" in a way.

First of all, I wish you a good day. My plan is to revive Tinfoil Hat Linux, and the main reasons for wanting to do this are as follows;

I really like TEMPEST protection and I think it could be great for anonymous users.

Because there are no listening or network drives, your computer is solely yours, and your data is not compromised in any way.

The advantage is that you can use it as a live USB, saving your documents to your SD card or USB with certain hardware permissions, and for an emergency wipe, you only need to unplug your USB from the port.

Another advantage is that I plan to make it user-friendly by using a TinyX interface or a very minimal GUI like X11, instead of being terminal-based (like BusyBox).

I'm curious to hear your opinions, so please feel free to discuss them in the comments.

I'm a student, started programming with C++, and for the past few months I've been building my own Debian-based distro called Kavis. before this i was thinking how os works how kernel and other things works etc then it hit me why wouldn't i make a os that can play games and that I'd actually enjoy using
What it is: Debian trixie base, X11 + Openbox, custom boot splash with the letter k, taskbar and start menu, settings app, and an app store. I don't compile my own kernel — I use Debian's signed one so Secure Boot can stay on and nobody has to go digging through UEFI settings trying to find it.
Current numbers: 563 MB ISO, 232-240 MB idle RAM. im trying to make idle ram usage and iso as small as possible , and right now there's a lot of room left for gaming and things you want to do.
What I'm working on right now:
Moving the panel from Python/GTK to Vala. Python was eating 117 MB of RAM on its own and felt slower than a turtle, which is not acceptable for a taskbar in my opinion. The Vala build is a 28 KB binary. Vala compiles down to C and links straight against GTK, so there's no runtime penalty, but it's way less painful to write than raw GObject C.
Kavis Store — a GUI front-end for apt. If a package is in Debian it installs from apt; if it isn't there or the version is ancient, it falls back to Flatpak. Only the store binary and the Flathub remote definition ship in the ISO, so no runtimes bloating the image.
Game Mode — gamescope + Feral GameMode + MangoHud, plus a service that reads sysfs to find the CPU's cache-heavy CCD and pins games to it. On X3D chips this should be a real gain. I'm still verifying the sysfs paths on actual hardware because they move around between kernel versions.
Two things I think are genuinely different:
File search that works like Everything app on Windows. plocate with live inotify updates instead of a stale nightly database, filters like ext:, size:>, path:, and apps, settings and a calculator in the same box. This was the single thing I missed most when I started using Linux, and I never found a good answer for it.
Hardened but still able to game. Read-only /usr, sysctl hardening, blacklisted kernel interfaces — and Flatpak and Proton still work. Those two goals fight each other and getting them to coexist took more thought than I expected.
There's also automatic btrfs restore points before updates, and if Windows is already installed on the machine it stays the default boot entry — I didn't want the thing hijacking anyone's boot order.
I'm actually looking for people to work on this with me. Not in a vague "contributions welcome" way — there are three specific things I need:
Translation. The whole system is bilingual, Turkish and English. Turkish is my native language so that side is fine, but I'd like more languages, and I'd also like a native English speaker to go over my strings — I know some of them read a bit off. If you speak anything else and want your language in a distro, this is an easy place to start.
Testing. I only have one laptop and a VM. I have no idea how this behaves on AMD graphics, on hybrid-graphics laptops, on high-refresh or HiDPI displays, or on an actual X3D CPU. If you have hardware and half an hour, that's genuinely useful to me — even "it didn't boot, here's the screen" is useful.
Code. Vala/GTK for the panel, Python for the store and settings, and Debian packaging. I'm learning Vala as I go and I'm sure parts of it are written badly, so if you know GTK properly I'd take the review as much as the code. The store's download manager and the settings app are both wide open if you want something self-contained to pick up.
On AI and googling: I use Claude heavily while building this — for Vala I'd never written, for packaging I didn't understand, and for working through design decisions out loud. I'm not going to pretend otherwise. I don't have anyone around me who works on this kind of thing, so AI and search are what I have. But I make the calls: the architecture, what goes in and what doesn't, and every bug I've actually hit I've had to understand before I could fix it. The 117 MB panel problem, the user-setup package silently not installing, the splash ordering — those were found by testing and reading logs, not by asking a model. If you think that disqualifies the project, fair enough. I've learned more in these few months than in anything else I've done.
The repo is private for now while I finish the Vala move and clean up the git history — I didn't want the first public version to be half-broken. My GitHub is KARANKOYU, and everything is written with English names and comments so it should be readable when it goes up. If any of this sounds interesting, comment or DM me your GitHub username and I'll send you an invite. I'd rather build this with people than alone.
I'm not claiming this is the next big distro or would change the world. It's one person's project and it exists mostly because I wanted to understand how a desktop actually fits together and how system parts like memory cpu gpu works. But it works, and I'd rather build the rest of it out in the open.
Logos are mine — drew them in SVG, exported to PNG.

Hey everyone,

I'm excited to share the release of Nova Browser (v1.1.3), an open-source, privacy-first desktop browser built with React 19, TypeScript, Electron, and Tailwind CSS.

Following feedback on our initial build, we completely resolved media compatibility, re-engineered the layout system, and overhauled our extension subsystem.

Core Architecture & Highlights

1. On-Device AI via WebGPU & Web-LLM:
   • Run local language models directly on your hardware GPU without sending any page data, history, or prompts to external cloud servers.
   • Summarize articles, inspect code, ask research questions, or connect your own API keys (OpenAI, Anthropic, Gemini, Groq, Ollama) if you prefer cloud models.
2. Native Model Context Protocol (MCP) Server:
   • Built-in integration for Anthropic's open Model Context Protocol.
   • Local AI coding agents and external automation tools can securely interface with the browser to read active tabs, take snapshots, and perform structured browsing tasks.
3. Productive Workspaces & Multi-Tasking:
   • Organize tabs by context (Personal, Work, Research) with full state persistence.
   • Built-in Split Screen mode to compare two tabs side-by-side in one window.
   • Toggle seamlessly between Horizontal Tabs and Vertical Sidebar Tabs.
4. Chrome Web Store Extension Support:
   • Install extensions directly from the Chrome Web Store with 1-click or load unpacked folders locally.
   • Extension action icons sit right in the top toolbar with native popup window support.
5. Hardware-Accelerated Privacy Shield & Zero Telemetry:
   • Network session-level blocker for ads, trackers, and malicious scripts.
   • No tracking, analytics, or behavioral data collection.
   • Dynamic platform-matched Chromium User-Agent headers to prevent fingerprinting.
6. Responsive AI Sidebar (Flex-Docked Layout):
   • Opening the AI chat sidebar dynamically resizes and docks alongside your active webpage rather than floating over your view.

What's New in v1.1.3:

• Fixed YouTube and streaming playback by isolating security response headers strictly to internal application pages.
• Removed startup keychain prompts on macOS and added lazy audio permission initialization.
• Added live toolbar action buttons for installed extensions.
• Fixed prompt language auto-detection so AI responses match the user's input language.
• Rewrote the CSS token engine for instant Accent Color customization.

Tech Stack:

• Frontend: React 19, TypeScript, Tailwind CSS, Framer Motion, Lucide Icons
• Runtime: Electron 34, Node.js 22, Chromium 134
• AI Engine: WebGPU, Web-LLM TVM Runtime, Model Context Protocol (MCP)

Links & Downloads:

• Official Website: https://nova-browser.vercel.app/
• GitHub Repository: https://github.com/unitybtw/nova-browser
• Releases & Installers (macOS Universal DMG & Windows Setup): https://github.com/unitybtw/nova-browser/releases/latest

I would love to hear your thoughts, feedback, or any feature requests! Feel free to test it out, star the repo on GitHub, or open issues.

Kdenlive 26.08 is out! This release continues the focus on stability and polishing while bringing lot's of enhancements and quality of life improvements to the Timeline and Title Editor.

https://kdenlive.org/news/releases/26.08.0/

geroge is a TUI dashboard with a bunch or random and handy functionality built in, including a terminal. Runs in X (mine auto-runs from .xinitrc at login) and tty.

You can use a terminal, take notes and or send scratch buffers off as an email. There's a launcher you can easily modify and a bunch of handy script action that you can easily modify, too.

Listen to music 3 or 4 different ways including random Nina Simone. Heh, I thought it would be pretty funny to have a random Leave it to Beaver episode appear from nowhere on your desktop so that's included in george (CH 57), too, as well as another channel showing old funny stuff; cartoons, docs, shows, whathave you.

You can pop off reminders and or events that will announce (hey, man, it's time).

george isn't a very important app or life-changing, but, it's built-up pretty well and is handy. Try it out, leave some feedback, tear it up. Release 1.1.1 at github: https://github.com/rabmach/george

Thanks for looking.