kj4ips

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".

Note that the status on this is entered/not assigned, so it's in the works. However, the court may have required that they do so before proceeding.

The offending use does not have to be a 1:1 match to dilute.

(not a lawyer; not legal advice)

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.

(not a lawyer; not legal advice)

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.

They have a Ubuntu derivative called DGX OS, that they use on their current lines.

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.

Two main reasons I can think of:

Most current BMC platforms are older than seL4

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.

HPE at least makes you flip a DIP switch, otherwise it complains loudly and halts.

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.

Do we know if this is also the case for other systems that use Aspeed/ami BMCs, or if the key pair in question is exclusive to SM?

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.

In that boat now, weak-modules means you sometimes get lucky, and can reuse. However, since it's more effort to determine if a rebuild is needed than just slap the "build all the vendor kmods and slurm" button, we tend to build for each kernel. IIRC el8 added kernel symbol signature hashes as Provide/Requires, with automation to extract them at build time, so kmods got a lot easier to deal with.

The starters used in start/stop vehicles are far more robust than normal ones, and start/stop in hybrids often don't even use the normal starter to turn the engine over. Because vehicles are often kept for quite some time, most start-stop systems will autodisable after a certain number of cycles, so that they only use a given portion of the starter's expected life. (disables the start/stop system, not the starter itself)

There is, it's a few days old, and it's a non-enforcement from the Biden administration, according to the man himself and his staffers, he intends to let it be the next administration's problem. Whatever the next administration does when it takes power is yet to be seen.

The restrict act was written really strangely, and I assume Oracle required some assurance from someone to not just delete Bytedance's accounts and resources.

There's a few cases where this makes sense:

* The laptop supports one or more power supplies, but with different current ratings, and the laptop needs to know how much it can safely draw. (This can be done with passives)

* The charger has dynamic power availability, possibly because it charges multiple devices, and the amount of power available varies with other factors, such as temperature.

* The charger has various output modes available, only some of which align with the device to be charged. Therefore, the two devices must negotiate a common set of parameters.

On the note of USB Condoms, they only interrupt the data lines, USB's power negotiation (nowadays) mostly happens on the power line itself. Though usually, the device's OS (if it has one) has limited/no visiblity to this, and a dedicated port controller handles this interaction, possibly passing higher-level information to the rest of the device.

There are some things that can be done to reduce the threat surface:

* Build the protocol parser as a FSM.

* Formal methods for critical systems.

* Severely restrict the expressiveness of the protocol, particularly any variable-length fields.

I've heard a ton of stories about .io, IMO, they play fast and loose in a space where that isn't okay, and they get away with it mostly because they are a ccTLD.

The last time someone I knew had an issue, they had to get a senator to make waves to get anything resolved.

TBH, my biggest gripe is that systemd doesn't play nice with musl or ulibc, I would like to not have to ship a cron, a supervisor, a xinetd equivelant, and a binary just to react to inotify/dnotify events. Though openrc how has a supervisor.

I have a vehicle w/o AM radio, and our local traffic authority uses an AM station for traffic and other civil alerts. It's really annoying that it is absent.

The FM is also an afterthought, the antenna system under-performs horribly, and appears to actually be //inside// the cabin.

I suspect this mostly refers to "Code Protect" or similar functions, that are designed to stop the user for extracting the firmware from a device in the field. Typically, when this is enabled, large parts of the debug interface stop working, and turning it off requires a "secure" erase, that clears the loaded firmware.

While many CP implementations are flawed, or can be bypassed by a skilled attacker (power glitching, &c), I wouldn't say they are purely theater, as they raise the required investment from a <$10 ISP to $$$+ for something like a chipwhisperer.

I was taught to listen to the sound the water made in the sink to tell when the hot was ready. I had always assumed this was something most folks already knew about.

I run it in my homelab, because gitlab is really reasource intensive by comparison, and I need it to work when the network is out. The annoying part is that means outside contributions that support enterprise-y features are probably not going to be accepted. Gitea does not appear to use a CLA, so they at least shouldn't be able to re-license existing OSS, but the base license is MIT, so no virality.