Hacker Newsnew | past | comments | ask | show | jobs | submit | orf's commentslogin

I wrote something similar with go, but MacOS only.

Creating a worktree became instant, but the bottleneck shifted from that to git needing to build its index. Claude code runs `git status` in the background, meaning any speed gains are instantly gone.


Why? Calling a reasonable thing grim without any follow-up isn’t the hallmark of a good comment either.

It is not remotely reasonable to ask "but why didn't he feed it to ChatGPT?". It is pretty silly to assume that ChatGPT should always be consulted.

I understand this is more about the process than the result, but note that: a) his result is completely wrong, he identifies a living land snail as the 100+MYa fossil; b) a conversation with Claude helps with some decent knowledge and provides a few possible candidates, that can be then double checked. c) Claude could have talked the author out of trying to identify a Jurassic fossil against a database of living species.

It's a good starting place. As an analogy imagine someone wanted to look up the definition of a word. If someone wanted to know the definition and they went out and crawled the entire internet, built an LLM, and then asked it for the definition you would wonder why they didn't check an existing dictionary first. I wouldn't consider it silly at all to always check a dictionary or existing LLM first when you want to know the definition of a word.

Wanting to know the definition of a word is not an original problem. Similarly wanting to know what's in an image is not a new problem either.


> The caveat is that Litestream replication is asynchronous. A restore can miss the newest local writes if the SQLite volume disappears before they are copied. That is fine for many AI and experimentation workflows

In short: SQLite is not all you need, unless you’re just experimenting don’t actually care about durability, in which case you also need litestream + object storage.

Right.


The suitability of Litestream for production disaster recovery is also an open question in my mind. I used 0.3.x for several years and when I tried to upgrade to the 0.5.x series there were runaway disk usage problems that would have caused downtime had they made it to prod. As far as I can tell these have not been entirely addressed, although recent bug reports suggest that they might be getting closer.

I want to love it, and I don't take open source projects like this for granted. But during my last production upgrade I chose to decommission Litestream in favor of a dumber, less granular solution using sqlite3_rsync and nightly backups because there is no point in using a backup system that is not rock solid.


Postgres also does not synchronously replicate for free. You can setup both to get a confirmation write if you require that durability.

> postgresql also does not synchronously replicate

By default. Generally your primary database is in a completely different failure category than a kubernetes node running an ephemeral workflow pod.


Either you have durable storage or you do not. SQLite and Postgres can both ensure local durability of commits. If you want distributed durability, you need to ship that data elsewhere. That is another Postgres node, object store, whatever that’s still an external dependency.

Not for free, but without the needing additional software.

  synchronous_commit = on

That’s about the local transaction, not replication. SQLite WAL also gives you strict durability.

  PRAGMA synchronous = full

"Durable workflows without the durability"

That's distributed workflows :)


S3 is strongly consistent, if you need it anyways you can just use s3 keys to deconflict and store the workflow state.

Yes, but directly using s3 as a key-value database is completely different from using SQLite + litestream.

try setting up replication/failover in postgres, it's much more work.

i mean it's durable as long as nothing crashes or litestream has a data corruption bug which only happens every other release...

> Google followed in 2010 with Cloud to Device Messaging, then Google Cloud Messaging in 2012, then Firebase Cloud Messaging in 2016

Classic


I’m curious if anything meaningful changed along with these name changes or it’s mostly issues of branding/implementation.

The essence of a program is all of those things. The omission of any one of them makes a program almost worthless.

The release post for v2.8 is not yet published. Check GitHub releases page for the latest release status of Deno.

Misc thoughts:

Perhaps sharing your take home exercise might be a more useful avenue for feedback?

I’m not sure how large the market is for ASP.NET developers, but the skills you’ve learned so far are more transferable than you think. Try creating some projects with Django or Rails and spread your wings a bit. Don’t be a monoglot.

A portfolio helps, as well as a personal narrative. Being a solo developer for 2.5 years is good and bad depending on the audience. For example it means you don’t have much recent experience working with a team, and I imagine clunky Belfast ASP.NET companies are not exactly hotbeds of entrepreneurial spirit. Maybe look for smaller companies or startups?

Extremely personally, Azure certifications and such things are worthless, bordering on a negative signal depending on the context. But some people/companies may value them.

Saying you think reading “C# in a Nutshell” is a good idea is concerning because you say you’ve got 6+ years of ASP.NET experience. Was this not using C#? Revision is always good, but identifying why you’re not already comfortable with C# is a good starting point.

Build some solo projects with C#, not using ASP.NET, with some artificial constraints (speed, memory, etc). Then smash them. Could be as simple as parsing a 20GB CSV into memory: start dumb and slow then make it as fast as you possibly can. For me this beats a book on data structures.


Thanks for taking the time to reply.

The take home exercise is here: https://github.com/mjb8086/checkout-kata/tree/main

I'd also created an launched an iPhone app in the meantime, and had an idea for another where I could write the backend in Python3/FastAPI.

Also, I mistyped, the book C# book I am reading is "C# In Depth", not "C# in a Nutshell". The former has details on the new language features of each version, when they'd be best used, etc


