intel won't allow its linux drivers to work above wifi 4 speeds in ap mode, so i created a kvm virtual windows machine with pci pass through on the wifi nic plus ip masquerade and now i'm getting wifi 6 speeds in ap mode.
Linux
From Wikipedia, the free encyclopedia
Linux is a family of open source Unix-like operating systems based on the Linux kernel, an operating system kernel first released on September 17, 1991 by Linus Torvalds. Linux is typically packaged in a Linux distribution (or distro for short).
Distributions include the Linux kernel and supporting system software and libraries, many of which are provided by the GNU Project. Many Linux distributions use the word "Linux" in their name, but the Free Software Foundation uses the name GNU/Linux to emphasize the importance of GNU software, causing some controversy.
Rules
- Posts must be relevant to operating systems running the Linux kernel. GNU/Linux or otherwise.
- No misinformation
- No NSFW content
- No hate speech, bigotry, etc
Related Communities
Community icon by Alpár-Etele Méder, licensed under CC BY 3.0
Oh god, this is horrible. I beg you to find a better solution 🙏
it's horrible in more ways that you would expect and what other solutions exist with intel wifi hardware in ap mode on linux?
I think NDISwrapper is still maintained for issues like this.
i wasn't aware that you could use ndiswrapper on an access point; i'll look into it.
UPDATE: googles says that you can't do this because ndiswrapper uses windows drivers that don't support ap mode.
My control key was broken, but I found that when I used an app and held down the space bar key, the CPU would get abnormally hot.
So I wrote an Emacs interrupt to interpret a rapid CPU rise as "press the control button".
Unfortunately the dev pushed an update that broke space bar heating, which broke my workflow. I opened a bug report about it, though...
That's horrifying.
Hey, my setup works for me! Just add an option to enable CPU overheating in the next update!
My mother uses some software that runs in the browser for her shop. It can print out receipts and scan items. To do these things it has a small "sattelite" application that runs on the system and interacts with the printer and scanner. This software only runs on Windows and Linux doesn't have drivers for the scanner.
When I switched her over to Linux and found this out in the process I wanted to stop, give up and install windows.
But then I had a stupid idea. I could run the sattelite program in a Windows VM and pass through the USB devices for receipt printer and scanner. The webapp uses requests to localhost:9998 to communicate with the sattelite so I set up a apache server that proxies these requests into the VM. I also prevented the VM from acessing the Interner so Windows doesn't update and screw everything up.
And it works. It has been in use for a week now and I've heard no complaints. I'm just praying to god it doesn't break
At least getting a snapshot of the Windows VM should be simple. And since it doesn’t connect to the internet and doesn’t update, restore should be quick and relatively easy.
Create a script to send important data records (if you need that for taxes or inventory data etc) as a nightly routine, that way you have a consistent database for any important records.
Then just create a restore point. If it breaks in 2 weeks, then you just relaunch it and know that it's going to kill itself in 2 weeks. A simple restart to that restore point solves everything.
Sounds 100% functional to me!
I like to use unclutter
to hide my mouse pointer after a few seconds without being moved.
Now, the thing is, it doesn't just visually hide the cursor, it actually removes it, so UI elements triggered by hovering disappear. Sometimes that's great, other times it's infurriating, like when reading a tooltip or menu.
I mostly use a touchpad, and so I developed a habit to wiggle my finger while I'm intentionally hovering something, so that there was enough mouse movement for unclutter
to not remove my pointer.
Then I found a setting for the jitter threshold of the touchpad. Basically, with the threshold on, it ignores tiny movements, because the hardware reports finger wiggling, even if you hold your finger perfectly still. Which is perfect for me to turn off.
Now when I have my finger on the touchpad, it automatically wiggles and allows me to read hover elements. If I take my finger off, it stops wiggling and removes the cursor.
It's almost like someone designed an OS with touchpads in mind, rather than them being an afterthought.
This certainly isn't of the same caliber as some of these other comments, but I found it to be fitting to the topic.
Last year I was having problems getting the game stellaris working on arch. (I use bazzite now, btw) My solution was the following:
- download the game via steam.
- switch it to use proton
- switch it back to linux version
- use the terminal to make the entire game folder read-only, so that steam couldn't touch the game anymore and screw it up.
- add the exicutable to PATH
- start the game via terminal
If any one of those step was left out, it didn't work. I'm no linux expert, so I didn't have the skills to actuality find the real problem.
I think this one beats them all.
My home server keeps a few services up, including an instance of Jitsi Meet. The server runs nixos and the nixos package for jitsi is incomplete to say the least and doesn't even support authentication, so I use the docker-compose version and I have a script that runs periodically to keep it updated. So far so good, right? Well, no.
Because the server is at home, I have a dynamic external IP address, so I have to use a DDNS provider, but jitsi doesn't expect this and uses a stun server at startup to determine the public IP of the server once, so if my connection goes down or is restarted and the IP changes, jitsi needs to be restarted or it won't work anymore.
The solution?
- My router runs OpenWrt, so I am able to run a script that checks for external IP changes. When a change is detected, it uses SSH to connect to my server to restart jitsi
- Because I don't want the router to just be able to run any command, I created a jitsi-restart user that has no shell
- When the router tries to log in with its pubkey, sshd creates a file called restartasap in the jitsi folder and closes the connection
- On the server, there's a systemd unit running a script as the jitsi user that periodically checks for that file, and if it exists it deletes it and restarts jitsi
I've been running this setup since mid 2020 and I expect this to continue until IPv6 becomes the norm.
I duct taped a Raspberry Pi to the back of a television once. Does that count?
I personally like this, so as far as I'm concerned, yes.
I have an old laptop running some basic services.
I have taken it apart before to replace the hard drive with an SSD, but I never replaced the dead CMOS battery because you have to literally completely disassemble it to get at the battery.
So I have a cronjob that runs on startup to change the system clock to the right time-zone.
It just felt simpler than completely disassembling a hard-to-take-apart laptop.
I have a folder full of scripts tied to aliases that fix various things when they go wonky, and I've long since forgotten what any of them do. I just know if xxx
app stops working, I type fix_xxx
into the terminal and then it does a bunch of stuff and then it works again lol.
Also I have a bunch of aliases tied to common tasks, like e1
= reboot, e2
= shutdown etc. I have no idea where that habit came from.
Edit: ALSO, just the general mish-mash of apps. I won't have anything to do with Snaps, but the rest of it is an unholy combination of native apps, things from the AUR, flatpaks, Appimages, Docker containers and wine setups, mostly (but not all) in Bottles.
I had to use unity game engine for one of my assignments for school, but unity wouldn't generate files needed for the language server unless I set the code editor to vscode. I fixed this by creating a bash script with the path /usr/bin/code
that opens neovim
in konsole
.
#!/usr/bin/env bash
konsole -e "nvim $@"
I'm using Gentoo with systemd and a customized kernel, and additionally I have the /usr
partition LUKS encrypted.
Because /usr
is absolutely essential for systemd to function, I configured dracut to make a specially crafted initrd which activates the luks lvm and prompts for the password to decrypt and mount /usr
on startup before systemd init tries to run.
About a year or two ago, some update to dracut or some other dependency (assumption) caused the dracut generated initrd's to kernel panic. After multiple days of troubleshooting, I discovered that just copying forward an older initrd in /boot
and naming it to match the new kernel, e.g. initramfs-6.6.38-gentoo.img
, allows the system to boot normally .
So, my Gentoo is booting a kernel 6.6.something
with a ramdisk generated in the 5.9
kernel era. I am dreading the day when this behavior breaks and I can no longer update my kernel 😳
Had a Centos VM that kept slipping time. Every week it would loose about 30min. No amount of NTP syncing got the time correct until manual intervention.
Msp couldn't work it out, couldn't rebuild the server for infrastructure reasons, and only that server had the issue. The other 3 VMs on that host were fine.
Cron job on one server took it current time, sshed to the dodgy server and configured the correct time.
An old (now decommissioned) notebook of mine had a broken headphone jack. I didn't have BT headphones then. Audio output worked technically but the detection whether headphones were plugged in or not did no longer work.
I wrote a very short amixer script to force unmute the jack, set the volume to 50 or so percent and set the speaker volume to 0% but not "mute" state. I could then use my wired headphones again.
BZ2-ing up a terabyte of zeroes (back when a TB was more than people commonly had, then zipping that file up together with another file, to bypass virus scanners in emails that prevent emailing .exe files.
I've also seen a self-referential .zip file somewhere that contains itself.
sssd didn’t work well with my company’s AD server, which would cause repeated authentication failures until I restarted sssd. I rigged up a bash script which would restart sssd any time xscreensaver logged an auth fail.
On my previous laptop, the trackpad had a bug that made it spam interrupts after waking up from sleep. It ruined battery life and basically kept one core at 100% permanently.
So I duct-taped a systemd script that unbound and bound the trackpad after each wake up.
#!/bin/sh
case "$1" in
post)
echo -n "i2c_designware.0" > /sys/bus/platform/drivers/i2c_designware/unbind
echo -n "i2c_designware.0" > /sys/bus/platform/drivers/i2c_designware/bind
;;
esac
I ran out of crtcs, but I wanted another monitor. I widened a virtual display, and drew the left portion of it on one monitor, like regular. Then I had a crown job that would copy chunks of it into the frame buffer of a USB to DVI-d adapter. It could do 5 fps redrawing the whole screen, but I chose things to put there where it wouldn't matter too much. The only painful thing was arranging the windows on that monitor, with the mouse updating very infrequently, and routinely being drawn 2 or more places in the frame buffer.
Youtube doesn't seem to inhibit idle for me for some reason, so my screen would always turn off with swayidle while watching youtube videos. So I made my lockscreen script (which is called by swayidle)
if [ "$(playerctl status)" = "Playing" ]; then
exit 0
else
exec "/path/to/lockscreen/script"
fi
(lockscreen script was just swaylock called with a bunch of arguments)
Not super crazy compared to some of the things people are saying in the comments, but also definitely not how you're meant to handle idle inhibition when media is playing lol
holy shit i was about to post about how i have automatic login and lock to start a program that refuses to work correctly on boot through systemd.
but then you guys are here casually posting some of the worst duct tape shit ive heard of so far. im not sure if i should reprimand or congratulate you for that jankiness.
I have a Logitech mouse with extra buttons, I used Piper to set one of those buttons to be Play/Pause media button. It worked well, however for some reason it only worked when the mouse was connected via the dongle, via Bluetooth the button did nothing. So I configured to a random shortcut (don't remember what it is now, something like super+p) and configured that to call playctl play/pause.
Not as creative or duct tapey as others but it's what I remember now, pretty sure there are many others too hahaha
So I use a surface device with the Linux surface kernel, and there was (and probably still is) an issue where the type cover doesn't properly rebind after being detached and re-attatched. To make matters worse, connecting other USB devices disconnected the type cover. My solution was to make a udev rule that detected if the keyboard is "removed" and then try to rebind it, effectively unplugging it and plugging it back in again in software.
Mounting a Samba share and moving my LVM pvolumes of / onto a losetup'ed file on it, while running the system. Bass ackwards.
Some years ago, I had a client with a really fucked up set of requirements:
- Must run Gentoo Linux. (No, I don't know why. But it was written into the project specs and everybody who had to sign off did.)
- Must use LUKS for FDE.
- Login (loosely interpreted as "booting up") must have MFA.
This was during the days when booting into a LUKS encrypted Gentoo install involved copy-and-pasting a shell script out of the Gentoo wiki and adding it to the initrd. I want to say late 2006 or early 2007.
I remember creating a /boot partition, a tiny little LUKS partition (512 megs, at most) after it, and the rest of the drive was the LUKS encrypted root partition. The encrypted root partition had a randomly generated keyfile as its unlocker; it was symmetrically encrypted using gnupg and a passphrase before being stored in the tiny partition. The tiny partition had a passphrase to unlock it. gnupg was in the initrd. I think the workflow went something like this:
- System boots up.
- Script in the initrd prompted the user for the passphrase for the tiny LUKS partition. (first authentication step)
- User entered passphrase.
- Script in the initrd unlocked the tiny partition and prompted the user for the passphrase to decrypt the root partition's keyfile stored therein.
- User entered the symmetric passphrase for keyfile. (second authentication step_
- Script used the passphrase to decrypt the keyfile to stdout, piped into an evocation of cryptsetup to unlock the root partition.
- /dev/mapper/root mounted, /boot mounted, boot process continued.
- User logged into the box.
I don't miss those days.
I created an SMS to Email gateway back in 2011 when data was still expensive on phones and I was trying to see if I could turn an iPod Touch into an iPhone. (I was a poor student at the time, was trying to find ways to save money 😅)
Basically I had a 3G modem plugged into a Linux server that could receive the messages, a prepaid SIM card with a long life credit expiry, a domain name set up with unknown email address capturing, and some tools to handle the actual SMS part.
At the time I published the scripts I used online and apparently they're still online 😅 This is on Whirlpool which is an Australian telecommunications forum.
I have a hardware malfunction with my secondary hard drive. Every once in the while it locks itself into read-only mode and corrupts a log file that crashes my system. My solution is to reboot Fn + Alt + Sysrq + 'b' and periodically delete the log files that exacerbate the issue. I need to replace the drive but that requires money and a backup solution, neither of which i currently have. It's been an ongoing issue for at least 4 years now.
I made a systemd script that fires when going to / waking up from sleep - it checks how long the sleep was and if it was just a few seconds, it puts the computer back to sleep.
In hindsight, I think the thing that made it work was bluetooth was somehow responsible for the initial failed suspend. The second shot at sleep happened before bluetooth came back up, so it succeeded.
Not me personally, but in one of my past project, my boss was running a bunch of "services" by leaving it on GNU screen terminal sessions and detaching from them.
Everytime I went in to debug something, I'd need to go thru a list of sessions, attach to one hoping that it's the right one (sometimes they'd name 'em), then see the console output.
I regularly recommend configurations to peers that are arguably impossible for normal humans. (Not on purpose! Sorry Dave!)
I love to run stuff on Raspberry Pi, and I fear no gcc
compile flag. (Ok. That's a bold faced lie, even I fear a couple of them.) So I frequently forget the bullshit I had to do to get something weird running on a random Pi.
Side of the case fell off.
I got an Orange Pi 5 Plus to play with smallish AIs (because it has an NPU) and I normally access it remotely, so I have to know its IP address to do it.
In order to easilly know the IP address of it, I've wired a little 128x64 monochrome OLED screen to it (Orange PIs, like Raspberry PIs have a pin connector giving access to GPIO and interfaces like I2C, Serial and SPI) which talks via I2C.
Turns out those interfactes aren't active in Linux by default (I.e. no /dev/i2c-x), so I figured out that I had to add a kernel overlay to activate that specific interface (unlike with the Raspberry PI whose Linux version has a neat program for doing it, in the Orange Pi you have to know how the low level details of activating those things), which I did.
To actually render characters on that screen I went with an ARM Linux port of a graphics library for those screens I used before with Arduino, called u8g2)
Then I made a program in C that just scans all network interfaces and prints their names and IP addresses on that screen, and installed it as a Cron job running once a minute.
Now, as it turns out when you shutdown your Linux on that board, if you don't disconnect it from power there is actually still power flowing through the pin connector to any devices you wire there, so after shutdown my screen would remain ON and showing the last thing I had put there, but because the OS was down it would naturally not get updated.
So the last thing I did was another small C program which just sends to that screen the command for it to go into power saving mode, shutting it down. This program was then installed as a Systemd Service to run when Linux is shutting down.
The result is now that there is a little screen hanging from the box were I put this board with Linux which lists its IP addresses and the info is updated if it connects other interfaces or reconnects and gets a new IP address. Curiously I've actually been using that feature because it's genuinely useful, not just a funny little project.
Well it was more like a temporary duct tape, but I "installed" a copy of Ubuntu in RAM from the running Ubuntu system so that I could "boot" (pivot_root) into it without restarting it
All because I didn't want to wait on a ticket for my dedicated server provider to hook in a KVM LOL
(See my meme post I posted to c/linuxmemes a few weeks back for more info)
Got fed up of Pipewire suspending (old receiver takes ~2 sec to work again after spdif stream is cut) that now I auto-run aplay to play a silent .wav on loop
For me it's probably the way I self-host overleaf, a online LaTeX editor. The community version has a docker image that's horribly maintained (because they want to sell enterprise, I reckon), and instead relies on a horrendous amalgamation of setup scripts that wrap docker compose.
What I have is a Dockerfile that pulls the image, manually installs a second version of TeX with the right dependencies, unlinks the old one and links the second one. Then for the database, it uses Mongo replsets, which be to be manually initialized. So I wrote a health check for the container that checks if the repl set is initialized, and if that fails the health check initializes it.
It's horrendous, it's disgusting, and it's an all-in-one compose file to get overleaf running. Good enough.
I've set Raspberry Pis to auto-reboot themselves at night if they are being used for headless network services that need to be available 24/7, just to clear out memory leaks or other things that may have gotten locked up. Not sure if that's duct tape or just a standard practice. They aren't the most stable things sometimes. They're known for power supply and SD card issues.