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

Bitcoin fixes this

Nos sure if sarcasm, but it does not. It will never get even close of handling 10% of CO's amount of transactions.

I hope it was sarcastic. If not, a bank does so much more. Banks lend money and keep deposits safe (most of the time :)). Does bitcoin lend money? Can bitcoin pay my vendors in USD? Will it accept my deposits or ACH direct deposits?

DateTime stuff is generally super annoying to debug. Can't fault them too badly. Adding a scheduler is a key enabling idea for a ton of use cases

> Can't fault them too badly

The same company that touts their super hyper advanced AI tool that can do everyone's (except the C-level's, apparently) jobs to the world can't figure out how to make a functional cron job happen? And we're giving them a pass, despite the bajillions of dollars that M$ and VC is funneling their way?

Quite interesting they wouldn't just throw the "proven to be AGI cause it passes some IQ tests sometimes" tooling at it and be done with it.


it would explain the bugs if they used the AI to make the datetime implementation though

Agreed on date/time being a frustrating area of software development.

But wouldn't a company like OpenAI use a tick-based system in this architecture? i.e. there's an event emitter that ticks every second (or maybe minute), and consumers that operate based on these events in realtime? Obviously things get complicated due to the time consumed by inference models, but if OpenAI knows the task upfront it could make an allowance for the inference time?

If the logic is event driven and deterministic, it's easy to test and debug, right?


The original cron was programmed this way, but it has to examine every job every tick to check if it should run, which doesn't scale well. Instead, you predict when the next run for a job will be and insert that into an indexed schedule. Then each tick it checks the front of the schedule in ascending order of timestamps until the remaining jobs are in the future.

This is also a bad case in terms of queueing theory. Looking at Kingmans equation, the arrival variance is very high (a ton of jobs will run at 00:00 and much fewer at 00:01), and the service time also has pretty high variance. That combo will either require high queue delay variance, low utilization (i.e. over-provosioning), or a sophisticated auto-scaler that aggressively starts and stops instances to anticipate the schedule. Most of the time it's ok to let jobs queue since most use cases don't care if a daily or weekly job is 5 minutes late.


Yeah, they're not exactly a scrappy startup- I'd be surprised if they had 0 QA.

Makes me wonder if they internally have "press releases / Q" as an internal metric to keep up the hype.


Maybe that's the Q* we've been hearing rumors about

they even deleted this link. powerful opponent to have

Maybe by design

Intelligence agencies minimizing effects of deployed secret technology, that would be a first

very carefully

sanitization of the commons


Compassion, decision making under uncertainty


up or down?


openai is so cooked


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

Search: