Google wants to keep users at google.com so it can keep showing them ads. Each time a user clicks away to speedtest.net or genius.com, that is a missed opportunity for revenue.
Except it's very likely that those 3rd party sites are monetized with Google AdWords. But I guess Google can make a bit more by cutting out the middle man.
My main device is a cheap Acer Chromebook, and I also have a low-end Mac mini. I've done a lot of development on the Chromebook using Remote Desktop to drive the mini. If you're looking for a flexible and affordable setup, it's hard to beat.
Originally I expected to write code directly on the Chromebook using Crostini (edit: Crouton), but it required a lot of hand-holding. I eventually gave up. But that was years ago, so maybe they've smoothed out the edges.
Crostini hasn't existed for years, and it's still in beta. Are you sure you don't mean Crouton?
In any case, Crostini has gotten much better since last year -- but the chromebook itself is too underpowered compared to a desktop to make a good experience. This is even true for the Pixelbook.
Crostini also seems to have problems with storage; the filesystem constantly soft-locks, for seconds at a time, under any appreciable load. This might be because they use Btrfs.
No, that's part of the strategy of shifting the messaging: Use both phrases together so people associate them, and then slowly drop the phrase that you want to go away.
Yeah, but the alternative bet is that they want the "safety driver" part to be the part that eventually goes away. If they want public acceptance, it will make sense to keep safety drivers.
Eventually they will go the way of the elevator operator.
Using structured cloning for deep copies is clever, but may or may not give you the behavior you want for SharedArrayBuffers. The copied value would be a new SAB with the same underlying data buffer, so that changes to one value will be visible to the other. That's good for most uses of structured cloning, but it's not what I would expect from a deep copy.
The point of structured clone was originally for passing data to web workers. Since the point of shared array buffers is to share data with workers, it makes sense that the structured clone algorithm keeps the SAB identity.
Also, a program that only works in one browser, and only due to that browser being willing to open security holes other browsers are not willing to open, is arguably still defective. That said, that might describe a lot of things people are doing nowadays (e.g. anything that uses WebUSB).
We’re an early stage startup bringing human-level intelligence to the machines that move our world. We are looking for passionate experts in robotics, computer vision, machine learning, and AI to help build our first product.
The potential to create truly intelligent machines has never been higher. The raw technologies of AI, robotics and cloud services are mature but haven't been applied to the most promising applications.
What you need to have:
- Passion, drive and grit
- Excellent programming skills
- Success solving complex engineering or programming problems
What will set you apart:
- Background in robotics, AI and cloud services
- Startup experience
- Experience with warehousing and logistics
What you’ll learn:
- Solving complex problems by combining machine and human intelligence
- Modern robotics algorithms for navigation, perception and manipulation
Charles DuHadway, founder and CEO of Fox Robotics, built deep expertise with our key technologies in a career that includes self-driving cars at Stanford, self-driving lawnmowers at Bosch, AI at YouTube, shared autonomy at Google Research, robot perception and navigation at Google Robotics and cloud robotics at KUKA.
If you'd like to find out more, send me an email at malcolm at foxbots dot co.
Use of SharedArrayBuffer in timing attacks was widely predicted and there were working examples showing how it could be used to extract information from browsers long before vendors enabled it by default. It's hard to have faith that the people who ignored all those risks won't do so again.
It would be an existential crisis for several of the browser vendors if they can't add things like threads with shared memory to javascript/webassembly. The existence of those organisations is based on the idea of the browser being a replacement for native platforms, and if they can't include basic and vital features like threads then they will always be at a huge disadvantage to native platforms.
Do you think Mozilla will admit the entire browser-as-platform project is flawed and disband the organisation? Or will they push ahead with these new features despite the risks?
Mozilla is the same organization behind Rust. "Unsteuctured shared-memory concurrency is inherently unsafe, and also not necessary for performance; here's how some structure permits a compiler to make it safe" would be a huge ideological win for certain parts of the company.
(Also, meanwhile, none of the native platforms that Mozilla is trying to replace have disabled threads.... so by that standard, Mozilla is already miles more credible here.)
> Those are entirely human qualities and concepts.
These are entirely human concepts only if you've already accepted some different axioms of your own. The Christian argument is that valuing freedom over slavery, and wanting worship, are divine qualities and concepts. And humans share those things because they were made after God's likeness for the sake of being loved (and more importantly, loving God in return).
Right now, some of the biggest users are applications where JavaScript's garbage collection pauses are show-stoppers, like games and audio recording software.
