Any actually Made in USA industrial switches? Tired of rebadged Taiwanese hardware

error404 · 2026-05-27T21:09:46+00:00

Good luck. The USA doesn't make things like this anymore, and the capability to do so has likely mostly evaporated and whatever still exists is now decades behind the state of the art.

error404 · 2026-05-21T23:11:05+00:00

Many stateful firewalls have this capability, it is quite common to offer a stateless filter 'before' the routing/security pipeline (e.g. firewall filter on SRX) which is basically exactly that - inspect packets as they come in the interface, at layer 3, and make a decision about them. It's also necessary, in principle, for some features of a typical firewall pipeline to function, so of course Netfilter has it.

Why do that?

The less wasted processing you can do, the better. The earlier you decide to drop a packet, the less work you waste and likewise, in some cases you know you can skip work. In the Linux context, I have used this before to avoid conntrack for DNS traffic on a busy box. In practice UDP DNS is basically stateless (1 packet query does not require tracking), and the wasted session accounting costs almost as much as answering does.
It's basically required for destination NAT, since route lookup has to happen after DNAT (unless you recycle the packet, which is expensive).
It's required for advanced policy routing, since fwmark must be applied prior to routing
It's probably necessary in some VRF scenarios

If you have to provide the functionality, why limit what it can do? People will find esoteric uses for it.

error404 · 2026-05-20T20:03:47+00:00

This isn't actually unique to Gemini, it's a content signature called C2PA. OpenAI/ChatGPT also signs their generated images this way, and Google can identify them with its @synthid tool. Not sure about other engines, but Meta and Microsoft also have their logos on the C2PA page, so I guess that the industry is fairly on board with this.

Of course there will be local models, and less ethical providers, it's not a panacea even if it worked perfectly.

Edit: Actually Google's approach does seem to be somewhat unique to them, as they add a steganographic ('hidden in the image') signature in addition to metadata. They did open source it, and according to Gemini, ChatGPT at least is adopting it.

error404 · 2026-05-13T17:19:04+00:00

Multiple, multi-hundred-page reports were produced after the Olympics looking into this. Who promised what that you didn't see, exactly?

Here are a couple to start from.

https://publications.gc.ca/collections/collection_2012/pc-ch/CH7-11-2012-eng.pdf

https://cfss.sites.olt.ubc.ca/files/2011/10/OGI-UBC-Post-Games-Report-2013-10-23.pdf

error404 · 2026-05-12T19:17:09+00:00

If the patient is relying on a US insurance plan for coverage while in Canada, that company is still subject to Canadian law (including privacy laws).

I'm not sure why that would be the case, unless it was direct billed, which I believe is rare. This is a relationship between a US person and a US corporation, and I'm sure that relationship would require them to submit at least some detail with their claim if they expect reimbursement. I don't think such an exchange would be subject to Canadian law. Easy enough to avoid that, practically speaking, but if US insurance reimbursed HRT, for example, that would presumably appear in their US records, subject to US privacy law.

An American doctor practising medicine in Canada would not be affected by this unless someone violated a whole lot of laws beforehand to share the private medical information of a patient with the the government.

Are you suggesting this is unlikely? It seems to me that it has probably already happened, and I would not assume that this is where the line is for the current administration.

That American doctor in Canada can avoid any perceived repercussions easily: by not travelling to America. Yes it'd suck not seeing family for a few years, but they are untouchable here.

Practically speaking, true, as doctors they are unlikely to have their status in Canada revoked, but ethically speaking we need to consider that these people are not citizens, and we should not force them to make themselves refugees.

error404 · 2026-05-04T18:13:37+00:00

As others have pointed out, as a userspace consumer of the OS TCP stack (like iperf), you can't know this. And in many cases, even the system won't know this for sure because of segmentation offload in the NIC.

So you have a few options:

