Another user posted the blog where they discuss their speedup techniques: https://tailscale.com/blog/more-throughput/

It's likely that the kernel version can use similar techniques to surpass the performance of the userspace version that tailscale uses, but no one has put in the work to to make the kernel implementation as sophisticated as the userspace one.

Like helping to find a bug, discussing about how to setup an application for a certain use case or anything like that? Answering questions on Stack overflow is an example but is that the best way?

Generally the best way to help out is to do a thing that's needed and that you can figure out how to do. Your list includes a bunch of good options, and I've been thanked for doing all those things at one point or another. Some common growth paths include:

1. Using the software
2. Encountering bugs, problems, or small opportunities for improvement.
3. Discussing those informally in forums and helping people find workarounds.
4. Identifying some of those issues as common things other things experience as well, so filing bugs for them with clear explanations and links to related forum discussions.
5. Reading source code to better understand bugs.
6. Discussing potential fixes in developer bug threads (or in GitHub or whatever).
7. Submitting small fixes for simple bugs as pull requests.

Another path might be:

1. Using the software and reading forums/docs for help.
2. Answering basic questions on forums, looking to old threads and relevant docs.
3. Learning about common questions.
4. Writing blogs or forum posts about common questions.
5. Submitting improvements to official docs to clarify common areas of confusion.

There are other paths as well, the main thing is to use a thing so you learn about it and then use that knowledge to make it a little easier for the next person. Good luck!

I had a look through the comments on this HN thread the other day and came away more intrigued by https://github.com/openobserve/openobserve than hyperdx. Hyperdx is built on top of clickhouse whereas open observe has it's own storage engines based on parquet files that can be accessed from local disk, S3, or a few other protocols.

I haven't tried either option yet… I'm, currently using netdata for metrics and don't do anything special for logs or tracing, but at tiny self-hosting scale I often find software with it's own storage engines (often sqlite) to be extra hassle-free. I'm curious to kick the tires on openobserve for that reason.

… only if you are in the US and get an API key from NCMEC. They are very protective of who gets the keys and require a zoom call as well.

Do you have a source for these statements, because they directly contradict the Cloudflare product announcement at https://blog.cloudflare.com/the-csam-scanning-tool/ which states:

Beginning today, every Cloudflare customer can login to their dashboard and enable access to the CSAM Scanning Tool.

… and shows a screenshot of a config screen with no field for an API key. Some CSAM scanners do have fairly limited access, but Cloudflare’s appears to be broadly available.

Yeah, misread the pricing page. Fixed the post, thanks for the correction.

I use Headscale, but Tailscale is a great service and what I generally recommend to strangers who want to approximate my setup. The tradeoffs are pretty straightforward:

• Tailscale is going to have better uptime than any single-machine Headscale setup, though not better uptime than the single-machine services I use it to access… so not a big deal to me either way.
• Tailscale doesn’t require you to wrestle with certs or the networking setup required to do NAT traversal. And they do it well, you don’t have to wonder whether you’ve screwed something up that’s degrading NAT traversal only in certain conditions. It just works. That said, I’ve been through the wringer already on these topics so Headscale is not painful for me.
• Headscale is self-hosted, for better and worse.
• In the default config (and in any reasonable user-friendly, non professional config), Tailscale can inject a node into your network. They don’t and won’t. They can’t sniff your traffic without adding a node to your tailnet. But they do have the technical capability to join a node to your tailnet without your consent… their policy to not do that protects you… but their technology doesn’t. This isn’t some surveillance power grab though, it’s a risk that’s essential to the service they provide… which is determining what nodes can join your tailnet. IMO, the tailscale security architecture is strong. I’d have no qualms about trusting them with my network.
• Beyond 3 devices users, Tailscale costs money… about $6 US in that geography. It’s a pretty reasonable cost for the service, and proportional in the grand scheme of what most self-hosters spend on their setups annually. IMO, it’s good value and I wouldn’t feel bad paying it.

Tailscale is great, and there’s no compelling reason that should prevent most self-hosters that want it from using it. I use Headscale because I can and I’m comfortable doing so… But they’re both awesome options.

