bilalq

I don't want to sound overly harsh here, but this is the kind of nonsense that shows why "vibes" are so much more trustworthy than "benchmarks" for assessments of what tools to use. The author has self-awareness about how flawed this benchmark is, but he still presents it as "evidence".

Coinbase also had a security incident recently due to a leak from Amplitude. It's surprising how little media attention that got: https://x.com/CoinbaseSupport/status/2115274731310002356

I don't know where the Strands team sits in the org structure, but there's been a lot of stuff put out by them lately too.

That was just an example anecdote to highlight the culture around respecting privacy and security. Obviously AWS would never allow for training on customer data, but even for metadata or data of our own internal systems, things are super strict.

Public datasets that are liberal with licensed access is one thing, but the best frontier labs clearly went well beyond that.

Touch is probably not going to be useful in most contexts, but there are two things that come to mind:

1. Since many iOS apps can run on Apple silicon Macs now, this might be useful for apps where touch matters for more than just clicking buttons.

2. For mobile app developers, you can actually try real touches events on the simulator/emulator while developing and get better sense of how it feels without needing to pull out a physical device.

I have a touchscreen on my Googlebook (I know, early adopter issues galore, but I love mine now). I basically forget I have it most of the time, but every now and then, it's been cool.

Coinbase claims 70k users had data visible in this leak. That's an odd number to me. I've only found a few articles about this and a few random Reddit threads. I haven't yet seen an announcement or disclosure from Amplitude, but I would suspect others were hit as well.

Oldest article I found: https://finance.yahoo.com/markets/crypto/articles/coinbase-h...

Reddit thread: https://www.reddit.com/r/CryptoMarkets/comments/1xhlag5/coin...

I did indeed mean it that way, but I agree with you. It sucks, but it's just the unfortunate reality of the world. Many of the most disruptive and successful startups made it there by ignoring legal or moral limitations.

Your comment was likely focused on dysfunctional parts of the culture there (and that seems to be how most replies to you interpreted it as well). There's truth to that, sure. But I think respect for data sensitivity and security is also a big part of what makes the culture ill-suited for frontier AI lab work.

When I was at AWS, we had data access locked down very tightly. I was trying to train a model to predict how long various dynamic workloads running on behalf of customers would take. Just getting access to anonymized production data from a DB that my team owned took well over a month and had me compromise heavily on what attributes I could access. I also spent a decent amount of time in meetings with lawyers and compliance folks to explain and justify all our data classifications for PII, retention, access controls, etc. We would review our data policies quite frequently. We needed break-glass procedures to access prod data in our own systems, and it was uncommon to need to resort to that. Even when you broke glass, certain classes of sensitive data would still not be visible to you. On the plus side, We did get quite good at operating and maintaining systems without needing to see sensitive info.

If you contrast that with Meta's disregard for privacy or the way frontier labs disregard the law, it's easy to see why Amazon would struggle in this space.

Definitely true for large PRs. But with stacked diffs and some discipline, a lot of PRs can be easy to review.

I was saying the Pixel Fold form-factor was great for productivity and that the iPhone Duo was better for video watching. But even the Duo could be nice for some productivity tasks if you hold it in a portrait orientation instead of landscape.

I love my Pixel 10 Fold and can't imagine ever going back to a non-foldable now. The larger screen is great for productivity. Reviewing PRs on the larger screen is way more comfortable than a normal phone size. The built-in terminal app also works nicely with herdr and Tailscale to let me connect to my work machine. I can interact with my agents and get real work done on the go. I also have saved split views so I can quickly launch two apps side-by-side. I do mobile app development, so being able to have the app I'm developing open side by side with Slack or Linear to create issues or discuss with people is very convenient.

I don't know if terminal access is as easy on iPhones, but the utility is there for many work related use-cases. I do think the more square-like form factor of the Pixel to be better for productivity than the rectangular form of the Duo, but the latter is nicer for videos.

I know it's probably not that difficult, but I always feel anxious doing things like that with expensive components. The thought of being slightly misaligned and causing issues gives me pause. I guess now that it's out of warranty, I have a bit less to lose.

I have a 3090 founders edition sitting on a shelf. The FE cards had VRM cooling issues, IIRC. Would this unlock have any uplift even if I undervolt and don't increase the power draw limits much? The use-case I'm thinking is to run a model to power a local only voice assistant for my family. I'm not really familiar with what instructions are used most heavily by LLMs, but is my read correct that this would be expected to help with TTFT? I'm curious if there's anything about this that helps in particular with audio processing models.

And maybe I'm overthinking the cooling issue. It's not like I'm hammering it 24/7. Probably fine to burst high on power draw on use.

Btw, I always love moments like this where library or project owners stumble on their work and chime in on the comments. I really appreciate your work here. It's given me motivation to actually do something with parts that have been sitting on a shelf.

