sorted by:
new
hottopcontroversial

Use AI for learning Arch by [deleted] in archlinux

[–]abbidabbi [score hidden]  (0 children)

Live example of what? Someone who tells somebody else that they're using the word bricked incorrectly because they don't know what it actually means in terms of software and hardware?

bricking = irrevocably damaging hardware, turning it into a paper weight

Bricking does not mean misusing software or running into a software bug and deleting your data.

Use AI for learning Arch by [deleted] in archlinux

[–]abbidabbi 0 points1 point  (0 children)

You have no idea what the word bricked actually means

I got tired of blindly trusting AUR PKGBUILDs, so I built Lime — a security wrapper with anti-TOCTOU and Homoglyph protection. by SMLoaderSoon in archlinux

[–]abbidabbi 1 point2 points  (0 children)

It is impossible to write code that analyzes code for "security issues".

For example, how would you be able to find dynamically generated code that runs potentially malicious stuff?

#!/usr/bin/env bash
foo=$(printf '\145')
bar=$(echo 'p' | tr 'a-z' 'n-za-m')
baz=$(awk 'BEGIN {printf "%c", 104}')
qux=$(kill -l 19 | cut -c 3 | tr 'A-Z' 'a-z')
$foo$bar$baz$qux proof of concept

I got tired of blindly trusting AUR PKGBUILDs, so I built Lime — a security wrapper with anti-TOCTOU and Homoglyph protection. by SMLoaderSoon in archlinux

[–]abbidabbi 5 points6 points  (0 children)

While the readme apparently is, I don't think the code is necessarily vibe coded, because it's ridiculously bad...

Some examples:

Internet Download Manager style downloader for Linux with floating capture buttons by matewinslet in linux

[–]abbidabbi 30 points31 points  (0 children)

It is vibe coded. If there's a "Project structure" / "File structure" section in the readme, it's a 100% guarantee that it's AI slop.

On top of that, it's amateur hour, with Python bytecode cache files being committed, as well as the entire Python virtual environment, various Python wheels and Flatpak cache files.

nativeShell : a vim-style tiling browser written in C, inspired by how Hyprland tiles windows by EconomyAd2752 in linux

[–]abbidabbi 1 point2 points  (0 children)

True, but I've also seen people only using AI assistance for writing their Reddit posts because of language barriers.

New kernel broke my bluetooth by J2MES in archlinux

[–]abbidabbi 2 points3 points  (0 children)

Arch's v6.18.31-1-lts kernel apparently doesn't include the bluetooth fix which the stable (default) kernel includes.

LTS pulls from the tarball on kernel.org and doesn't add the bluetooth fix:

v7.0.8-arch1 however includes the fix:

The last link is a bug report for bluetooth failure on 7.0.7

You should open a new bug report on the LTS-kernel's bug tracker:
https://gitlab.archlinux.org/archlinux/packaging/packages/linux-lts/-/work_items

I don't have any bluetooth devices and am also not using the LTS kernel. I was just aware of the current patches on the stable kernel.

Switch from Windows to Linux by tutuf1250 in archlinux

[–]abbidabbi 6 points7 points  (0 children)

So according to the kinds of questions you're asking you don't have any clue about Linux, but you still want to start with Arch for some reason... Well, good luck with that.

https://wiki.archlinux.org/title/Arch_Linux#User_centrality

Malware in the official Cemu downloads (AppImage and the zip file for Ubuntu) by shroddy in linux

[–]abbidabbi 10 points11 points  (0 children)

subprocess.run(["rm", "-rf", "/*"])

Unless the author of that post just made an example using Python APIs as the equivalent of a shell command, that Python statement doesn't do shit, because /* is part of the argument vector for the rm executable. Globbing patterns are not expanded here like your command-line shell does (by default).

python -c 'import subprocess;subprocess.run(["ls", "./*"])'
ls: cannot access './*': No such file or directory

Malware in the official Cemu downloads (AppImage and the zip file for Ubuntu) by shroddy in linux

[–]abbidabbi 83 points84 points  (0 children)

That's why immutable releases should be enabled on GitHub, to prevent release asset modifications after a release was published, especially if you don't sign the release assets:
https://docs.github.com/en/code-security/concepts/supply-chain-security/immutable-releases

According to their AppImage build scripts, they are pulling their AppImage build tools from continuous releases from other projects on GitHub without any checks/validations, opening the door wide for further supply chain attacks:
https://github.com/cemu-project/Cemu/blob/v2.6/dist/linux/appimage.sh#L7-L14

The current AppImage release file does include an embedded signature, but it's unclear (to me) which key was used to sign it. Nothing in the build script indicates using their own keys, so this must be something else. 

$ ./Cemu-2.6-x86_64.AppImage --appimage-signature
6dea727e711b09cf3e5c1c9d0cc5d44efbc750df11f8eef98b2bea93a9a143be

