BaumGeist

joined 2 years ago
[–] BaumGeist@lemmy.ml 2 points 3 months ago

iw dev <interface> station dump will show every metric about the connection, including the signal strength and average signal strength.

It won't show it as an ascii graphic as with nmcli, but it shouldn't be hard to create a wrapper script to grep that info and convert it to a simplified output if you're willing to put in the effort of understanding the dBm numbers.

E.g. -10 dBm is the maximum possible and -100 dBm is the minimum (for the 802.11 spec), but the scale is logarithmic so -90 dBm is 10x stronger than the absolute minimum needed for connectivity, and I can only get ~-20 dBm with my laptop touching the AP.

Basically my point is that the good ol' "bars" method of demonstrating connection strength was arbitrarily decided and isn't closely tied to connection quality. This way you get to decide what numbers you want to equate to a 100% connection.

[–] BaumGeist@lemmy.ml 5 points 3 months ago

I'm a big fan of the idea of efficient computing, and I think we'd see more power savings at the End Users based on hardware. I don't need an intel i9-nteen50 and a Geforce 4090 to mindlessly ingest videos or browse lemmy. In fact, I could get away with that using less power than my phone uses; we really should move to the ARM model of low power cores suitable for most tasks and performance cores that only turn on when necessary. Pair that with less bloatware and you're getting maximum performance per instruction run.

SoCs also have the benefit of power efficient GPU and memory, while standardizing hardware so programmers can optimize to the platform again instead of getting lost in APIs and driver bloat.

The only downside is the difficulty of upgrading hardware, but CPUs (and GPUs) are basically blackboxes to the End User already and no one complains about not being able to upgrade just the L1 cache (or vram).

Imagine a future where most end user MOBOs are essentially just a socket for a socketed-SoC standard, some m.2 ports, and of course the PCI slots (with the usual hardwired ports for peripherals). Desktops/laptops would generate less waste heat, computers would use less electricity, graphical software developement would be less of a fustercluck (imagine the manhours saved), there'd be less e-waste (imagine not needing a new mobo for the new chipset if you want to upgrade your cpu after 5 years), you'd be able to upgrade laptop PUs.

Of course the actual implementation of such a standard would necessarily get fuckered by competing interests and people who only want to see the numbers go up (both profit-wise and performance-wise) and we'd be back where we are now... But a gal can dream.

[–] BaumGeist@lemmy.ml 3 points 3 months ago

From an outsider perspective (I haven't used Nix at all), the downsides I see are that it's extra software on top of the defaults for any given distro, it's not optimized for the distro (meaning it might pull in dependencies that already exist or not use distro specific APIs/libs), and it doesn't adhere to the motivations of the distro (e.g. not adhering to the DFSGs for Debian).

And of course, most of the packages are community maintained and there's the immutability, which might be a hinderance to some use cases, but not for me.

All in all, not really the worst if you're not worried about space or getting the absolute most in performance and not an ideologue, but it's enough to make me stick with APT. I chose Debian because of its commitment to FOSS, not the stability nor performance.

[–] BaumGeist@lemmy.ml 2 points 3 months ago

Currently virt-manager on top of qemu/kvm on Debian 12. It was the easiest to get to emulate a TPM on my ancient hardware (9ish years old, but still powerful).

I'm learning enough about the backend that I'm hoping to get off the Redhat maintained software and only use the qemu cli, maybe write my own monitor with rust-vmm when I learn enough rust to do so.

[–] BaumGeist@lemmy.ml 2 points 5 months ago (1 children)

My c920 now glitches out and refuses to stream video after about 10 minutes of use (mic still works tho). After some unknown long period of time, it resets and works for another 10 minutes

[–] BaumGeist@lemmy.ml 13 points 5 months ago* (last edited 5 months ago) (1 children)

how do I install rpm fusion repos on debian? I only found instructions for fedora and rhel https://rpmfusion.org/Configuration

Stop. You do not want to do this.. While resources published on other sites may be full of information, that information is not always relevant to you. Don't blindly follow bad advice.

The "rpm" in "rpmfusion" refers to the filetype that Fedora's built-in package management system, dnf, uses.

You want to use Debian's builtin package management system, apt, which uses the "deb" filetype.

Here is an explanation of how to add Debian's "non-free" repository


Do not follow information for other distros unless you know how to extract the bits that are relevant to your distro.

In general, I recommend following the advice from Debian's wiki or website, then debian's forums if you can't find anything there, then debian specific forums elsewhere, then other distro's wikis, then any other site in a last-ditch effort.


Now that you understand the "why," here's the "how": go back to Debian's download website and download the appropriate installation image from the bullet point that says

A larger complete installation image:

Reason being: the smaller "netinst" images are made to work generally for most people who can plug their computer into ethernet. It's made to only use the bare minimum of disk space and get the rest of the files it needs from the internet (the "net" in "netinst").

You need the installation image that come with the "drivers" (firmware) for your WiFi card already on disk, which should automatically detect your device, find the correct firmware for it, and set up the non-free-firmware repository for you.

If that doesn't work out for you, you can try manually installing using the guide on Debian's own wiki, which I found by searching for your wifi card BCM4360

[–] BaumGeist@lemmy.ml 1 points 5 months ago
  1. Don't use hacky unlocks if there's an official way. The best case scenario is it becomes a headache and isn't reliable; ghe worst case is that it bricks your phone or installs malware in the bootloader

  2. All I could find looking for custom ROMs for your phone was XDA users shrugging their shoulders and unverified downloads from very shady websites/githubs. I'd suggest getting the most out of this phone you can before selling it and getting one you know works with the OS you want

[–] BaumGeist@lemmy.ml 5 points 5 months ago

I know it's bad form to suggest using other software that handles the same functionality instead of suggesting a fix, but it looks like sddm doesn't have the functionality to change displays at the time of writing.

GDM seems to have a workaround

But it looks like every display manager chooses whichever display based on arbitrary criteria.

[–] BaumGeist@lemmy.ml 8 points 5 months ago

chmod -R 777 my_project_managed_by_git && rm -r my_project_managed_by_git

[–] BaumGeist@lemmy.ml 2 points 5 months ago

I haven't found a good GUI (Balena's Etcher is cross platform, but the flatpak never worked for me)

dd has never failed me

sudo dd if=<path to ISO file> of=<path to USB> bs=4M status=progress conv=fsync

(double, triple and quadruple check that the output file, of=, is the correct device with multiple different commands before running this)

[–] BaumGeist@lemmy.ml 2 points 5 months ago

I have 2 lenovos (ideapad and yoga) and a pinebook. I'm happy with all of them, though I'm happiest with the pinebook and yoga's impressive battery lives

[–] BaumGeist@lemmy.ml 0 points 5 months ago

While I'm not gonna argue the merits of GPL—it is technically restricting modification, even if there is no practical difference for those only interested in adding/removing functionality—I disagree with the assessment that using the GPL causes harm to the users.

The reasoning seems to be that a 3rd party's refusal to use the software because of the license, and suvsequent use of a shittier product is somehow the (hypothetical GPL-using) OpenSSH dev's fault.

The problem is that accepting the premise that the devs are responsible for what people who choose to not use their software do entails that they are then responsible for everyone who uses any type of software tangentially related to OpenSSH's functionality. It also means that it's their fault for whatever consequences of using the licenses they currently do, which inevitably drive some people away for various reasons. It also means any potential license (or even lack thereof) is open to the same criticism.

view more: ‹ prev next ›