If you haven't checked out sequoia (sq), you should! I think it ticks your boxes.
2,504 karma · joined December 20, 2023
I think UDP support for SOCKS5 proxies and clients is very spotty, especially beyond DNS. Probably some bugs out there. That might go for UDP in more or less esoteric container networking setups too...
If everything else fails, I've had the least hassle with socat, as well as just chucking workloads in full vm (if in container with --network=host) and using ip routes and policies.
If you need the pod to do outbound connections as well as receive incoming traffic, usually that would be two different proxies (forward and reverse, respectively). Unless you do some fancy p2p service mesh.
Caddys "magic TLS" can be neat for this if you actually do want to dynamically intercept those https connections in an easy way. It's a use-case where Caddy really shines. You can go nuts trying to configure that cleanly in squid. The docs (perhaps intentionally) make you work for the hidden knowledge of these dark arts. You also get modernities like builtin http2, http3, etc.
Nobody else bothered by squids very lengthy restart time or have I just never configured it properly?
(Not to dunk on squid, it's otherwise mostly great. Especially for its caching features)
All for what? Lack of initiative and independent thinking? Did you intend this to be a reply to a different comment?
- Easy access to (newer versions of) some particular package like a device driver in distro repos[0]
- You prefer the Kubuntu default experience more and don't want to customize
- Company policy
[0]: For most packages, ~half the time Debian stable is ahead of Ubuntu LTS as the former is the base of the latter. Currently latest Ubuntu LTS 24.04 is still based on Debian oldstable. It will catch up with 26.04, until next Debian stable release. Sometimes, though, Ubuntu do their own backports or releases where Debian stable does not.
Reality must have been falling apart for someone for a brief moment there.
They are not in the same class, which is reflected in the power envelope.
BTW what's up with people pushing N150 and N300 in every single ARM SBC thread? Y'all Intel shareholders or something? I run both but not to the exclusion of everything else. There is nothing I've failed to run successfully on my ARM ones and the only thing I haven't tried is gaming.
The index could be split from the build and the package build defs could live in independent repos (like go or aur).
It would probably take some change to nix itself to make that work and some nontrivial work on tooling to make the devex decent.
But I don't think the friction with nixpkgs should be seen as damning for backing a package registry with git in general.
I still think anyone who grew up with such a machine would be able to graduate to a numerical temp knob without having a visceral reaction over the numbers every time they do laundry.
Host gh-auth
Hostname github.com
Identityfile blah
User git
Like you, I don't buy the argument that people are actually too dumb to deal with the latter or are allergic to numbers. People get used to and make use of numbers in context naturally if you expose them.
I don't know if you rely on github.com but IMO vendor lock-in there might be a bigger issue which you can avoid.
It excludes many and is a vector for censhorship and surveillance.
Giscust.
The issues are only fundamental with that architecture. Using a separate repo for each package, like the Arch User Repos, does not have the same problems.
Nixpkgs certainly could be architected like that and submodules would be a graceful migration path. I'm not aware of discussion of this but guess that what's preventing it might be that github.com tooling makes it very painful to manage thousands of repos for a single project.
So I think it can be a lesson not to that using git as a database is bad but that using github.com as a database is. PRs as database transactions is clunky and GitHub Actions isn't really ACID.
Every package has its own git repository which for binary packages contains mostly only the manifest. Sources and assets, if in git, are usually in separate repos.
This seems to not have the issues in the examples given so far, which come from using "monorepos" or colocating. It also avoids the "nightmare" you mention since any references would be in separate repos.
The problematic examples either have their assets and manifests colocated, or use a monorepo approach (colocating manifests and the global index).
Hence upvoting the OP ("What has robpike come to? :shriek:") and downvoting GP.
Here not only are the senders apparently happily associating their actual legal names with the spam but frame the sending as "a good deed" and seem to honestly see it as smart branding.
We don't want the Overton window wherever they are.
Those settings will affect what email shows up in commits.
In commits you vreate on other tooling you can configure a fake/alternate user.email address in gitconfig. Git (not just GitHub) needs some email address flr each commit but it is freetext.
There is one problem: commit signatures. For GitHub to consider a commit not created by github.com Web UI to be "verified" and get a green check mark, the following needs to hold:
- Commit is signed
- Commit email address matches a verified GH account email address
So you can not use a 'nocontact@thih9.example.com' address and get green checks on your commits - it needs to be an address that is at least active when you add it to your account.