As someone who develops iOS and Android apps, I run production, store-installed variants on my Mac all the time for iOS apps. It's pretty nice and would be cool if I could do the same for Android.

I'm no expert on the matter, but I've developed and published multiple Android apps to the Play Store. Some of those apps have needed Google Play Services APIs. Google has also been actively making moves to lock down control and offering things like the Play Integrity API that some apps use.

By your phrasing, it sounds like you're implying my understanding is wrong somehow. If so, what am I missing?

In practice, the Google Play Services dependencies and other walled-garden initiatives from Google will make this less useful than it could otherwise be. But still, this is really cool.

I wonder if something similar to this vim plugin exists for emacs: https://github.com/christoomey/vim-tmux-navigator. Or you could maybe vibecode one yourself now.

I've used it for years to have consistent keybindings for movement across vim windows and tmux panes. Worked much better than trying to do terminals inside vim.

You (and HN as a whole) have a pretty good track record of intervention when automated moderation fails. I certainly don't mean to accuse you of any malicious intent here.

But it's pretty clear that there was a concerted effort to suppress those posts by various actors who did have such intent. I do think it's a failing of the automated system that such suppression can be done at all.

Powerful corporations and nation states have always tried to maintain control over the flow of information. It was never really rules or regulations that kept them in check, but the practicalities of budgets and resourcing constraints. Now that those barriers are crumbling, I think the challenge of moderation will be much harder for all discussion going forward.

That was just one of several dupes. The actual thread of that discussion had 650 points and 554 comments: https://news.ycombinator.com/item?id=50078141

Buried to the fifth page. Ridiculous suppression.

Workloads that either are superseded or there is a desire to supersede them. It's not just old deprecated stuff, but also stuff that people want to deprecate.

An example could be old API endpoints only hit by old versions of a mobile app where users may be slow to update. Or a case where only newer clients/instances support modern features and old ones are stuck on a frozen featureset until they cutover.

But active services with no immediately existant alternative may also be legacy. If your auth is behind a disappointing managed service like AWS Cognito, you may consider your entire auth stack legacy while the replacement is still looming in the roadmap down the line. Maybe you can't justify funding to work on a transition just yet, but you already would avoid building on top of the existing tech stack.

Cloudflare could make the biggest impact by doing something similar to AWS DSQL. There are very few options in the multi-region replicated space, and it ties in nicely with their edge workers.

> "Working Effectively with Legacy Code" defines legacy code as code without tests thus hard to change it easily or with confidence.

This is not a universally accepted definition. I've owned plenty of services with 95%+ unit test coverage, massive integ test suites, and synthetic canary tests that ran every minute that I would consider legacy. Plenty of AI slop today gets barfed out with 100% test coverage, but much of it is legacy from day 1.

Time and again, staying on the mainstream node/npm stack continues to be the validated choice. I've seen this happen with io.js, bun, and deno. The situation has been similar for yarn/bun and most alternatives on the package manager side.

Of course, that's not to say the work done on these platforms was wasted. The divide around io.js was meaningful to getting things moving faster and change the governance structure. Deno and bun both showcased things Node could be doing better and some of that was folded back in.

And in spite of all those past experiences, I still find myself using pnpm over npm today. I'm sure npm will continue to evolve and eventually the critical features of pnpm will just be part of core npm. But the gap today is massive enough that pnpm over npm feels critical. The disk usage and performance wins are life-changing for daily work and CI flows.

Claude Tag could actually be really useful. Unfortunately, it's too much of a black hole for money. I tried adding it to incident channels, but if a channel gets left open for a few days, Claude will find ways to burn tokens waking up with empty prompt caches and doing nothing. $400 burned by Sonnet 5 on a single incident created because some alarms were oversensitive and didn't distinguish faults from errors. And I still had to prompt it like 5 times to get it to adjust metrics and tweak alarms correctly. Absolutely insane for a change that I could've made as a human in 10 minutes or had a directed Claude session under me do it in 2.

They've acknowledged the issue now: https://github.com/firebase/firebase-ios-sdk/issues/16728#is...

Absolutely wild that such a widespread SDK could crash everyone with a serverside change.

FWIW, this has not been my experience. Google Play usually approves within 24 hours for me still. Apple has been taking over a week though.

When Shopify announced their shift from React Native, this is actually what was on top of mind for me. Week+ delays for critical bugfixes is insane. Being able to patch things with OTA updates is tablestakes at this point.

The responses to this thread seem to be from people who are familiar with Temporal but haven't ever actually used Restate. They're both durable execution platforms, with differences mostly around how abstractions are organized and how orchestration of work happens (Temporal has you setup worker pools that pull from a queue while Restate pushes to service handlers). If some of your infra runs on serverless providers, Restate will often be a more natural fit.

Sure, Temporal is more mature and battle-tested, but Restate is quite nice and I honestly prefer it in most cases.

EDIT:

I started drafting this reply before seeing someone from the Restate team chimed in.