cross-posted from: https://linkage.ds8.zone/post/848773

Past couple days connection attempts to snickket hosts give “login failed” instantly w/out further details. Just me?

This post got over 50 comments a couple yrs ago:

https://linkage.ds8.zone/post/367822

Looking through the comments shows a strong bias in favor of centralization. Is it fair to say the masses in the fedi are merely anti-GAFAM? Considering how people pile onto a Cloudflare node (lemmy.world), the fedi is indeed mostly composed of those who do not resist network effect. Choosing the most evil node of a less evil network still reflects a problem.

We need to evolve more. We need a platform that does more to thwart centralized power. The network needs to build in a penalty for disproportionately large nodes w/a single point of influence. And there should be a built-in mitgating mechanism to keep Cloudflare out, as Cloudflare is inherently centralized to the most abusive extent.

Past couple days connection attempts to snickket hosts give “login failed” instantly w/out further details. Just me?

Rationale:

• The db currently tracks “has_captcha”. Cloudflare influences that regardless of whether the site is itself configured to push a CAPTCHA.
• The db currently tracks “open_registrations”. The degree of openness depends on whether a node is on Cloudflare, regardless of how the software is configured.
• Checking for Cloudflare is free. That is, no extra connections are needed. It’s simply a matter of checking for the presence of CF-RAY in the http headers on existing fetches.
• The mission purpose of fediseer is to facilitate trust assessment. The use of Cloudflare is a significant factor in that regard.

cross-posted from: https://linkage.ds8.zone/post/724293

Wireapp has been a non-stop running goat fuck for years. The incompetent devs finally have a Debian procedure (here). It’s unclear if they are still pushing bloated Electron junk. But they seem to think banning Tor is not bad for optics in the deployment of a comms app pitched for security-minded folks. I modified their instructions to give:

 $ echo "Types: deb
URIs: tor://wire-app.wire.com/linux/debian
Suites: stable
Components: main
Signed-By:
$(torsocks wget -O- tor://wire-app.wire.com/linux/releases.key | sed -e 's/^$/./' -e 's/^/ /')" | sudo tee /etc/apt/sources.list.d/wire-desktop.sources

Notice I used the tor:// scheme instead of https://. Doing aptitude update gives:

E: Failed to fetch tor://wire-app.wire.com/linux/debian/dists/bookworm/InRelease  403  Forbidden [IP: 127.0.0.1 9050]
E: The repository 'tor://wire-app.wire.com/linux/debian stable InRelease' is not signed.

cross-posted from: https://linkage.ds8.zone/post/543756

This seems quit serious because there is a security issue when one app can interfere with another.

If Ungoogled Chromium is running when Nheko launches, U/C instantly freezes. No i/o is possible with U/C. Then when Nheko is quit, U/C goes down with it.

cross-posted from: https://linkage.ds8.zone/post/515550

Folks— Most Lemmy client apps are on the phone. I am looking for a FOSS phone app that works offline. That is, the phone has no data plan and only occasionally connects to public wifi hotspots. I do not want to be entering login passwords and reading and writing posts when I am connected. Reading and writing posts interactively needs to happen offline. Typical workflow: when I meet people at a bar/cafe, I need the app to sync over the public wi-fi without using my attention. It should post my comments and fetch threads for which I am active, for offline access later. It needs to support multiple accounts spanning multiple instances.

Does anything like this exist? Or do all Lemmy/kbin/mbin phone apps demand your realtime attention when connected?

cross-posted from: https://linkage.ds8.zone/post/523771

Before posting an image to the fedi, I want to be mindful about the network burden it will cause. I’m only uploading the image once but potentially thousands of people could end up downloading it.

If it’s a color image, then JPG is typically best. This #ImageMagick command reduces the filesize quite a bit, trading off quality:

  $ convert "$original_image_file" \
    +dither \
    -posterize 8 \
    -sampling-factor 4:2:0 \
    -strip \
    -quality 75 \
    -interlace Plane \
    -gaussian-blur 0.05 \
    -colorspace RGB \
    -strip \
    smaller_file.jpg

If it’s a pic of a person, this processing will likely be a disaster. But for most things where color doesn’t matter too much, it can be quite useful. Play with different -posterize values.

If you can do with fewer pixels, adding a -resize helps.

  $ convert "$original_image_file" -resize 215x smaller_file.jpg

If you can get away with black and white, jpeg is terrible. Use PNG instead. E.g.

  $ convert "$original_image_file" -threshold 30% -type bilevel smaller_file.png

For privacy, strip the metadata

The ImageMagick -strip option supposedly strips out metadata. But it’s apparently not thorough because the following command yields a slightly smaller file size:

  $ exiftool -all= image.jpg

What else?

Did I miss anything? Any opportunities to shrink images further? In principle the DjVu format would be more compact but it’s not mainstream and apparently not accepted by Lemmy.

cross-posted from: https://linkage.ds8.zone/post/523771

Before posting an image to the fedi, I want to be mindful about the network burden it will cause. I’m only uploading the image once but potentially thousands of people could end up downloading it.

If it’s a color image, then JPG is typically best. This #ImageMagick command reduces the filesize quite a bit, trading off quality:

  $ convert "$original_image_file" \
    +dither \
    -posterize 8 \
    -sampling-factor 4:2:0 \
    -strip \
    -quality 75 \
    -interlace Plane \
    -gaussian-blur 0.05 \
    -colorspace RGB \
    -strip \
    smaller_file.jpg

If it’s a pic of a person, this processing will likely be a disaster. But for most things where color doesn’t matter too much, it can be quite useful. Play with different -posterize values.

If you can do with fewer pixels, adding a -resize helps.

  $ convert "$original_image_file" -resize 215x smaller_file.jpg

If you can get away with black and white, jpeg is terrible. Use PNG instead. E.g.

  $ convert "$original_image_file" -threshold 30% -type bilevel smaller_file.png

For privacy, strip the metadata

The ImageMagick -strip option supposedly strips out metadata. But it’s apparently not thorough because the following command yields a slightly smaller file size:

  $ exiftool -all= image.jpg

What else?

Did I miss anything? Any opportunities to shrink images further? In principle the DjVu format would be more compact but it’s not mainstream and apparently not accepted by Lemmy.

Before posting an image to the fedi, I want to be mindful about the network burden it will cause. I’m only uploading the image once but potentially thousands of people could end up downloading it.

If it’s a color image, then JPG is typically best. This #ImageMagick command reduces the filesize quite a bit, trading off quality:

  $ convert "$original_image_file" \
    +dither \
    -posterize 8 \
    -sampling-factor 4:2:0 \
    -strip \
    -quality 75 \
    -interlace Plane \
    -gaussian-blur 0.05 \
    -colorspace RGB \
    -strip \
    smaller_file.jpg

If it’s a pic of a person, this processing will likely be a disaster. But for most things where color doesn’t matter too much, it can be quite useful. Play with different -posterize values.

If you can do with fewer pixels, adding a -resize helps.

  $ convert "$original_image_file" -resize 215x smaller_file.jpg

If you can get away with black and white, jpeg is terrible. Use PNG instead. E.g.

  $ convert "$original_image_file" -threshold 30% -type bilevel smaller_file.png

For privacy, strip the metadata

The ImageMagick -strip option supposedly strips out metadata. But it’s apparently not thorough because the following command yields a slightly smaller file size:

  $ exiftool -all= image.jpg

What else?

Did I miss anything? Any opportunities to shrink images further? In principle the DjVu format would be more compact but it’s not mainstream and apparently not accepted by Lemmy.

LaTeX mode and pretty much any programming mode supports comments. In principle, comment blocks could really benefit from some org mode features, particularly a mechanism to collapse lengthy paragraphs and lists (like the markdown spoiler).

Or is there already a universal way to collapse text in code comments?

cross-posted from: https://linkage.ds8.zone/post/517080

I have over 700 street addresses that ultimately need to become a category or group of favourites in #OSMand. In the past I used a web service called something like nomenatum. I don’t think that option still exists. This article suggests batch encoding on this site, claiming it’s gratis but it looks like a costly subscription.

I must say that using a service to do the job of software is not a great idea. We have #OpenStreetMaps. In principle, OSM and a tool should be able to handle this offline without a service.

Of course it’s possible to search each address by hand in OSMand and then save the location. It would be absurdly labor intensive but it proves that a service is not needed, in principle.

Is there any way to feed a list of addresses to OSMand?

Or is there a linux app that can do this work, ideally offline?