• 0 Posts
  • 278 Comments
Joined 1 year ago
cake
Cake day: June 10th, 2024

help-circle



  • 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.





  • balsoft@lemmy.mltoADHD memes@lemmy.dbzer0.comFreaks
    link
    fedilink
    English
    arrow-up
    14
    arrow-down
    7
    ·
    5 days ago

    Apart from what @[email protected] said, it’s also important to understand how a human brain works.

    Massively oversimplifying, you have a “primate” brain, good at complex and novel things like logic, casuality, motivation etc; and a “reptile” brain, good at just keeping you alive by repeating the same thing over and over. Crucially, the primate brain takes up a lot of energy and other resources when it works, so your reptile brain will shut it down wherever possible. The trick is to use your primate brain to form habits by repetition, which the reptile brain will pick up, because that’s literally the only thing it’s good at.

    To form a (good) habit, you need three things: first, motivation. You need to understand why doing some action is good for you. Second, a trigger - some concrete event that “breaks the flow” of your life, e.g waking up, coming home from work, or just a loud alarm you set on your phone; this is needed for your reptile brain to wake up your primate brain so that it could use the motivation you have to force your body to do something. Third (and this is the hard part) repetition. If you force yourself to do the action every time a trigger occurs, your reptile brain will eventually start catching on. Remember, it is wired to simply repeat what you have been doing before, because you’ve survived up until now so it must be a good thing to do. This can take different amounts of repititions depending on various facrors, somewhere between dozens and hundreds. After that, you will start doing the action almost automatically when the trigger happens.

    E.g. I exercise when I take a break from work in the middle of the day. To do that, I forced myself to do exercise whenever I took a break for like a month. Now I get this natural urge to do push-ups when I stand up from my table :)




  • 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”.








  • 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.