Hacker News new | past | comments | ask | show | jobs | submit | marksomnian's comments login

Assuming arguendo that apple did want to do that kind of messing with DNS though - what's there to stop them from changing getaddrinfo() in the same way? As someone pointed out upthread, if you don't trust your OS vendor to do DNS lookups correctly, your only option is to not usre your OS vendor for DNS lookups, which is in the realm of Byzantine faults.

(And further, assuming arguendo that there was DNS meddling happening but somehow getaddrinfo() was exempt - now the user has one app that behaves differently to all their others, which is worse in every practical sense.)


> Assuming arguendo that apple did want to do that kind of messing with DNS though - what's there to stop them from changing getaddrinfo() in the same way?

Nothing, I already acknowledge they have the power to do rootkity things if they wanted to, but I don't consider that likely.

I do consider it likely they might do that kind of a thing at a framework level and try to push most developers to use it.

> As someone pointed out upthread, if you don't trust your OS vendor to do DNS lookups correctly, your only option is to not usre your OS vendor for DNS lookups, which is in the realm of Byzantine faults.

I responded to that as I'm responding here, by pointing out that isn't relevant to the threat model that I've described.

> now the user has one app that behaves differently to all their others, which is worse in every practical sense.

Not if that app actually gets the user to where they actually wanted to go.


Seems like a non-sequitur? Why does LLM integration mean that Zed is less good of an editor for junior devs?


Right, LLM integration should be a huge boon for junior developers.


Not sure if it's what GP is talking about - but haven't you noticed how many juniors seem to be shooting themselves in the foot with LLMs these days, becoming over-reliant on it and gaining expertise slower?


This is exactly what I'm talking about. Ever since LLMs took over, I've noticed an uptick in my fellow senior developers complain about the quality of work, but I've also seen a huge increase in the poor quality of PRs to open source projects.

Like, normally my primary complaint about LLMs is their copyright violating nature, and how it is hanging everyone who has ever published the output of an LLM out to dry, but unless LLM output improves, I think it may end up being a non-issue: their use will die out, and every AI startup will die, just like all the Alt-coin startups did.

Want to change my mind on LLM quality? Have it produce code so good that I can't tell the difference between an inexperienced developer (the kind that would be hired into a junior role, not the kind that would be hired for an internship) and the output of this thing.


Here's one of my best documented examples: https://simonwillison.net/2024/Apr/8/files-to-prompt/

And a more recent example (writing me a Django app): https://simonwillison.net/2024/Aug/8/django-http-debug/#clau...


I've noticed the opposite: people who had never even started learning to program who are now getting stuck in because they don't have to wade through six months of weird error messages about missing semicolons to get started.

But I guess I'm talking about complete newbie developers, which is a different category from junior developers.

I have 25+ years experience at this point so I'm pretty far removed from truly understanding how this stuff benefits newcomers!


Interesting footnote:

> In the 2022 engagement, the client’s engineers were enthusiastic about the prospect of a public analysis, and Jepsen was allowed to file public issues against systems including etcd. Following the conclusion of the contract, Jepsen independently completed a written report discussing the behaviors we’d found in etcd. However, Jepsen was unable to secure official permission from the client’s legal department to disclose that the client had funded part of the work. This created an unusual state of affairs: the issues, test suite, and reproduction instructions were all public, but per Jepsen’s ethics policy, the analysis itself could not be published. Jepsen shelved that analysis and it remains unpublished. The present analysis is based on entirely new work and verifies a different software system: jetcd, rather than etcd


> No one followed up on the jetcd issue, and it was automatically closed as stale.

Another excellent outcome from those GH automations


Makes me wonder if the Go v3 client has the same problem. If yes, that would be a major problem for all the Kubernetes systems in production.


At the very real risk of "talk is cheap," my understanding is that is part of why Jepsen publishes the test suites (e.g. https://github.com/jepsen-io/etcd ) so it's not "take my word for it" but rather "lein run test-all" and watch the fireworks. So, a sufficiently motivated actor, say for example one of the deep-pocketed stewards of the Kubernetes project could run the tests themselves

Between my indescribable hatred for etcd and my long-held lust for a pluggable KV backend (https://github.com/kubernetes/kubernetes/issues/1957 et al) it'd be awesome if any provable KV safety violations were finally the evidence required for them to take that request seriously


Having looked at the test suite already, I know enough to know that I don't understand it well enough to be that guy to do this. It's for this reason, I'm personally going to pull out the popcorn and see what happens over the next few weeks.


I'm currently working on a Rust v3 client, and have been reading the Go v3 source code, and the code definitely is hard to follow so I would be unsurprised if there were issues lurking.


could you be more specific on what's so hard to follow? it's quite literally just the implementation of the GRPC interface [1].

[1] https://github.com/etcd-io/etcd/blob/main/client/v3/kv.go#L3...


I was curious and dug into the Go client code. You linked to the definition of KV – the easiest way to create one is with NewKV [1], which internally creates a RetryKV [2] wrapper around the Client you give it.

RetryKV implements the KV methods by delegating to the underlying client. But before it delegates an immutable request (e.g., range), it sets the request retry policy to repeatable [3].

Retries are implemented with a gRPC interceptor, which checks the retry policy when deciding whether a request should be retried [4].

The Jepsen writeup says a client can retry a request when “the client can prove the first request could never execute, or that the request is idempotent”. In my (cold) read of the code, the Go client stays within those bounds.

For non-idempotent requests, the Go client only retries when it knows the request was never sent in the first place [5]. For idempotent requests, any response with gRPC status unavailable will be retried [6].

Unlike jetcd, the Go client’s retry behavior is safe.

[1] https://github.com/etcd-io/etcd/blob/main/client/v3/kv.go#L9... [2] https://github.com/etcd-io/etcd/blob/main/client/v3/retry.go... [3] https://github.com/etcd-io/etcd/blob/main/client/v3/retry_in... [4] https://github.com/etcd-io/etcd/blob/main/client/v3/retry_in... [5] https://github.com/etcd-io/etcd/blob/main/client/v3/retry.go... [6] https://github.com/etcd-io/etcd/blob/main/client/v3/retry.go...


Just dropping a comment to express my gratitude for sharing a breakdown of your interpretation. :)



The watch is a simple processing loop that receives and sends on a bi-directional GRPC channel. Leases have a similar loop for keep-alive messages, everything else is quite literally delegated.

I get that it's difficult to translate this 1:1 into Rust without channels and select primitives, but saying it's complex is wild. Try the server-side code for leases ;)


