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.
_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.
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.
Are you saying it displays even when the input source is selected for your external device/computer? That does not happen for me. And when I turn off/on the TV, it remembers the last selected input source -- so the external device/computer displays right away.
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.
I work for Netflix on Open Connect, the Netflix CDN. We run a modified FreeBSD on our CDN nodes. My job involves improving performance and scalability in the FreeBSD kernel. See https://medium.com/netflix-techblog/serving-100-gbps-from-an...
Very much like the NFS article author describes, I also tend to find "naive" solutions that end up being polished a lot before landing upstream.
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.
VCF only contains variant information; FASTQ and BAM contain the “raw” sequencing information (in reality that data is already heavily processed but it’s the starting point for all usual analysis). Depending on how you do the analysis, the variant data will be slightly different. There are some current baselines (so-called “best practice” workflows) for performing the analysis but many of the details are variable, and subject to much current research.
To be fair, for most things the VCF is completely sufficient (and in fact most people won’t care even about that). It just feels cooler to be in control of the raw data (and personally if I end up using a sequencing service, I would want to perform my analysis; but this is obviously irrelevant for 99.99% of users).
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!
7148SX was not truely non-blocking. It was a Clos in a box. 4 chips in front (12 ports each, and 2 in the back, each front panel chip wired 6 ports to each of the rear chips as a LAG). If the hashes worked right it was non-blocking, but taking an Ixia out of the box and clicking go on a RFC ful mesh test would give you drops. The 7148S was created after the 7148SX shipped as a cost reduced version for those that had a workload that fit the tput characteristic. The 10GBaseT version was the same 3 chip switch. The power draw on the 10G-T phy was quite high at the time.
The FM4000 doesn't appear to have an actual programmable CPU either; just the same "lots of lookup tables and configuration registers" (but more of them.)
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).
