it seems like a new version of this kind of thing pops up often enough, but it seems like the people making them have never heard of AppStream. like I guess managing webapps too is unique, but everything else and more support AppStream, along with existing gui managers like kde discover, gnome software, etc
they're putting large amounts of binary data in git lfs, which is what it was designed for. lfs does have some rough edges though. if I had something really heavy on binary blobs, ex a large game or similar, idk if I'd be using git either. he extrapolates way too far though, most use cases don't run into any of these problems
and storing all that in a separate db is insane, it's stuff that should be versioned with the code. it's likely being created at a specific rev for the current code, and it evolves with it. if you git revert or create a pr, it should be part of that. it's not like they committed built binaries or smth. there should be tools able to handle this. git could be one of them if lfs was less rough
gitea has had some organizational problems so a lot of people have been using forgejo instead, which is just a community fork of gitea plus some more features
my team was driving me insane with leaving console.log("here")
all over the place in every pr, so now we have a "no console.log" eslint rule in ci.
I guess my answer is it depends on your team. good logs are different, but imo if they're just debugging statements they shouldn't even make it into the repo let alone prod.
if it's just you, do whatever you want lol, performance is almost certainly not significant and most users should end up ignoring them anyway
well the language server plugins all run a binary language server out of sandbox so zed doesn't really do anything safer in particular there either. no ide has solutions, solutions don't really exist right now. it's not a problem of features of the language as much as it is features developers expect in extensions. I suppose there is a hypothetical "the extension wants to make this change to this file, approve" type flow like AI tools have now, but that sounds unpleasant to use. it still doesn't get around things like language servers being designed to run as standalone processes out of sandbox.
by audits I meant you individually go and read all the code of all the extensions you use. of course that's impossible too, but that was my point
I can't imagine a sandbox would help. what can an an extension do that doesn't touch some arbitrary code that gets run? it could add a line to the middle of a giant file right before you run and remove it immediately after. even if you run the whole editor in a sandbox you do eventually deploy that code somewhere, it can change something inconspicuous like a url in a dependency file that might not get caught in a pr
the only solution is to audit everything you install, know all the code you run, etc. ofc that's not reasonable, but idk what else there is. better automated virus check things maybe? identity verification for extension publishers? idk if there's an actual solution
it legitimately is a neutral network, I'm not sure what you're trying to say here. https://en.wikipedia.org/wiki/Generative_pre-trained_transformer
they are the first thing that comes up when searching "cursor" in both ddg and google, so I think they're doing ok
idk if 2 users is fair, it may just be my circles but I see nixos mentioned more than almost anything else on lemmy/hn/etc in the past couple years
not sure what you're talking about but there's two things here.
TRAMP is great and you can run the lsp on the remote machine without installing anything assuming the linters and lsp are already installed. for comparison, vscode remote downloads and runs a shim thing when you connect.
I use doom emacs at work for large codebases all the time and haven't run into any problems. why does it only work for really small projects?
the instructions for installing on not nixos https://nixos.org/download/
plenty of package managers have.
flatpak doesn't require any admin to install a new app
nixos doesn't run any code at all on your machine for just adding a package assuming it's already been cached. if it hasn't been cached it's run in a sandbox. the cases other package managers use post install configuration scripts for are a different mechanism which possibly has root access depending on what it is.
yeah there isn't really a general purpose react way to do that.
if order didn't matter then you could just have a Header component that registers itself in a context but there's no way to know where each component is relative to its siblings.
the other way is to break out of react and just walk the dom. pass a ref to your component and use that as the root to walk. only works assuming normal react dom renderer and no portals.
you can combine those two options too, use context for registration so you can attach extra info, then dom for position.
there are some libs that let you walk a component tree, but they're all focused on ssr and idk how they work in a browser. wouldn't go this route for anything prod.
last option is just store your content as data. have md/mdx/json/whatever files that are the content for your page, then as you parse them build up the tree. probably the most robust if it fits your use case. if you use MDX it seems like they already have some solutions
there's sort of ways to achieve this but none of them good react. what's the actual goal?
yeah that should just be a pip package instead, then install it any normal way
the social pressure of other kids
seems like everything. canonical has it listed as still evaluating. it requires you to open a url with emacs though, so shouldn't be that bad to avoid.
most things seem to have settled on this, but tabs are so much better for accessibility. programmers with bad vision can have trouble differentiating smaller indentation levels, while some of them just bump the font size up so high that 4 spaces takes up too much screen space. each one can set a tab width that is comfortable for them. https://alexandersandberg.com/articles/default-to-tabs-instead-of-spaces-for-an-accessible-first-environment/ has some good arguments
with a forced formatter and a configured editor there really isn't any argument for spaces
alpine fits that, or derivatives like postmarketos
have you considered https://github.com/a-schaefers/systemE plus https://github.com/emacs-exwm/exwm ? that's basically an entire emacs userland