• 0 Posts
  • 445 Comments
Joined 3 years ago
cake
Cake day: June 16th, 2023

help-circle

  • jj4211@lemmy.worldtolinuxmemes@lemmy.worldGUIs
    link
    fedilink
    arrow-up
    2
    ·
    11 days ago

    It depends on the complexity of the operation. “I want to rename all my files to have underscores to spaces”, CLI will let you construct that easily. I want to move all mp4/mkv files to one folder, but all ‘.opus/.mp3’ files to another folder, CLI is a bit quicker. Or I want to take the audio tracks out of all these mp4/mkv and then name the result according to the basename of the original file and move the result, well, mkvextract and mv are quicker than trying to wrangle all the content in comparable GUIs.

    But yes, if you are wanting to do an operation on a file or a range of files easily handled with shift-click to select, then GUI will be both approachable and quick.






  • I would imagine it’s nowadays at the point where employment verification is automatically fired off to some vetting agency automatically during the process where software does all the cross referencing and anomalies would be caught and reported.

    I don’t think they have to go all private investigator to get basic employment verification from the actual employers anymore.






  • I mean, diskpart and dir don’t make especially any more sense than lsblk/parted and ls. A fair point can be made for ‘copy’ being more intuitive, but ‘diskpart’ means you had to learn what disks and partitioning were, and lsblk means you need to learn what ‘block’ devices rae, and of course ‘parted’ references partitions. ‘dir’ means you wanted to ‘show the directory’ which means you had to learn of it as a directory, but then learn that the shortname of directory is the way to see the contents of a directory. ls means you learned you want to ‘list’ contents and that unix had this laziness of just the first and third letters of a word. Both involve learning, neither is ‘intuitive’.

    You end up writing ridiculously long commands

    I assume this is the likes of dbus-send and crap, and I agree with you if that’s the case. Dbus is a complication I could do without and have to confess that powershell cmdlets generally do a better job of instrumenting the system than a system that increasingly has no specific help and only long dbus-send commands to tackle certain things. dconf has issues too, but I think does a better job than the Windows registry at analagous function.


  • I suppose the takeaway is once the weather is 100 or higher, I don’t care it’s just too damn hot.

    After being in 115 degree heat, 100 degree heat still feels just terrible.

    Similarly below zero, subjectively I didn’t need specifics anymore. I know that salting ice outside is probably not going to work anymore. Yes it does make a difference, but comfort wise I just hate it either way.

    So I can see, mostly joking but a grain of truth that you have “stupidly cold” then 0 to 100 scale of usual air temperature then “too damn hot”.

    It’s like the only way the farenheight scale is kind of appealing from a “humans like 0 to 100 scale”, but it’s mathematically painful and nonsense apart from comfortable human temperatures.




  • Same for me. In Linux, I plug in USB-C and both monitors in the chain light up every time without thinking.

    For some reason, dual boot into Windows and it always disables one of the two by default until I manually go in and tweak it alive, and then it will do it again next time I plug in.

    Now back in the day, futzing with XFree86 config files and CRT monitors and absolutely lots of ‘voodoo’ to match what Windows pretty simply did with display configuration. But nowadays at least with kwin wayland compositor on nVidia proprietary drivers, it always does exactly what I expect without asking, and Windows is the one that assumes that I don’t want to use all the displays that are connected.

    Windows seems pretty clunky by comparison nowadays when it comes to display configuration.

    Now juggling my bluetooth audio… I think Windows still has the advantage. I have no idea why sometimes my bluetooth microphone just doesn’t work under Linux. I do appreciate the ability to manually select the bluetooth codec in Linux where in Windows it ‘guesses’ and often guesses wrong, throwing it into ancient headset codec territory when I’m trying to listen to music, because who knows what has made Windows think the microphone device is open…

    Networking… Linux wins hands down with VPN connectivity, much much easier to manage all my VPNs in one place in the ‘casual’ user scenario instead of a litany of competing ‘endpoint managers’ in Windows. When VPNs step on each others routing tables, well no OS makes that easy but at least Linux network namespaces makes it possible for me to have multiple network ‘worlds’ in one place to reconcile the conflicts…

    Probably the other area where Windows has a bit of an advantage is a consistent binary driver model. In Linux if you are an out-of-tree driver, it’s going to suck to keep up with changing in-kernel APIs to keep your source compatible, let alone have a module running without a recompile after a minor kernel update. I guess the silver lining is almost everyone decided to have their drivers ‘in-tree’ to make sure they are maintained and don’t need a lot of ugly #ifdefs to contend with multiple kernel behaviors… Then there’s nVidia and some commercial filesystems that either cannot or will not go in-tree…




  • You don’t have to target every distribution, target a vaguely credible glibc, and of course the kernel, and you are covered.

    As a distribution platform themself, they don’t have to sweat packaging N different ways, they package the way they want. Bundle all the libraries (which is not different then the way they do it in Windows, the bundle so many libraries).

    They don’t get the advantage of the platform libraries and packaging, but that is how they treat Windows already because the library situation in Windows is actually really messy, despite being ostensibly a more monolithic ecosystem.