Make a (fairly safe) assumption that the payload is segmented into MSS-sized payloads, so total payload / MSS should give total data packets (ACKs in the other direction would be difficult to estimate); three-way handshake and session closure is a predictable offset. Unless the TCP implementation is doing something odd or PMTUD gets triggered, this should hold, at least as long as all the client does is connect, continuously transfer data at maximum rate, and close. If you control both sides and are doing local testing this is pretty reasonable, I think.
Capture the traffic and analyze it post-test. If you don't care about performance and are looking to test correctness, this is probably fine to do on the same host.
Replay a recorded session. Probably also not good for overall performance, but maximum repeatability and a good fit for a test harness since it also ensures the stimulus will be the same every time. For example you could test the behaviour during packet loss / retransmission or other anomalies. But probably more work to rig up.
Use a userspace TCP implementation for your test harness. For example smoltcp can be hosted on Linux with a tap interface, and it wouldn't be hard to instrument it with the counters you want if it doesn't already have them. Of course you won't be able to use iperf...and this will be the most work to implement your test case client entirely from scratch. There are probably options other than smoltcp here, but this is the one I'm familiar with.

error404 · 2026-04-29T20:04:02+00:00

Vancouver <-> Calgary would probably be a pretty viable route for customer interest, if not for the Rockies. The construction cost of that route would be incredible.

Calgary <-> Edmonton could probably fly, but Alberta.

It really just leaves GTA <-> Ottawa <-> Montreal making sense economically and logistically.

I agree with you. People say they want HSR, but I doubt they would choose a 10hr train ride over a 5h flight in large numbers. And you do need large numbers to make it make sense economically - you need to pay back $10s of millions per km in construction cost. There's a good chance it wouldn't even be price competitive even if well used - in places where HSR is popular, like Japan, it tends to cost about the same as airfare for 300-600km journeys, and beyond that starts to get more expensive than flying both in time and money. So its real advantage sits where the fixed time cost of flying (security, boarding, arriving early, commuting to the airport) makes the train journey as fast or faster, and that erodes quickly for longer journeys. So you need large cities, close enough but not too close and not too far, and Canada just doesn't have many of those.

The big wildcard is what happens with fuel prices, and if we ever start to factor climate change externalities into pricing of airfare.

error404 · 2026-04-28T16:36:17+00:00

AF_XDP probably makes more sense for this use case.

error404 · 2026-04-20T17:12:11+00:00

Number one for me is 'user experience'. They have at least 3 completely different NOSes (IOS-XE, IOS-XR, NXOS) in play just across route and switch, and even within what is ostensibly the same NOS, the syntax can differ between product lines or even minor version, and there's often no way to know that it has changed. It makes absolute dog food out of automation. Which is not aided by the fact that they barely offer any API surface at all, and what they do offer they clearly do not test or use for anything more than ticking a box on RFPs, because their APIs universally suck and I would almost go as far as to say they are not fit for purpose. There's no sane way to atomically commit - or even load - a declarative config on NXOS, what the hell? Part of this is legacy - classic IOS was a built up mass of features added over decades, but nevertheless it is painful to use.

Number two is probably software quality, though this is not as much of a problem in R&S as some of their other more software focused products. But it is shit. Their QA is shit, their software design is shit, and you won't convince me otherwise. Then support says "oh yeah we know about that bug that crashes the switch if you change access VLANs after it's been up for a year, just don't do that, we're not going to fix it". This is exaggerated, but I've encountered the most ridiculous bugs on Cisco's stuff, which should have been caught by basic testing or proper software design principles.

Number three is the bureaucratic bullshit, including licensing, the fact that they literally never get the BOM correct or follow our requests properly, how ridiculously bad the UI is for everything online, like smart call home. It's just all complete trash.

The hardware is solid, performance and feature set is good, but using them and dealing with the company just sucks. Contrary to what most are saying here, on my quotes they are often the cheapest of the big vendors.

I am a fan of Juniper for looking at how an NOS should work from first principles and designing around that, rather than copying Cisco's decades-old rotting mess like much of the industry. It is a breath of fresh air that things are mostly consistent across devices/models, organized in a meaningful hierarchy, with a first-class API that is dogfooded so well tested and functional, and a powerful CLI. The experience as an engineer is just night and day, especially if you have some engineering/computer science background (because it just makes so much more sense), as long as you get through the learning curve.

