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

help-circle


  • i feel like if you’re not sat stationary at a workstation (who is these days) what you want is a laptop that’s good at being a laptop. 99% of the software developers i work with (not a small number) use Macbook Pros. they are well built, have good components, have best in class battery life (we’ll see how things shake out with Qualcomm), and are BSD based and therefore Unix compatible. my servers and gaming/CUDA PC? Linux all day. my laptop? Macbook. i’m not ideological enough to have range anxiety every time i step away from my desk. plus any decent sized org is going to have to administrate these machines, from scientists to administrators, and catering to .4% of your users is not a good ROI if your software vendors struggled for 8 years to get their Windows 98 based specialty sensor software to run on Mac.

    that .4% is likely not 0 because they are nerds.

    seriously tho if Qualcomm chips can make a Linux book that lasts all day i would happily make the switch


  • chrash0@lemmy.worldtoLinux@lemmy.world*Permanently Deleted*
    link
    fedilink
    English
    arrow-up
    11
    arrow-down
    4
    ·
    edit-2
    20 days ago

    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.


  • chrash0@lemmy.worldtoLinux@lemmy.world*Permanently Deleted*
    link
    fedilink
    English
    arrow-up
    15
    arrow-down
    9
    ·
    20 days ago

    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.





  • as you might have guessed i haven’t really tried it, but i have been reading about it. that said i have used “drop in replacement” tools like this (we use pnpm at work), and a drop in replacement is not without quirks. they wouldn’t have made a different tool altogether if it was really a 1:1 replacement. just because the commands are the same doesn’t mean it behaves the same. i.e. i doubt one person on the team could be using uv while everyone else sticks to pip


  • definitely not the real reason for a project like this to exist. Python package management can be nightmarish at times depending on what you’re doing. between barebones requirements.txt, Poetry, and the different condas there’s a ton of fragmentation, and none of them do everything you’d want in an ideal way. above and beyond speed, i think uv is another attempt at it. but it could just be another classic xkcd moment where now there’s just another standard to deal with








  • seems like chip designers are being a lot more conservative from a design perspective. NPUs are generally a shitton of 8 bit registers with optimized matrix multiplication. the “AI” that’s important isn’t the stuff in the news or the startups; it’s the things that we’re already taking for granted. speech to text, text to speech, semantic analysis, image processing, semantic search, etc, etc. sure there’s a drive to put larger language models or image generation models on embedded devices, but a lot of these applications are battle tested and would be missed or hampered if that hardware wasn’t there. “AI” is a buzz word and a goalpost that moves at 90 mph. machine learning and the hardware and software ecosystem that’s developed over the past 15 or so years more or less quietly in the background (at least compared to ChatGPT) are revolutionary tech that will be with us for a while.

    blockchain currency never made sense to me from a UX or ROI perspective. they were designed to be more power hungry as adoption took off, and power and compute optimizations were always conjecture. the way wallets are handled and how privacy was barely a concern was never going to fly with the masses. pile on that finance is just a trash profession that requires goggles that turn every person and thing into an evaluated commodity, and you have a recipe for a grift economy.

    a lot of startups will fail, but “AI” isn’t going anywhere. it’s been around as long as computers have. i think we’re going to see a similarly (to chip designers) cautious approach from companies like Google and Apple, as more semantic search, image editing, and conversation bot advancements start to make their way to the edge.


  • you’d be surprised how fast a model can be if you narrow the scope, quantize, and target specific hardware, like the AI hardware features they’re announcing.

    not a 1-1, but a quantized Mistral 7B runs at ~35 tokens/sec on my M2. that’s not even as optimized as it could be. it can write simple scripts and do some decent writing prompts.

    they could get really narrow in scope (super simple RAG, limited responses, etc), quantize down to even something like 4 bit, and run it on custom accelerated hardware. it doesn’t have to reproduce Shakespeare, but i can imagine a PoC that runs circles around Siri in semantic understanding and generated responses. being able to reach out on Slack to the engineers that built the NPU stack ain’t bad neither.


  • they likely aren’t creating the model themselves. the faces are probably all the same AI girl you see everywhere. you gotta be careful with open weight models because the open source image gen community has a… proclivity for porn. there’s not a “function” per se for porn. the may be doing some preprompting or maybe “swim with the sharks” is just too vague of a prompt and the model was just tuned on this kind of stuff. you can add an evaluation network to the end to basically ask “is this porn/violent/disturbing”, but that needs to be tuned as well. most likely it’s even dumber than that where the contractor just subcontracted the whole AI piece and packages it for this use case