The trend of slapping two STT 4-port hubs together is so common, that even name-brand hubs for reputable brands are often this, including the back feed issues. I purchased hubs form a solar-named company, and one that has a similar name to a large US department store, and they were cascaded 4port, STT, ganged overcurrent and switching.
I've started buying PCBAs from Ali, where the vendor advertises the exact chip set in use. It's often cheaper than domestic options.
Listings for assembled hubs (whether ali or domestic) almost never include information about the hub's actual characteristics, unless you're looking at a 300+ hub sold to audiophiles.
I'd really like a source for a true 7p hub, with MTT, proper power, per-port overcurrent and power switching, but I can't seem to find one, especially since vendors tend to rev b2c products with no notice (one of the name-brand ones I bought had been downcosted shortly before I bought it).
I like the idea behind ostree and bootc, but I feel that OCI (with tarlayers) is not a good fit. `repack` makes an absolute hash of things, and since the layers are logically packaged, they will have to be composed somehow, and then ostree becomes only slightly more useful than coreos's A/B usr.
OCI roughly assumes that layers will be laid out in some logical way, and that a given host will see opportunities to reuse across different instances, but with bootc, there will only ever be one instance.
OCI also assumes that individual layers are small enough that it is always worth pulling and unpacking a layer instead of some kind of authentication delta, which is great for a k8s cluster in a center, but not great for devices out on the edge, where you might want this kind of pseudo-immutable system even more.
I really want some standardized way for a manifest in OCI to say that "this content is also available in other format X here".
Trademarks are about recognizability, not about some objective similarity. There's no magic Levenshtein distance from a trademark.
However, they are also scoped to domains, so if there was some non-car business with such a name, they would also be entitled to the name, and the domains tend to be first-come first-serve in those kinds of cases.
Think of all the "Acme" or "A-1" companies that all have different products, and the general public doesn't have an issue conflating them.
I agree pretty strongly. A translation layer like this is making an intentional trade: Giving up performance and HW alignment for less lead time and effort to make a proper port.
It's my opinion that nvidia does good engineering at the nanometer scale, but it gets worse the larger it gets. They do a worse job at integrating the same aspeed BMC that (almost) everyone uses than SuperMicro does, and the version of Aptio they tend to ship has almost nothing available in setup. With the price of a DGX, I expect far better. (Insert obligatory bezel grumble here)
At least in most jurisdictions, the egress to a gathering area can __never__ be blocked, there is some provisions for delay on emergency exits, but those require NRTL certification, and are actually usually mechanical.
You might be able to lock it down during periods of limited occupancy, and you can rig it to an annoying alarm, and maybe try to identify the person, and ban them from future. It is possible to get variances for this, but you usually need to either be a medical or penal facility.
Most run on hardware that is not supported by seL4, or at least on hardware where it has not been validated.
Not to mention that a task manager would be needed as well as tons of other services which aren't provided out of the box, and don't share the verification provided guarantees.
Pretty much all of them allow unrestricted access from KMS from factory, tough all of them have a way to disable it once configured, and HPE even throws shade until it's limited. KMS only works from the host itself.
I think the idea here is to induce the request to a garbage domain (such as by using it as an email domainpart, to get an SPF and/or DKIM lookup), and forge a response with other names in the additional section. This also somewhat fits with DNSSEC as a mitgation, as the additional section (if not discarded outright) should result in a signature chase by the resolver, which should fail if the targeted domain is dnssecd.
Imagine that:
* I have an evil system at 192.0.2.1
* target at 198.51.100.1 which is an MTA, and is it's own resolver with dnsmasq.
* foobar.com has a nameserver that silently drops any request with a ! in the first label
I first send a mail to 192.51.100.1 claiming to be from bob@"foo!bar.foobar.com"
192.51.100.1 sends a request to the auth ns for foobar.com, which gets droped.
While this is happening, I spam the crud out of 192.51.100.1 from 192.0.2.1 with forged answers for foo!bar.foobar.com that contain additional responses stating deb.debian.org is at 192.0.2.1 with a ttl of months.
If I am lucky dnsmasq caches BOTH the foo!bar.foobar.com response, and the deb.debian.org one, meaning that future accesses to deb.debian.org instead go to my attacker-controlled nastybox.
Honestly, unless you //really// need nvlink/ib (meaning that copies and pcie trips are your bottleneck), you may do better with whatever commodity system with sufficient lanes, slots, and CFM is available at a good price.
Fair warning: the BMCs on those suck so bad, and the firmware bundles are painful, since you need a working nvidia-specific container runtime to apply them, which you might not be able to get up and running because of a firmware bug causing almost all the ram to be presented as nonvolatile.
TL;DR: It's massively easier to run a few models really fast than it is to run many different models acceptably.
They probably are using some interesting hardware, but there's a strange economy of scale when serving lots of requests for a small number of models. Regardless of if you are running single GPU, clustered GPU, FPGAs, or ASICs, there is a cost with initializing the model that dwarfs the cost of inferring on it by many orders of magnitude.
If you build a workstation with enough accelerator-accessible memory to have "good" performance on a larger model, but only use it with typical user access patterns, that hardware will be sitting idle the vast majority of the time. If you switch between models for different situations, that incurs a load penalty, which might evict other models, which you might have to load in again.
However, if you build an inference farm, you likely have only a few models you are working with (possibly with some dynamic weight shifting[1]) and there are already some number of ready instances of each, so that load cost is only incurred when scaling a given model up or down.
I've had the pleasure to work with some folks around provisioning an FPGA+ASIC based appliance, and it can produce mind-boggling amounts of tokens/sec, but it takes 30m+ to load a model.
[1] there was a neat paper at SC a few years ago about that, but I can't find it now
Tons of the rolling key systems on the market are based on KeyLoq, and keyloq is a fairly well designed system with a big lynch pin.
It has something called a 'manufacturer key', which needs to be available to any device that allows field pairing of remotes. If that manufacturer key is known, it only takes two samples from an authenticator to determine the sequence key.
Absent the manufacturer key, jamming+replay attacks work, but brute forcing a sequence key is generally prohibitively costly.
However, since any receiver that supports field programming needs the magic "manufacturer key", one could purchase such a unit, and may be able to extract said key.
Massive. AD isn't just LDAP and Policies. There's somewhere around 14 services that are involved, even NetLogin still has it's tiny part to play. AD uses LDAP referrals, expects clients to follow them, and use the SRV records to find the DC in the same site (if one exists). AD as it is typically deployed is active/active multimaster with per-record tiebreaking based on edit time, client-based load balancing with proximity awareness, ACLs for every possible field and record, overridable at any point in the tree (389ds can do this, but openldap is a nightmare). There's a full automated PKI in there for managing certs for everything, and that's before we get into the KDC logic, the strange things SYSVOL can do, and various other things that integrate with AD.
Samba, krb5 &co can handle small cases, but it's architecture is still stuck in the nt4 days, and there's limited cohesive integration with LDAP and the other services.
This is a prime example of "If you make an unusable secure system, the users will turn it into an insecure usable one."
If someone is actively subverting a control like this, it probably means that the control has morphed from a guardrail into a log across the tracks.
Somewhat in the same vein as AppLocker &co. Almost everyone says you should be using it, but almost no-one does, because it takes a massive amount of effort just to understand what "acceptable software" is across your entire org.
Yep, one of the more popular FOSS CNC controllers (LinuxCNC) draws its heritage from a NIST project, and at least one major manufacturer ships a variant of it in their machines.