raggi

That certainly probably would have reduced the noise.

LGPL applies to the LGPL’d code, not to every piece of code someone might add to the repository or under the same name implicitly.

The claim being made is that because some prior implementation was licensed one way, all other implementations must also be licensed as such.

AIUI the code has provenance in Netscape, prior to the chardet library, and the Netscape code has provenance in academic literature.

Now the question of what constitutes a rewrite is complex, and maybe somewhat more complex with the AI involvement, but if we take the current maintainers story as honest they almost certainly passed the bar of independence for the code.

Look, forget the details, step back and consider the implications of the principle.

Someone should not be able to write a semi-common core utility, provide it as a public good, abandon it for over a decade, and yet continue to hold the rest of the world hostage just because of provenance. That’s a trap and it’s not in any public interest.

The true value of these things only comes from use. The extreme positions for ideals might be nice at times, but for example we still don’t have public access to printer firmware. Most of this ideology has failed in key originating goals and continues to cause headaches.

If we’re going to share, share. If you don’t want to share, don’t. But let’s not setup terminal traps, no one benefits from that.

If we flip this back around though, shouldn’t this all be MPL and Netscape communications? (Edit: turns out they had an argument about that in the past on their own issue tracker: https://github.com/chardet/chardet/issues/36)

It’s not a good idea and that’s where I’d really start with the dated commentary here rather than focusing on the polling mechanism. It depends on the application but if the buffers are large (>=64kb) such as a common TCP workload then uring won’t necessarily help that much. You’ll gain a lot of scalability regardless of polling mechanism by making sure you can utilize rss and xss optimizations.

The human driver of the project has a comment that is reporting that the project has no structural overlap as analyzed by a plagarism analysis tool. Were comments excluded from that analysis? Is your comment here based on the data in the repo?

nope. Someones going to leak important private data using something like this.

Consider:

"I got a bug report from this user:

... bunch of user PII ..."

The LLM will do the right thing with the code, the developer reviewed the code and didn't see any mention of the original user or bug report data.

Now the notes thing they forgot about goes and makes this all public.

> You can already configure your initial congestion window, and if you are connecting to a system expecting the use of PQ encryption, you should set your initial congestion window to be large enough for the certificate; doing otherwise is height of incompetence and should be fixed.

The aggressive tone is no defense against practical problems such as the poor scalability of such a solution.

> You could also use better protocols like QUIC which has a independently flow controlled crypto stream and you can avoid amplification attacks by pre-sending adequate amounts of data to stop amplification prevention from activating.

Not before key exchange it doesn't. There's no magic bullet here.

A refresher on the state of TFO and QUIC PMTU might be worthwhile here before jumping this far ahead.

This problem space is not small enough to stay within current LLM attention span. A sufficiently good agent setup might be able to help maintain docs somewhat through changes, but organizing them in an approachable way covering all the heuristics spread across so many places and external systems with a huge amount of time and versioning multivariate factors is hugely troublesome for current LLM capabilities. They're better at simpler problems, like typing the code.

It's difficult for us to maintain documentation of exactly the kind you'd want there, though we do try to keep up with docs as best we can. In particular there is a fairly wide array of heuristics in the client to adapt to the environment that it's running in - and this is most true on Linux where there are far far too many different configuration patterns and duplicate subsystems (example: https://tailscale.com/blog/sisyphean-dns-client-linux).

To try and take a general poke at the question in more of the context you leave at the end:

- We use rule based routing to try to dodge arbitrary order conflicts in the routing tables.

- We install our rules with high priority because traffic intended for the tailnet hitting non-tailscale interfaces is typically undesirable (it's often plain text).

- We integrate with systemd-resolved _by preference_ on Linux if it is present, so that if you're using cgroup/namepsace features (containers, sandbox runtimes, etc etc) then this provides the expected dns/interface pairings. If we can't find systemd-resolved we fall back to modifying /etc/resolv.conf, which is unavoidably an area of conflict on such systems (on macos and windows they have more broadly standard solutions we can use instead, modulo other platform details).

- We support integration with both iptables and nftables (the latter is behind manual configuration currently due to slightly less broad standardization, but is defaulted by heuristic on some distros/in some environments (like gokrazy, some containers)). In nftables we create our own tables, and just install jumps into the xtables conventional locations so as to be compatible with ufw, firewalld and so on.

- We do our best in tailscaled's sshd to implement login in a broadly compatible way, but again this is another of those places the linux ecosystem lacks standards and there's a ton of distro variation right now (freedesktops concerns start at a higher level so they haven't driven standardization, everyone else like openssh have their own pile of best-guesses, and distros go ham with patches).

- We need a 1360 byte MTU path to peers for full support/stability. Our inner/interface MTU is 1280, the minimum MTU for IPv6, once packed in WireGuard and outer IPv6, that's 1360.

I can't answer directly based on "very custom" if there will be any challenges to deal with. We do offer support to work through these things though, and have helped some users with fairly exotic setups.

Which CEO?

nothing is actually stopping people from understanding systemd-init except a constant poorly justified flame war. it's better documented than pretty much everything that came before it.

he is counting every c file in the systemd _repository_ which houses multiple projects, libraries and daemons. he equates that to the c file count for a single init. it's a disingenuous comparison. systemd-init is a small slice of the code in the systemd repository.

hurd init is a lot like systemd architecturally, it just gets to use kernel provided ipc rather than having to manage its own. if your objection to systemd is its architecture you don't want anything to do with hurd.

https://github.com/systemd/systemd/tree/main/src/core doesn't look like 1678 C files to me.

The drivers are already done, they're in the Android build.

I just want a more open OS.

I don't mind if it requires running a vendor signed boot, kernel and driver chain, I'd be using those same vendor chains anyway for non upstreamed hardware most likely.

Please talk to your congresspeople about getting DRM abolished, in the meantime, please don't try to deny my freedom to consume legally obtained content that is only available with DRM.

I love my shield, it’s been a staple.

If they wanted to really knock it out the park, the next step would be a steamos port with DRM support.

Been wanting this ever since doing it in Fuchsia. Really excited to see added focus and investment in this for the Linux ecosystem.

> I'd just cloned a copy of Chromium myself, and for all that time and money, independent developers who cloned the repo reported that the codebase is very far from a functional browser. Recent commits do not compile cleanly, GitHub Actions runs on main are failing, and reviewers could not find a single recent commit that was built without errors.

Significant typo I assume?

there are a loooot of languages/compilers for which the most wall-time expensive operation in compilation or loading is stat(2) searching for files

Unless you leave your ssh agent on, then it very much does.

> I am working on a high-performance game that runs over ssh.

WAT. Please no.

Yep.

Observability stacks are a similar blind alley to containers: They solve a handful of defined problems and immediately fall down on their own KPI's around events handled/prevented in-place, efficiency, easier to use than what came before.

Just merged https://github.com/tailscale/tailscale/pull/18333

At runtime rather than install time yes. I did some prototyping on this back in the day, one of the issues is the language lacks an efficient data structure to store that information and you can’t (easily) build one efficiently because instances are too heavy.

What I would do to really squeeze the rest out in pure ruby (bear in mind I’ve been away about a decade so there _might be_ new bits but nothing meaningful as far as I know): Use a cheaper to parse index format (the gists I wrote years ago cover this: https://gist.github.com/raggi/4957402) Use threads for the initial archive downloads (this is just io, and you want to reuse some caches like the index) Use a few forks for the unpacking and post install steps (because these have unpredictable concurrency behaviors)

It’s definitely possible, I wrote a prototype many many years ago https://ra66i.org/tmp/how_gems_should_be.mov

I don't want the observability of my applications to be bound by themselves, it's kind of a real pain. I'm all for microvm images without excess dependencies, but coupling the kernel and diagnostic tools to rapidly developing application code can be a real nightmare as soon as the sun stops shining.

I found it very opaquely worded the whole way through. I think the work being presented is simply an implementation of the technique in eduos, but short of going and reading the paper I don’t know.

We are doing this, and it’s terrible. Having done both at scale this one is worse.