In fact, they also have a promotion right now where you can get $800 back on either the Pixel 9 or 9 Pro, spread over 24 months; that makes the 9 free and the 9 Pro only $200.

I'd love to see better examples of subtle problems that your tool can detect: the kind of thing where an engineer says "oof, yes, that's obvious now that you've pointed it out" but wouldn't have noticed it right away on their own.

However, it reappears every time the TV is turned on. At some point, a houseguest (assuming those are a thing at some point in the future) is going to hit "okay", or I'm going to do so accidentally while fumbling with the remote, and that isn't the same thing as actual/deliberate consent from me, the owner of the device.

I do what you suggest in step (3), and never connect it the TV to a network, but it's still concerning.

Lots of people may have exposed credentials to Docker Hub that can do much more than disclose proprietary source code.

I think that a comparison to the FM4000, which is the programmable series of parts in the "Monaco" family, would be more fair. Here's their datasheet: https://www.intel.com/content/dam/www/public/us/en/documents...

The FocalPoint ASICs were, as far as I know, some of the first to support (a demo-quality implementation of) OpenFlow in hardware. When Intel bought them, they released the datasheets, which is neat.

As a real-world example, these ASICs were used in Arista's 7100 series (c. 2008) switches. They published a two-part "Technical Evaluation Guide" for those switches which are, among other things, an interesting glance at how switches are constructed out of ASICs. Part 1 (https://local.com.ua/forum/index.php?app=core&module=attach&...) shows the topology of each switch (starting on page 13).

The 7124 is a single 24-port FM4224 with all 24 ports connected to front-panel ports. The 7148S has three FM4224 ASICs; each is connected to 16 front-panel ports and uses 4 ports (40 Gb/s) to connect to each of the other two ASICs in a ring. Intuitively, this means that it's possible that those inter-ASIC connections could cause bottlenecks (if e.g. all 16 ports connected to the first ASIC try to send 160 Gbit/s of traffic to the 16 connected to the second ASIC, they'll saturate the 40 Gbit/s of connectivity between the ASICs). Therefore, Arista also offered the 7148SX, which is non-blocking but needs six (!) FM4224s to make it happen!

I don't think that your claim that GRO is "a software implementation of a hardware optimization that is known as Large Receive Offloading (LRO)" is correct, though. GRO effectively replaces LRO [1]; it has fewer limitations (it works with non-TCP traffic and with bridging [2], for example). Drivers need to support it, but they are free to take advantage of hardware offloading/acceleration, and many do (including e.g. the ixgbe driver [3]).

----

[1] In terms of function, and in the sense that LRO could be removed if the drivers that were using LRO were updated to use GRO instead.

[2] Relevant bug: https://bugzilla.redhat.com/show_bug.cgi?id=772317

[3] Which actually supports both LRO and GRO; if I recall, in older versions, bad things(tm) would sometimes happen if you had both enabled at the same time (whereas now the LRO setting is ignored if GRO is enabled).

(http://events.linuxfoundation.org/sites/events/files/slides/..., http://www.devicetree.org/Main_Page, https://en.wikipedia.org/wiki/Device_tree, http://elinux.org/Device_Tree)

Any of these "datacenter LANs", though, tend to be fast and free (in terms of bandwidth). We just use a VPN overlay and call it a day.

"OSv was designed from the ground up to execute a single application on top of a hypervisor... OSv... runs unmodified Linux applications (most of Linux's ABI is supported) and in particular can run an unmodified JVM, and applications built on top of one."

("Building on top of a platform is a foundational risk, and if your platform decided one day that it doesn’t like what you are doing, or likes what you are doing so much they want to compete with you, it’s Very Bad. Your platform partner can easily damage your quality of service, or simply shut you down. If that happens, your business is dead.")

Have I missed an explanation from Dalton or the App.net crew about how what they're envisioning will be different? What protects a developer from being at their mercy for uptime, timely bugfixes, continued development, and so on?

Actually, on a more general level... what can platform/tech providers do to provide those reassurances? I can't seem to think of anyone who's done a really stellar job of it.

All I have to type is "cli53 import example.com --file example.bind --replace --wait" and it'll replace all of the records for example.com with what's in the BIND file, and the --wait makes it poll Amazon until the "pending changes" go through.