the control plane is closed source, but headscale is an open source alternative that we embrace and encourage people to use if it meets their needs/desires

Consider that if every DE wrote their own Xorg implementation the story would be the same.

A key question is why everyone is writing their own compositor, this is not about the protocol design, it's about the state of collaboration.

I spent some time in the last week fixing lowdpi font rendering in cosmic, enabling me to switch to it. I then discovered that cosmic-comp's VRR had a terrible feedback path causing conformant applications to stutter badly, so I have large patch stack rewiring full screen feedback, tranche compatibility, fence timing and so on (it's fucking buttery now though, which is nice). That then showed up some input processing bugs becoming visible via playing videos in firefox, leading further to me discovering that cross-plane locking was causing frame drops too. Now I've got a giant stack of shit I need to cleanup and upstream - but the end result (along with the freetype render patches I got into Firefox a while back) is a better DE than I've had on Linux in decades. Maybe if upstreaming goes well I'll do MPO for an encore.

> In X, if the WM crashes, X is still running, and you can just restart the WM. In Wayland, if you hit a bug it takes everything down with it.

See above, the WM did not need to embed the compositor. That's not a protocol requirement, it's and implementer choice. I actually really wish it didn't. Of all the aforementioned patches only two are in Smithay. As I was actually fixing compositing for the workflow I just had to suffer through I would have had to restart pretty much the whole session anyway - though in fact the later stages of my workflow I was only directly killing cosmic-comp and cosmic-session was automatically restarting it all. No really good way to recover the surfaces though, so apps still need to restart.

This is not unlike the _another_ bug stream I tracked down this evening, where cosmic-applets would fail to display tray icons on both displays correctly - that turned out to be a bug where one icon provider was unresponsive to part of the protocol, coupled with a synchronous dispatch from the event handle into that blocking return call. Perhaps more interestingly though that manifest during diagnosis something I've seen a lot in other DE chains where tray icons for auto-started electron apps were highly sketchy - well a common electron wrapper gives up entirely on the first whiff of an error with the dbus interface and doesn't retry.

Years ago I gave up on Linux DE's because reconfiguring xft, gnome, etc was too much of a time sink. How far I've come, now I'm back :'(

> Fourth, there is a bandwidth concern. FHE encryption schemes generally increase the size of the data being encrypted, and the user must send the server a special set of encryption keys to enable the computation, which are relatively large as well. The special keys need only be generated and sent once and can be used for all future computations, but they can easily be gigabytes in size. In one example FHE scheme with lightweight keys, a ciphertext encrypting a single integer is on the order of 25 KB, and the special keys are about 0.5 GB. In others, 16,000 or more integers are packed into a single ciphertext of similar size, but the keys can be 10s of GiBs.

The team chose SQLite early on (there are some blog posts about this) and then we vertically scaled against the SQLite architecture. There are subtle ways you come to depend on the proximity/latency when you scale with local storage that mean switching requires a lot of non-obvious work - it’s probably the largest hazard for embracing SQLite in a growing saas - but at the same time you can push the vertical scale pretty far, which has great margins.

Had we scaled a different architecture of database there’s little reason to believe it would have been plain sailing as seems to be implied here.

Comments URL: https://news.ycombinator.com/item?id=49263928

Points: 7

# Comments: 0

It was a very useful contraction in the right senior circles where there was a pretty good understanding of the meaning and decently reliable assumed consensus.

I eventually stoped using the phrase because it had started leaking deeper into the team and the impact on earlier career or less confident programmers was often no longer positive, it could be misinterpreted in lots of different ways but the most harmful was when it would further decimate confidence and discourage requests for help when something wasn’t obvious to the ultimate author.

As with almost every attempt to generalize in software engineering the repetition or extrapolation beyond the context in which it was intended can have negative side effects, it doesn’t matter if it’s a simple notion like “dry”, or a comment like “code was never the hard part”. None of these phrases survive context loss and still retain efficacy at general receivers.

Honestly at this point I'd be kind of happy if we could just use an x.509 cert from a webpki acme provider in the sshd and be done with it, for the host identity part.

When I last harassed Crawshaw about this and we discussed bits, he submitted https://github.com/C2SP/C2SP/blob/main/well-known-ssh-hosts....

Unfortunately neither of us has taken time (AFAIK) to go back and implement it anywhere.

webpki is on by default.

on terminal.shop, steal credit cards on jobs endpoints, perform identity theft on exe.dev, whatever you put on there

If you are motivated to build a much less featureful client, it is easier now than it has ever been, and this work is ongoing.

What is likely to get more muddy over time is the accuracy of any copyright registration, and the enforcement of copyright infringements on portions of the whole. These are already complicated cases and definitely so for compilers with so much "scènes à faire".

It's not clear how much this has a negative impact on cases around the whole, which tend to be the more important cases for the four freedoms that, while they have other intentions, have a primary intention of ensuring that the whole continues to be available for redistribution and extension in perpetuity.

I do not think that there is a clear link between these two areas at all, and the GPL's most important intents may be far safer long term than concerns of dilution suggest.

I also don’t think this is about mixing, the LLM part of the problem doesn’t have determinism around the boundaries so they’re feel good at best, maybe making some cases a bit harder

trifecta is a forever problem with this architecture