• 0 Posts
  • 13 Comments
Joined 1 year ago
cake
Cake day: April 30th, 2025

help-circle
  • Could be QOS or packet shaping going on at your ISP, or just throttling or congestion. Speed tests only really test for typical traffic patterns, so will give you a warped view: it certainly disagrees with your observed measurements. There are lots of factors that can affect how quickly traffic passes between two hosts on the internet, but domestic broadband is generally the worst of all worlds - you usually share bandwidth with other subscribers, and although the throughput can be quite good, the latency and error rate can be quite bad, and you can get fragmentation as frame sizes can differ between network segments, causing buffering especially when congestion is occurring. Your ISP might also have deprioritised your type of traffic, or they might be dropping packets, which causes retries, and thus slows your connection down.


  • Digital ads do not promote things I’m interested in buying. I do not see ads very often at all - I haven’t had a TV for 20+ years, I don’t go to cinemas, so I don’t even see those kinds of ads. Occasional ads on YT pop up, and I’ll skip them; if they are unskippable or too frequent, I’ll abandon the vid. I’m not on any commercial “social media”, so I don’t see ads on them either. I’ve just never liked social media - Lemmy and Mastodon are all I use these days.

    Occasionally, very, very occasionally, I’ll see a meatspace ad that I pay attention to: there’s a local alternative music collective that wheatpaste ads around in a nearby town. I actually WANT to know about these events, and I will actually go to them, and I actually sought them out in the first place. I also see ads at my local community centre, for local events. Same kind of thing.

    So how is this resistance futile?



  • You mean in the context of high availability?

    tl;dr: It’s to test if the cluster fail-over configuration is working properly.

    So this was before things like Kubernetes or Terraform were a thing, so had to be done by the operating system itself. The simplest HA cluster is made of two nodes, one in “active node”, the other “passive”. The active node does all the work, and the passive node just keeps its data synchronised with the active node. I used to use DRBD for this, which is a system for copying writes to the active node over a network link to the passive node. That only gives you a “second, up-to-date copy” which is not that useful on its own - you also need a way to automatically switch over to using the passive node if the active one “dies”, and for that I used to use “heartbeat”, which simply passes packets back and forth between the two cluster members - ping-pong style - and if the passive node notices that the active node hasn’t sent its scheduled packet for, say, 10 seconds, it cuts it off the current active node (kills it), and promotes itself to the active role, thus preserving the service. Killing the “other node” is necessary to stop data corruption or user requests going to a node that can’t actually service them, and is called STONITH - Shoot The Other Node In The Head. STONITH can involve an electronically controlled switch, which literally cuts off power to the “other” node, or can isolate it on the network, by shutting down its network ports on the switch, or in a VM setup, sending a notification to the hypervisor to kill the VM.

    The reason you need to be able to kill the kernel on the active node, is that when you manually shut down the active node, it automatically informs the passive node that it’s going down, known as an “orderly fail-over”, and you’re not actually testing if the heartbeat fail-over works, you’re just testing an orderly fail-over. Killing the active node’s kernel tests that the passive node is properly configured to take over during a catastrophic failure of the active node. You can watch the heartbeat status go from “up” to “down”, and then see the passive node decide to take over, promote itself and bring up its services, and begin processing requests.

    To make sure it’s all working, you need to test orderly fail-overs first, from both nodes, then test disorderly fail-overs both ways, by using the kernel gun on the active node.

    Things moved on from Heartbeat-based HA clusters to multimode clusters managed by Corosync and other software, enabling other strategies to be employed. This was eventually supplanted by “orchestration” systems like Kubernetes, and proprietary Virtual Cloud systems that move this functionality to the platform rather than the operating system.


  • Nah man. “kill” doesn’t shut the system down quickly. This is the “instant death” way - the kernel reset gun - no shutdown scripts, no disk sync, just reset to BIOS boot sequence, instantly:

    As root:

    echo 1 > /proc/sys/kernel/sysrq

    echo b > /proc/sysrq-trigger

    If you change out the “b” in the second command for “o” it will just halt the kernel instead of rebooting. Still switched on, but the system is doing absolutely nothing.

    I used to use this trick all the time to test high availability server clusters.




  • cybervegan@lemmy.worldtomemes@lemmy.worldSay it ain't so
    link
    fedilink
    arrow-up
    6
    arrow-down
    2
    ·
    26 days ago

    I learnt to “type” when I was at school, programming a Commodore Vic-20. I thought I was quite fast, but what I had really learnt was just the key combos for common words. It’s what most people who have never learnt properly before do, and it’s called “point and poke”. You don’t realise the extra effort you’re putting in, and the mistakes you’re making (overuse of the backspace key) and so on.

    When I went to college at 16 (UK) to study computer science, we had the option of learning touch typing. We all thought we were pretty good at typing, but afterwards, we’d all doubled our typing speed (or more) and increased our accuracy by 10x. We learnt on proper electric golfball typewriters, and as we got better, we all noticed that code entry got a lot faster. The thing that is affected most, though, is typing up from notes or printed copy - because you don’t have to keep looking away from the source, back to the keyboard and screen, you can be much quicker. Also, typing your thoughts is much faster as you are not having to split your attention between the thoughts and the keyboard - what you think just appears on the screen without having to spend mental effort on typing.



  • Can confirm. Back at the beginning of my IT career (mid 1980’s), I worked as a temp for a computer manufacturer in their refurb repairs department. In those days, kit was so expensive that everything got repaired if it went wrong, and one of my jobs was repairing keyboards - PC keyboards, and dumb terminal ones - and the first part of the process was stripping and cleaning them. There was a lot more room for crumbs and dust back then, too, and man did they get full. Crumbs, staples, paper clips, hair grips, all sorts. I had literal mould growing in some of them. I remember the ones coming in from Italy were the worst for that for some reason.