kevincox

I wonder how much GrapheneOS support will help other Android "distros" like LineageOS. In theory since GrapheneOS is open source it should be quite easy to port the low-level stuff including security updates for the full supported lifecycle (at least as much as the security patches affect both Graphene and other ROMs).

1. It's opt-in. The user is choosing the occasional broken site over light themes.

2. The site can always provide their own dark theme if the automatic one is broken.

I think a sensible architecture would involve many pools of wallets with different availability. So the majority of funds can probably be completely offline, with only occasional transfers to/from various offline vaults. The there could be different groups of different levels of online funds that are ideally physically separated (individual teams and employees can only access a subset of the wallets).

I can maybe remember CVE-2026. But there is no way I can remember 6 random digits.

What if they never fix it? Is there at least a deadline where the researcher's are ungagged? What if the exploit is being used in the wild, can the researcher warn people then?

I'm having the same issue. It seems that their CRL updates aren't working well on Android?

The words in a novel and the order in which try appear are so facts. But somehow that is clearly copyrightable.

Are you sure? When they announced it they said they will update quotas to account for it. Which just means that the next adjustment will effectively null it out.

The docs all say there is a time and billing cost:

> Auto mode may have a small impact on token consumption, cost, and latency for tool calls. https://claude.com/resources/articles/auto-mode#what-to-expe...

https://code.claude.com/docs/en/permission-modes#cost-and-la... doesn't say anything specific. It mentions that server-side classification can be used but doesn't talk about the billing for it.

But at the end of the day it is a leaky system. It may reduce the frequency of bad actions but doesn't prevent it. So you need the sandbox either way.

This is the only way. Auto mode is really just yolo mode with more LLM tokens billed. It may catch some weird shit but it isn't a reliable sandbox. Just lock up the LLM and let it run.

Not only revenue but enterprise users are valuable market share. Think of things like Slack calling which last I checked don't work in Firefox unless you spoof the user-agent. More enterprise users will force better Firefox support in a huge variety of websites which will benefit all Firefox users.

I wonder if you keep compiling back and forth would you ever hit a cycle or would it be constantly growing?

I don't mind 64-day certificates. However they recommended renew at 2/3 validity remaining means that I can no longer take a month off without needing to be prepared to debug a certificate re-issuance problem. Not a problem for companies with 24/7 oncall or even at most a week of the whole company off at a time. But for individuals this is pretty annoying.

Sure, re-issuance usually works. But when you only do it every 42 days it does break from time-to-time without you noticing.

I would love if we still renew with 30d remaining. I really don't care if they reduce certificate lifetime to 31 days as long as I am allowed to renew daily. But lowering the gap between expiry and when you are allowed to renew is very annoying.

That list is the IPs users connect to. It is entirely distinct from the list of IPs the VPN traffic egresses from. I doubt believe that they publish their egress ranges.

Of course I wouldn't recommend taking the conclusion. But it is a valuable view of some differences that the Forgejo developers perceive as valuable.

Seriously, are you proud of the new look? SHOW IT TO ME. Even the video was mostly themed mock-ups that didn't show what the actual design looks like. Just post a screenshot of the whole browser.

llama.cpp has a flake in-repo that I often use for trying out different branches and patches. I also have yet to have an issue just replacing the src and build number attribute in the nixpkgs build (in one cases I wanted to add an additional CMake flag but that was also easy).

IMHO this is way easier than without Nix in many cases as figuring out the upstream build process and getting it running can often be quite the chore. With Nix it is all set up for you.

One major issue with Vary is that it makes cache coalescing very complicated. This is because you can't know whether two requests will share a response until you get that response. So for subsequent requests you need to decide if you should block it hoping that the response will satisfy it or if you should send it through pessimistically, possibly triggering a thundering herd effect on every cache rotation.

I'm not sure if it is possible to solve this nicely in a generic way, but it does make it a bit ugly.

Thanks. This link has more detail about Linux support. I submitted it separately for discussion.

https://news.ycombinator.com/item?id=49824189

I'm 99% sure the Computer Fraud and Abuse Act covers this. The problem is that it seems that none of the victims want to, or are brave enough, to sue a company with absurd amounts of funding.

Documenting public water sources is an incredible public good. I thank you for your efforts.

How does Rust help with 2 at all? IIUC the main requirements were not memory or performance related but TPM and instruction set minimums.

No, but my credit card has no battery, requires no cell service, is waterprrof and quite durable.

I see the advantages of the Chinese system but I really found myself missing my card.

- While payer-offline payments were possible most merchants didn't want to (and some seemed unable to) so payments in places with bad cell service were painful.

- It was a lot more steps to open the app and enter scanning mode or display your code than to just tap a card or phone.

- It was always unclear if you were scanning or being scanned, leading to friction for every payment (generally larger brands scan you and you scan for smaller merchants).

Honestly for in-person card payments are just nicer.

For online WeChat was better, but no different than Apple Pay or Google Pay except for course that it is standardized by the government.

This is almost certainly a you problem. Tons of people play remuxes with Jellyfin.

I would check that your client supports the requisite codecs, and has a sufficient network connection. Or alternatively check that your server has enough horsepower (GPU or CPU) to transcode.

Probably because the account has only ever submitted its own content.

https://news.ycombinator.com/submitted?id=LabsLucas

> Please don't use HN primarily for promotion. It's ok to post your own stuff part of the time, but the primary use of the site should be for curiosity.

> https://news.ycombinator.com/newsguidelines.html

Yes, I found this comment very hard to understand until I realised they were talking about it being opt-out with no setting to change it. (At first I thought it was opt-in by default, and the "by default" implies that there is a setting to change the opt-in/opt-out setting)

This also has nothing to do with GrapheneOS except for some user overlap.

It sounds like you are just writing your own allocator? That sounds great, but why is it going to be better than jemalloc?

There are many reasons a specialized allocator can be better, but just saying "write your own" doesn't really add much value to the discussion.

It seems that you could just compile the data into the WASM blob. Then use a more optimized query engine than sqlite. This should be very fast to compile (most of the WASM is just a byte buffer, the code is just a few binary searches and some result encoding). The downside is that you need to recompile to update the repo, but I don't think that should be particularly expensive.

Thundering herd is different. Thundering herd is when a lot of clients trigger requests at the same time. Common situations being a specific time, some other event just occurred or synchronize on other parts of your infrastructure (such as readers queuing behind a R/W lock that then get unblocked at the same time to continue to make a bunch of requests at the same time.

Request amplification via retries is a different problem that causes large amounts of traffic (but it is generally more steady than spiky)

Sandboxing the process only works well when the malware requires more capabilities than the software itself.

So if your software needs to make HTTP requests and read the filesystem then the malware will be able to make HTTP requests and read the filesystem, which is enough for a ton of malware. Sure, maybe you can limit the directories it can access a bit and possibly some sort of network filtering, but it isn't a silver bullet.

Capability security in-language would make a huge difference, because the more granular you "sandbox" the less likely it is that the compromised component has the access it wants. For example if the HTTP client library is compromised maybe it can't access the filesystem so can't steal your cookies. Or maybe like in this case no permissions were needed at all and despite the process having enough capabilities for malware this malware can at worst return bad values and try to chain this to an exploit which is far more difficult than just running it itself.