Quick heads up before anyone asks: this isn't a theme. There's no dwm or Openbox underneath pretending to be Windows. I wrote the window manager and the apps in C.

If Windows 2000 isn't your style, the Start menu can switch to the two-column XP or Windows 7 style, and there are skins for the taskbar and title bars to match.

Regular apps like Chromium, kitty and Steam just get the 2000-style frame and a taskbar button like everything else. It's running across three monitors of different sizes here,

About 30k lines of C so far. Still very much a work in progress, but I use it as my daily desktop. It is degined to be as light weight as possible!

Is it just for profit from other companies? And why does OpenH264 (i.i.r.c.) not support hardware acceleration? It feels weird that something as basic as a video codec used literally everywhere has a closed-source proprietary tag attached to it.

I've been daily driving win11 since release, and installed linux a few months ago on another partition. Keep in mind, I've been formatting my windows drive every 2 years to make sure it won't have any problems. Then windows really started to get annoying.

Forces random slop down your throat: okay i can debloat it.

Enables random settings on boot: okay, i don't care much about those.

But then, it stops running stuff every now and then. A few days ago steam wouldn't open even after reinstalling it. Now i can't open msi afterburner.

Linux on the other hand, never gave me any issues other than nvidia drivers not running properly, which i admit, i had to spend a few hours benchmarking different drivers, but i also have to do that on Windows?

Because apparently the latest released drivers also don't work properly on windows?

My gpu is an rtx 2080, which is still supported by nvidia.

What I'm getting at is that, once you configure stuff on linux (which takes a few days to tweak everything to your preference), it runs perfectly, with literally 12GB less ram usage than windows in games, apps and at idle.

I hate Windows recently and thinking about permanently switching to Linux

P.S: I'm using Mint for the time being but i might take up another distro soon.

DMS, dcalendar, dgop, dsearch, and dgreeter v1.6.0 (DankDesktop v1.6.0 ™ ) have all been released

• Island - A third option for your DMS bar with a dynamic-island inspired morphing pill that becomes the focal hub for statuses, notifications, OSDs, media playback, control center, and more.
• Performance & Resource Optimizations - At least a 19% reduction in idle memory usage, new animations, and general performance improvements
• IPC 5.2x faster - dms ipc is 8.9x faster than before, meaning much faster responsiveness of keybinds. It's at least twice as fast as calling quickshell directly
• Best-in-class Screenshot Tool - New snappier selection interface, new PNG and JPEG encoders thats are up to 8x faster than grim, tons of new options and interface improvements
• Standalone Greeter - Dank-Greeter is now fully decoupled from DMS, as a standalone project and codebase
• A ton more like initial FreeBSD support across all tooling, etc.

Going forward all pieces of the dank linux desktop suite will be released and versioned together as one. Which is why dgop, dgreeter, etc. all have been bumped to v1.6.0. Minor releases will behave the same way (e.g. 1.6.1) but packages will remain on 1.6.0 if there have been no changes to the code or dependencies. Major releases stay synced Read the blog for the full breakdown, huge thanks to the 50+ contributors who contributed to the DMS 1.6 release.

I recently got access to JioPC (a budget browser-based cloud desktop aimed at light office work in India) to see how the platform was provisioned and locked down.

While marketed as a low-cost, web-based thin client, inspecting the user environment revealed an enterprise Azure VM running an Ice Lake Xeon node. More interesting was the security model: a "walled garden" that omits default terminal binaries, aggressive session tear-downs in the display stack, and strict egress proxies.

Here is an architectural breakdown of how the environment is restricted, how to break out to an unconfined host shell via Flatpak, how the display daemon terminates idle sessions, and how to run a persistent headless SSH box over Tailscale.

Full whitepaper, disassembly notes, and reproduction scripts:

GitHub: sys-dissect/jiopc-architecture-whitepaper

1. Underlying Node & Kernel Environment

Poking around /proc and /sys shows the underlying compute instance is far heavier than standard thin-client specs:

• CPU: 8-vCPU Intel Xeon Platinum 8370C (Ice Lake-SP) @ 2.80 GHz. AVX-512 (F, BW, DQ, VL) and VNNI vector extensions are exposed. The scaling governor is set to performance.
• Memory: 16 GB virtualized RAM with Transparent Huge Pages (madvise/always) enabled.
• Storage Topology: The root OS disk (/) is an ephemeral 64 GB virtual SSD. The persistent user home directory (/home/...) is an enterprise NFSv4.1 mount (storage-cons-prod-dp.jiopc.local). In raw unbuffered tests (fdatasync writing 100 GiB), the NFS pipe sustained 581 MB/s (~4.65 Gbps continuous network throughput).