My money is also on IO. Outside of CPU and RAM, it’s the most likely resource to get saturated (especially if using rotational magnetic disks rather than an SSD, magnetic disks are going to be the performance limiter by a lot for many workloads), and also the one that OP said nothing about, suggesting it’s a blind spot for them.

In addition to the excellent command-line approaches suggested above, I recommend installing netdata on the box as it will show you a very comprehensive set of performance metrics without having to learn to collect each one on the CLI. A downside is that it will use RAM proportional to the data retention period, which if you’re swapping hard will be an issue. But even a few hours of data can be very useful and with 16gb of ram I feel like any swapping is likely to be a gross misconfiguration rather than true memory demand… and once that’s sorted dedicating a gig or two to observability will be a good investment.

Tailscale is out, unfortunately. Because the server also runs Plex and I need to use it with Chromecast on remote access…

I rather suspect you already understand this, but for anyone following along… Tailscale can be combined with other networking techniques as well. So one could:

• Access Plex from a Chromecast on your home network using your physical IP, and on your tailnet using the overlay IP.
• Or one could have some services exposed publicly and others exposed on the tailnet. So Immich could be on the tailnet while Plex is exposed differently.

It’s not an all or nothing proposition, but of course the more networking components you have the more complicated everything gets. If one can simplify, it’s often well worth doing so.

Good luck, however you approach it.

So for something like Jellyfin that you are sharing to multiple people you would suggest a VPS running a reverse proxy instead of using DDNS and port forwarding to expose your home IP?

I run my Jellyfin on Tailscale and don’t expose it directly to the internet. This limits remote access to my own devices, or the devices of those I’m willing to help install and configure tailscale on. I don’t really trust Jellyfin on the public internet though. It’s both a bit buggy, which doesn’t bode well for security posture… and also a misconfiguration that exposes your content could generate a lot of copyright liability even if it’s all legitimately licensed since you’re not allowed to redistribute it.

But if you do want it publicly accessible there isn’t a hoge difference between a VPS proxying and a dynamic DNS setup. I have a VPS and like it, but there’s nothing I do with it that couldn’t be done with Cloudflare tunnel or dyndns.

What VPS would you recommend? I would prefer to self host, but if that is too large of a security concern I think there is a real argument for a VPS.

I use linode, or what used to be linode before it was acquired by Akamai. Vultr and Digitalocean are probably what I’d look to if I got dissatisfied. There’s a lot of good options available. I don’t see a VPS proxy as a security improvement over Cloudflare tunnel or dyndns though. Tailscale is the security improvement that matters to me, by removing public internet access to a service entirely, while lettinge continue to use it from my devices.

Do I need to set up NGINX on a VPS (or similar cloud based server) to send the queries to my home box?

A proxy on a VPS is one way to do this, but not the only way and not necessarily the best one… depending on your goals.

• You can also use port-forwarding and dyndns to just expose the port off your home-ip. If your ISP is sucky, this may not work though.
• You can also use Cloudflare’s free tunneling product, which is basically a hosted proxy that acts like a super port-forward that bypasses sucky ISP restrictions.
• If you want to access Immich yourself from your own devices but don’t need to make it available to (many) others on devices you don’t control, I like and use tailscale the best. The advantage of tailscale is that Immich remains on a private network, not directly scannable from the internet. If there’s a preauth exploit published and you don’t pay attention to update promptly, scanners WILL exploit your Immich instance with internet-exposed techniques… whereas tailscale allows you to access services that internet scanners cannot connect to, which is a nice safety net.

Do I need to purchase a domain (randomblahblah.xyz) to use as the main access route from outside my house?

Not for tailscale, and I don’t think for Cloudflare tunnel. Yes for a VPS proxy.

I’ve run a VPS for a long while and use multiple techniques for different services.

• Some services I run directly on the VPS because it’s simple and I want them to be truly publicly accessible.
• Other services I run on a bigger server at home and proxy through the VPS because although I want them to be publicly accessible, they require more resources than my VPS has available. When I get around to installing Immich, there’s a decent chance it will go into this category.
• Still other services, I run wherever and attach them to my tailnet. These I access myself on my own devices (or maybe invite a handful of trusted people into my tailnet), but aren’t visible to the public internet. If I decide not to use immich’s shared gallery features (and so don’t need it publicly accessible) or decide I don’t trust it security-wise… it will go here instead of the proxy-by-vps category.

I use k8s at work and have built a k8s cluster in my homelab… but I did not like it. I tore it down, and currently using podman, and don’t think I would go back to k8s (though I would definitely use docker as an alternative to podman and would probably even recommend it over podman for beginners even though I’ve settled on podman for myself).

1. K8s itself is quite resource-consuming, especially on ram. My homelab is built on old/junk hardware from retired workstations. I don’t want the kubelet itself sucking up half my ram. Things like k3s help with this considerably, but that’s not quite precisely k8s either. If I’m going to start trimming off the parts of k8s I don’t need, I end up going all the way to single-node podman/docker… not the halfway point that is k3s.
2. If you don’t use hostNetworking, the k8s model of traffic routes only with the cluster except for egress is all pure overhead. It’s totally necessary with you have a thousand engineers slinging services around your cluster, but there’s no benefit to this level fo rigor in service management in a homelab. Here again, the networking in podman/docker is more straightforward and maps better to the stuff I want to do in my homelab.
3. Podman accepts a subset of k8s resource-yaml as a docker-compose-like config interface. This lets me use my familiarity with k8s configs iny podman setup.

Overall, the simplicity and lightweight resource consumption of podman/docker are are what I value at home. The extra layers of abstraction and constraints k8s employs are valuable at work, where we have a lot of machines and alot of people that must coordinate effectively… but I don’t have those problems at home and the overhead (compute overhead, conceptual overhead, and config-overhesd) of k8s’ solutions to them is annoying there.

11,263 lbs, huh? It’s not a kind estimate, but not unrealistic either.

If a proxy is useful, I believe this is the implementation that powers Caddy2’s QUIC support.

Nutbutter sort of covered it.

• Tailscale creates a virtual network.
• That network can be (and is by default) private in that no one can join that you don’t allow, and in that respect it’s similar to your home network. You can join your laptop, desktop, and phone to your tailnet… but probably you cannot join your Chromecast or smart-television (they don’t publish tsilscale clients for these devices).
• If you configure Jellyfin to listen on your tailnet and not on the Internet… then you can access Jellyfin from anywhere using a device that is connected to your tailnet, but attackers on the Internet cannot access Jellyfin without first accessing your tailnet, which is hard to do.

The security/convenience tradeoff of tailscale is pretty good if you want to access a service from anywhere, but only from your own devices and only from supported operating systems (Linux, windows, OSX, android… not sure about iOS). It is another networking layer, which can be mind-bending… but as much as such a layer can be easy to use… tailscale is as easy as any of them.

However, Tailscale’s backend is not open-source. They may not log all the data passed through, but they certainly can look at it.

This see sentence is nonsense though.

• Tailscale is end to end encrypted, tailscale cannot quietly see your traffic.
• Tailscale COULD, by default, surreptitiously join a node to your tailnet. If you’re super paranoid, they provide a way to disable this but it makes tailscale much less convenient to use: https://tailscale.com/kb/1226/tailnet-lock/
• Tailscale is phenomenally transparent about security and has WAY higher standards than self-hosters: https://tailscale.com/security/.
• Tailscale clients are open source, and they employ the author of Headscale an open source implementation of the Tailscale control protocols.

There is very little to fear from Tailscale as a provider, and they support the headscale project if you want to go that route (which I do… but not because I am concerned about Tailscale’s integrity or security posture).

This is a great approach, but I find myself not trusting Jellyfin’s preauth security posture. I’m just too concerned about a remote unauthenticated exploit that 2fa does nothing to prevent.

As a result, I’m much happier having Jellyfin access gated behind tailscale or something similar, at which point brute force attacks against Jellyfin directly become impossible in normal operation and I don’t sweat 2fa much anymore. This is also 100% client compatible as tailscale is transparent to the client, and also protects against brute force vs Jellyfin as direct network communication with Jellyfin isn’t possible. And of course, Tailscale has a very tightly controlled preauth attack surface… essentially none of you use the free/commercial tailscale and even self-hosting headscale I’m much more inclined to trust their code as being security-concscious than Jellyfin’s.

Fair enough, sound like you have a well considered use case for Kuma specifically. Good luck, I don’t have much to offer on your OP question.