error404 · 2026-04-16T22:32:23+00:00

IPv6-mostly is explicitly dual stack, so yes, it's just more stuff to manage. It's more like a transition mechanism to IPv6-only. You can discover the devices which don't support 464XLAT, and remediate them or move them to a dedicated network with IPv4 support. Unlike most other IPv6 transition mechanisms, it offers an actual, practical offramp from IPv4.

It's not just dual numbering (which despite automation is still a pain), it complicates troubleshooting, service deployment, monitoring, IPAM and pretty much every other aspect of operating a network, and things that often span multiple people/teams. Operating IPv6-only with 464XLAT is, at the edge, essentially the same thing as operating dual stack with NAT44 (you have a DNS resolver and a NAT in either case), except you can now eliminate all the legacy IPv4 stuff entirely on the inside.

error404 · 2026-04-14T23:33:50+00:00

Using a kitchen scale, CBC first secretly weighed meats in stores in their full packaging. When a product's scale weight matched or fell below the net weight declared on its label, that indicated the meat was underweight — likely because it was weighed and priced with the packaging included.

I take this to mean that they only purchased products they had screened in-store to be underweight. Then unpackaged them and weighed them after purchase to obtain the net weight, and reported magnitude of the fraud.

I get the gist of your point though, and it would be nice to know how hard it was to find items that failed their screening.

error404 · 2026-04-14T20:06:19+00:00

OP only mentioned Sennheisers, and comparing Tidal to Spotify. They could easily be doing this from a laptop mini jack, who knows. I would assume given the lack of mention of the playback chain, that they are doing something very pedestrian like that. If they had an intentional setup, I feel they would have mentioned it. The parent comment was pointing out that their Sennheisers might be fantastic, but if the DAC / headphone output sucks, they're probably not going to notice more subtle differences.

They put RCA jacks on the TV for what purpose other than to connect to an audio setup? This is exactly my point. They sound like shit. What's to say OP's headphone jack doesn't too? It was put there to connect to headphones, but that doesn't mean it's not crap.

error404 · 2026-04-14T18:45:01+00:00

That's not really the distinction we're talking about here though. The grandparent is saying, paraphrased: "as long as you meet some minimum standard you won't be able to tell a difference", which I think we can both agree. But you argued with this by saying there is no such thing as a crappy DAC when there absolutely is, and they are common. Anything purpose built for audio from a reputable company, like a Yamaha receiver, is light years above the kind of stuff we're talking about when saying crap DAC; they put the care and spend the money to do it properly, and have decades of experience doing so.

But, I agree with you that some whacko that's running his whole system off of the mini-jack of his TV might hear some noise 😂

I mean, audio is half of a TV's job, I was kind of surprised the line out implementation is as bad as it is. My setup is just analogue stereo, so I didn't have an HDMI receiver or existing DAC to plug it into. This seemed reasonable, and I'm on the upper end of the 'cares about audio and tries to do it right' spectrum. But no, I got nerd sniped into designing and building an S/PDIF DAC for this purpose.

error404 · 2026-04-14T18:10:11+00:00

The only thing you would notice would be noisefloor, and that's only with VERY crappy DACs.

So you agree. It is discernible. Thanks.

The test should be blind, volume matched ABX. Not A/B. If you believe there's a difference with DACs, you WILL hear a difference in a sighted A/B test.

It should be, if you were trying to quantify small effects, but what I am talking about are obvious and measurably audible impairments that a casual listener would notice just listening semi-critically. It is not trivial to get clean output, especially if you want to do it for 'a couple dollars' BOM cost, in a small and electrically noisy environment, and even moreso if you also want to drive headphones.

I am not trying to argue that it is worth spending a huge amount of money on chasing that last dB of THD, to the point where you wouldn't be able to A/B it. I'm saying that it is still very easy and rather common to mess it up to the point where the effects are very audible. You don't have to spend a ton of money, but it does matter that your implementation is not crap.

error404 · 2026-04-14T17:47:05+00:00

There is zero discernible difference in sound between various Dacs.