Some lines on the London Underground do use ATO without platform barriers. The driver closes the doors, checks that the platform is clear, then starts the train. ATO takes over until the next station, where the driver watches to make sure there's nobody too close to the edge, ready to slam on the emergency brake.


And https://www.map.signalbox.io/, which tries to interpolate signal locations onto a geographic map (with the expected level of inaccuracy, though still not half-bad)


I believe http://go isn’t special cased, but instead (ab)uses DNS search domains - the server is actually something like go.corp.google.com, and all Google PCs are configured to use corp.google.com as a search domain


That's normal DNS behavior. If your machine is foo15241.corp.google.com, and you ask DNS for "go", you are supposed to get "go.corp.google.com".


Also it's a violation of Obsidian's license:

> Obsidian is free for personal and non-profit use. However, if you use Obsidian for work-related activities that generate revenue in a company with two or more people, you must purchase a commercial license for each user. Non-profit organizations are exempt from this requirement.

https://obsidian.md/license


Perhaps they pay for a commercial license?

> Q3. Can I buy a license for myself, or do I have to ask my company to buy it for me? > Yes, you can buy a license for yourself; just put your name in the company > field. You can use such a license to work for any company.

https://help.obsidian.md/Licenses+and+payment/Commercial+lic...


Interesting that Ryujinx is written in C# - I'm not sure why, but at first thought I'd have expected something like a console emulator (where one would have to do "unusual" memory / GPU operations to fully match the quirks of the platform) to be written in C or C++, like Dolphin or PCSX2 (Wii / PS2 emulators) are. Though clearly they can make C# work well for it, and the benefits of working in a managed language are probably worth it.


It originally had a very unique approach, it would JIT the emulated instructions into .NET bytecode and then let the .NET runtime JIT that into native code. At some point they switched over to their own bespoke JIT-to-native engine for more control though.


I'm also using the dynamic code-loading to get free JIT in other projects and quite a few features of .NET relies on that, there are limitations (and for something as dynamic as an emulator I'm not at all surprised that they hit a brick wall at some point).

Another benefit of C# is that they continually add features to make the language less susceptible to GC stalls. Compared to Java you have Value types, real generics, ref and out arguments, Span<T> types, stackalloc allocations, unsafe blocks and so on. You can get quite far without allocating anything on the heap and the ergonomics won't be that much worse than even C++ when doing so.


The YoY performance improvements after going .NET Core 1.1/2.1 up until current .NET 8 have been very significant which allows C# to be the language of choice for writing systems-like performance-sensitive code.

It also had quite a rich unsafe API since .NET Framework days which has since then been complimented by safer alternatives which offer similar or better performance namely Span<T>s and then lately struct optimizations which are helped by the fact that C# generics with struct arguments == Rust generics with struct arguments (aka the ones which are not Box<dyn Trait>).


C# has an unsafe mode if you need it. I've written some low level hardware twiddling code in C# before. It can also be very fast.

https://learn.microsoft.com/en-us/dotnet/csharp/language-ref...


It's probably not super important with the switch like it would be with the nintendo 64 or something because it's an ARM cpu.


This is (I believe) the PR that fixed this specific issue: https://github.com/Ryujinx/Ryujinx/pull/5933

In short, no - from my understanding, it does actually fix the underlying issue, rather than special-casing the game. I wouldn't be surprised if there are a few edge cases like that which are special-cased, particularly for older games (when "abuse" of CPU/GPU quirks was more common to eke out extra performance).


No need to spoof the GPS signal, pop open the lid and replace the GPS chip with one that outputs an attacker-controlled time signal. I suppose it could encrypt this signal with some certificate burned into the silicon, but that could still (slowly and painfully) be reverse-engineered.

GP’s point stands, you can’t enforce a time lock with cryptography primitives. That’s the fundamental issue with DRM - you’re trying to restrict someone from getting your ciphertext, while at the same time allowing them to get to it if they meet certain (non-cryptographic) conditions, which standard cryptography just can’t do.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: