I made this mistake. I love where I've wound up, but I would have gotten there much more quickly and with a lot less heartache if I'd worked as part of an existing company before starting my own.
It is! If you also need service, Google Fi has had a promotion for a while that gives you the $500 purchase price back over 24 monthly bills.
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.
There are three "example programs" available on your website, but none of them are very interesting.
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.
You can absolutely ignore it, even without switching inputs; it appears above the menu/input bar at the bottom and isn't modal.
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.
_Can_ you reject Samsung's EULA? My Q90T prompts me to accept it every time it's turned on, but the only option appears to be to accept it. I can't find a "no/reject" option.
I do what you suggest in step (3), and never connect it the TV to a network, but it's still concerning.
Also, if you need to interact with a Supermicro BMC that doesn't support the HTML5 console (for example, because it's running older firmware), I reverse-engineered the proprietary "iKVM" protocol (along with a lot of other parts of the BMC) and implemented support for it on a branch of noVNC, which you can find here: https://github.com/kelleyk/noVNC
I haven't seen anyone mention that Docker Hub's automatic build integration requires either "Owner"-level permissions on your organization or "Admin"-level permissions on the individual repository. Based on the GitHub-side audit log, Docker Hub seems to be using this access to add deploy keys to your repository, but this isn't mentioned in the documentation (which is why we had to go spelunking in the audit log), and if you try to take a least-privilege approach and grant only the read-only access that Docker Hub should require, your GitHub repository will simply not appear in the list of available repositories when you try to configure an automatic build.
Lots of people may have exposed credentials to Docker Hub that can do much more than disclose proprietary source code.
There may be nice things to say about Veritas, but they charge an extra $99 for VCF files, and the actual raw data (FASTQ/BAM) is not available at any price (to you; Veritas has it). This is after you've paid $1,000 for sequencing.
That's not because it's slower; that's because it's the low-end (non-programmable) member of its family. It was designed by a company called Fulcrum, which produced the FocalPoint FM2000/FM3000/FM4000 (1/10G) and FM5000/FM6000 (10G/40G) switching ASICs before being acquired by Intel.
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.
[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).