Hmm, I see, it’s not a real L2 bridge, it’s a hacky pretend one that relays.
I don’t have a solution for this particular situation, but I do have a suggestion on how I would do it:
Make B have its own subnet, say, 192.168.1.0/24, assuming that A is on 192.168.0.0/24. Enable DHCP and everything, it’s now it’s own full network.
Make B a client of A with a static IP, like 192.168.0.2. That makes B present on A’s network.
Add a route on A for B’s network: 192.168.1.0/24 via 192.168.0.2.
Disable NAT on B, just set A as the default route. Since A can talk to any IP on B, B doesn’t need to NAT, A can handle it for both networks.
Now, both routers should be able to exchange traffic while being responsible of their own subnet. The only thing missing would be to handle broadcasts so stuff like Bonjour/Avahi works correctly. But as a whole both layer 2 and 3 would behave a bit more cleanly with less surprises.
I think what’s going on is B sorta pretends to be A in some way to do the relaying but something is going wrong.
Bit more context behind that now that the coffee kicked in:
Back then everyone had HDDs which strongly prefers sequential reads and writes. So if you can buffer all those in RAM, the system can optimize the throughput.
For the most part, IO happens on internal, non-removable drives so it makes sense to let applications write to RAM and do the flushing to disk in the background. For example, Firefox can write to its cache without having to worry whether it’ll slow down the browser too much. Generally makes applications much snappier, especially single threaded ones that vastly predates async runtimes.
If the program does IO on multiple drives, by acknowledging the write on one immediately may let the program perform IO on the next file, which the kernel can then flush to both drives in parallel.
By acknowledging the write immediately, the modified file is also immediately available to other programs on the system which can access the file immediately, from RAM, as it’s still being flushed to disk in the background.
The buffering allows writes to potentially cancel a pending write. If you’re updating multiple files for example, the kernel can delay updating the filesystem state to do it just once with the updated file list.
That’s largely why Linux works so much better with millions of tiny files compared to Windows.
You can still get speed benefits even with modern NVMe doing this. Those are so fast the kernel can run out of stuff to write before it’s gotten around to wake up the application for more. Instead let the application fill up the buffer fast, and only then, block the application.
Pretty much the only time this matters and becomes confusing is when you’re copying a file and wanted an accurate transfer rate, and the target disk is much slower than the rest of the computer, ie. USB sticks and SD cards.
Example case: updating your system. The package manager will write a whole bunch of files everywhere, but also run a bunch of commands to update some other files, rebuild caches and indexes, maybe do some computations and compiling. The package manager will call sync at the end of the process, and it’s likely by the time you get there, most of the data will have been flushed to disk. So it runs much faster.
That’s a kernel thing that dates from the 90s where allocating a quarter to half of your RAM for write caching made sense. These days we have more RAM than the USB stick we’re writing to, so it fits well into the buffer to be flushed asynchronously.
One use case I’ve seen professionally is that if you’re in a datacenter shared with other people, one could easily plug a laptop or change your switch ports or whatever and see your database traffic or whatever. Or in the case of the cloud, it makes it so nobody can snoop on your traffic at the router or hypervisor level.
I’ve seen VMs getting traffic they shouldn’t be getting, so even if you trust your provider, bugs happen.
On smaller, regular LAN, some devices are pretty innocent on their own but may have vulnerable firmware and become part of a botnet, which then can be used for attacks like ARP spoofing.
I’ve had a conference room IP phone with a public IPv6, from another country, that triggered CPU warnings. It was being used to crawl our website and it was hitting some heavier pages and was trying all sorts of known exploits.
On my own home LAN, I just have VLANs and SSIDs based on trust level, but for the most part nothing that would be sensitive. I guess you could copy all of my Linux ISOs.
I think it’s mostly intended for remote access like when SSH’ing in, it locks up after too many bad attempts.
When you have physical access a lot of security stops being relevant. Although for users with full disk encryption, that’d also force the attacker to wipe the keys in RAM so it’s still got some value.
I doubt it’ll do anything, or at worse something that can be easily fixed by resetting a config file somewhere. It’s much less weird than even switching between Gnome and KDE.
For the most part, only KWin and KScreen and maybe Plasma Shell might care but I’d expect nothing worse than a panel going to the wrong monitor.
For your input redirection, have you tried running it in gamescope or a rootful xwayland? Not sure gamescope has much special sauce since it’s based on wlroots and also runs xwayland, but they may have extra hacks for input grabbing.
Advertisers are just using their free speech to decide they don’t want to pay to have their speech presented next to hate speech. Nobody’s silencing anyone. Elon could do just fine with no ads, he’s just greedy and also wants hate speech to be profitable.
I'll add, it also depends on the efficiency of the local power supplies if those devices were using wall warts. Those are often pretty generic, and may only be used at 25% which for some wall warts would be outside of their top efficiency curve. A single power supply in the form of PoE can be more efficient if it lets both the switch and PoE regulator on the device operate at a better efficiency point.
In some way, stepping down 48V DC down to 3.3/5V is a bit easier than stepping down the 168V that results from rectifying 120V AC to DC. But the wart could be stepping down the 120V to 5V first with a simple AC transformer which are nearly always more efficient (95%+) than a DC/DC buck converter, but those can still reach 90% efficiency as well.
In terms of cabling, power loss is a function of current and length (resistance). AC is nice because we can step it up easily and efficiently to extremely high voltages as to minimize the current flowing through the wire, and then step it back down to a manageable voltage. In that way, american 120V has more loss than rest of the world 240V, although it only matters for higher power devices. That also means that the location of the stepping down matters: if you're gonna run 30m of ethernet and a parallel run of 30m of 5V power, there will be more loss than if you just ran PoE. But again, you need to account the efficiency of the system as a whole. Maybe you'd have a wart that's 5% more efficient, but you lose that 5% in the cable and it's a wash. Maybe the wart is super efficient and it's still way better. Maybe the switch is more efficient.
It's going to be highly implementation dependent in how well tuned all the power supplies are across the whole system. You'd need either the exact specs you'll run, or measure both options and see which has the least power usage.
I would just run PoE for the convenience of not having to also have an outlet near the device, especially APs which typically work best installed on ceilings. Technically if you run the heat at all during the winter, the loss from the power supplies will contribute to your heating ever so slightly, but will also work against your AC during summers. In the end, I'd still expect the losses to amount to pennies or at best a few dollars. It may end up more expensive just in wiring if some devices are far from an outlet.
The switch can put out 15.4W, but it doesn't control how much power flows. The device can draw 15.4W if it wants to but it won't necessarily do so. The switch can lower the voltage it supplies, and it can cap the power output by lowering the voltage it supplies, but it can't push a certain amount of power. That would violate the fundamental physics of electronics.
Put a 2.4kΩ resistor as the "device", and at 48V, the absolute maximum that will flow is ~1W. The switch would have to push 196V to force that resistor to use 15.4W which would put it way out of spec. And there's nothing preventing the device from being smart enough to adjust that resistance either to maintain 1W. That's basic Ohms law.
The device must negotiate if it's going to use more than the default 15.4W, or it can advertise it's low power so the switch can allocate the power budget to other devices as needed. But the switch can only act as a limiter, it can't provide more than the device takes. It can have the ability to provide more than the device takes, but simply can't force the device to take more.
If they don't hang outside the window they'd have to hang inside the window, and would need a more complicated ventilation system to take air from outside, heat it up and vent it back outside. At that point you'd have a window mounted two hose AC anyway.
So yes, your next best option is going to be a two hose portable AC. One hose takes air from the outside to cool the condenser, one hose to throw that hot air outside.
Single hose works too, but they're less efficient because they take cold inside air, cool the condenser and vents it outside, which waste some of the air it just cooled for that and it creates negative air pressure inside which will bring hot air from the outside to replace it from any cracks and holes in the house.
I do, Postfix and Dovecot. Mine’s got 10 years of history so I’ve been spared being blocked everywhere.
Most will tell you the software side is not too bad these days but the constant fighting to get your emails through can be really rough.
Personally I find it useful if only for the sake of just registering every service to its own unique email address so I can track who got my data where, and I get the privacy of Google not knowing every site I’m registered with. I still use my Gmail when I want to be sure it goes through.
I really don’t send that many emails so it works pretty well for me.
Or if OP really can’t do that (that’s by far the best solution), KDE Connect also lets you hardcode some IPs it’ll try to connect to. Given the computer is on the main network, using the IP of the computer directly would make it work fine behind the second router.
But ideally, they really should be the same network.
Basically buying time to attempt to win the election and abuse power to pardon himself or block prosecution, and if that fails, he’s still gonna have plenty of time to flee the country before his court date is due. Or drag it on until after statute of limitation.
You can probably ask them to pull the wires there but not install or terminate them for a patch panel.
Because you specified a patch panel, they probably quoted for the installation of the rack and the patch panel, as it’s not there and therefore they need it to complete the task completely.
You’ll end up with loose unterminated wires you can then just put an RJ45 plug on and wire directly to a switch or whatever.
I’d just manage the actual patching with VLANs on the switch. Unless you plan a more complex setup with some jacks going directly to a server or other routers/switches, it should be plentiful to just have 24 live ports you can plug devices into. Fair amount of switches can be simply wall mounted without a rack.
