romshark

GitHub is slowly turning into the Deutsche Bahn of git providers.

Is there something I'm missing? Why does this workstation need a ~$1000 motherboard and a ~$1000 Xeon CPU? Those two components alone cost more than either of my computers and seem like severe overkill.

Yes, as stated in the article, it probably could have been cheaper. But this setup is supposed to:

1. Run simulations and benchmarks of/on entire SCION topologies with multiple ASes.

2. Potentially grow beyond 25 Gbit/s into the 200 Gbit/s ranges (and more?).

3. Be available to me ASAP (can't wait months for it to arrive from China).

4. Potentially be used for CI/CD performance regression testing in the future.

The budget allowed a bit of headroom for the future.

First of all, at this point, SCION is not here to replace BGP. It's here to provide a more secure way of interconnecting ASes for critical infrastructure applications (finance, defense, government, etc..) that allows path selection and verification over multiple-ISPs. It can for example, be seen as an alternative to MPLS but offering more capability.

SCION also offers more protection against DDoS attacks and other outages thanks to its multi-path routing capabilities and ability to failover quicker than BGP as it builds and stores its path knowledge in advance.

How do I peer with the big corps in a SCION world?

You do so by joining an ISD (Isolation Domain) and inheriting TRC (Trust Root Configuration).

so SCION doesn't really enable a more secure internet, it enables more (largely corporate) control

Much critical infrastructure is still reliant on leased lines or MPLS which is expensive and reliant on a single ISP which often reduces resilience. It often also requires assurances about where its traffic is being forwarded (e.g. through particular countries or regions) which is difficult or impossible with BGP. SCION can instead provide these assurances over the commodity Internet provided by multiple ISPs, by being able to verify paths and allowing packet senders to control how packets should be routed given the available path options.

ISDs are typically for specific use cases (e.g. Swiss Secure Finance Network) where strong assurances are needed for where traffic is sent, but ISDs can decide admission criteria for themselves and how they wish to communicate with other ISDs and the rest of the Internet.

Think of the power grid for example. Putting power plants on the internet is probably a bad idea. A better idea is to interconnect power plants through multiple ISPs over a SCION ISD. Less expensive than leased lines or MPLS, and more flexible.

The developers of data-star.dev are working on something interesting they call "Rocket", but it's currently a WiP and hidden behind a paywall so I can't really compare it to Lit. Lit is great though, used it myself a few times (e.g. github.com/romshark/demo-islands). But I still think there's a learning curve to Lit. Better than raw vanilla JS custom elements API, but still not as simple as it could be.

Repos: https://github.com/romshark/tik https://github.com/romshark/toki

I'm trying to make i18n easier, integrate it better with CI/CD and automate it more with LLMs (for now in Go, second priority is TypeScript and other languages later).

For this I had to develop a completely new approach and subsequently a specification for the "textual internationalization key" (TIK) which are programmatically translatable to ICU MF.

Toki is the first TIK processor implementation for Go.

You might also want to check out this abomination of mine: https://github.com/graph-guard/gqlscan

I've held a talk about this, unfortunately wasn't recorded. I've tried to squeeze as much out of Go as I could and I've went crazy doing that :D

I've recently held a talk (https://youtu.be/a7VBbbcmxyQ?si=0fGVxfc4qmKMVCXk) about github.com/romshark/jscan that I've been working on. It's a performance-oriented JSON iterator / tokenizer you might want to take a look at if interested in high performance zero allocation JSON parsing in Go.

I tried to come up with the most efficient implementation of this rather simple function that I could think of with pure Go without going down to SIMD Assembly: https://go.dev/play/p/zHFxwvWOoeT

-32.31% geomean across the different tests looks rather great. Any ideas how to make it even faster?

A high performance GraphQL proxy that allows you to define a whitelist of queries that you explicitly allow to protect your GraphQL API from malicious queries with undefined complexity.

A simple HTTP file server written in Go that's watching the served file for updates and automatically reloads the page in any modern JavaScript-capable browser.

Shouldn't such old standards like SMS just die?

I didn't write or receive any SMS for like 5 years now (except some confirmation codes) since encrypted messengers became so common and accessible.

I think it's obvious that SMS is outdated either way and I too think that encryption should be P2P on the "application layer" for many reasons. Encrypting the actual physical transport would add extra cost in terms of latency and hardware and could become a maintenance disaster over time if I'm not mistaking.

It'd rather reduce complexity. It'll make Go code less ambiguous leading to fewer bugs that you'll have to spend your time debugging. When working in big teams on big projects you better describe your intentions clearly.

Yes, you can hide state behind interfaces and opaque types, but you don't take into account, that the implementations of those types and interfaces need to be reliable as well. An interface with read-only types, for example, can declare its methods immutable enforcing an immutable receiver type on the implementing functions which makes sure that it's always correctly implemented and doesn't mutate its object for sure! A field can be declared immutable to make sure it remains immutable after the object is initialized, and so on. Immutable types allow you to better express your intentions when implementing something because in a month from now you'll be a different person too and you won't remember certain implementation details like "why you shouldn't mutate this inner slice in this struct" etc.

The whole concept is actually composed of 5 fundamental rules that are relatively easy to pick up. It also shouldn't be compared to C++ or even C style const qualification, because it's easier and safer.

Quick reminder on the live conversation, feel free to join us and share your thoughts and experiences!

https://t.me/yc_summer_2017

Share your thoughs with us, even if you were rejected!

https://t.me/yc_summer_2017

live conversation: https://t.me/yc_summer_2017

for all those who click the button every single minute :D

Live conversation just started, everyone's invited!

https://t.me/yc_summer_2017

South Germany (9 hours ahead) - not yet so far... awaiting