WaterWaiver @ WaterWaiver @aussie.zone

I once met a person that never drank water, only soft drinks. It's not the

---

Read more

Posts

12

Comments

276

Joined

2 yr. ago

USB/2.0 (4.0; Gen 2; rv:1.1) USB4.1 Gen 3x3 (FIREWIRE, like RS232)

Ah thanks, sorry, I was thinking of my MK3.

Are you turning off the magnetic ABL, or using it through the garolite?

So this problem is intermittent? Eep. If you're lucky enough to be able to capture a video of the full home and print start when the problem occurs then that might help; but that might be difficult.

Those security features are misleading.

A second app can already read all of your files, modify the first app, modify $PATH to replace your display server and do anything it wants as your user. Running wayland instead of Xorg provides no tangible benefits in security.

Can't understand sigils. Printer was cursed. Makes sense.

I am not so sure that it will end up faster or better.

**In theory: **A CPU scheduler should give programs as much CPU time as they want until you start nearing CPU resource saturation. Discord doesn't need very large amounts of CPU (admittedly it's a lot more than it should for a text chap app, but it's still not diabolically bad). It will only start getting starved when you are highly utilising all cores. That can happen on my 2-core laptop, but I don't have any games on my 6 core desktop that will eat everything. Nonetheless on my laptop I'd probably prefer my games take the resources (not Discord) and I'd happily suffer any reasonable drop in responsiveness of Discord as a result.

I don't think that a new process (a new dedicated browser-client) instead of a new thread (tab in existing browser) is intrinsically faster or better. CPU schedulers are varied and complex, I wouldn't be surprised if any differences in performance measurements would end up down in the noise. If anything the extra memory usage might cause more IO contention and memory starvation, making everything slower rather than faster. But this is all conjecture, so don't give it much credit.

Basically, it’s faster to focus on painting a single canvas than it is to painting 3 at the same time.

I don't think that's much of a problem in practice, at least for Firefox: one tab can crash and stop rendering completely (or lock up 100% of 1 CPU core) but the others will keep going in other threads. For the most part they shouldn't be able to affect each other's performance.

In practice: What's the actual metric that you think will be better or worse? I assume responsiveness to typing and clicks in the discord UI?

I've never seen discord lag or stutter from causes other than IO limitations (startup speed, network traffic, heavy IO on my machine) or silly design (having to refresh the page after leaving it open all day, I suspect it's intentionally auto-disabling but I'm not sure). That's not something that running a separate discord client in a separate dedicated/embedded browser will fix.

https://halestrom.net/darksleep/blog/054_nvme/

Summary: two Silicon Power P34A80's died within a few months of use, the second one was the warranty replacement of the first. In both cases sectors suddenly became permanently unreadable.

Eat bad food, wake up with your wallet stolen.

Yay. It's so much nicer to go through these routes, especially when the have extra info. Youtube just wants you to watch more junk.

Gamersnexus used to do this, then they just abandoned their site. I think they're using it again now but as a companion, it doesn't link to their videos?

"Thou has missed daily prayers for two whole weeks"

My father was recently commenting about the lack of coverage of Israel-Gaza, Russia-Ukraine and even the Qld floods on the ABC. He was going to DW and finding more there about even the Qld floods than on the ABC.

I looked and the ABC was all royals stuff.

Smart locks are worse. They have all the insecurity of a regular lock, plus more methods of insecurity, plus more failure modes that will shut you out of your house.

In Kerbal Space Program your ships sometimes catch the NaN virus. If one fuel tank level is reading NaN then whatever you do DON'T try and fill it from another (full) tank. I'm not sure if it can spread to physics (thrust, mass, etc) EDIT: Yes it can happen to physics, oh dear.

I wonder what would happen if you landed a NaN-infected spaceship on a planet.

"The formerly successful website known as Twitter"

Transactions per second. Bitcoin is slow and expensive to get your transaction "approved".

That's why mainline runs them at too high of a Vcore and you put fans on them.

My case for it was dealing with proprietary sensor devices with ethernet ports and garbage firmware. They could work if your server was on a different subnet, but a bunch of stuff broke (including the config tool) if you were not on the same ethernet LAN. The L2 tinc VPN allowed us to fix things without needing to walk around to the dozens of devices in a building with an ethernet cable, laptop and a ladder.

The firmware (& vendors) of the devices that we spent over 100K on were garbage in so many ways. One product's proprietary server software would misbehave (read: open files but never close them, after a time running out of file descriptors) which would then cause its fleet of individual sensors to all start SYN flooding it. Another brand's device model required us to spend lots of time manually updating them through every version of firmware because you were not allowed to jump straight to the latest version. I think it took an hour to complete the process for each unit (during which they'd get really hot and presumably throttle).

A bonus of tunnelling things back to our server over tinc was that everything was now encrypted. I used cheap GL.inet "mango" routers running OpenWRT to backhaul the sensors over the existing shared wifi network (rather than needing dedicated copper or wired VLANs). They worked almost like magic -- a weird wifi stack reliability issue required me to write a watchdog that rebooted them, however, otherwise we were back on ladders every few days :| But once that pain was over things overall worked much better.

Aside: Don't buy ANY off-the-shelf sensor product without first:

1. Confirming that you're not tied to their proprietary server software. Them claiming that they speak an open protocol is NOT enough.
2. Buying a few to actually test the above AND reliability over the span of at least a week's operation AND that they're not just outright lying about the device's accuracy/reliability/usefulness/etc

I made the mistake of being on holidays when the decisions on what to buy were made :P I ended up designing and building some of our sensor devices (somehow at a cheaper price even including my labour) that worked better for us, but shortly afterwards the funding ran out and I got a job elsewhere.

Not quite the same thing, you can't do layer 2 VPNs on wireguard (I ended up using tinc for that on a previous project, it worked well). For layer 3 however it's really good. Fast, simple, reliable, client works well on the platforms I've tried so far.

Never use an SoC that's not at least 5 years old ;)