> Some of you may remember Google's much-hyped AI voice "Duplex," which was supposed to automate all those annoying phone calls and call centers. That was in 2018, six years ago. Since then, we've seen how it's turned out
Reasonably successfully?
Call screen is easily one of the best features of my phone. Call hold navigation is also really useful. It calling restaurants and the like is not something I commonly use but it works and I've used it sometimes.
Yeah, I'm not sure if people have become so reactionary when it comes to unsupported tech-land hype, but on the flip side I find this unwarranted pessimism almost as annoying.
The call features on my Pixel are amazing IMO, and new ones (like the one that warns you if you are being scammed) could be great for large swaths of people.
It's not. It's trying to access unmapped or protected memory in its own process.
Basically what its used for is to implement an 'if' that's super fast on the most likely path but super slow on the less likely path.
It's not super clear what its being used for (this is often used for the GC but the fact that graal isn't affected means that likely still works). Possibly they are using this to detect attempts to use inline-cache entries that have been deleted.
object.field is implemented as a direct load from the object; if the object turned out to be null, then the resultant signal is caught and turned into a NullPointerException
"Content creators" (assuming by that you mean those who are trying to make a living off the platform) are mostly irrelevant.
Youtube's main source of revenue is ads which they serve regardless of whether the uploader is taking a cut from the upload or not. Most users have always and will continue to upload to and consume from youtube without the expectation of making money from the process.
So, yes in general users have historically been more or less satisfied with the deal: watch ads, get free video platform.
The actual kernel binary was smaller but the loader s limit was based on the amount of memory the kernel laid out in memory takes, including anonymous sections.
Also turning on optimizations in rust and the linker helped a lot but were not enough in the end.
I guess you are the author of linked paper. Well done.
I wonder if you have any opinions on how useful higher-kinded types (HKTs), one of the most requested features for Rust, would have been in implementing this OS. For example the absence of HKTs means that Rust can't have smooth and general handling of monads that is comparable to Haskell's. Would Haskell-style monads or Arrows have been helpful?
I believe HKT would have been useful but am not really sure how much HKT would have helped me overall. They would likely have been most useful (if at all) in the VFS/S5FS/VM stages that I was unable to fully get to.
Honestly, I have not used haskell enough to definitively say whether monads/arrows would have been useful.
Ah, so all memory used by the kernel must be listed in sections loaded by the bootloader? As opposed to the normal situation where the kernel just starts grabbing it from the hardware?
I know no specifics of the situation, but llvm optimisations can be manually toggled through rustc. Maybe there are more special-case optimisations that could help.
That or they just drank the Kool aid
reply