dpeckett

Secondly the extension is explicitly marked as experimental and is disabled on pretty much all kernel builds.

Some of these platforms are incredibly janky atm, so I'm not at all surprised that something like this could slip through.

The real surprise is scaleway rushing them into production.

Yeh it's a shame T-HEAD didn't release the source for the draft vector extension. Admittedly they had their reasons.

While it might be true, and remain true for high-end designs, we're really seeing a proliferation of mid-to-low end RISC-V SoCs out of china based on open source IP.

Isn't this the Cathedral vs Bazaar debate all over again? All designs have flaws, but at-least with something like the C910 you can open a PR to fix it going forwards.

Sure the first revisions of a new design will be buggy, but over time with iteration and continuous improvement they'll only get better.

I don't think too many folks will be designing new RISC-V cores from scratch, in the same way that very few people build their own OS's. It'll be contributing features and bugfixes to existing designs (and designing custom extensions).

Man biology is weird, yeh it looks like for Lupus and Psoriasis it pretty much doubles the risk of developing it.

Fascinating stuff, it's interesting to read that the main ligands of the AhR (Aryl hydrocarbon receptor) are PAHs (Polycyclic aromatic hydrocarbons) and that activation of the AhR receptor improves the markers of Lupus.

Polycyclic aromatic hydrocarbons are nasty, carcinogenic, molecules that are commonly found in smoke, tar, and char. Basically burnt organic matter. On the other side of the coin AhR is also activated by a bunch of Polyphenols, which are found in a variety of plant derived foods.

Does this mean, it is possible that Lupus (and Psoriasis) are diseases of affluence caused by processed food (low in Polyphenols), and a reduced exposure to smoke byproducts in the environment?

Debco is a declarative, BuildKit powered, Debian base system builder.

Basically mint your own customized Debian distroless images (directly from upstream), with as few or as many packages as you need.

Currently it just builds base images, but I'm hoping to expand it over time to include the ability to perform other common provisioning tasks, such as adding users/groups etc (kind of a mini cloud-init). Also in the future, potentially SBOM generation.

Exactly this whole discussion hinges on the idea that modern vehicle interfaces are somehow "fancy". Touchscreens, ARM boards running Linux, CMOS camera sensors, and drive-by-wire (heck Tesla is even adopting Ethernet) are totally commoditized. They were fancy 30 years ago, but today they are the boring cheap option.

It's pure nostalgia.

