Here is a nice summary from https://www.reddit.com/r/firefox/comments/o28yi4/comment/h26mguk/?context=3 :

Privacy Badger is also redundant. It’s useless at best and can do a disservice:

Its local learning is disabled by default. Since they turned off the heuristic, PB just blocks third-party cookies from the yellowlist. Keeping a separate extension to block cookies from ≈800 domains makes no sense when you have uBlock Origin with tens of thousands of domains in filter lists. It’s detectable, that is, it adds extra info to your fingerprint. Even despite the disabled local learning, some of its methods of work are still detectable (function code: API tampering detected). And if you enable local learning, PB can become even more detectable.

Also it sends Global Privacy Control and Do Not Track headers (which even one of its creators called “a failed experiment”) by default, which is useless and only gives an extra bits for fingerprinting.

Basically how privacy badger works is noticeable, but you can turn on local learning to get bespoke ad blocking at the cost of your device being much more easily identifiable. Maybe half-n-half and have privacy badger off on private browsing so you can shop in that mode without Amazon knowing your life’s history as easily

Sounds like your freezer isn’t actually getting cold enough for the ice cream. Semi-melted Tilamook will get whipped-esque if not cold enough. Put a digital thermometer in there for a while and see what temp it’s holding! No ice cream is “drop metal into it and it slides to the bottom” unless it’s not cold enough

As for ice cream consistency, afaik more cream content (which is better ice cream) will be softer at the same temperature compared to ice cream with more water content (shit ice cream). Breyers regular (I think they have a fancy attempt with more cream) is pretty watery, Tilamook is creamed up

(Do you notice a lot of frost on stuff? That is a sign of a bad seal and (humid) air is getting in)

Tiger, you’re very similar to many of the semiconductor EEs I know :) and I mean that in a teasing-but-you-know-cause-you-work-in-the-industry way. Yeah, we only really care about whiskering in the context of electrical devices. That’s what it’s saying. Read the “Mechanics” section, it tells you nothing about actual electromigration doing it; they describe an E field encouraging metal ions in a fluid to make a reaching whisker and link to electromigration because it technically is “electromigration” making the targeted whisker occur. But IC-style electromigration is not causing the whisker, clearly cause no currents are flowing, which is why I took the time to write the explanation in the first place.

But just because the semiconductor community called it whiskers so it shares the name with the Big Whiskers, does not make the process anywhere close to similar. The current densities that cause absolutely not present for the stress ones, which the wiki article is about.

Tiger I think you’re being pedantic, they linked to Whiskers (metallurgy) not Whiskers (electromigration). There is a difference! But it’s not super clear cut, which is why I took the time to write about it.

Electrons do not always move at the same speed in a given metal. A lot of things affects mobility, but the E field is very important too. Both things combine so that electrons do not always move at the same speed in a given metal. But you can simplify in an IC world because there you’re riding the saturation velocity basically always, which is why I assume you keep claiming that.

I want you to know that your experiences from your education and job are valid - you do deal with whiskers in ICs, not denying that; the fact is that whiskers due to stresses and strains aren’t called electromigration which is what the original comment says.

“A similar thing also called whiskers can happen inside ICs and has been a known failure mode for high frequency processors for many years. I work in chip design, and we use software tools to simulate it. It’s due to electromigration and doesn’t rely on stresses but instead high current densities.”

Check out https://en.wikipedia.org/wiki/Hot-carrier_injection hot carrier degredation, it’s in the vicinity of electron mobility but in a semiconductor setting. Key link is it’s electrons with momentum doing the work. In this case electrons (much hotter than in electron mobility, which are limited by the saturation velocity) smash into the gate dielectric, making it a worse dielectric. Hot carrier injection doesn’t have to end in damage to the dielectric, but when it does it’s hot carrier degredation. There’s a lot going on though, semiconductors are really complex - like electron tunneling also exists.

The metal moves due to very different reasons. I would not say whiskers due to mechanical/residual stresses are due to “electromigration” - electromigration isn’t even there since the wiki definition is “transport of material caused by the gradual movement of the ions in a conductor due to the momentum transfer between conducting electrons and diffusing metal atoms”. You build stresses and strains into semiconductors for better mobility profiles, and I’m sure that can cause whiskers - but again, it’s not electromigration.

Electromigration, as noted, plays a role in the form of encouraging stress whiskers to grow in a direction.

