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.

deleted by creator

i haven’t personally had trouble with that since early 2023, but it depends on your dependencies

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

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.

the semantics of C make that virtually impossible. the compiler would have to make some semantics of the language invalid, invalidating patterns that are more than likely highly utilized in existing code, thus we have Rust, which built its semantics around those safety concepts from the beginning. there’s just no way for the compiler to know the lifetime of some variables without some semantic indication

i’ve used Chezmoi for years now pretty successfully. works on my Mac and Linux machines. it probably could be made to work on Windows. i am transitioning to NixOS, but i’ll probably keep using it anyway, since i still have Macs for work (and because they’re great laptops don’t @ me). the only real downside is that it only works for the home folder, so i have to manually control stuff for /etc, but i generally prefer user configuration for most tools anyway.

i had messed around with Ansible for this in the past, but i didn’t really like it for this use case. it’s been a while tho so it’s hard to say why.

not to pile on, but you might also look at GNU Stow. i decided against it, but it’s there.

obligatory i s’pose: https://github.com/covercash2/dotfiles

lol this is like Ben Shapiro telling people in areas threatened by climate change to sell their houses. “to who? fucking Aqua Man?”

best case you’ll get $10 and whoever bought it will end up back here

Users who need to run their application in Python 2 should do so on a platform that offers support for it

damn go off

ah yeah. maybe less well known, but i had a dev kit from Qualcomm that came with Ubuntu

not likely. i think it requires a lot of systems working together

always? Android runs a linux kernel, and they support all kinds of embedded systems that run Linux.

pretty standard compared to OSs like Android and iOS. i think the mobile OSs, at least recently, have done better at this; they don’t ask for permission until they need it. want to import bookmarks? i need file system access for that. want to open your webcam? i need device access. doing it all upfront leads to all the problems mentioned in this thread: unclear as to why, easy to forget what access you’ve given, no ability to deny a subset of options, etc.

nushell is excellent for dealing with structured data. it’s also great as a scripting language.

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.

i mean, you’re right. i’m just saying it’s a little silly to ship a Python interpreter when there are easier, better supported ways to do the same thing.

looks like tesseract provides C bindings which are probably being utilized in those apps.

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.

used to be the Android team used Ubuntu, not sure if that’s still the case. Linux is pretty much the native environment for Android dev. i’d recommend at least 4GB of dedicated RAM if not 8. definitely at least 8 if you plan to use the emulator (which is itself a VM).

Android Studio will get you 90% of the way there. it will help you install the SDK, emulators, etc, and provide UI front ends for the CLI tools, ie adb.

there’s really not much to system level dependencies. if your distribution supports JDK 17 (probable) you’ll be fine with whatever.

obligatory: i use Arch, btw

IBM then. or, i don’t know, the British Royal Family?

the reality of talking about extremist economics is no one knows how it would work out in the long term. but regardless, if it happened tomorrow we already have a Microsoft to deal with.

“taxation is theft” “wage labour is exploitation”

sometimes things are subtle and complicated and can’t be practically boiled down to absolutes.