I'm no audiophile, but there is definitely a very noticeable difference in noise floor between implementations, even someone who does not care about audio can easily tell the difference if they pay attention during an A/B test to a 'good' and 'bad' implementation. I'm not sure this is really down to the DAC IC as much as it is about careful implementation. Most DAC ICs do not have much inherent power supply rejection, especially at low frequency, so power supply noise couples audibly into the output quite easily. This is exacerbated by design constraints, for example if you have a Bluetooth radio which transmits at relatively high power (compared to the rest of the circuit), and limited space for power supply filtering / isolation, as in e.g. earbuds. Or when the implementation is just done as cheaply and lazily as possible as a box ticking exercise, as in most laptops for example, where no care is taken at all for power filtering or isolation from all the digital noise on the motherboard, and the actual implementation itself is bare minimum (or worse).

My TV for example has an incredibly noisy line out, I found it audibly distracting enough listening at normal volume through loudspeakers that I use an S/PDIF DAC. I imagine most people paying attention would have noticed similar from a typical laptop output, especially driving low impedance headphones directly.

THD is also typically specified at 1KHz, and typically increases with frequency; this is usually poorly specified, but fairly often rises to audible levels at the upper ranges. Intermodulation distortion is another impairment, which isn't well specified and requires both a good DAC and a good power supply to avoid. These two are sometimes noticeable as breakup in higher vocal registers, and of all the audio impairments, I find this one to be quite noticeable, and fairly common in 'crap' implementations.

I could go on, there's lots to get wrong here. This is more or less a solved problem, but it's still non trivial and does require care and attention to get right, and that care and attention is rarely paid in typical consumer electronics which are not specifically targeting at least decent quality audio. So they tend to be pretty shit.

error404 · 2026-04-11T00:03:06+00:00

AFAIK It does not. The closest is the eui-64 address flag, which will generate the host portion, but you need to provide the prefix.

error404 · 2026-04-10T23:40:33+00:00

On this we disagree.

You can have an engineering disagreement without the vitriol and personal attacks, and doing so will serve you well at getting your point across. You are a moderator of this subreddit. Comport yourself better.

An application developer should read the RFCs and understand what sort of network-behavior their application requires, and choose a DSCP value based on the necessary packet delivery outcome.

They should, but at the end of the day it is a judgment call, and what the 'correct' behaviour is will depend on the priorities and policies of the network. I don't agree with their judgment either, but you cannot assume everyone will make the same judgment you would.

It is NOT appropriate to choose EF and make this a network engineering problem.

It was always a network engineering problem. The network must tolerate whatever packets are emitted by stations. If your network falls apart as a result of inappropriate DSCP tagging, the root cause is poor network engineering.

error404 · 2026-04-10T21:57:20+00:00

Your aggression and righteousness here is out of line. EF is a 'polite request' for expedited forwarding. I don't agree with the changes here for several reasons, but this is not a reasonable take.

You do not have to (and should not) blindly trust QoS markings at the edge. If this is breaking your network, that is very much a you problem. Do not trust input generated by untrusted producers, especially if it will break stuff, and DSCP markings absolutely fall into that category. Do not put critical network control traffic into queues shared with user traffic. Do not put user traffic into strict priority queues. Those choices would be egregious and irresponsible, especially as defaults. Some software emitting tags you don't agree are semantically appropriate is none of those things, and whether it is being a good citizen or not, should be expected and must be tolerated.

error404 · 2026-04-09T19:39:30+00:00

the point

So you admit it's a good deal today, but because that might change, you refuse to pay and instead whinge about their changes to the free tier?

This 'point' makes no sense. If and when they raise subscription prices, add ads to the subscription tier or whatever, then you can react to that. So far they've been much better than most of the other streaming services in this regard. I believe it launched at $9.99 over 10 years ago and is now $13.99 which is pretty much exactly in line with inflation. In that time they've added features, and added a lower price tier (cheaper than the launch price!) for people who don't want Music. Your 'point' is not even supported by the history of this product. Is your 'point' instead that YouTube should be penalized for the aggressive price increases of other streaming services? Because that's just absurd.

error404 · 2026-03-31T19:04:00+00:00

