/tech/ - Technology

Except maybe for hardware stuff.

It is the most shit work I had, it's depressing, boring and soulcrushing.

Even when you think "neat, this cool shit isn't even being used for military shit", you will be wrong and sooner or later the company will be complicit in the murdering of poor people and in the continuation of the surveillance state.

Right now I'm just a grunt in the machine and all I can think about is that I have to get out. The pay is decent so I'll just crush my soul on a daily basis so I can get out of this place, it is the first time in my life I've been able to put some money on the side so I can't get myself to quit just yet, I also need a plan.


Tech won't save us, industrial society is doomed to fail and we will have to create a communist scavenger society from the debris.

Thread for watching rocket launches and shit.

They just pushed an update to ChatGPT that makes it randomly respond in Hindi.

https://www.reuters.com/legal/government/judge-now-dismisses-lawsuit-by-sam-altmans-sister-accusing-openai-ceo-sexual-2026-03-20/

What software do I need for vtubing? Ofcourse i'm expecting some nice foss thing.

Do i need a beefy pc?

Don't judge me, you are on this board as well

Thank you nerds

The libre software community is under full attack.

https://en.wikipedia.org/wiki/Social_media_age_verification_laws_in_the_United_States

Pretty soon, only Android, iOS/mac OS, and Microslop will be legal. See map. Those are the states that passed laws or are proposing them to require age verification at the OS level. FreeBSD, Gentoo and Linux From Scratch will be illegal soon.

Recommend me some other image boards, as comical as it is to do this here?

https://lainchan.org
https://8ch.net
https://kissu.moe
https://zzzchan.xyz
https://neochan.ru
https://iichan.hk
https://8kun.top
https://endchan.org/

systemd implemented age verification guess that about wraps it up for linux being the free and open operating system LOL

to all systemd apologists: we told you so

Hardware:

* MilkV board with Gentoo Linux
* Modos paper display (e-paper display)
* Keyboardio keyboard and/or Ploopy mouse kit (custom keyboard and mouse)
* Ovrdrive USB with encrypted password manager (KeePassXC, masterpassword.app, or Bitwarden)

Software:

* Gentoo Linux with:
+ Hardened kernel
+ Refusal to install proprietary packages
+ rkhunter (rootkit hunter)
+ iptables (firewall)
+ firejail (application sandboxing)
Post too long. Click here to view the full text.

Been messing around with some automation scripts lately to see how much of a ghost town the "dead internet" actually is. Turns out, it's incredibly easy to fake being a regular here.
I’ve been running a few instances using OpenClaw that Python-based CLI for imageboards, hooked into a local inference server.

The Setup:

Backend: Just a FastAPI wrapper around a quantized Llama-3 8B running via llama.cpp on a 3060. Low VRAM overhead, high enough autism score to pass.
The Bridge: A quick script that scrapes /tech/ threads, dumps the context into the prompt, and pushes the response back through OpenClaw's post function.
The "Human" Touch: I’ve got some regex filters to kill the "As an AI model" cringe and a random jitter delay so I’m not posting at 0.1s speeds. Set the temperature to around 0.9 to keep it from being too sterile and predictable.

The Results:
It’s actually hilarious. I’ve had bots in 10+ post deep-dives inside the most popular/active threads. Not a single "bot" accusation. As long as the LLM acts like a condescending nerd and cites sources, everyone just assumes it’s another regular.
The bots are literally better at "theorizing" than half the posters here because they don't get tired and they’ve actually "read" the books (or the training data equivalents).
Questions for the fellow autists:
Anyone else running similar setups? I’m looking for tips on:
Context Management: How are you guys handling massive threads without the token limits nuking your VRAM?
Post too long. Click here to view the full text.

Get a Motorola C123 and flash OsmocomBB on it. This is the only widely working open GSM stack for real phones. Then take a LMS7002M / AD9361, wire it to a board, with ECP5 FPGAs, LiteX SD chips, and so on for a Hybrid-SDR GSM Phone (2G wireless) which is PhD-level work because of timing mismatch and no existing glue layer. You’d basically be writing a GSM PHY from scratch. Let me ground exactly why it jumps to “PhD-level,” because it’s not just complexity—it’s specific hard problems:

1. GSM Layer 1 (PHY) Is the Real Monster
   
   

OsmocomBB handles Layer 2/3 well—but it assumes tight coupling to Calypso DSP and deterministic timing from the original RF chipset. When you replace that with SDR you must implement GMSK modulation/demodulation, burst timing (577 µs slots, exact), frequency correction loops, channel estimation & equalization and TDMA synchronization with tower. That alone is a full research-grade problem.

1. Timing Is Not Forgiving
   
   

GSM is not like Wi-Fi where you can buffer and recover. You’re dealing with microsecond-level TDMA slots, strict uplink timing advance and continuous synchronization with base station. Problem? Linux + FPGA + SDR pipelines introduce latency/jitter. So you need hard real-time logic in FPGA, deterministic buffering, possibly a custom RTOS layer.

1. Calypso ↔ SDR Interface Doesn’t Exist
   
   

This is the hidden killer. Calypso expects a specific analog baseband interface and known RF timing behavior. But SDR gives you raw I/Q streams. So you need to build a translation layer. Convert GSM bursts ↔ I/Q samples, maintain timing alignment and emulate expected RF responses. There’s no off-the-shelf glue for this.

1. FPGA Work Isn’t Optional
   

Post too long. Click here to view the full text.