Big fan! Was like magic at first but now I have a big bunch of Aptfiles to deal with instead... Currently working on solving that with the next-generation tool apt-bundle-bunch, which has a simple declarative format to manage your apt-bundle projects in an Aptbundlefile. It's already great for agents and Im working with Claude on a curl|sh install for the v1.
> Big fan! Was like magic at first but now I have a big bunch of Aptfiles to deal with instead... Currently working on solving that with the next-generation tool apt-bundle-bunch, which has a simple declarative format to manage your apt-bundle projects in an Aptbundlefile. It's already great for agents and Im working with Claude on a curl|sh install for the v1.
Good luck share the progress and let us know how it goes. Is it similar to nix? but from what I can feel, is intending to be simpler?
One key insight is that bundles are really sets of packages and that what we're doing when we bundle things is really just set join operations. Imagine the possibilities if we implement arbitrary set operations. So a bunch is defined as a set of bundles (which can themselves be down to a single package of course) and the declarations in the Aptbundlefile translates under the hood to references and set operations. This is not only declarative, it's also purely functional. Still working on if arbitrary set operations should be accessible by DSL in Aptbundlefile or if that should be left to tools building on top of intermediary API. So yeah, parallels to Nix for sure but it's still apt packages, not building the world from source.
This whole thread was fiction and was missing this: "/s". I don't believe any of what I proposed above would be a good idea. Didn't think it would woosh and couldn't help myself doubling down when (if?) it did. Sorry for trolling.
I remember my parents doing online banking authenticating with smart cards. Over 20 years ago. Today the same bank requires an iOS or Play Integrity device (for individuals at least. Their gated business banking are separate services and idk what they offer there).
Can't help you with AV but otherwise your issues and confusions are all Ubuntu and Canonical and nothing on there is representative of other Linux dists.
Ubuntu is highly opinionated. Great for some/many people but not the best fit for everyone or even an obvious recommendation for newcomers (anymore). For your consideraion: Mint is basically a project that repackages Ubuntu to adress those issues to make it accessible for people not onboard with the Ubuntu idiosyncracies and more casual users who just want their desktop. Should be an easy migration for you.
Your Vivaldi problem comes from that you trusted gpg key for their stable. release repo, and fail verifying package from their archive. repo. Change repo to stable (that's prob what you want) or get the key for archive.
Your Ubuntu experience as told is not representative of desktop Linux experienced outside of Ubuntu. "But Linux sure could work better" is a misleading conclusion to share when that's all you know.
You're right that I mixed up the Vivaldi repo (maybe you are the one who pointed that out on the thread I linked). But even after fixing that, it's still not working---slightly different warning message, but still about gpg.
Assume they mean having to recompile the AUR package they were trying to install using yay.
If users mental model is mostly "yay is like pacman but can also install packages from AUR the same way" wihout thinking deeper about the difference then I think it using it is very risky and that you should just stick to pacman + git/makepkg. Only consider helpers once that's become second nature and routine. Telling people to "just yay install" is doing them a disservice. An upgrade breaking the system isn't even that bad compared to getting infected with malware due to an old package you were using being orphaned and hijacked to spread malware or getting a bad copycat version due to a typo.
I think EndeavourOS is doing users a disservice if they provide sth like yay preinstalled and ready to use out of the box. It isn't installing packages from a shared repo: It's downloading code from arbitrary locations and running it on your machine in order to produce a package. Being able to read and understand shell script (PKGBUILD) is kind of a prerequisite to using it safely.
Did they really have to geo-block entire countries? I think the blocks of unrelated users is what's really affecting normal folks and that's the choice of operators.
It's like if you had incidents with a few violent drunk Brovanians in your town, then saying it's those few peoples fault that Brovanians are now being discriminated against and are being banned from entering shops just because they come from the same place as the vandals.
Site operators arbitrarily blocking entire countries due to a few botters (albeit with a lot of bots) causing issues aren't without responsibility in the loss of an open web.
You have a choice in how to respond and where to draw lines. We can't just throw up our hands and blame the botters.
I mean the whole thing is confusing - is OP actually Iranian? Do we have evidence that Briar is being used in Iran, and is effective? Why was the Farsi manual linked to an English website, when the English is next to it?
From a quick Google search it seems there's no reference to Briar having any connection to Iran other than this discussion, and other places linking to it.
Why isn't your comment the top one? You're absolutely right. Where is the proof or study of the title? Or at least the title should be rephrased as a question to its users? (What I tried the other day https://news.ycombinator.com/item?id=46592912) This should be reported (to dang).
Yeah, I get hundreds of requests if not more per hour for some obscure personal but public servers that have ~0 legitimate other users. I guess once you're in some index that's just that. For an e-commerce shop, a few thousand irrelevant requests per day should just be part of the background noise that comes with being online these days? Cache is king.
Shell and bash are easy to write insecurely and open your CI runners or dev machines up for exploitation by shell injection. Non-enthusiasts writing complex CI pipelines pulling and piping remote assets in bash without ShellCheck is a risky business.
You shouldn't be pulling untrusted assets in CI regardless. Hacking your bash runner is the hardest approach anyways, just patch some subroutine in a dependency that you'll call during your build or tests.
reply