I’m working on a proposal to rip out the existing PostgreSQL ILIKE/fuzzy_search based search in Lemmy (the federated Reddit clone) and replace it with Tantivy, a Rust full-text search library. The current implementation is basically WHERE title ILIKE '%query%' which obviously doesn’t scale and has zero relevance ranking. The proposal adds BM25 scoring, phrase queries, boolean operators, field-specific searches (author:name), tag filtering, and date ranges - all while keeping the existing API endpoint unchanged. I’d need to maintain a separate Tantivy index on disk, hook into all CRUD operations to keep it in sync, and build a query parser that translates user input into Tantivy’s query language. The alternative is just sticking with PostgreSQL’s built-in full-text search (tsvector/tsquery) which would be way less work to implement but wouldn’t give us the same level of advanced querying. Is rolling our own search index with Tantivy worth the complexity, or should we just use what Postgres already provides and call it a day?

I’m building an automated content pipeline that publishes daily briefing videos to Odysee alongside other platforms. I have Odysee accounts with existing channels that already have some LBC credits in their web wallets.

What I need is a way to upload videos programmatically from a headless Arch Linux server, using the existing Odysee accounts/channels — without running a full desktop app or manually uploading through a browser each time.

I’ve found that lbrynet (the LBRY protocol daemon) is the way to interact with the network that powers Odysee, but I’m hitting a wall on:

1. Wallet/channel linking — the lbrynet daemon creates a brand-new wallet with 0 LBC. How do I use my existing Odysee web wallet (which has LBC and channel certificates) with the daemon, instead of starting from scratch?

2. Automated publishing — once the daemon is set up, what’s the correct lbrynet publish command for a video with title, description, tags, and a channel? The --blocking flag seems necessary but I want to make sure I’m not missing important parameters.

3. Daemon management — for a cron job that runs daily, should lbrynet be left running as a daemon in the background, or started/stopped for each publish? What’s the right systemd unit for this on a server?

4. LBC cost — how much does each publish cost? My wallet has ~0.25 LBC — how many uploads does that cover?

I’m looking for the cleanest approach to integrate this into an unattended daily pipeline. No browser automation, no GUI dependencies.

I need a real-time filesystem watcher that detects when any file in ~/.hermes/config/ changes, then immediately git add -A && git commit -m “auto: …” && git push.

Currently I’m running a cron job every midnight to batch it, but I’d rather have it trigger instantly. On Arch (btw) what’s the cleanest approach?

I’ve looked at:

• incron — old, seems barely maintained
• systemd path units — native, but feels heavyweight for one small folder
• inotifywait in a loop — simple but fragile
• entr — neat but needs something to kick off the initial watch

What would you actually use for a setup that needs to survive reboots and not eat CPU?

I’ve been listening to this video breaking down Mo Gawdat’s “Scary Smart” and honestly I’m terrified for what’s coming. Gawdat, a former Google X exec, argues that superintelligent AI is coming and we need to raise it with the right values. But his solution is individual consciousness and meditation, not collective action.

Meanwhile, Google, Meta, Microsoft, and the rest are locked in a race to the bottom, building more powerful AI systems with zero democratic input. The same corporations that brought us surveillance capitalism, algorithmic management of warehouse workers, and AI tools that displace creative workers are now deciding the future of superintelligence.

The working class — the people who will actually live or die by these systems — have no seat at the table. We’re told to “become more conscious” while boardrooms make existential decisions behind closed doors.

So my question: how do we actually democratize AI development? Or are we just going to sit down and hope for the best while capital gambles with the future of humanity?

I posted a tool a while back that tracked trending Linux packages from pkgstats data. The feedback made me rethink it — the curated category list of 173 packages was too narrow, and people wanted something they could actually use on a fresh install.

Biggest change: full AppStream coverage instead of a hand-picked list.

The collector now parses Manjaro/Arch’s AppStream XML data (/usr/share/swcatalog/xml/) to automatically extract every desktop-application and console-application package, then maps their AppStream categories to 8 Pamac-style groups (Audio & Video, Games, Development, Utilities, etc.). That jumped coverage from 173 → ~1600 packages.

