Shakahs

Well when you describe it that way, OpenAI also started as a blank text box that gave you a bunch of good answers, and they've already expanded with other services.

I already use ChatGPT as my first go-to stop for certain search queries.

Those issues are absolutely worth discussing, in a reasonable way. Cloudflare isn't the bad actor perpetuating these DDoS attacks, and they aren't forcing website operators to use their services either.

So now the government needs to compel a corporation to hand over some data, because they are no longer able to read it straight off the wire like they could before. That sounds like a significant improvement to privacy.

Another HN hot take about the Cloudflare bogeyman.

The CDN can't give you content you're asking for without knowing which content you're asking for.

This improvement prevents your ISP and the government from reading your packets to get that same information.

Gemini Flash API costs 50% less than gpt-4o-mini. It's not clear why your benchmark recorded 13x more token usage for Flash for the same input.

This is a pointless attempt at a hot take made only because AI is the latest thing HN luddites like to dump on.

Theranos never shipped a real product. OpenAI has, and has millions of direct active users plus millions more indirect active users via tech companies building products on top of their API.

Currently the carrier will publish the phone's IMEI to a central blacklist, so the phone can't be used with any carrier that subscribes to the blacklist. Also iPhones can be activation blocked via Apple, which is entirely independent of the IMEI block done by carriers.

Restate.dev seems to offer a different implementation of the same feature set, and I think I might like their durable execution syntax more.

ECR is slow. Despite being a static datastore presumably backed by S3 it will only serve container image layers at around 150mbps, when dealing with large (10GB) container images this is a problem. R2 will happily serve the same data at multi-gigabit speed.

I'm curious how they built this. It's SSH but the IP address is Cloudflare's edge network. It could be using CF Tunnel to transparently route all the SSH sessions to some serving infrastructure, but I didn't know you could publicly serve arbitrary TCP ports like that. Building it in serverless fashion on CF Workers would be ideal for scalability, but those don't accept incoming TCP connections.

Beyond forks, at this point Redis is an API target that has been implemented by other databases (Dragonfly, Upstash, AWS ElastiCache Serverless).

I agree. Coming from NodeJS I appreciate how explicit Java is. The complexity is there either way, but in Java it's right up front where I can see it, not hidden away under layers of abstraction for a supposedly better DX.

Not that I support any of this, but why would networking speed be the bottleneck in that system? Telematics seems very much like an OLAP situation where data ingest and querying can be asynchronous.

> "This device will not support X service after Y date" has happened.

Again, that's a symptom of shitty manufacturer firmware, it's a burden on streaming services to support these devices because they are the ones that have to maintain software packages for hundreds of different TV models.

In contrast, Fire/GoogleTV OS are built on Android, so streaming networks don't need to support individual TV models, they just have to target supported versions of Fire/GoogleTV OS. Android has APIs to handle Smart TV functionality.

The benefit should be completely obvious. Having a single integrated system is always going to be more reliable than running 2 separate machines that need to cooperate. Otherwise every issue needs to be isolated to the TV, the streaming device, or the connection between the two.

Also hand waving about "new codecs" doesn't hold any weight. A Roku/Fire/Google TV is a Linux computer with hardware acceleration for all modern codecs. By the time AV1/VP9/H265 are being replaced in the 2030s, you're going to need a new TV anyway to support 8K and whatever other features are de rigueur then. Same goes for audio codecs and Wifi support.

Everybody says they want a "dumb" TV, but only so they can connect a streaming device (Roku/Fire/Kodi etc.).

The problem isn't TVs being smart, it's the terrible firmware written by appliance manufacturers like TCL which are not software companies.

It's more practical to just buy a smart TV running Roku or Fire OS internally, which are both built on Linux.

This looks pretty reasonable overall, but it seems like it could have been implemented far more simply.

It appears they are emailing PDF copies of stock market transactions to fulfill a regulatory requirement, so the PDF generation should be deterministic and email delivery of a receipt is an idempotent operation.

Instead of all that scheduled orchestration complexity they could just queue their PDF jobs to SQS and do the work in a Lamba function, this would also let them queue the PDFs as the transactions are happening instead of continuing to run this as a nightly batch job.