But in ICs, with their very unique extremely small scales, electromigration can directly form whiskers by moving individual ions via electron collisions. But the generation mechanism for those whiskers shares nothing with Big Whiskers generation mechanism. That’s my point.

Electrons in metal do not always move at the same speed; they move at v=mu*E where v is the velocity, mu is the electron mobility, and E is the electric field. Crank the E, you go faster. At very high E fields you reach the electron saturation velocity where slowing factors limit the maximum speed - I assume in your IC world you’re basically always there due to the extremely small regions (E = V/m; any V with m at nanometers is big E) which is why you claim that. But even then the electrons are accelerating due to the E field, smashing into ions and losing their momentum (mass static, so it’s just velocity), and then re-accelerating. The saturation velocity is the average bulk motion of electrons but it’s not a smooth highway, it’s LA traffic (constant crashes).

Electrons can gain significant momentum, which is just their static mass times their velocity. Limited at velocity by the saturation velocity, current density is important for significant momentum exchange. Luckily ICs are so tiny that the currents they drive are massive current densities.

What you said originally is correct; it’s just in ICs electromigration can cause whiskers. In the Big World it can’t. But it can influence Big Whiskers to grow to the worst places and fuck up things optimally if you take an extremely relaxed view of electromigration that defines it as “movement of ions encouraged by an electric field”.

This statement is not fully accurate. Whiskers in OP’s case are about (usually) tin whiskers that grow, often visibly, and then can connect (short) to unintended areas.

Electromigration is effectively when a large potential difference encourages ions to relocate to reduce the potential difference.

Big Whiskers have two methods of formation. The first way is that tin ions are able to move by becoming soluble in some form of water so they’re mobile. The other way whiskers can form is from stress alone. (Stress being force per area that compresses or tensions the metal in question, applied through a multitude of ways) Whiskers can be directed by electromigration so they form tendrils to a differing potential, basically purposefully ruining stuff instead of randomly shorting things.

Now in integrated circuits (ICs), there are extremely high currents running through extremely small regions. Electromigration in ICs is caused by electrons getting yeeted at extremely fast speeds, giving them significant momentum. They collide with ions in their path and dislodge the ions from their matrix. This can result in voids of ions preventing current from flowing (open circuits) or tendrils of ions making a path to an unintended area and connecting to it (shorting it). The tendrils here are also called whiskers, but are generated in a very different way (e.g., no water solubility or inherent stresses required) and on a significantly smaller scale. And probably not in tin.

The more you know!

In incus, I had the same setup of an LCX container with a Docker container inside of it. I passed 1000/1000 to the LXC container but the LXC container’s default root user has a an ID set of 0/0. So I had to pass 0/0 to the Docker container, not 1000/1000 to get the read/write permissions working.

That may fix your issue as it’s basically the same tech, just different automated things implementing the LXC container!

Good to know Proxmox’s bad updates are more pervasive than the latest bad update.

I have been able to install Docker in the LXC containers and pull images in with the normal commands. I do that container-in-container to get effectively rootless docker containers for stuff that I couldn’t figure out how to run rootless. So you don’t even lose out on docker if you’re determined! And as you said incus goes on any OS, you can docker just fine on the base OS of your choice and use incus for specific things!

Try a diff email if you do want one, a friend recently got one via email signup and wait a few weeks. But I do abs agree it fuckin sucks you have to do any of this effort to get one, it is just enabling scalpers

I do use it to hold internet-exposed things in LXC containers to sidestep having to figure out how to not run things as Docker root.

You do not need it for everything, but since it’s not an OS that makes it your everything, that’s ok! Run Docker containers as you need, put internet-exposed ones in an LXC container, put home assistant in a VM because it’s special.

Ah, I was wondering which one you updated and it made your containers inaccessible!

You have to sign up for the in stock notifications, annoying but it works in a delayed fashion. Sad it does enable scalpers.

Incus or Proxmox (e.g., should I shift to Incus LTS or something?)

Incus is way easier to work with than Proxmox, and it sits on your OS of choice instead of being the OS you must use. For home use it’s way easier to use with the web ui, it even has clustering if you want to go hard.

So you can install Incus when you want a VM/LXC container and not have to commit to a VM/LXC container OS from the start.

Also Proxmox free just had a bad update that björked some stuff if you updated when it was live. Proxmox free is rolling and apparently lacks basic sanity checks for updates.

Your budget is really near a https://store.ui.com/us/en/collections/unifi-dream-router/products/udr Unifi dream router. Your family is gonna be way happier with you (0 downtime) and it’ll give you extender options if you ever need it. Unifi is good enough and they update regularly, just disable cloud access stuff and you’re good.