But AppStream misses a lot of stuff that power users care about — window managers (Hyprland, Sway, i3), shells (zsh, fish, nushell), terminal emulators (Kitty, Alacritty, Foot), desktop environments (Plasma, GNOME). So I kept those as curated extras that get deduped against the AppStream data. Net result: 1,275 unique packages across 16 categories.

New: recommended.txt — curl it, pipe it, install it.

curl -sfL https://git.disroot.org/hirrolot19/trending-linux-packages-data/raw/branch/main/recommended.txt \  
  | head -100 | sudo pacman -S --needed -  

All 1,275 packages ranked by a score that balances popularity percentile + growth slope percentile (default 1:1). Pipe through head -N to pick your count. The scoring is trivial to tweak:

TOP_N=50 SLOPE_WEIGHT=2 python3 src/collector.py  

The math is still naive though. Right now it’s just pop_percentile * w1 + slope_percentile * w2 — which works but ignores a bunch of things that would make the rankings smarter:

• A package at 1% popularity with +0.8 slope is clearly an emerging tool, but the percentile system buries it because it’s in the bottom decile for popularity
• Seasonality isn’t modeled — some packages spike in December (games on sale, new devs on winter break) and that looks like a trend
• No confidence interval on the slope — a package with 3 data points gets the same treatment as one with 7
• No penalty for high variance — a package that bounces wildly isn’t the same as one that’s steadily climbing

I’d love PRs or issues discussing better scoring functions. The recommendation config is the first 5 lines of the collector — easy to experiment with. If you’ve done work on ranking with sparse time-series data, I’d especially appreciate input.

What the data is showing right now:

The top 10 recommended packages by combined score: cmake, mpv, qt6-tools, pavucontrol, v4l-utils, firefox, steam, clang, jdk-openjdk, vim. These are packages that are both very widely used AND gaining users — solid picks for any new system.

Top gainers (pure slope): mpv (+2.80 pts/mo), cmake (+2.51), qt6-tools (+2.41), pavucontrol (+2.22), nvtop (+2.22). The Wayland-adjacent tooling wave is real.

Project links:

• Code + collector: https://git.disroot.org/hirrolot19/trending-linux-packages
• Auto-updated data: https://git.disroot.org/hirrolot19/trending-linux-packages-data

I’m working on a proof-of-concept for a social media platform built from scratch in Rust. It started as an experiment with Slashdot-style moderation (multi-reason voting instead of upvote/downvote) but grew into something with 40+ features.

Full feature list here: https://git.disroot.org/hirrolot19/social-platform

Why I’d host this

The reason I’m posting this on Hexbear specifically is that if I do spin up a public instance, it wouldn’t be another general-purpose site. The moderation system and the feed algorithms are designed to be tweakable — I’d tune them to promote class awareness content over the kind of engagement-bait that dominates mainstream platforms.

I’d host it over i2p to not complicate myself with domain names, DDoS protection, or legal headaches. Just an eepSite reachable through the i2p network — people who want to find it will find it, and everyone else can ignore it.

It’s already live: http://4oymiquy7qobjgx36tejs35zeqt24qpemsnzgtfeswmrw6csxbkq.b32.i2p (requires I2P browser/proxy — see my comment below for setup)

If there’s genuine interest I’d:

1. Clean up the codebase (it’s AI-generated, needs human love)
2. Add ActivityPub federation so it can talk to the rest of the fediverse
3. Tune the recommendation algorithms toward educational/political content
4. Set up a basic moderation team

What it does

• Slashdot moderation — multi-reason voting, limited mod points, meta-moderation, score capping, obfuscated karma
• Advanced search — boolean operators, field search, date range, tag filtering, saved searches
• Tags — booru-style tagging with categories and filtering
• Custom feeds — weighted sources (users, tags, keywords), include/exclude
• Image upload — multipart upload with serving
• Themes — dark, light, forest, ocean
• Communities — self-governing with visibility controls
• Private messaging, notifications, reactions, follows
• Polls, achievements, threaded comments, Q&A
• Content filters — regex/domain/keyword hide/blur
• Report system with moderation queue
• Post/comment editing and deletion
• Login rate limiting