This makes sense if you’re a human-rights journalist working in a dangerous country, with the threat of state-level actors looking to compromise you.

If you’re not then this seems quite paranoid, bordering on LARPing.


I turned it on a week ago to see what it was like. I expected it to be significantly annoying, but I found basically nothing changed other than a bit of text in safari that says it's in lockdown mode. Otherwise I wouldn't have been able to to tell the modes apart. I was expecting the browser to be slower without JIT or use more battery but I haven't noticed any change, it's all still snappy.

Apple over hypes the "you need to be in significant danger" part. Basically anyone can turn this on and it's fine. The UX seems mostly exactly the same either way.


I take it that you mostly communicate with other people using services that are not iMessage.


I’m not a heavy iMessage user but I use it a bit and I haven’t noticed a difference there either. Photos still load, maybe pdfs wouldn’t work?


It basically degrades back to SMS if you turn this on. Obviously, this is fine for a lot of things, but most people generally expect more than that out of their messaging app in this day and age.


BRING BACK EMOTICONS!


I thought it was common knowledge that all kinds of Americans (not to mention other nations) are routinely compromised with zero-clicks, mostly developed in the US and Israel.


This is the kind of assertion without evidence that just muddies the waters. “All kinds” of people is so vague as to be an almost entirely vacuous category and “routine” means almost nothing without an actual quantification of how prevalent and frequent the problem is.

It’s undeniable that the proverbial guns for hire make it easy (if not cheap) to target basically anyone — but just because the vibes are bad doesn’t mean we can just say “it’s common knowledge that …”

The fact is mitigations are costly in terms of convenience and ease of use. Helping people make informed choices about whether to enable mitigations and bear that cost requires more than platitudes imo


LARPing is imagining that Lockdown mode protects you from state-level actors. It is frankly baffling why a industry that has been laughing for literal decades at even the possibility of stopping state-level actors just turns around and uncritically believes Apple's marketing team with literally zero support, evidence or proof except for a long track record of failure. You would think that extraordinary claims would demand extraordinary evidence.

We have seen multiple software hacks resulting in >10 million dollar payouts. Apple's bug bounty program only pays out 4 million dollars (2 million dollars (2x) more than non-Lockdown) for a zero-click total compromise that can trivially worm to take down hundreds of millions of iPhones simultaneously. Even at the low end of that cyberattack payout range that is still a >2x ROI if your successful cyberattack depends on a iPhone zero-click, with many publicly known attacks being in the 10x ROI range. Lockdown mode, at best, raises the bar slightly for commercial profit-motivated attackers and reduces their profit margin from wildly profitable to slightly less, but still, wildly profitable.

And of course I am using the Apple bug bounty program as merely a available metric with at least some semblance of objective support. There are zero certifications, audits, or analysis that Apple has even attempted that would confirm any claim of protection against state level actors.


I strongly disagree that there is no evidence that Lockdown mode is effective; there have been numerous exposed, active iOS exploitation campaigns of which none have worked against Lockdown mode. When we're trying to prove a negative, that's actually some of the strongest evidence we can get.

The economics of the device exploitation industry are completely orthogonal from bug bounty payouts; the markets only overlap at the _extreme_ fringes. Trying to use one as a proxy for the other is meaningless.


I don't necessarily disagree but a lot of chains will bail out if they find like the Norton Antivirus app on your phone so


In this case the body of evidence is still quite powerful though, given that not only do we not have any forensic evidence of compromise from a phone with Lockdown Mode, but in all public cases where chains were RE'd back out of the forensic evidence, they don't work when tested on Lockdown Mode! So, there's even signal that the lack of forensics indicating Lockdown Mode compromises is not due to artificial targeting or detonation gates, but rather successful mitigation.

(as an aside): I'm not trying to say Lockdown Mode is infallible; I am sure phones in Lockdown Mode are or will be compromised. But it's clearly a very powerful tool, and to try to argue that it is some kind of marketing-driven conspiracy, against the body of evidence of its success, using bug bounty payout numbers (???), as the grandparent post did, is ridiculous.


I wouldn't say that it's useless but I do want to consider the option that the chains that get caught are probably the ones that are less competent.


That is a total strawman. The standard of “effective” being used by the person I was responding to and Apple themselves is “protects against state actors targeting you”, not “has any benefit whatsoever” or even “has a material benefit”.

Protecting against state actors is not a instantaneous property of the present. It demands durable protection against compromise by state actors who can easily spend tens to hundreds of millions of dollars on teams of hundreds for multiple years to develop novel, durable exploits known only to them. To the extent that compromises exist, they would require expected resource expenditure in excess of what state actors can deploy or are in excess of the value derivable by state actors which is going to be in the hundreds of millions to billions of dollar range to constitute as being "effective against state actors targeting you".

Protecting against state actors means secure against Iran, Saudi Arabia, China, and the NSA. That is the unsupported marketing bullshit I am calling out.


Apple is almost certainly spending hundreds of millions if not billions on software security.


Sure, but that is not related to anything I said.

