raggi

Openssh should have been a game changer but they made a classic openssh porting bug (not reading all bytes from the channel on close) and have now been sat on the fix in “prerelease” for years. I prodded the VP over the group about the issue and they repeatedly made excuses about how the team is too small and getting updates over to the windows team is too hard. That was multiple windows releases ago. Over on GitHub if you look up git receive pack errors being frequent clone problems for windows users you’ll find constant reports ever since the git distribution stopped using its own ssh. I know a bunch of good people at Microsoft, but this leadership is incapable of operating in a user centric manner and shouldn’t be trusted with embedded OSS forks.

I've considered doing something like this a few times, this is seriously ripe for an ON AIR sign :D

dang: the two posts are different topics, also isn't this one "show hn"? I'm so confused by the application of rules around self-posts.

> (This is not real Rust code. Quick challenge for the curious Rustacean, can you explain why we cannot rewrite the above code like this, even if we import all of the symbols?)

Um, you can:

        #![feature(import_trait_associated_functions)]
        use Iterator::{collect, map, filter};
        
        fn get_ids2(data: Vec<usize>) -> Vec<usize> {
            collect(map(filter(<[_]>::iter(&data), |v| ...), |v| ...))
        }

and you can because it's lazy, which is also the same reason you can write it the other way.. in rust. I think the author was getting at an ownership trap, but that trap is avoided the same way for both arrangements, the call order is the same in both arrangements. If the calls were actually a pipeline (if collect didn't exist and didn't need to be called) then other considerations show up.

It sure would be nice if we could actually fix dns.

I have trouble with that because it’s brimming full of plugins too (see them all disorganized all over the source), and failing to keep such a system up to date ends in tears rapidly in that ecosystem.

It's amusing that Xe managed to turn what was historically mostly a joke/shitpost into an actually useful product. They did always say timing was everything.

I am kind of surprised how many sites seem to want/need this. I get the slow git pages problem for some of the git servers that are super deep, lack caches, serve off slow disks, etc.

Unesco surprised me some, the sub-site in question is pretty big, it has thousands of documents of content, but the content is static - this should be trivial to serve, so what's going on? Well it looks like it's a poorly deployed Wordpress on top of Apache, with no caching enabled, no content compression, no HTTP 2/3. It would likely be fairly easy to get this serving super cheap on a very small machine, but of course doing so requires some expertise, and expertise still isn't cheap.

Sure you could ask an LLM, but they still aren't good at helping when you have no clue what to ask - if you don't even really know the site is slower than it should be, why would you even ask? You'd just hear about things getting crushed and reach for the furry defender.

I think it ended at the first "ribbon" UI, which was in the 2003 era, but not all products ate the dirt at once.

As you escape the React/JSX intoxification, you can drop the XML syntax.

It took us a while back in the day after the XHTML arc, but for sure it'll be ok.

I know this looser SGML universe might feel a little kooky, but trust me it wears baggy trousers, rocks gifs with a hard g and offers great <hugs>.

  <thank><you>
  <nothankyou/>

you should see what happened to the rodents in the lab

<insert line of nodding emojis here>

There’s SSHFP, but it’s off by default and assumes an attacker can’t modify dns, though most mitms would be executed with dns and dnssec deployment is generally a disaster.

Currently their host key page is only linked once at the bottom of their page and isn’t referenced in any onboarding docs, so effectively onboarding encourages “yolo”, and if users aren’t savvy they’re likely putting other things at risk, whatever their keys happen to also have access to.

The other argument that comes up here then is “well mitms are rare so this doesn’t seem like a big problem in practice”, however there are actually great targets here, for example you go to a conference and hijack the WiFi, then spend your time in hallway track advertising these services to your targets. This kind of thing has a high success rate.

The web improves on this problem with PKI, though similar phishing tactics exist in a similar situation where you encourage people to sign up explicitly guiding them to an incorrect domain, but propensity for using search in address bars strongly helps resist this too.

SSH is terrible for this use case, no matter how it makes people feel.

So approximately nothing?

What are you doing about TOFU and MITM?

In case y'all missed it in the first post, and you just want to try this out, it's working in this v86 image:

https://copy.sh/v86/?profile=custom&m=768&vram=16&hda.url=ht...

You can start tailscaled and tailscale inside the VM. It may take a while to come online sometimes due to limited proxy availability.

Edit: alt gives you the third button. To start a terminal, hold alt and right click, select new, release alt, and right click drag to size the terminal window.

Dave was ever-present in the areas he had passion for and that presence and unwavering advocacy had many positive outcomes. I'll miss his friendly challenges during future work in this space, they were always enjoyable and valuable even when we had differing approaches.

You might wanna look at a system profiler too, pprof doesn't show everything.

So we aren't using mmap (but we are using WAL), so for one thing there's a lot of buffer and cache copy work going on - I'd expect it's the old classics from string.h. WASM is a high level VM though so I'd expect (provided you pass the relevant flags) it should be using e.g. the VMs memory.copy instruction which will bottom out in e.g. v8s memcpy.

we also don't use a common driver, ours is here https://github.com/tailscale/sqlite

sqlite in general should be mostly optimized for the targets it's often built with, so for example it'll expect everything in string.h to be insanely well optimized, but it should also expect malloc to be atrocious and so it'll manage it's own pools.

I can probably help but what are you looking for?

There are three areas of subject matter here (Go, Zig, SQLite).

Our affected deployment was an unusually large vertical scale SQLite deployment, with the part causing primary concern hitting >48 fully active cores and struggling to maintain 16k iops, large read workload you can think of almost like slowly slurping a whole set of tables, with a concurrent write workload updating mostly existing rows. Lots of json extension usage.

Something important to add here: Go code is largely, possibly entirely unaffected by Zigs intrinsics, as it has its own symbols and implementations, but I didn't check if the linker setup ended up doing anything else fancy/screwy to take over additional stuff.

it was the intrinsics, sometime ago zig "imported" compiler-rt and wrote pure-zig variants that are lacking machine level optimizations and a lot of vectorization and so on. SQLite performance is highly dependent on them.

Why on earth would you think kids are bad at reasoning? Early on we lack experience necessary for as much reliance on derivative thinking.

dedramp

It is 100% your responsibility what your servers do to other peoples servers in this context, and wanton negligence is not an excuse that will stop your servers from being evicted by hosting companies.

There is a real practical problem with the dichotomy in Go unfortunately, where on the one hand a single threaded program is safe, but on the other hand no go programs are single threaded. More mitigations are coming and synctest for example is quite welcome and is already helping where we've tested it, but this stuff just feels like the same old whack-a-mole as e.g. fuzzing for other solutions. gvisors checklocks for example isn't tenable for us without hugely more investment as there are tons of cases it just can't handle (like inline funcs, which we have more than we ought to). You're right that it's different, though - data races are often much harder to discover, arrange and leverage.

We've witnessed memory corruption events (from plain go code), and it's raised real concerns even among our strongest advocates. Our most recent case was actually a false-positive, in that there was a real race on a map, but it so happened it would never have reached a data race - still it tore down a process in production, and this is good and bad on multiple fronts. It doesn't make the solution invalid, and no one should be throwing internet punches over it, but it's absolutely reasonable to be concerned about memory corruption cases in complex go programs. In general my advice for Go usage is to write small programs with low concurrency and small heaps, this manages associated risks well, both in terms of authorship and exposure when events come up. Small container sized things are probably fine, essentially, but many tens of gb of user data in heaps with hundreds of constantly changed kloc is a place to be genuinely concerned.

Reflecting back on the starting context, and this advice, they align. The compiler has no high value user data to corrupt, if it suffers memory corruption the bad cases have to be pretty lucky not to end up in sufficiently total failure as to cause true end user problems. The runtime is short lived and compartmentalized, and it's not in a highly adversarial environment - this is a fine fitting use case. In an attacker heavy situation like the font system though, essentially I'm almost ready to drop maybe one layer of sandboxing once it's implemented with stronger guarantees and had some appropriate testing. I'm not sure I'd be ready to say that with less safety guarantees.

Odd comparison / statement in the context of MS rewriting GDI in Rust

It has a smaller API surface into the consuming applications and platforms.

Skia tendrils run deep and leak all over the place.

There's also a different set of work to invest in, next-generation Skia is likely to look quite different, moving much of the work on to the GPU, and this work is being researched and developed: https://github.com/linebender/vello. Some presentations about this work too: https://youtu.be/mmW_RbTyj8c https://youtu.be/OvfNipIcRiQ

I really want hinting, subpixel and anti-aliasing available on all systems, and i want to pick the appropriate set of techniques based on the dpi and font size to minimize error, fuzzy excesses, and balance computation cost. Obviously we still don't all have high DPI all the time and likely won't for a long while. Apple dropping support was a disaster, and I currently run Apple devices plugged into to regular DPI screens with a slightly downsized resolution to trick it into rendering in a sane way, but it's a bonkers process that's also expensive and unnecessary for non-font paint work.

That said, one of the horrors of using the old font stacks, and in many ways the very thing that drove me away from fighting Linux desktop configurations for now about 10y of freedom from pain, was dealing with other related disasters. First it's a fight to even get to things being consistent, and as seen in your screenshot there's inconsistency between the content renders, the title, and the address bar. Worse though the kerning in `Yes` in your screenshot is just too bad for constant use for me.

I hope as we usher in a new generation of font tech, that we can finally reach consistency. I really want to see these engines used on Windows and macOS as well, where they're currently only used as fall-back, because I want them to present extremely high quality results on all platforms, and then I can use them in desktop app work and stop having constant fights with these subsystems. I'm fed up with it after many decades, I just want to be able to recommend a solution that works and have those slowly become the consistently correct output for everyone everywhere.

HTTP/3 is not a mobile centric technology. Yes there was a lot of discussion of packet pacing and it's implications for mobile in early presentations on QUIC but that's not the same as "centric", that's one application of the behavior. Improved congestion control, reduced control plane cost and removal of head of line blocking behaviors have significant value in data center networks as well. How often do you work with services where they have absolutely atrocious tail latencies and wide gaps between median and mean latencies? how often is that a side effect of http/tcp semantics?

IPv6 is the same deal, I sort of understand where the confusion comes from around QUIC because so much was discussed about mobile early on, and it just got parroted heavily in the rumor mill, but IPv6? that long predates the mobile explosion, and again, it helps as an application, but ascribing it as the only application because of it's applicability somewhere else doesn't hold up to basic scrutiny. The largest data centers these days are pushing up against a whole v4 IP class (I know, classes are dead, sorta) in hardware addressable compute units - a trend that is not slowing.

We did this with quic data center side: https://tailscale.com/blog/living-in-the-future#the-c10k-pro... and while it might be slightly crazy in and of itself, it's far more practical with multiplexing than with a million excessively sized buffers competing over pools and so on.

There is absolutely value to quic and ipv6 in the data center, perhaps it's not so useful for traditionally shaped and sized LAMP stacks, but you can absolutely make great use of these at scale and in modern architectures, and they open a lot of doors/relax constraints in the design space. This also doesn't mean everyone needs to reach for them, but I don't think they should be discarded or ascribed limited purpose so blithely.