big oof.

We can conclude: that photo isn’t AI-generated. You can’t get an AI system to generate photos of an existing location; it’s just not possible given the current state of the art.

the author of this substack is woefully misinformed about the state of technology 🤦

it has, in fact, been possible for several years already for anyone to quickly generate convincing images (not to mention videos) of fictional scenes in real locations with very little effort.

The photograph—which appeared on the Associated Press feed, I think—was simply taken from a higher vantage point.

Wow, it keeps getting worse. They’re going full CSI on this photo, drawing a circle around a building on google street view where they think the photographer might have been, but they aren’t even going to bother to try to confirm their vague memory of having seen AP publishing it? wtf?

Fwiw, I also thought the image looked a little neural network-y (something about the slightly less-straight-than-they-used-to-be lines of some of the vehicles) so i spent a few seconds doing a reverse image search and found this snopes page from which i am convinced that that particular pileup of cars really did happen as it was also photographed by multiple other people.

🥛🤝🦆

(it’s odd that PBS is promoting this, as it is actually a terf movement)

RedHat was a major military contractor with job postings like this current one [archive] long before they were bought by another older and larger military contractor.

https://en.wikipedia.org/wiki/IBM_and_World_War_II

https://web.archive.org/web/20240530005438/https://www.redhat.com/en/resources/israeli-defense-forces-case-study (original is 404 for some reason)

them: fedora is the lesser evil

me: but why do they have job listings like this [archive] with requirements like “This position requires daily on-site work at Fort Meade and an active Top Secret/SCI clearance with Polygraph” ? 🤔

Lets Enhance is a pretty great supercut, but nothing beats the original Blade Runner scene.

enhance 224 to 176

enhance, stop

move in, stop

pull out, track right, stop

center and pull back, stop

track 45 right, stop

center and stop

enhance 34 to 36

pan right and pull back, stop

enhance 34 to 46

pull back, wait a minute, go right, stop

enhance 57 to 19

track 45 left, stop

enhance 15 to 23

give me a hardcopy right there

The canonical documentation is https://www.kernel.org/doc/Documentation/filesystems/proc.rst (ctrl-f oom) but if you search a bit you’ll find various guides that might be easier to digest.

https://www.baeldung.com/linux/memory-overcommitment-oom-killer looks like an informative recent article on the subject, and reminds me that my knowledge is a bit outdated. (TIL about the choom(1) command which was added to util-linux in 2018 as an alternative to manipulating things in /proc directly…)

https://dev.to/rrampage/surviving-the-linux-oom-killer-2ki9 from 2018 might also be worth reading.

How to make your adjustments persist for a given desktop application is left as an exercise to the reader :)

I’m not sure what this comic is trying to say but in my recent experience a single misbehaving website can still consume all available swap at which point Linux will sometimes completely lock up for many minutes before the out-of-memory killer decides what to kill - and then sometimes it still kills the desktop environment instead of the browser.

(I do know how to use oom_adj; I’m talking about the default configuration on popular desktop distros.)

404 Media neglected to link to her website, which is https://ada-ada-ada.art/

I think it depends which side of the debate one is on?

$ systemd-analyze calendar tomorrow
Failed to parse calendar specification 'tomorrow': Invalid argument
Hint: this expression is a valid timestamp. Use 'systemd-analyze timestamp "tomorrow"' instead?
$ systemd-analyze timestamp tuesday
Failed to parse "tuesday": Invalid argument
Hint: this expression is a valid calendar specification. Use 'systemd-analyze calendar "tuesday"' instead?

ಠ_ಠ

$ for day in Mon Tue Wed Thu Fri Sat Sun; do TZ=UTC systemd-analyze calendar "$day 02-29"|tail -2; done
    Next elapse: Mon 2044-02-29 00:00:00 UTC
       From now: 19 years 4 months left
    Next elapse: Tue 2028-02-29 00:00:00 UTC
       From now: 3 years 4 months left
    Next elapse: Wed 2040-02-29 00:00:00 UTC
       From now: 15 years 4 months left
    Next elapse: Thu 2052-02-29 00:00:00 UTC
       From now: 27 years 4 months left
    Next elapse: Fri 2036-02-29 00:00:00 UTC
       From now: 11 years 4 months left
    Next elapse: Sat 2048-02-29 00:00:00 UTC
       From now: 23 years 4 months left
    Next elapse: Sun 2032-02-29 00:00:00 UTC
       From now: 7 years 4 months left