It's also unclear why render + sign + add to mail queue need to be 3 separate queued tasks. They have to execute serially, so a single worker could do the whole process and checkpoint to S3 after each step, or not because the output is deterministic anyway.

It would also eliminate their issues with S3 request limits by keeping all the data relevant to a PDF local to 1 worker for the duration of processing.

Better manufacturers do give you a TBW endurance rating, and document what type of flash is being used (SLC, MLC, etc.).

I used one of these Micron cards in my RPi4, it has high write endurance and also an A2 performance rating so it can support the IOPS needs of a boot drive. https://www.mouser.com/new/micron-technology/micron-i400-mic...

Rclone is the general purpose "swiss army knife". It can be used to read/write/sync/copy/move files between any supported service and your local device, and also mount remote storage as a local drive. Restic and Borg are for making backups only.

Is being tied to the JVM that much of a problem these days? Developer workstations and servers have much more compute and RAM these days, and native compilation with GraalVM seems to eliminate high JVM startup times and memory overhead. Quarkus for example is known for a snappy developer experience.

Tethering doesn't always work. I've experienced numerous failures even trying to pair a Macbook to an iPhone.

Besides that:

Phones will turn off tethering if they think the connection is idle, to save battery power. iPhones are very aggressive about this when the client device is not an Apple device.

Some cell networks don't support simultaneous voice and data usage, so a phone call will kick you offline.

It adds latency.

Some network operators charge for it because they can distinguish the tethered traffic.

It really is counterproductive. If projects are going to take months to work on critical issues, they need to change the definition of "stale" to match, or just not auto-close issues at all.

It accomplishes nothing and obscures the sign posts that would help the next developer that encounters the same issue.

GCP has some nice things but AWS is simply more reliable.

The GCP outage [1] in April is a great example. A fire in europe-west9-a "zone" took down the entire europe-west9 "region" (because this entire "region" is actually housed in a single datacenter), which then caused a global GCP console/API outage because GCP's single global control plane couldn't reach europe-west9.

The fact that a zonal issue escalated to a regional and then global outage shows that GCP is not serious about limiting blast radius and all their talk of independent regional/zonal infrastructure is marketing fluff.

In comparison, AWS AZs can be up to 60 miles apart, share no physical infrastructure, and every region hosts its own API/console/control plane.

Also, Nitro. AWS has essentially eliminated the performance overhead of virtualization with Nitro, and years later GCP still has no equivalent so GCP customers still have to pay for that overhead.

1: https://status.cloud.google.com/incidents/dS9ps52MUnxQfyDGPf...

Building self healing server clusters that:

  -can run any workload 
  -on any hardware  
  -at any scale 
  -with load balancers
  -and persistent disks 
  -and auto scaling 
  -and resource limits 
  -and certificate management
  -and no single point of failure 
  -and etc.

requires a lot of esoteric complexity. Kubernetes did not create this complexity, but it is solving it in a standardized and universal way.

It's not documented in a single authoritative place, but AWS has documented much of the S3 architecture you are curious about via white papers and presentations at Reinvent and other conferences.

This talk explains how S3 achieves such high performance: https://youtu.be/sc3J4McebHE?si=-slHmjdQ4Z0EKQXs&t=1386

GPS seems like a better choice for a cell tower.

They're also using ZFS in Raid1+0, so 38.4TB of usable storage. $14,566/month on AWS io2 with max IOPS.

Cloudflare Domains is not a legitimate registrar option because you are REQUIRED to use the Cloudflare nameservers. If you want to use different nameservers, you have to transfer the domain out to a different registrar.

The public cloud route is pretty elegant. Red Hat is restricting source code to subscribers only, so Rocky contributors will just subscribe for an hour at a time when they need to download source code. There’s no way for Red Hat to stop this without terminating all public cloud licensing everywhere.

I'm genuinely curious, how does the hardware investment make sense for a SaaS platform when bare metal can be leased as a service from Equinix and such? It the difference in TCO between bare metal you own and bare metal you lease really that large after factoring in the cost of all the logistics and labor?