Canadian software engineer living in Europe.
The term for this “vampire load” the power being consumed across a given network that’s doing literally nothing.
Those little LEDs are a tiny amount, but when they number in the millions, that shit adds up. People have calculated the cost in terms of tonnes of CO2.
At my first-ever tech job back in 2000, I was given a little Celeron desktop computer to do my work: mostly writing some ColdFusion and cutting up images in Photoshop. For the most part, the machine worked fine, except whenever I scrolled down on a webpage in Netscape, the box’s PC speaker would start screaming. I tried to ignore it, but I was in a small room with two other nerds and it was getting really annoying.
One day, my frustrated colleague decided it was time to investigate. As part of the process, he noticed that there was very little air coming out of the power supply fan port. “Must be a busted fan and that’s causing an overheating alarm” he declared. We unplugged the box, popped it onto my desk, and opened it up. The internals were pristine. No dust, nothing. The computer was practically brand new after all.
We were just about to crack open the power supply (not recommended, but we were getting desperate) when my colleague noticed that something was wedged inside the fan… it was the biggest (dead, thankfully) cockroach I have ever seen, at least 10cm long. For context, this was in Vancouver, Canada. Those just don’t exist there.
My colleague jammed his screwdriver in there to grind up the cockroach carcass, then plugged the box back in. After a shittone of dessicated cockroach guts spewed out the back, my little computer was operating normally.
As best we could guess, the monster crawled into the fan in Malaysia when as was assembled and somehow got pinned in there, died of starvation, and then stowed away to Canada.
There’s a nifty project on Mastodon where someone is running an instance entirely on solar (and I think a battery?). They’ve been tinkering with some of the code to do things like optimise images for reduced weight or CPU cost.
The project is called @solaradmin@solarcene.community and the account for the person running it is on a separate instance, presumably so people can message them about problems: @smallsolar@techhub.social.
The right time to look elsewhere was when Microsoft bought it.
The next best time was when viable alternatives like GitLab and later, Codeberg appeared.
The next best time was when it became clear that they were stealing your code to feed into their sparkly autocomplete and were going to sell it back to you.
The next best time was when they dumped a bunch of vibecoded garbage into the codebase and killed the uptime.
The next best time is now.
You don’t even have to migrate all your stuff. Just start all your new projects on Codeberg, or GitLab, or something self-hosted. Once you get used to the new place, you can migrate your old stuff when you’re ready.
That was great. This is why I subscribe here.
That’s very cool. Hopefully GNOME will steal this idea one day.
That won’t do in my case 'cause I need to share multiple windows throughout the session as I switch between my terminal/IDE/browser etc.
[I’ve now edited the initial question to reflect this]
The problem is that I need to switch workspaces rapidly as part of the share: terminal → browser → IDE → browser → IDE → terminal, etc. I can’t be constantly going back and toggling which window I’m sharing.
[I’ve now edited the initial question to reflect this]
I started using it 'cause I was working with a lot of Linux nerds and they convinced me to try it out. I liked the politics of the GPL and the potential in the Free ecosystem.
25 years later I refuse to use anything else. Windows & Mac are built to take options away from you, to force you do use your hardware their way, and I hate it. My machine does exactly what I want it to, with hundreds of keyboard shortcuts and a solid UI built atop transparent subsystems. Windows ties my hands while pushing ads and AI into my eyeballs. Mac only “Just Works” if you’re using it precisely the way that want you to and exclusively with other iShit. No thanks.
As this is your first go, I’d recommend not tinkering with USE flags at all. Take the defaults, find what you don’t like, and consider tweaks later. USE flags can end up like a sort of “dependency hell”, with one package not working correctly because it expects another package to have something you’ve excluded. It’s uncommon, but frustrating when it happens. It’s best to start with the defaults.
I like this alot.
How would you reset the timer whenever input is detected though?
I’ve had a really hard time figuring out how to get cloud native pg working 'cause I couldn’t get longhorn working for disk space.
So instead I went with a separate Raspberry Pi that isn’t part of the cluster to host a single Postgres instance.
It’s inelegant, but has worked for years. Still, I’d rather host a separate pg instance for each project… I just have to figure the above out first.
Ferengi rule of aquision #285: “No good deed ever goes unpunished”.
#Solarpunk!
This feels oddly specific, like there’s a famous map out there with Carter and a rabbit. Anyone know what he’s talking about?
Edit: I found the Wikipedia article about the incident, but no map yet.
I have Arch on my desktop, and all my laptops, but all of my servers run Debian. If you want your machine to have all the latest stuff, then Arch is great. If you want it to Just Work™ all the time without any concerns, Debian is great.
This would be much less of a problem if fewer people insisted on bringing their whole living room everywhere they go.
I’ve used FluxCD in the past and have looked into ArgoCD, but honestly, I’ve not seen any big benefit from either to be honest. I use k8s both at home and at work, and in both cases, we do “imperative” deploys: you run helm install ... either directly or via the CI and stuff is deployed.
So for example at my last job, our GitLab CI just had a section triggered exclusively for merges into master that ran helm install ... for all three environments. We had three values.yaml files, one for each environment, and when we wanted to deploy a new version, the process was:
1.2.3) and push it to the repo. This would trigger a build and push the resulting image into the container registry.1.2.3 to development but not yet to staging or production, then the tag: value in each of the environment files would look like this:k8s/chart/environments/development.yaml: tag: 1.2.3k8s/chart/environments/staging.yaml: tag: 1.2.2k8s/chart/environments/production.yaml: tag: 1.2.2Once that change is pushed, the CI will automatically apply it with helm install ... and make sure that all three environments are what they’re supposed to be.
As for dependent services, that should all be in your Helm chart so they’re stood up and torn down together. The specific case you mention about “Service A” being dependent on “Service B” but stood up before “Service B” is ready is a classic problem, but easily solved:
The dependent service (“A” in this case) should have an entrypoint that checks for everything else before starting. Here’s what I’m using right now in a project:
#!/bin/sh
while ! nc -z "${POSTGRES_HOST}" 5432; do
echo "Waiting for postgres..."
sleep 0.1
done
echo "PostgreSQL started"
touch /tmp/ready
exec "$@"
I’ve even got some code that checks that all the Django migrations have run first for the same situation. The Kubernetes philosophy is that any container should be able to die at any time and be eventually be brought back up and that every container needs to be prepared for this. Typically this means that your containers should operate on the basis of “if I can’t work, die, and hope the problem is solved by the time Kubernetes redeploys me”.
This wasn’t nearly as interesting as the headline made it sound.
It’s a physical box you purchase to effectively break the law, so some of the architecture is going to be shady because it has to be.
There’s nothing special or nefarious here. Indeed I’ve worked on projects that had to take the same considerations into account.
The “someone else’s Hulu account” claim sounds like bullshit to me because it doesn’t make sense from a business perspective. They’d want to control the accounts in question and rotate the passwords regularly, again to avoid freeloaders. More likely they’ve paid for 25ish Hulu subscriptions in every region (hence the initial call for IP geolocation) and are then relaying credentials to a box based on this info.
The only really sketchy thing in this whole video was the disabling of TLS checking, which was likely done to get around sketchy pirate websites with bad or nonexistent certs. It wasn’t clear though which part of the OS this applied to. If it’s only doing this for the pirate streaming, that’s sort of a bullet you have to take if you want the service. So long as the only data being sourced unencrypted/unverified is some audio and video, you’re fine (assuming you’ve already accounted for streaming such data in your jurisdiction, ie. you’ve got a VPN). If you’re pulling down software updates though, you’re gonna have a bad time.