Otherwise you want Opnsense instead of Openwrt. The upgrade process for Openwrt is not automatic, while Opnsense is. Worth it not to have to dote on your router.

And you should get an access point (Unifi something or Tplink Omsomething), wifi is problematic with openwrt and I’m not sure if opensense even lets you do it (haven’t tried).

And you’ll need a switch, dumb or managed, up to you if you want VLANs. The Opnsense box will have just one LAN port, so it requires a switch if you want to plug more than one thing into it. A switch with PoE+ can power the access point directly.

Opnsense needs x64 arch (Intel or AMD CPUs), get a small thin client like a Dell Wyse 5070 extended or HP T730 or that mentioned Fujitsu Futro S720 (its CPU is old tho, you can do better). There may be newer thinclients, you just want a mini PCIe slot to install some Intel gigabit card from eBay with 2 ports. Google power efficient gigabit mini PCIe card - there’s an older model that sucks power and a newer one that doesn’t suck; if you go more than gigabit skip 2.5 on Intel unless you google hard and expect extra power draw. Very limited point to 4 port cards, just go higher gigabit speeds don’t think about multiplexing ports or whatever it is called; and switches switch better than the router can and remove CPU overhead for more actual routing work - 2 port card is the way.

Slap Incus (superior but newer, less guides, LXD is previous name if googling stuff) or Proxmox (good enough, more guides for this) on it, make a VM and pass through the 2 ports of the PCIe cards, slap Opnsense in the VM. Make an LXC container and slap Debian on it and spin up the Unifi controller for your AP. Another container for adguard home or pi hole and you’ve got a box that does the basic nets all in one. The built-in port on the thin client is how you will access the underlying OS, it gets plugged into the switch you’ll have to get. If you got something with 2 gigs of RAM and an AMD Geode/GX or aged Intel Atom CPU I’d just only do Opnsense no hypervisor stuff.

Sorry for the info dump but there’s a lot of angles!

But really, the Unifi dream router is much easier and solves it all-in-one. You need 3 pieces (router, wifi access point, Ethernet switch) for a good experience otherwise.

It looks like regular PSUs are isolated from the mains ground with a transformer. That means that two PSUs’ DC grounds will not be connected. That will likely cause problems for you, as they’ll have to back flow current in places that do NOT expect back flow current to account for the voltage differences between the two ground potentials. Hence it might damage the GPU which is going be the mediator between these two PSUs - and maybe the mobo if everything goes to shit.

Now I am not saying this will be safe, but you may avoid that issue by tying the grounds of the two PSUs together. You still have the issue where if, say, PSU1’s 12V voltage plane meets PSU2’s 12V voltage plane and they’re inevitably not the same exact voltage, you’ll have back flowing current again which is bad because again nothing is designed for that situation. Kind of like if you pair lithium batteries in parallel that aren’t matched, the higher voltage one will back charge the other and they’ll explode.

Old AMD cards can be flashed with any BIOS that says anything. Maybe the card was used for a scam and flashed to say it’s an RTX 2070, it should have a switch to go to its 2nd BIOS near the top left (when slotted in). And if it doesn’t, you can just get its original BIOS off of Techpowerup’s database and flash it with atiflash, also from Techpowerup.

Picture stolen from some Reddit help thread for a red dragon RX 580.

This is assuming that Linux is reading what the card claims it is correctly. Which seems likely, since reading device IDs is a really important feature that probably works nearly perfectly.

It accomplishes the same thing as Proxmox (VMs and LXC containers, which are “lite VMs” for if you wanted a Linux VM), I recently learnt about it too! It is new, but it was backed by Canonical up until the LXD/Incus split so it’s very solid. Split because Canonical tried to control LXD heavily, so they forked and renamed it Incus.

I just used Incus and it’s very nice, use the profiles to create a profile for “GPU pass through” and “macvlan”, among others you’ll find you want. Then make instances as needed! It was easier for me to use than Proxmox.

First try an HDMI dummy plug, in case the thing doesn’t dig no screen (classic intel firmware)

Then try Debian + Incus, less Proxmox shims to go wrong. Install Incus via the “zabby” repo mentioned on the incus install page. Search for “LXD” if Incus help/guides aren’t enough for you, they’re the same thing (for now). Providing an ISO in Proxmox is really clunky, and incus smooths that out so nicely. And again, less Proxmox shims to go wronk