I said that “protects against state actors” means the cost of finding a exploit as generally applicable and powerful as a zero-click RCE needs to cost on the order of hundreds of millions to billions of dollars per exploit to be problematic for state actors to field.

That amount of resources is a competent team of 100 skilled individuals finding zero zero-click RCEs after 3 years of full time investigation. That could credibly be called secure against state actors, though would still not be out of reach of a real military operation as a hundred million dollars is still just the cost of a single jet fighter.


> We have seen multiple software hacks resulting in >10 million dollar payouts

This sets a nice price bar for exploitation. Is someone willing to pay 10+ million dollars to get access to your phone?

The obvious caveat here is that for a lot less than 10 million dollars someone can be hired to hit you with a metal pipe until you give up your passcode.

> click total compromise that can trivially worm to take down hundreds of millions of iPhones simultaneously

Where is the profit motive in doing this? Possibility is one thing, but a realistic threat is another.


Is someone willing to pay 10+ million dollars to get access to your phone?

Not yours specifically usually, but there is a lot of money in a general tool that law enforcement can use to read out phones. Of course, most of them focus on physical access. In the few Cellebrite reports/presentations that have leaked, iPhones would fall after a relatively short time (IIRC a few months), but did better than most Android phones (except GrapheneOS).

Also, sometimes you do not need the 10M exploit, you can buy many cheaper exploits and make a chain yourself.

The obvious caveat here is that for a lot less than 10 million dollars someone can be hired to hit you with a metal pipe until you give up your passcode

If they hit you with a metal pipe, it's likely that you won't survive even if you give up your passcode. So most likely you are protecting something or someone else. Set up a duress PIN so that you have options in that case.


... really? Zero-click RCEs can be used on arbitrarily many phones until they are discovered which usually takes on the order of months. You do not need to burn them on every individual target.

As a example of how they might be used in that fashion for profit, NSO group had a revenue of 240 million dollars in 2020. Many of their customers were governments who wanted to spy on activists and journalists. NSO group was in the business of economies of scale to democratize access to journalist devices by reusing a small stockpile of exploits across many targets with enough revenue to assure a steady stream of new exploits as fast as they were burned.


You’re right, I misstated. It’s not 10 million per exploitation, it instead limits the pool of people who can exploit you to those willing and have the ability to spend 10 million+ on an exploit.

That is still quite a small pool, and there are other network effects preventing any Joe blogs with that much capital from launching an exploitation campaign.


Again, no. You do not need to spend 10 million on a exploit if you are working with a company like NSO Group who sells white-glove access to target individual as a service. The cost lower bound is going to be on the order of ((cost of exploit) / (number of times exploit can be used)) and the denominator there is going to easily be in the hundreds to thousands. Of course prices are likely to be higher than the minimum due to profit margins.

To, once again, use the same example of NSO Group as it is infamous and well-documented [1]. In 2016 it was 500,000 $ upfront and 650,000 $/year for 10 devices. That article claims Saudi Arabia was monitoring 15,000 phones at a average cost of 10,000 $/phone. In [2] it was 7 million $ for 15 devices, but the upfront versus marginal cost per device is not broken down. And this was a relatively "above-board" company in the sense that they were a legitimate business entity with government deals which commands a premium relative to random unknown blackhat organization with no reputation.

And again, my original comment was discussing commercial profit-motivated attackers for which 1 million $ is easily within reach and just a cost of doing business to unlock greater amounts of profit. That is less than the cost of setting up a McDonalds. There is a vast, vast gap spanning factors of millions between Joe Schmo and commercial actors and a even vaster gap to state actors. There is no evidence that Lockdown mode is adequate against even commercial actors, let alone the vastly more capable state actors.

[1] https://prodefence.io/news/pegasus-spyware-operating-costs-c...

[2] https://www.reuters.com/business/media-telecom/meta-suit-aga...


No root and no way to firewall them. "Lockdown" mode - a lot of inconveniences.


"If you’re not then this seems quite paranoid, bordering on LARPing."

There are sooooooo many other situations where such device lockdown is warranted. Government intrusion, sensitive industry, journalism, anything ITAR/EAR covered, and more. Your reduction to a single issue is absurd.


Why does the on-disk size matter for any of that?


Because it will load into RAM. And RAM cost money. Also, quite hard to upgrade on the laptop


The entire executable isn’t loaded into RAM.

And are laptops a primary deployment target?


More code to load from disk to memory, and while it may be fast, it’s not instantaneous.


SSDs can read at gigabytes per second, and only the used portions are paged into memory.

Anything else?


Loading a program in memory is much more complicated than raw disk transfer speed.


So you’re saying that if you append 1GB of junk data to the end of an executable it would be slower to execute?

No? So it’s not purely a function of disk size.


> You don't want that as an automatic update because it will break in production for anyone who is actually using it

The problem with this take is that it’s stuck in the early 2000’s, where all servers are pets to be cared for and lovingly updated in place.

It’s also circular: you have the same problem with the current model if you don’t have a test environment. And if you do have a test environment, releases can be tested and validated at a much higher cadence.


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

Search: