aerc

To this day i still plug my wh-mx10004 … (Or whatever their stupid number is cause sony thinks a ten digit alphanumeric code is the catchiest name for their products…) b/c every time they connect by bt they will ONLY do ‘handsfree’ codec, yknow, the one that sounds like shit for phone calls. I have done everything… pavucontrol, pipewire, wireplumber, blueman, cli system level shit and yes i can force it to proper high def audio after some really annoying steps… but then ill start up a game or something and it suddenly goes “nope! This calls cor handset audio!” And switches itself back.

If you’re talking about WH-1000XM4, they work for me. Sometimes on first connect they only have mSBC codec for me too, but if I just disconnect/reconnect them then all other codecs appear. If I switch to SBC-XQ or LDAC they then work fine until I turn them off (which can be hours and many different playback streams). I’m on pipewire+pipewire-pulse.

I’ve heard about Linux being highly customizable and decentralized OS, and suddenly I can’t define my own shortcuts because there is a list of un-features?

You can customize it to do whatever you want. Heck, you can write your own terminal emulator that does exactly what you need. But some things can be harder to do than others and require skills and experience. Once someone implements those harder things, they become a “feature”. Before then, therefore, they are an “un-feature”. See https://xkcd.com/1349/

E.g. it is probably possible to set up your shell to use shift-selection for the command you’re currently editing, but shift-selection for the output of a previous command will require terminal support. You will have to make sure that the two don’t interfere with each other, which can be quite complicated.

I already have my workflow and I’m trying to transfer it to Linux

Linux is a different OS that, by default, does things differently from others. You can configure it to emulate some other UX, but it won’t necessarily be easy. In the meantime, you can install the micro editor, set EDITOR=micro, and then Ctrl+x Ctrl+e in bash to edit the command in a more familiar setting.

I prefer compose keys because they are easier to remember.

Oh, also, I think GTK apps have that Ctrl+shift+U thing which allows you to enter characters by code. Never really got used to it though.

I think this is one of many un-features in Linux world where

• It would benefit a beginner
• It sounds simple but actually quite complicated to get right (especially if you aim to keep compatibility with things)
• Anyone possessing the skills to implement it neither needs it nor cares about it

As such, for you individually, I suggest just getting more comfortable with tmux (or zellij) and vi-like keybinds for text manipulation. Once you learn those (and set your readline mode to vi), you won’t look back. Oh, also, try Ctrl+x Ctrl+e in bash, it might help.

Or switch to emacs and using it as a terminal emulator. In that case you will have to learn and use emacs keybindings, but the selection semantics in the “terminal” will be the same as in the “editor”.

You definitely shouldn’t look through this topic, but especially avoid titles tagged “Original + Sub (Eng)”. I have never done anything like that and advise everyone to avoid using that website. That would be illegal!

I assume many people just live in a sanitized, sterile internet created by Google/Meta et al. They might have never encountered the gooner/pervert culture before. Again, when most people see “cameo” their mind doesn’t jump to “fetish porn cameo”. As such, I don’t think there was real consent here.

She consented to something but didn’t consider/understand what that something implies. While it might be obvious for terminally online people, most people don’t expect “cameos” to necessarily mean “fetish porn cameos”.

Also check out Nix. It’s a pretty weird package manager but has a lot of packages. Also allows you to configure your entire macOS install declaratively with a text-based config file, if you’re into that.

We actually have two, for both of us to ride on. It’s the main way we get around the city. They cost us ~$80 combined (I’m not in the US tho), plus maybe another $50 in spare parts over the year or so we’ve had them. Also, as a proud 30yo shitbox owner, what’s a monthly car payment?

I’m assuming not many suburbanites have bikes.

Ah yeah, that makes sense. However, if all roads are fully jammed, most people would be able to walk to a grocery store - it’s likely not insanely far away from you (quick search suggests average straight-line distance to a grocery shop in the US is ~4 km = 50 min, which sounds very far away from a non-US perspective but still not completely unreachable), it’s just that usually there’s a highway full of traffic between you and the store.

You are overestimating the danger of a punctured tire. It is easy to notice, usually gives you plenty of time (on the order of minutes) to come to a complete stop before the tire is deflated, and even after the tire is fully deflated it still allows you to stop relatively safely for a short while (until it is cut through completely). It would probably result in a few crashes (because in carbrained places many drivers don’t know how to operate a vehicle at all), but the worst outcome from this is ambulances/firetrucks being stuck in traffic jams.

Scatter random tire spikes on the roads. 10k would probably get you quite a few

Are there any risks or disadvantages to building software from source, compared to installing a package?

Well, compiling from source is the “installing dodgy freeware .exe” of the Linux world. You have to trust whoever is distributing that particular version of the source code, and ideally vet it yourself. When installing a binary package from your distro’s repositories, presumably someone else did the vetting for you already. Another slight risk is that technically you are running some extra build scripts before you can even run the application, which is a slight security risk.

Can it mess with my system in any way?

Yeah, unless you take precautions and compile in a container or at least a sandbox, the build scripts have complete unadulterated access to your user account, which is pretty much game over if they turn out to be malicious (see: https://xkcd.com/1200). Hopefully most FOSS software is not malicious, but it’s still a risk.

If you “install” the software on your system, it also becomes difficult to uninstall or update, because those files are no longer managed from any centralized location.

I recommend using a source-based package manager, and package your software with it (typically won’t be any more difficult than just building from source) to mitigate all of those (as typically source-based PMs will use sandboxing and keep track of the installed files for you).

All x86_64 CPUs support a certain “base” set of instructions. But most of them also support some additional instruction sets: SIMD (single instruction multiple data - operations on vectors and matrices), crypto (encryption/hashing), virtualization (for running VMs), etc. Each of those instructions replaces dozens or hundreds of “base” instructions, speeding certain specific operations dramatically.

When compiling source code into binary form (which is basically a bunch of CPU instructions plus extra fluff), you have to choose which instructions to use for certain operations. E.g. if you want to multiply a vector by a matrix (which is a very common operation in like a dozen branches of computer science), you can either do the multiplication one operation at a time (almost as you would when doing it by hand), or just call a single instruction which “just does it” in hardware.

The problem is “which instruction sets do I use”. If you use none, your resulting binary will be dogshit slow (by modern standards). If you use all, it will likely not work at all on most CPUs because very few will support some bizarre instruction set. There are also certain workarounds. The main one is shipping two versions of your code: one which uses the extensions, the other which doesn’t; and choosing between them at runtime by detecting whether the CPU supports the extension or not. This doubles your binary size and has other drawbacks too. So, in most cases, it falls on whoever is packaging the software for your distro to choose which instruction sets to use. Typically the packager will try to be conservative so that it runs on most CPUs, at the expense of some slowdown. But when you the user compile the source code yourself, you can just tell the compiler to use whatever instruction sets your CPU supports, to get the fastest possible binary (which might not run on other computers).

In the past this all was very important because many SIMD extensions weren’t as common as they are today, and most distros didn’t enable them when compiling. But nowadays the instruction sets on most CPUs are mostly similar with minor exceptions, and so distro packagers enable most of them, and the benefits you get when compiling yourself are minor. Expect a speed improvement in the range of 0%-5%, with 0% being the most common outcome for most software.

TL;DR it used to matter a lot in the past, today it’s not worth bothering unless you are compiling everything anyways for other reasons.

Ah, sorry, missed the context

It’s a word predictor. It is good at simple text processing. Think local code refactoring, changing the style or structure of a small text piece, or summarizing small text pieces into even smaller text pieces. It is ok at synthesizing new text that has similar structure to the training corpus. Think generating repetitive boilerplate or copywriting. It is very bad at recalling or checking facts, logic, mathematics, and everything else that people seem to be using it for nowadays.

• A pinecil. It was like $30, and has paid for itself within the first two things I did with it (repaired a good computer mouse which just had a USB connector lift from the board, and fashioned a DIY solar connector). I have repaired/made countless other small things in the few years I’ve owned it.
• Our bicycles, I guess? Financially speaking, they were dirt cheap (~$80 for both), we’ve sold our Prius since we bought them ($5000), we’re not paying for gas for trips within the city (~$30/mo), we’re not paying insurance or parking or maintenance or any of that crap (~$20-30/mo or so). So they have paid off within the first couple of weeks. And there’s so much more: both of us lost some weight, city errands are sometimes faster, and usually more pleasant now (no being stuck in traffic ever), and we’re not wasting space on a useless hunk of metal or polluting the air we breathe.

Joanna, fire.