• 0 Posts
  • 18 Comments
Joined 9 months ago
cake
Cake day: March 3rd, 2024

help-circle
  • these days Hyprland but previously i3.

    i basically live in the terminal unless i’m playing games or in the browser. these days i use most apps full screen and switch between desktops, and i launch apps using wofi/rofi. this has all become very specialized over the past decade, and it almost has a “security by obscurity” effect where it’s not obvious how to do anything on my machines unless you have my muscle memory.

    not that i necessarily recommend this approach generally, but i find value in mostly using a keyboard to control my machines and minimizing visual clutter. i don’t even have desktop icons or a wallpaper.



  • i’m not really here to advocate for Rust in the kernel. i will say that i work on Rust professionally at a Fortune 100 company that is in the process of adopting it, which may skew my perception of it as mainstream, just to get the bias out of the way.

    it is part of the project though, no? drivers still need to be interfaced with. so the people working on driver interfaces should be comfortable with it, again at least to preserve basic builds and do basic code review. this is specifically in reference to the issue that this thread is ostensibly started from: a kernel dev was getting worked up about “having to learn Rust”. so no, i don’t think it’s a strawman to point out the real people denying or frustrating patches just because they don’t understand the language. overly harsh maybe but not a total mischaracterization.


  • i can definitely see it as a “hostile takeover” of sorts, but this is something the project has decided on, for better or worse. i can understand not wanting to learn a new language that you may not like or agree with, but that means you will have to divest yourself from a project that adopts that language to a certain extent. Rust is—again for better or worse—something Linus thinks is good for the project, and thus learning Rust at least enough to not break the builds is a requirement for the project. i can’t imagine working on a software team where a chunk of people refuse to take part in a major portion of it simply because they’re not immediately familiar with it. that does sound like old crotchety behavior. on the other hand it’s tragic that so many people with all this experience are being forced into a design decision that arguably may have been made hastily and that they had little say in.

    that makes this definitely an old guard vs new issue. and maybe it is an olive branch for the old guard to say “let’s just take our time with this.” but we have crossed a threshold where seeing a new project in C is the oddity while new projects in Rust are commonplace. Rust is mainstream now, and “i don’t want to learn this” is a dogshit technical justification.












  • yeah i see that too. it seems like mostly a reactionary viewpoint. the reaction is understandable to a point since a lot of the “AI” features are half baked and forced on the user. to that point i don’t think GNOME etc should be scrambling to add copies of these features.

    what i would love to see is more engagement around additional pieces of software that are supplemental. for example, i would love if i could install a daemon that indexes my notes and allows me to do semantic search. or something similar with my images.

    the problems with AI features aren’t within the tech itself but in the surrounding politics. it’s become commonplace for “responsible” AI companies like OpenAI to not even produce papers around their tech (product announcement blogs that are vaguely scientific don’t count), much less source code, weights, and details on training data. and even when Meta releases their weights, they don’t specify their datasets. the rat race to see who can make a decent product with this amazing tech has made the whole industry a bunch of pearl clutching FOMO based tweakers. that sparks a comparison to blockchain, which is fair from the perspective of someone who hasn’t studied the tech or simply hasn’t seen a product that is relevant to them. but even those people will look at something fantastical like ChatGPT as if it’s pedestrian or unimpressive because when i asked it to write an implementation of the HTTP spec in the style of Fetty Wap it didn’t run perfectly the first time.



  • no need for Python. there’s a Google SDK, ML Kit, that will do the heavy lifting on this. if that’s not acceptable, TensorFlow, PyTorch, and ONNX support Android, albeit not as nicely integrated.

    your image processing pipeline will be imageSource -> RGB encoding -> OCR -> profit. your OCR just needs an RGB encoded image. doesn’t matter if that’s a JPEG or YUV video feed at the source.

    as for if there’s an app that fits OP’s exact use case, dunno.



  • chrash0@lemmy.worldtoLinux@lemmy.mlLix - a new fork of Nix
    link
    fedilink
    arrow-up
    34
    arrow-down
    2
    ·
    edit-2
    7 months ago

    i really want to like Nix.

    gave it a shot a few years ago, but i felt like documentation and community support wasn’t really there yet. this was long before Nix surpassed Arch in terms of number of available packages. now people still complain about documentation, especially of the Nix language. i see a lot of package authors using it, and that kind of tempts me to start using at least the package manager. but a lot of packages don’t. the allure of GitOpsing my entire OS is very tempting, but then there’s been these rumors (now confirmed) of new forks, while Guix splintered off much earlier. for something that’s ostensibly supposed to be the most stable OS, that makes me nervous. it also seems to have some nontrivial overhead—building packages, retaining old packages, etc.

    the pitch for Nix is really appealing, but with so much uncertainty it’s hard to pull the trigger on migrating anything. heck, if i could pull off some PoCs, i think my enterprise job might consider adopting it, but it’s a hard recommend for me today as it was 5 years ago.