Re: Google's Pixel security team
That's not unintentional. That's what you get when you have a huge software project lead only by programmers. They've no interest in something unless there is code, and code is more important than design.
16 posts • joined 28 Mar 2017
It's possible that's it's Linux based but my problem is that, I fear, they are taking on unnecessary development.
Take agl (or genivi -- they had a nice stack for media interoperability), skin it, and call it a day.
In fact, it looks like they did deploy agl very recently.
I'm not doubting that you've had problems involving dbus, but I can't say that those were problems caused by dbus (indication of a deeper issue). That you couldn't determine the actual issue provides additional support for my assertion.
Dbus is just ipc, and stratis is going to make heavy use of IPC as the daemon which can hold additional state so that better global decisions can be made than would otherwise be possible (this is exactly how they plan to be able to take advantage of these well defined, existing, services while enjoying many of the features that monolithic fs like zfs/btrfs have without needing to poke holes through the vfs/block boundary).
Something else to keep in mind, userspace is far more forgiving of errors than a kernel.
So, had anyone informed the Facebook and Oracle devs that the fs they've been working on its finished?
You know, it's not as though rh had ever been a vigorous backer of btrfs since most of their fs folks are on team xfs..not to mention clustering filesystems like Ceph and Gluster.
Btw, some rh dev announced a new project that seems to be aiming for a more UNIX-y zfs (that is, without the layer violations, but with many of the same features). It actually looks kind of interesting with most of neat stuff happening in the fs daemon.
Your ssd would have a much broader latency curve that results in those occasional several ms pe operations.
The small sizes aren't very useful for enterprises, but nvm with dram-like latency distributions over pcie is a big deal. For one thing, dram sucks up power even when it's not doing anything and has to refresh its leaky capacitors every ~50-100us.
I assume you mean "emits"? As long as backpropagation applies the right weight, it will.
It does remind me of the ai version of a honeypot.
A paper was making the rounds recently that described a universal method to fool, iirc, cnn, by applying a distortion field over an image. The images remained recognizable by humans. What seemed to be forgotten was that the algorithm is now a part of new training sets which will make the systems more robust.
That you immediately look to those two as an option (rather than suse) suggests that you are either not a customer, or have been looking for a reason to move to a Debian-based distro (for whatever meaningful difference you think exists).
For what it's worth, red hat tends to score amongst in the industry when it comes to customer service.
Your might want to brush-up on your knowledge of rust (very important here for a reason I'll get to in a moment), servo and project quantum.
Most importantly they AREN'T going to spawn a process per tab but only start a few processes that handle content duties (I believe four is the current goal) and handle the different pipelines of the frames (and tabs) using THREADS. This is where rust is important. It allows enough thread isolation such that a single thread can't affect the other threads in the process. THAT'S one the big changes relative to the other browsers. The others are webrender and Stylo.
Biting the hand that feeds IT © 1998–2019