I’m mostly in the pro-written word camp myself, but I have sought out video tutorials in cases where written docs seem to assume something I don’t know. When I’m learning something new, a written doc might have a 3-word throwaway clause like “… add a user and then…”. But I’ve never added a user and don’t know how. If it’s niche open-source software with a small dev team, this may not be covered in the docs either. I’ll go fishing for videos and just seeing that they go to a web-ui or config-file or whatever sets me on the path to figure out the rest myself.

That is to say, video content that shows someone doing a thing successfully often includes unspoken visual information that the author doesn’t necessarily value or even realize is being communicated. But the need to do the thing successfully on-screen involves documenting many small/easy factoids that can easily trip someone inexperienced up for hours.

I’m as annoyed as anyone when I want reference material and find only videos, and I generally prefer written tutorials as well. But sometimes a video tutorial is the thing that gets me oriented enough to understand the written worthy I wasn’t ready to process previously.

Edit: The ubiquity of video material probably has little to do with it’s usefulness though, and everything to do with how easy it is to monetize on YouTube.

This isn’t exactly an answer to your question, but an alternative monitoring architecture that elides this problem entirely is to run netdata on each server you run.

• It appears to collect WAY more useful data than uptime Kuma, and requires basically no config. It also collects data on docker containers running on the server so you automatically get per-service metrics as well.
• Health probes for several protocols including ping and http can be custom-defined in config-files if you want that.
• There’s no cross server config or discovery required, it just collects data from the system it’s running on (though health probes can hit remote systems if you wish).
• If any individual or collection of services is down, I see it immediately in their metrics.
• If the server itself is down, it’s obvious and I don’t need a monitoring system to show a red streak for me to know. I’ve never wasted more than minute differentiating between a broken service and a broken server.

This approach needs no external monitoring hosts. It’s not as elegant as a remote monitoring host that shows everything from a third-party perspective, but that also has the benefit of not false-positiving because the monitoring host went down or lost its network path to the monitored host… Netdata can always see what’s happening because it’s right there when it happens.

I wouldn’t say that my partner “doesn’t care”, but they take a much more pragmatic view than I which results in more exposure. In general, we do the following:

1. To a first approximation, they decide what apps and services they use. It’s not a monarchy. They’ll ask for feedback when comparison shopping, but often the answer is “every dominant ecosystem in this space is terrible, the privacy respecting options don’t meet your requirements, this option is 5% worse and this one is 5% better… glhf”.
2. For social media accounts that share posts about our nuclear family, we come to broad consensus on the privacy settings and practices. There’s give and take here, but I make space to use dominant sharing apps and they make space to limit our collective exposure within reason. If I have a desire to “harden” the privacy settings on a service, it’s on me to put in the effort to craft the proposed settings changes and get their buy in on the implications.
3. I have many fewer privacy raiding accounts than they do. I both benefit from transitive access to the junk they sign up for, and pay a cost in my own privacy by association. This just is what it is. The market for partners that align with my own views perfectly is basically zero though, and honestly I probably wouldn’t put up with my shit even if I could find one.
4. If I can self-host a competitive option for a use-case that I’m happier with… they’ll give it the old college try. But it has to actually be competitive or they’ll fail out of the system and fall back to whatever works for them. If we can figure out what’s not working we’ll sometimes iterate together, but sometimes it’s just not good enough and we go back to something I like worse.

It’s basically like navigating any other conflict in values. You each have to articulate what your goals are, and make meaningful compromise on how to achieve something that preserves the essentials on both sides. As a privacy outlier, sometimes one also needs to be able to hear “I want to do normal shit and not feel bad about it” and accept it. But if we do want to reach for outlier privacy practices in some specific area, it’s on us to break that desire down into actionable steps in realistic directions at a sustainable pace and to not ignore the impacts to our partners of the various tradeoffs we’re proposing. Privacy is often uncomfortable and we need to acknowledge the totality of what we’re asking for when we ask our partners to accommodate our goals there.

The headline of the article is just The History of the Modern Graphics Processor, though. OP is having a fever dream with that post title, it has nothing to do with the article title or with the article.

Did the government invent OP to make us question Betteridge’s law of headlines? Has the law of headlines become too dangerous to ignore?