ISO

• The way to the provider does account auth varies.
• The API for getting e.g. server list info varies.
• Configuration generation varies.
• Implementation choices for the VPN protocols varies (e.g. which user-space wireguard implementation to use if the kernel one is not usable for some reason).
• Some features would require some scripting/light programming if not implemented by the provider. Not only is that asking for a lot, but errors here can be catastrophic.
• ...etc

All that, and we didn't even talk about user experience 😉.

Having said all that, if you're not using a service that offers configuration generation, which allows you to use your own clients, you're doing it wrong.

I use one of the services from your list. And beyond private key generation, I do everything with simple scripts on desktop (or using "protocol" clients on mobile). This is trivial since the server list with its addresses and public keys is publicly available as JSON, even without auth. So putting that info and my private key(s) together, I can actually generate all the configs I want myself with ease.

But that's just me. And providers would go broke if they only catered to the likes of me.

It’s not paywalled. They just require to log in.

tom-aih-to tom-aa-to

Overall 404media is pretty solid.

Clearly not, considering the intelligence-insulting rage-baiting attempt.

PAYWALLED ARTICLE
HUGE SCANDAL: Public Content Is Getting Indexed

There must be a hidden requirement somewhere for "AI bad" posting forcing such content to touch the bottom of the barrel of human intelligence.

Who knows, maybe it's a deliberate counter measure against good technically coherent "AI bad" talk.

Or maybe people can't get angry without losing 90% of their supposedly existing intelligence in the process anymore.

Probably a bit of this, a bit of that!

Should users who don't self-host start recording themselves while coding just as a precaution, in case their host will ask for evidence of work authenticity?

While it is indeed amusing to think that perma-online often-wrong people are geniuses who perfected the execution of Cunningham's Law. In reality, they couldn't be further from that. And everything they write is second or third hand anyway, often sourced from the bottom-of-the-barrel corners of the internet.

Watch them call me AI again because of the "while..they", after the magnificent leap of detecting my supposed anti-immigrant sentiment (which is a dog-whistle for "fervent racist" of course).

how ironic

I was referring to a 20 year old experience, not 20 years of experience. But I'm glad that triggered you to do a known variation of ad verecundiam.

For someone who ~~lurks~~ roams that much, and makes baseless claims liberally, you appear to be missing a lot of basic info, like responsible disclosure, gap periods, or the private mailing list every distro is on which allows them time to ship fixes before the vulnerabilities are announced.

My almost 20 years old experience is that it's the worst of all Debian worlds, and none of them are good in any case.

You would be neither getting distro's promised stability, nor would you be close enough to getting upstream's fixes like sid/unstable.

I vaguely remember Gnome's bug tracker filled with duplicate reports about crashes that are long fixed upstream, but also don't trigger in either stable or sid Debian packages. They all came from Debian Testing. Gnome must have been very happy with Debian enabling the crash reporter in their packaging!

Do note that sid/unstable itself becomes as shit as Testing whenever the next Debian release is around the corner, as the project freezes the world in that period (or used to at least).

If you want the imagined stability you guessed you would get from Testing, you can use Ubuntu. At least with that you won't get packages that are left crashing for everyone. Or honestly, if you're on a desktop, just use Arch. The supposed meme about using Arch exists for a reason.

It would be a cool if you report back in a separate post if you discovered anything interesting. It's not like we're overwhelmed by too much activity here.

Also, while I think it should be obvious, but I forgot to clarify that if you're inheriting from a profile with codegen-units = 1, then you need to set that explicitly to a higher value in the inheriting profile.

Fun because you like rewriting existing code?

Rust4Linux is not a "rewriting" endeavor.

Fun because you already have test suites you don’t have to rewrite?

See previous point.

Fun because you feel morally superior by writing fresh code, even though the old code is running critical applications in production?

Can you point to where "moral superiority" was used as a reason for using Rust in the Linux kernel?

Can you point to an example where Rust code in the kernel caused breakage in "critical applications in production"?

Bonus: Do you think "critical applications" closely follow mainline?

Fun because you think your smarter than the engineers that lay the ground work before you?

Who were the engineers that came before Greg Kroah-Hartman?

What ground work exactly are you referring to?

How does Rust code in the kernel relates to this?

Fun because you like hunting bugs you created thinking you know better, while calling your rewrite superior.

Better than whom?

What rewrite?

Where was it stated that the fun was in hunting more bugs?

Bonus: Do I actually prefer it if someone other than the original coder is hunting bugs?

And to finish with a meta question:
Why the likes of you feel the need to share opinions based on fictional events regarding matters your clearly completely clueless about?

Make sure you're using a fast linker. Although I think lld is the default now, so that should be less of a concern these days. But see if mold or wild would help.

More relevantly, you should be using cranelift for codegen in dev builds.

If you have codegen-units = 1 in your release profile, make sure you have a separate dev profile that doesn't.

If you still experience decapitating slowness (doubtful), and it's actually the rust compiler being slow (super doubtful), you can try the parallel frontend. Apparently there are almost™ no bugs left in its implementation (It's one of the project priorities now).

Needless to say, but you should be checking your --timings to really know what's going on.