I made my master thesis on real-time, with a chapter where I experimented with different levels of jitter and latency.
Jitter is the consistency of the latency, is it like a locked 66ms or sometimes does it go to 200ms. Jitter is more impactful than latency for a wide range of applications, from gaming to music and video call. Having a lower latency allows for lower jitter, or less jitter while keeping the same latency.
Today’s discovery is huge imo.
Also, there is a very narrow threshold of latency timings in which "real time" communication goes from looking real time to actually feeling real time. That narrow window is why people end up interrupting each other or feeling like they can't get a word in edge wise on video calls all the time.
For years, I heard it's better to use cron, because the problem was already solved the right way(tm). My experience with cron has been about a dozen difficult fixes in production of cron not running / not with the right permission / errors lost without being logged / ... Changing / upgrading OSes became a problem. I since switched to a small node script with a basic scheduler in it, I had ZERO issues in 7 years. My devs happily add entries in the scheduler without bothering me. We even added consistency checks, asserts, scheduled one time execution tasks, ... and now multi server scheduling.
Deployments that need to configure OSes in a particular way are difficult (the existence of docker, kubernetes, snap are symptoms of this difficulty). It requires a high level of privilege to do so. Upgrades and rollbacks are challenging, if ever done. OSes sometimes don't provide solution when we go beyond one hardware.
If "npm start" can restrain the permissions to what it should be for the given version of the code, I will use it and I'll be happy.
If cron is broken for you, than the logic solution would be to replace it with something that does work for you. But do so at the right place and abstraction. That's hardly ever the runtime or in the app.
Do One Thing (and do it well).
A special domain specific scheduler microservice? One of the many Cron replacements? One of the many "SaaS cron"? Systemd?
This problem has been solved. Corner cases ironed out. Free to use.
Same for ENV var as configurations (as opposed to inventing yet another config solution), file permissions, monitoring, networking, sandboxing, chrooting etc. the amount of broken, insecure or just inefficient DIY versions of stuff handled in an OS I've had to work around is mind boggling. Causing a trice a loss: the time taken to build it. That time not spent on the business domain, and the time to them maintain and debug it for the next fifteen years.
One of the very first slides of François’ presentation is about defining AGI. Do you have anything that opposes his synthesis of the two (50 years old) takes on this definition?
And yes, you're absolutely right. Attempting to manage NHIs across multiple cloud/service providers without having proper automation in place is a total nightmare.
Ahaha! Read the subtitle of the blog, literally at the top:
"If you take nothing else from this blog: quantum computers won't
solve hard problems instantly by just trying all solutions in parallel."
None of them are good players for humanity. "Don't be evil" is long gone.
They don't pay taxes, pollute, give means to manipulate billions of humans, concentrate wealth in a few hands.
They all give with ulterior motives, never from the goodness of their heart.
While I don’t disagree with your argument, it is bad form to claim that companies like these don’t pay massive amounts of taxes, specifically payroll taxes. They do and it’s a huge amount.
I' m European. Apple got charged by the European Union for $14.4 billions of unpaid taxes between 2019 and 2021.
Back of the mapkin they employ 22k people in EU (data Apple), average salary $80k (Apple), taxes at 30% per employee (my own understanding). Thats $550M. So their payroll taxes is about 15% of their tax package. If you have any contradictory data, I would love it, but your point is moot for 95% of the world outside California.
Do you mean the tax dispute for the years 2004 to 2014, or is there another one for 2019 to 2021? One thing about this is that the Irish government made a deal with Apple and various courts have ruled in favour and against Apple in this matter. https://en.wikipedia.org/wiki/Apple's_EU_tax_dispute
The idea behind Homomorphic lib is to allow 2 basic operations (such as add, multiply) on encrypted numbers. They return encrypted numbers as well.
From those basic operations, we can build more complex functions.
That's the gist of the magic.
I'm all in until figuring out what to do with those operations. In this example, I think the scenario is straight forward. What do I do with adding or multiplying phone numbers? If I add phone numbers, what results should I expect and how do I use those post-decrypt?
I was under the impression here, that I hand you an encrypted phone number and you provide meta data back suggesting scam / known business / etc. Hence having trouble grasping how you can mathematically approach a phone number you wouldn't know to then change it.
I recognize the use-case, have you the service provide info/data back based on my query, and I don't want you to know I am receiving a call from said phone#. But what do I add to the phone number when querying you the service or what are you adding via FHE operations? Or why are you adding to the phone number that you can't know? What results from the addition when I'm decrypting, a longer phone number or additional results regarding the unknown phone number?
Separately, why would I provide this service two phone numbers to then multiply? I'm not sure the axis which would result, but the string I would expect is not a valid phone number and wouldn't result in my knowing more than before? Are there other technical aspects which cause add / multiply to be novel per implementation which isn't resulting in classical plaintext data actions?
Pretty awesome. Would love to use it in CI and locally for our PG product.
We use Prisma, so I guess we have to wait for the connector that looks like pg to plug it in.
I start to feel this is all marketing. Pretend it's dangerous, so it implies it's beyond what we imagine.
Because on our end, on the reality of a B2B product used daily, finding use cases for the limited OpenAI we have access to is far from trivial.