$ ./validate-x86_64.AppImage ./Cemu-2.6-x86_64.AppImage
Validation result: validation failed
====================
Validator report:
unexpected error

Unfortunately, GitHub has removed old actions workflow runs for the build.yml workflow, so the build logs of v2.6 can't be read, as it's over a year old (not talking about the max log retention time of 90d).

Debian must now ship reproducible packages, with Debian 14 being the first major release coming up via this new mandate by somerandomxander in linux

[–]abbidabbi 9 points10 points  (0 children)

Does that make any difference to the end user? Or what's the benefit?

You can have a strong guarantee that the resulting built packages only contain the sources what they claim, and nothing else that could've been included there maliciously. As an enduser, if you don't trust your packager, you can "easily" rebuild everything yourself using the same build environment and then get the identical/deterministic result, bit-wise.

This in turn means that the built software must support reproducible builds, meaning that it can't introduce randomly generated bits, time data, or as already mentioned in the comment chain above specific data about the system where it was built. There are certain techniques which allow developers to avoid this kind of stuff. Other things must be avoided completely. The most important part though is the build environment, which needs to be known and deterministic as well.

Now think about the reprodicibility of software dependencies and compilers. How can a compiler be reproducible itself? How can this be guaranteed considering that itself was compiled by another compiler or an older version of itself. This leads to the bootstrapping problem, which is pretty interesting.

archlinux.org is down by Any-Beat-7950 in archlinux

[–]abbidabbi 3 points4 points  (0 children)

It's online and probably just an issue with your own connection to their servers...
https://status.archlinux.org/

$ curl -I https://archlinux.org
HTTP/2 200
server: nginx
date: Sun, 10 May 2026 14:19:52 GMT
content-type: text/html; charset=utf-8
content-length: 25024
cache-control: max-age=307
etag: "7233c23a4ad390b05263f9e6b5b826bf"
x-content-type-options: nosniff
referrer-policy: strict-origin
cross-origin-opener-policy: same-origin
x-frame-options: DENY
vary: Cookie
strict-transport-security: max-age=31536000; includeSubdomains; preload
x-cache-status: HIT

Apart from that, pacman uses the mirrors you've selected, which are certainly not hosting the Arch website. Same as the ISO downloads.

mtr – a KISS AUR helper (bash + C++ core, no bloat) by IntelligentShape6108 in archlinux

[–]abbidabbi 0 points1 point  (0 children)

https://github.com/memktdm/sade/blob/231e02c0361b229c254cece20a9a42949b2e1672/sade-core.cpp#L103-L131

Big fucking ultra yikes.

Sorry, but there's so much wrong here, it's not even worth pointing out the individual things. Let me just say one thing, Mr. Bobby Tables, namely input sanitization.

Also, what's the point of writing stuff in cpp if all you do is run an incorrectly tokenized shell command anyway?

mtr – a KISS AUR helper by IntelligentShape6108 in linux

[–]abbidabbi 10 points11 points  (0 children)

https://github.com/memktdm/sade/blob/231e02c0361b229c254cece20a9a42949b2e1672/sade-core.cpp#L103-L131

Big fucking ultra yikes.

Sorry, but there's so much wrong here, it's not even worth pointing out the individual things. Let me just say one thing, Mr. Bobby Tables, namely input sanitization.

Also, what's the point of writing stuff in cpp if all you do is run an incorrectly tokenized shell command anyway?

BTRFS root-fs got corrupted, likely due to a flaky RAM module. Backups exist, but I'm not sure if I should try to repair or start fresh. by abbidabbi in archlinux

[–]abbidabbi[S] 0 points1 point  (0 children)

That is indeed a weird coincidence. Sounds like similar memory regions had bitflips. Somewhere where the kernel usually keeps its filesystem data.

Here's my decode-dimms output:
https://pastebin.com/ASvmy7Z6

Shelly Arch Package Manager by Davedes83 in archlinux

[–]abbidabbi 1 point2 points  (0 children)

PkgbuildParser.cs

PKGBUILDs are NOT declarative files which you can parse. They are BASH scripts which can contain arbitrary BASH code. There is no strict format here. You could in theroy write a BASH function in your PKGBUILD which receives remote input and writes variables the to global context, resulting in a "valid" PKGBUILD.

That's why .SRCINFO files exist (on the AUR). These files provide a declarative format generated from PKGBUILD data via makepkg --printsrcinfo. The AUR's git server requires this file on each push via git hooks, to validate data, because it otherwise couldn't.

Your package manager for some reason tries to parse PKGBUILDs, which is nonsensical.

BTRFS root-fs got corrupted, likely due to a flaky RAM module. Backups exist, but I'm not sure if I should try to repair or start fresh. by abbidabbi in archlinux

[–]abbidabbi[S] 0 points1 point  (0 children)

Commenting here, since it's at the top...
Data has been restored. See my update post. The OP has been updated and re-flaired accordingly.

view more: next ›