I think the key insight behind this approach (and I'm biased here having written something similar) is that the difference between QUIC and (wireguard + network stack) is A LOT less than you might think.

Really cool to see others hacking on netstack, bit of a shame it's tied up in the gVisor monorepo (and all the Bazel idiosyncracies) but it's a very neat piece of kit.

I've actually been hacking on a similar FOSS project lately, with a focus on building what I'm calling a layer 3 service mesh for the edge. More or less came out of my learned hatred for managing mTLS at scale and my dislike for shoving everything through a L7 proxy (insane protocol complexity, weird bugs, and you still have the issue of authenticating you are actually talking to the proxy you expect).

Last week I got the first release of the userspace router shipped, worth taking a look if you want to play around with a completely userspace and unprivileged WireGuard compatible VPN server.

https://github.com/noisysockets/nsh/blob/main/docs/router.md

Thanks for the kind words and great suggestions, I'll take a very close look into ZeroMQ, I'm also keeping an eye on NATS.

Some kind of paid connection broker / app platform actually sounds like a solid way to build a sustainable business out of something like this.

I'm trying to avoid the tailscale model of having to lock up the control plane.

Done, the noisysockets CLI is now available under the AGPLv3 (and NSSL-1.0), pick the license of your choosing with no legal ambiguity. If it turns out the FSL-1.1, and by virtue of being a derivative the NSSL-1.0 is legally sound, after four years the code will be available under the MPL-2.0.

But you don't have to trust me, the AGPLv3 starts immediately.

I'll update the source headers in the following days.

Thanks!

That's actually a really good suggestion, the main reason for using a time limited source available license was that I didn't want to impose a viral copyleft on everyone and lock up the code forever.

The custom license is a pretty basic derivative of the FSL-1.1 with MPL-2.0 instead of Apache (for a weak copyleft), I think I might keep the custom license in place (I'll make the very minimal changes from the stock FSL-1.1 clear).

But adding an AGPLv3 license for those with ambiguity concerns is totally okay with me (it's ultimately more restrictive than the source available license in a lot of ways).

Thank you for the great suggestion.

One of the things on my TODO radar is to implement a LD_PRELOAD'able Unix sockets implementation. Plus I need to get some additional language bindings done (eg. Python).

Mosh was a big inspiration but I took a more traditional PTY based approach rather than object orientated updates.

One thing it does have in common with mosh, is excellent roaming support. And the other major selling point is that the remote shell protocol is browser compatible. No need for things like "Shell In A Box".

Very good summary, and thanks for bringing up the license distinction, the noisysockets core library will always be MPL-2.0 and open to the community.

The fundamental thesis behind noisy sockets is, "What if your network endpoints were processes instead of machines?"

And as you say bypassing the host networking stack actually brings a lot of benefits (eg. avoiding those VPN leak shenanigans), it's actually interesting when you squint enough it begins to even look vaguely something like QUIC (in that you have multiple encapsulated streams/channels/sockets going over UDP with their own congestion control).

Peer discovery and NAT traversal are next on my list. I'm going to implement a kind of userspace lighthouse peer that will advertise peer endpoints to the network. I'm still trying to think about how I will deal with TURN/DERP. I suspect I'll tunnel WireGuard over WebSockets and just have each peer listen on UDP/TCP. Maybe one day that will allow even an in browser peer with WASM (which I'm sure someone will find an interesting use case for).

Also on the list is fine grained authentication/authorization (interestingly netstack has an iptables implementation), some of it will be opensource and some of it will be source available (sorry for the SSO tax).

Thanks everyone for the wonderful Sunday afternoon surprise, I'd posted this originally on a Friday and I guess a lot of us were out watching the polar lights. This was a fun project to work on.

Right now it doesn't support a multi-user daemon mode, kind of similar to mosh. But in the future because the server is able to cryptographically verify the source of connections, it's only a matter of time until I implement something akin to a per user `~/ssh/authorized_keys`.

With noisysockets I'm effectively building out a suite of WireGuard powered "apps". Which are small, unprivileged, programs you can attach to a WireGuard network and will act as virtual peers.

Because WireGuard is a P2P protocol and if you want the server could be behind a NAT (eg. reverse shell). Very useful for accessing your home machine without having to open up a port etc. In the near future noisysockets will get NAT traversal support (with a Nebula lighthouse type server) which will make this use-case a lot simpler.

And that's totally fine :). It's worth noting that as a derivative of the FSL/BSL in four calendar years everything will be released back to the community under the MPL-2.0.

The shell implementation is already under the MPL-2.0 and worth a look at for anyone who's interested https://github.com/noisysockets/shell

An interesting (and portable) alternative to network namespaces is to bypass kernel networking entirely and use a userspace network stack.

I've got an example of doing just that with my project Noisy Sockets, https://github.com/noisysockets/noisysockets/blob/main/examp...

FWIW, I'm currently on the market for freelancing roles, so if you're interested in Go freelancers in the network storage space, please reach out (email is in my profile).

That's the beauty of it, people will leave, and it won't be the people desperate enough to commit marriage fraud.

Anyway none of this is about respecting German law.

Lets combat marriage fraud by making it a kafkaesque ordeal to get married in the first place.

Big brain move, how many innocent couples get caught in the net, versus how many fraudsters can you realistically catch (organized crime has figured out how to game the bureaucracy, no doubt).

I actually looked into this, apparently its popular across western Europe (not just Germany) and a relic of historical times when the states didn't have centralized birth and death registries. I believe the limited validity and Apostille requirement is a medieval method to combat fraud.

As a new world Australian, the fact this remains in force is completely insane. In Australia the authorities can trivially query the birth and deaths register to verify the validity of certificates.

In Germanys defense, centralized registries were used by the Nazi regime to facilitate the Holocaust.

Anyway Biometric passports/ids pretty much completely supersede this use-case and can be as equally decentralized.

We're talking about an interaction with the authorities here. In all developed western nations I am aware of (there's maybe 4-5 countries I've interacted with personally) public authorities will communicate in clear and direct language.

No the point is my wife was struggling, and she asked for help integrating, and the state refused to help her integrate. Even as a hardcore capitalist you should be in favor of getting immigrants into the labor market ASAP.

The irony is that fifteen years ago when she was a new immigrant to Australia, the state sponsored TAFE system was amazing for her, taught her English, and totally turned her life around.

People often forget marriage is also a legal contract (in Germany it simplifies so many things, eg. health insurance, joint income tax filings, etc).

I think most immigrants who get married in Germany are doing it for legal reasons primarily.

Yeh two weeks would be very quick for a German marriage involving foreigners, more realistically a few months at-least all things considered.

Yep the Danes are an entrepreneurial bunch, strict cash for marriage document type deal (but all done very professionally, not some vegas chapel pony show).

We ended up going the Denmark route due to the German process requiring, what was for us, unobtainable documents.

We've had a number of friends do the same due to similar issues, plus the German process can be very cost prohibitive once you start including official translators and such.

The Danish authorities accept a passport as a proof of ID, and the supporting documents can be in Danish, English or German.

I can confirm that moving out into the bacon belt of Brandenburg drastically improved the quality of my public services interactions (as an immigrant). Getting an anmeldung done didn't require a 3 hour ordeal and the local Ausländerbehörde answers their emails.

My favorite Berlin anecdote is when my wife (then girlfriend) and I first arrived in Germany, she was unemployed for the better part of a year as no-one would give her a chance. She actually got quite depressed about it, and reached out about state sponsored integration courses as the language lessons she was taking were expensive and she wanted to do something more holistic. The authorities told her in no uncertain terms that they didn't care and that there were no places available.

My biggest bugbear with Germany is that the state intrudes extensively in your affairs, most of the time they are being benevolent but that intrusion brings in a tremendous amount a bureaucratic baggage. And that baggage is slow, paper based, and becomes a significant barrier for doing anything. In many countries the kind of paperwork you have to slave over here just doesn't exist in the first place.

FWIW my wife and I got married in Denmark. It was impossible for my wife to provide an up-to-date (less than six months old) translated copy of her Chinese birth certificate. Theoretically she could have traveled back to china (in the middle of the pandemic) and begged her backwaters local police authority to print a new copy but they weren't obliged to issue her one. Denmark was happy with her passport and some declarations from the local authorities in Germany.

Some days I really wonder why I continue to put up with the hassle, probably just sunk cost at this point and stubbornness. Wouldn't recommend Germany for anyone with a low frustration tolerance.

Yep noisysockets is based originally off wireguard-go but is an attempt to simplify and make things a lot more idiomatic for library use. Filling in the gaps etc and improving the ergonomics. Hoping to build a bit of an ecosystem of supporting projects around it, eg. I'm currently working on a STUN server implementation based on the approach described in https://nordsecurity.com/blog/reaching-beyond-1gbps

One of the recent feature divergences from upstream is support for network exit nodes / gateways.