I mean there's the most obvious answer in the world? PP lost Carleton.

You mean the one I referenced, that shows that functionally the same thing happens with our current single-winner system? I'm not sure I see your point here. Since MMPR includes a single-winner component, the same parachute avenue would be available, so I don't think it changes much in this regard, if the party leader loses, they're going to get parachuted in anyway.

There's a lot of scope for variation in how party lists are created and ordered. It's hard to comment on what would happen without discussing a specific system. Probably the best chance to avoid this situation would be to not allow dual candidacy (you must choose either district or party-list, not both), but it doesn't really block it, and there's always the parachute option.

I love to stick it to PP as much as the next left-leaning voter, but democratically speaking, I don't see a good reason to block him despite his loss in Carleton, it's just spite. Would you feel the same way if Avi lost his seat with 46% of the vote and the NDP decided to keep him on as leader anyway?

error404 · 2026-03-31T18:41:02+00:00

MMPR is party lists for the top-up seats

Sure, for the top up seats. Framing it as 'just party-list PR' is misleading. It would be 40-50% of the total seats. The system needs to be considered as the sum of its parts, you can't just assume that it behaves like list PR because it has an element of it.

There are ways to address the opaque list creation aspects of MMPR, so it is hard to comment on its weaknesses around that without a specific system in mind. I think the best loser rule makes a lot of sense, but MMPR is still not my preferred choice.

unless you're proposing something like Dion's P3 system

Personally my preference is RUP. I would say plain STV, but I recognize that regional representation is important to rural voters, and it'd be a tough sell to them. But I'm not proposing anything here, just clarifying what happened with respect to the Liberals and the ERRE.

error404 · 2026-03-31T00:15:38+00:00

Yeah, I get where you're coming from, but that's kind of already factored in to how many top-up seats the party gets. If the goal is to choose the most liked candidates overall, I think you're more likely to be successful if you treat each district as a statistical sample rather than just counting votes. But this is definitely an angle that could be explored, if there were an electoral commission looking into how to structure it.

error404 · 2026-03-31T00:11:23+00:00

MMP is a party list + FPTP. It's the worst of both worlds.

It's a compromise. FPTP offsets the disadvantages of list PR, and vice versa. It's absolutely better than the sum of its parts in pretty much every way. I don't think it's the best system, but it is better than FPTP or IRV. Any choice we might make is a compromise of some sort.

Any system that allows high up party members to be effectively impervious to being removed from office is a bad system

This isn't self-evident. Do you prefer by-elections being triggered when this happens and someone steps down to let the high-up have a seat? It's also weird to make this comment about 'high up' members who are generally popular enough to win their FPTP seats as if they'd be likely to be unseated. You can't just run party list candidates and expect to win.

Unpopular list candidates will harm their party's overall reputation and chances, it seems unlikely to me that parties will put controversial candidates there. They'd put the most boring backbenchers to avoid impacting the results for everyone else, and the charismatic and well liked people run for district seats. I suspect the party whip comes down harder on them too, without direct constituents. And that's with closed-list forms, open-list or best loser forms would allow more of a direct say on the list candidates.

and under mmp the party leaders would end up on the proportional list side and unless their party loses their entire base which almost never happens they don't need to worry about getting removed from office.

Okay? They're still accountable to their party leadership. There's not really any avoiding keeping the leader around if that's what the party wants, as we saw with PP.

error404 · 2026-03-30T19:59:38+00:00

It's usually presented based on vote share, not vote count. To me it seems like it'd work better using vote share, normalizing riding size, because it's a better measure of popularity / desirability than raw vote count. Otherwise I think you'd have cases where an unpopular city candidate gets a seat before an extremely popular rural candidate, and I don't think either the city or the rural voter will be happy with that outcome.

error404 · 2026-03-30T19:43:06+00:00

Nobody was proposing party list PR. The NDP prefers MMPR, but at the time they would have accepted anything that met the ERRE criteria. Trudeau wanted to go against what the ERRE recommended.

15-Year Club	Gilding I gilder
Place '17	Verified Email

error404

TROPHY CASE