(It checks out.)

Surprisingly its calendar specification parser actually allows for 31 days in every month:

$ TZ=UTC systemd-analyze calendar '02-29' && echo OK || echo not OK
  Original form: 02-29
Normalized form: *-02-29 00:00:00
    Next elapse: Tue 2028-02-29 00:00:00 UTC
       From now: 3 years 4 months left
OK
$ TZ=UTC systemd-analyze calendar '02-30' && echo OK || echo not OK
  Original form: 02-30
Normalized form: *-02-30 00:00:00
    Next elapse: never           
OK
$ TZ=UTC systemd-analyze calendar '02-31' && echo OK || echo not OK
  Original form: 02-31
Normalized form: *-02-31 00:00:00
    Next elapse: never           
OK
$ TZ=UTC systemd-analyze calendar '02-32' && echo OK || echo not OK
Failed to parse calendar specification '02-32': Invalid argument
not OK

Funny that blog calls it a “failed attempt at a backdoor” while neglecting to mention that the grsec post (which it does link to and acknowledges is the source of the story) had been updated months prior to explicitly refute that characterization:

5/22/2020 Update: This kind of update should not have been necessary, but due to irresponsible journalists and the nature of social media, it is important to make some things perfectly clear:

Nowhere did we claim this was anything more than a trivially exploitable vulnerability. It is not a backdoor or an attempted backdoor, the term does not appear elsewhere in this blog at all; any suggestion of the sort was fabricated by irresponsible journalists who did not contact us and do not speak for us.

There is no chance this code would have passed review and be merged. No one can push or force code upstream.

This code is not characteristic of the quality of other code contributed upstream by Huawei. Contrary to baseless assertions from some journalists, this is not Huawei’s first attempt at contributing to the kernel, in fact they’ve been a frequent contributor for some time.

Wasn’t Huawei trying to put a Backdoor into linux?

as far as i know, that has not happened.

what makes you think it did?

fremdscham++ 😬

headline was more exciting before i read the last four words of it

i can’t help but wonder if there isn’t some more useful science that these scientists could be doing (i write, while reading garbage on the internet)

Or you could just… learn to use the modern internet that 60% of internet traffic uses? Not everyone has a dedicated IPv4 anymore, we are in the days of mobile networks and CGNAT. IPv4 exhaustion is here today.

Where are you getting 60%? Google’s IPv6 Adoption page has it under 50% still:

(while other stats pages from big CDNs show even less)

If you have ::/0 in your AllowedIPs and v6 connections are bypassing your VPN, that is strange.

What does ip route get 2a00:1450:400f:801::200e (an IPv6 address for google) say?

I haven’t used wireguard with NetworkManager, but using wg-quick it certainly adds a default v6 route when you have ::/0 in AllowedIPs.

You could edit your configuration to change the wireguard connection’s AllowedIPs from 0.0.0.0/0 to 0.0.0.0/0,::/0 so that IPv6 traffic is routed over it. Regardless of if your wireguard endpoint actually supports it, this will at least stop IPv6 traffic from leaking.

ipv4 with an extra octet

that was proposed as “IPv4.1” on April 1, 2011: https://web.archive.org/web/20110404094446/http://packetlife.net/blog/2011/apr/1/alternative-ipv6-works/

The article text doesn’t support the headline (“Biden helped end the dockers strike by saying reopening the ports to help Hurricane Helene victims would be patriotic”):

“ With the grace of God, and the goodwill of neighbors, it’s gonna hold,” President Joe Biden told reporters Thursday night after the agreement.

In a statement later, Biden applauded both sides “for acting patriotically to reopen our ports and ensure the availability of critical supplies for Hurricane Helene recovery and rebuilding.”

[…]

Thursday’s deal came after Biden administration officials met with foreign-owned shipping companies before dawn on Zoom, according to a person briefed on the day’s events who asked not to be identified because the talks were private. The White House wanted to increase pressure to settle, emphasizing the responsibility to reopen the ports to help with recovery from Hurricane Helene, the person said.

Acting Labor Secretary Julie Su told them she could get the union to the bargaining table to extend the contract if the carriers made a higher wage offer. Chief of Staff Jeff Zients told the carriers they had to make an offer by the end of the day so a manmade strike wouldn’t worsen a natural disaster, the person said.

By midday the Maritime Alliance members agreed to a large increase, bringing about the agreement, according to the person.