y0din

There are many good answers here already, just wanted to add to it.

It sounds very much like what you’re seeing could be either a driver fault or a memory-related issue. Both can manifest as hard system freezes where nothing responds, not even Ctrl+Alt+Fx or SysRq. You mentioned this briefly before, and that still fits the pattern.

If it’s a driver issue, it’s often GPU or storage related. A kernel module crashing without proper recovery can hang the whole system—especially graphics drivers like NVIDIA or AMD, or low-level I/O drivers handling your SSD or SATA controller. Checking dmesg -T and journalctl -b -1 after reboot for GPU resets, I/O errors, or kernel oops messages might reveal clues.

If it’s memory pressure or the OOM killer, that can also lock a machine solid, depending on what’s being killed. When the kernel runs out of allocatable memory, it starts terminating processes to free RAM. If the wrong process goes first—say, something core to the display stack or a driver thread—you’ll see a full freeze. You can verify this by searching the logs for “Out of memory” or “Killed process” messages.

A failing DIMM or a bad memory map region could also behave like this, even if Windows seems fine. Linux tends to exercise RAM differently, especially with heavy caching and different scheduling. Running a memtest86+ overnight is worth doing just to eliminate that angle.

If your live USB sits idle for hours without freezing, that strongly hints it’s a driver or kernel module loaded in your main install, not a hardware fault. If it does freeze even from live media, you’re probably looking at a low-level memory or hardware instability.

The key next steps:

Check system logs after reboot for OOM or GPU-related kernel messages.

Run memtest86+ for several passes.

Try a newer (or older) kernel to rule out regression.

If it’s indeed a driver or OOM event, both would explain the “total lockup” behavior and why Windows remains unaffected. Linux’s memory management and driver model are simply less forgiving when something goes sideways.

Subtitles are not always simple text files in the source. They can come in various formats like SRT, WebVTT, Teletext, and VobSub—if they are present at all.

To integrate them into WebM, you must first determine if they exist, ensure they have the correct language tags (and tag them properly if they don’t), then extract them, convert them into a format compatible with the player, and finally remux them alongside the video and audio. This process can easily fail in an automated workflow if any of these conditions are unmet or if the subtitle format is incompatible.

Given this complexity, it’s understandable why many choose to avoid the effort rather than addressing whether WebM supports subtitles.

I am not defending anyone, but the process of it all makes it understandable, at least for me.

Alright, let’s get into the nitty-gritty of Duckpower.

First, let’s settle the “waddling vs. flying vs. swimming” debate. Horses aren’t big on flying, so we’re talking waddling power here. Until someone locates a Pegasus, we’re limited to the traditional land-bound horsepower. If you want swimming power, I guess you’d need to measure a seahorse?

Now, here’s where it gets serious: according to the brilliant minds at Art of Engineering, we can calculate Duckpower using a clever formula. They took the mass of a duck, compared it to a horse, and ran it through Kleiber’s Law. The answer? One horsepower = 131.2 Duckpower. So, back to our math:

3 horsepower = 3 x 131.2 Duckpower = 393.6 ducks waddling their hearts out.

But wait! We probably don’t need all 393.6 ducks if we give them some solid shift schedules. Horses only get 3 HP so two can rest; following this logic, we’d only need around 100 well-rested ducks, provided they get naps and stay hydrated.

So, let’s optimize our duck workforce with a shift schedule. Assuming we only need 100 ducks, here’s the plan:

Duckpower Shift Schedule:

Total Ducks: 100

Working Ducks per Shift: 25

Shift Duration: 2 hours on, 6 hours off (plenty of time for snacks and naps)

In a day, we’d run 4 shifts like this:

1. Shift 1: 25 ducks start strong at 8:00 AM, waddling with purpose.

2. Shift 2: Fresh 25 ducks take over at 10:00 AM while Shift 1 ducks hit the ducky lounge for snacks and a nap.

3. Shift 3: At 12:00 PM, another 25 ducks clock in to keep those wheels turning.

4. Shift 4: Finally, at 2:00 PM, the last 25 ducks take over while the others catch up on R&R.

With this cycle, each duck works only 2 hours out of every 8, staying energized, waddling at peak efficiency, and ready for action.

TL;DR: 3 horsepower = 393.6 ducks waddling but if we set up a 4-shift system, we can pull this off with only 100 ducks working 2 hours each, plus snack breaks.

3 horses = 3 horsepower, which translates to a whopping 393.6 Duckpower.

Honestly, why are we still using horses as the standard here? Ducks are clearly the superior metric. So if you’re like me and prefer a more feathered approach, just remember:

3 horses = 3 horsepower = 393.6 ducks You’re welcome.

(PS: Just imagine 393.6 ducks handling 10Gb… now that’s efficiency.)

Er jo en hel Lemmy instans for Danmark her, så det finnes nok flere av osw, og ja, jeg er fra Norge 🙂

Håper det ordner seg når du får installert ny font når du har tid og anledning til det 🙂

replying to myself here, but also, if this where supposed to work, which I doubt it will because it’s not feasible with tcpip, your second router would need to have the first router as gateway, but that is not possible when they are on the same subnet, and also your router will most likely not allow it because nat/routing will break, but if this was possible, devices behind your second router would not be able to connect to the devices before and vice versa, because since they have the same subnet, the traffic is considered local and not going through the router, and therefore the will not see each other as the NAT provides a separation between the networks…

you cannot use a router as a switch without using routing and different subnets … so … you might want to reconsider your design

Might be conflicts due to several routers using the same subnet… could cause some interesting ARP issues for the switches, and also DHCP conflicts if something is wrongly cabled / configured.

I would try disconnecting everything from after the first switch, connect a computer there to see if it works ok, then reconnect and test behind each step to see where it breaks instead of checking in the end where the problem could be agitated from a issue earlier in the network…

also, if the router has a firewall/nat you will not be able to reach anything behind it, even if there are different subnets being used… to be able to reach devices behind a router, the network would need to be routed and not nat’ed as nat combines all network traffic into the IP of the router before sending the traffic away, so clients on the other side has no way of knowing who or where the traffic came from after the nat’ed router.

I suggest you read up about this if you are not familiar with difference between NAT and routed traffic.

anyway, this is just my theory, hope you find your problem and get it sorted :)

(edit added part about nat)

you’re welcome :)

or since you probably are from Denmark since you mentioned Danish in your other comments:

🇩🇰 bare hyggelig, og håper du fikk løst problemet ditt 🇳🇴

thank you :)

not to be that guy . but have you tried to search for an answer?

https://github.com/flatpak/flatpak/issues/4435

first hit on “flatpak question marks”… it’s due to the font you use in the terminal does not support or not fully support Unicode characters or your locale settings are not correct.

hope this helps and answers your question :)

(edit, lost part of a sentence)