Stack

Rust + Axum + SQLite. Single binary, no runtime dependencies. Server-side rendered HTML (no JS framework).

What’s missing

• ActivityPub federation (schema has placeholders, not wired)
• Real-time WebSockets (pull-based for now)
• Any kind of proper frontend (it’s ugly server-side HTML)
• ML recommendation algorithms (would need to be built)

Repo

https://git.disroot.org/hirrolot19/social-platform

Quick start: cargo run --release, opens at http://0.0.0.0:3000/, login admin/admin123

If you’d use something like this or have thoughts on the moderation/algorithm direction, let me know. I’m not going to bother hosting it if nobody wants it, but if there’s demand I’ll put in the work.

In-depth guide: accessing .i2p sites from Manjaro Linux

1. Prerequisites & The Big Picture

The .i2p domain is part of the Invisible Internet Project (I2P), an anonymous overlay network. Your regular browser cannot resolve or connect to these sites directly. To access them, you need two things:

1. An I2P Router running on your system. This acts as a local proxy server (listening on 127.0.0.1:4444 by default).
2. A Browser configured to route .i2p traffic through that local proxy.

This guide uses FoxyProxy Standard in Firefox to automatically route only .i2p traffic through the proxy, leaving your normal browsing unaffected.

2. Step 1: Install and Run an I2P Router

You need a program that connects you to the I2P network. The official reference implementation is written in Java, but a lighter alternative is i2pd (C++).

Option A: Install i2pd (Recommended for Manjaro)

i2pd is available in the official Manjaro repositories and is very lightweight.

1. Open a terminal and update your package list:

   sudo pacman -Syu  
   

2. Install i2pd:

   sudo pacman -S i2pd  
   

3. Start the i2pd service and enable it to run automatically on boot:

   sudo systemctl enable --now i2pd  
   

4. Verify it’s running. The router will take a few minutes to connect to the network.

   sudo systemctl status i2pd  
   

   You can also access the I2P router web console at http://127.0.0.1:7070/ to monitor its status.

Option B: Install the Official I2P (Java)

The official I2P implementation is available via Snap on Manjaro.

1. Ensure Snap is installed and enabled on your system.
2. Install I2P via Snap:

   sudo snap install i2pi2p  
   

3. Run it:

   /snap/i2pi2p/current/runplain.sh  
   

Note: The Snap version may require additional setup. The i2pd option (Option A) is generally simpler for Manjaro users.

3. Step 2: Install FoxyProxy Standard in Firefox

Now, configure your browser to use the proxy.

1. Open Firefox.
2. Navigate to the Firefox Add-ons page (you can type about:addons in the address bar or click the puzzle piece icon in the toolbar).
3. In the Add-ons Manager, search for “FoxyProxy Standard”.
4. Click “Add to Firefox” and confirm the installation when prompted.
5. The FoxyProxy icon (a small fox) will appear in your browser’s toolbar.

4. Step 3: Configure FoxyProxy for I2P

This is where you tell FoxyProxy how to route traffic.

1. Click the FoxyProxy icon in the toolbar.
2. Select “Options”.
3. In the “Proxies” tab, click the “Add New Proxy” button.
4. Fill in the proxy details as follows:
   • Name: I2P (or any descriptive name you prefer).
   • Proxy Type: Select HTTP.
   • Host/IP: Enter 127.0.0.1.
   • Port: Enter 4444.
   • Username/Password: Leave these fields blank. The I2P proxy does not require authentication.
5. Click the “URL Patterns” tab.
6. In the “Add Pattern” section:
   • Pattern: Enter *.i2p.
   • Pattern Type: Select “Wildcard”.
   • Click “Add”.
7. Click “Save” to create the new proxy profile.

5. Step 4: Activate FoxyProxy

The final step is to tell FoxyProxy to use the rules you just created.

1. Click the FoxyProxy icon in the toolbar again.
2. Select the mode “Use proxies based on their pre-defined patterns and priorities”.