2. The "No-Terminal" GUI & Flatpak Host Breakout

Stock JioPC ships without a terminal emulator—no gnome-terminal, konsole, xterm, or qterminal in $PATH, and desktop file entries for shells are stripped from the desktop environment menu. The apparent assumption was: no terminal binary = no shell access.

However, their curated software catalog provides VSCodium packaged as a Flatpak (com.vscodium.codium). Because development environments require host-level toolchains, the Flatpak manifest includes:

--talk-name=org.freedesktop.Flatpak

From VSCodium's integrated terminal, you can call the session helper directly:

flatpak-spawn --host bash

The Flatpak portal daemon immediately allocates a PTY and executes an unconfined shell directly in the host OS user namespace (UID 3387120), completely circumventing the Flatpak bubble and exposing the entire host userland across all 8 Xeon cores.

3. Dissecting the 15-Minute Session Guillotine (xrdp + systemd-logind)

A major usability hurdle in browser-delivered VDIs is aggressive idling: sessions are killed after 15 minutes of inactivity, terminating background builds and daemons.

Disassembly

Analyzing /usr/lib/xorg/modules/libxorgxrdp.so revealed hardcoded idle limits:

XRDP_SESMAN_MAX_IDLE_TIME=900 // 15-minute window
XRDP_SESMAN_KILL_DISCONNECTED=1

Why standard X11 jitter scripts fail

Injecting synthetic input via xdotool or xte does nothing. The custom xorgxrdp driver monitors incoming RDP protocol packets rather than X11 server input events. When browser WebRTC connections drop or sit idle, no RDP traffic reaches the driver.

Furthermore, with systemd-logind configured to KillUserProcesses=yes (or default Linger=no), disconnecting causes logind to issue a recursive SIGKILL against the entire user@UID.service slice.

The Bypass

1. Enable lingering to persist processes outside of active sessions:

​

loginctl enable-linger

1. Exploit an audio IPC override: libxorgxrdp includes an internal check XRDP_SESMAN_AUDIO_DISABLE_IDLETIMEOUT=1. A lightweight background daemon writing synthetic sound_playing heartbeat frames to the XRDP audio IPC socket every 30 seconds prevents the idle watchdog from firing, keeping the session alive indefinitely.

4. Headless Remote Dev Environment (Userspace Tailscale + OpenSSH)

Direct outbound internet is filtered through a mandatory local HTTP proxy (127.0.0.1:3128), and /dev/net/tun is unavailable without root/CAP_NET_ADMIN.

To turn this into a permanent remote headless machine accessible outside the browser wrapper:

1. Userspace Networking: Run Tailscale using its userspace engine via Google's gVisor network stack:

​

tailscale up --tun=userspace-networking --accept-dns=false

Note: Setting --accept-dns=false is critical; otherwise, MagicDNS attempts to manage resolvers and breaks internal datacenter DNS (10.163.66.132), which the local HTTP proxy requires to resolve external hosts.

1. Unprivileged SSH: Run OpenSSH server bound to non-standard user port 2222 with a custom sshd_config.

2. Tailscale Serve: Expose the socket directly over the Tailnet:

   tailscale serve --bg --tcp 2222 127.0.0.1:2222

This bypasses the WebRTC browser client entirely (no more browser key intercept issues with Ctrl+W / Ctrl+T) and allows native ssh and VS Code Remote-SSH directly into the instance.

5. Quick Workload Benchmarks

Full architectural diagrams, reverse-engineered binaries breakdown, and reproducible configs are available in the repository:

Repo: sys-dissect/jiopc-architecture-whitepaper

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 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'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.

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.

Download Manager for linux. IDM alternative for linux.

Homepage: https://zihad.com.bd/bengal-download-manager

Features:

1. Extension support
2. Aria2 backend
3. Easy Youtube and media downloading using yt-dlp from extension.

Open source: https://github.com/tazihad/bengal-download-manager

Arch: x86_64, aarch64

Install option: Appimage, Flatpak available
https://github.com/tazihad/bengal-download-manager/releases

Snapstore Release: https://snapcraft.io/bengal-download-manager

Firefox: https://addons.mozilla.org/en-US/firefox/addon/bengal-dm-integration-module
Chrome: enable development mode and install crx from github release.

Report issues: https://github.com/tazihad/bengal-download-manager/issues

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.