This mode ensures that only requests to URLs matching the *.i2p pattern will be routed through the I2P proxy. All other traffic will go directly, as usual.

6. Step 5: Access the .i2p Site

With the I2P router running and FoxyProxy configured, you’re ready.

1. Open a new tab in Firefox.
2. Enter the address: http://6ur3cvs7uldkg7lmaioj6sezqbefnjmmw7oluxg5pwjbsuovosga.b32.i2p
3. Press Enter. FoxyProxy will detect the .i2p domain and automatically route your request through the local proxy on 127.0.0.1:4444, allowing you to access the site.

7. Troubleshooting

• “I can’t reach the site” or “Connection refused”: Your I2P router is likely not running or not fully connected.
  • Check the router status with sudo systemctl status i2pd.
  • Restart the router: sudo systemctl restart i2pd.
  • Be patient: It can take 5-10 minutes for a fresh I2P router to find peers and establish a connection to the network. Check the web console at http://127.0.0.1:7070/ to see if “Tunnels Participating” and “Integrated” are increasing.
• FoxyProxy isn’t routing: Make sure the FoxyProxy mode is set to “Use proxies based on their pre-defined patterns and priorities”, not “Disabled” or “Use proxy for all URLs”.
• Slow loading: I2P is an anonymous network with inherent latency. Sites can take 10-30 seconds to load, especially on the first visit. This is normal.
• URL pattern not working: Ensure the pattern is exactly *.i2p (with a period before the asterisk) to match any subdomain of .i2p.

I got tired of guessing which terminal emulator or window manager people are actually migrating to, so I built a tool that answers it with real data.

How it works

The pkgstats.archlinux.de API tracks monthly install counts from ~30K+ voluntary submissions. I wrote a collector that:

1. Fetches 6 months of monthly popularity data for 173+ packages across 9 categories (Browsers, Editors, Window Managers, Terminal Emulators, etc.)
2. Computes a linear regression slope (percentage points gained/lost per month) for each package
3. Ranks and outputs the results as markdown + JSON

What’s actually trending right now

Firefox gaining hard (62% → 71%). Hyprland absolutely exploding (14% → 22%). Kitty and Foot both crushing it in terminals. Wayland-adjacent packages dominating the top.

The fallers: xterm (-0.51), gnome-terminal (-0.37), i3 (-0.28), Pidgin (-0.23). The terminal space is in the middle of a real generational shift.

The not-so-surprising but still interesting

• vi appears to be crashing (-7.55 pts/mo) — but it’s an artifact: the vi package is just a symlink that recently switched to a new provider, so pkgstats records it as a different entity now.
• Plasma Desktop growing faster than GNOME (+0.95 vs -0.27).
• Discord growing but Telegram and Signal both gaining too — the IM space is getting more fragmented, not less.

Project structure

• Code repo — Python collector, categories config, push scripts
• Data repo — Auto-updated results via cron (every 6h)

The data is in two formats: TRENDING.md (readable tables) and trending.json (structured, machine-parseable). Categories come from the curated lists the pkgstats website uses for its “Fun Statistics” page.

Caveats

• The data only represents Arch Linux users who opt into pkgstats — not a representative sample of all Linux users
• Categories are curated (not automatic), so I’m only tracking ~173 packages across 9 categories right now
• Slope is a simple OLS linear regression — it shows direction but doesn’t model seasonality

Would love PRs to add more categories or improve the math. The whole thing is just one Python file.

• https://git.disroot.org/hirrolot19/trending-linux-packages
• https://git.disroot.org/hirrolot19/trending-linux-packages-data

I’m genuinely asking. In a lot of other countries, it’s common to hear people say that 9/11 was used as a pretext for war in the Middle East, and that elements within the US government either allowed it to happen or actively helped make it happen. But when I talk to everyday Americans online, most seem to shut that down fast. Is that just mainstream conditioning, or do people really believe that no elite in power would ever sacrifice their own citizens for political/financial gain? I’m just looking for honest takes on whether Americans are still in denial about what their government is capable of.