The Linux Thread - The Autist's OS of Choice

  • Want to keep track of this thread?
    Accounts can bookmark posts, watch threads for updates, and jump back to where you stopped reading.
    Create account
DavidS877 said:
How often do you people boot?
Click to expand...
I boot it when I wake up and shut it down when I go to sleep. I turn the screen off when I'm not using the computer and I shut it down if I am not home.
I don't see the point of leaving it on 24/7 doing nothing.

DavidS877 said:
SNEED_3371.webp
Click to expand...
He looks like wears diapers.
 
Akerman said:
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.
Click to expand...
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!?!?!?
 
Private Tag Reporter said:
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?
Click to expand...
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.
Akerman said:
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.
Click to expand...
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.
Click to expand...
 
Last edited:
Private Tag Reporter said:
but what the hell is a distro for anyways?
Click to expand...
saving time. same reason people use modpacks for games.

prollyanotherlurker said:
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.
Click to expand...
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:
Private Tag Reporter said:
I hate to follow up a question with a question, but what the hell is a distro for anyways?
Click to expand...
Imagine some train loving autists getting together to make a "real" train set, because mass market coomsumer Lionel sets don't meet their standards.
- The steam engine autist wants to make a steam engine set.
- The freight train autist wants to make a freight set, but only with 1950's engines and wagons.
- The diorama guy wants 15 types of plastic trees, because that's the minimum necessary for a basic set.
- Freight guy doesn't want any trees, just trains.
- Steam engine guy says 3 or 4 trees are okay, but 15 is too many.
- And on and on it goes.
Since they can't agree about anything, they all end up making their own special train set that has the things they care about.

Linux is the same way. They care about autistic issues like licensing, proprietary blobs, programs that are too large or too small, too many shell scripts or too few, developers who are too gay or not gay enough, etc, etc. Then they act like they want people to use their special toy, but they don't really like it when normies show up and just want it to work.
 
Speaking of USB setup, I remember that once when I wanted to do something from the Linux userspace on a USB drive while in Windows, not wanting to do a live boot, I would just use VMware and do USB passthrough to a Linux VM and do what I had to do there. I remember that I even used to boot from a USB stick within a VMware VM after configuring it for a UEFI delay and entering it's boot menu like that. You could probably do the same for Windows only USB tasks under Linux, whip up a little VM, do a hardware passthrough, run whatever, close or freeze the VM for later use.

Virtualization is neat.
 
prollyanotherlurker said:
I thought people already assumed there are malicious packages in the aur.
Click to expand...
Arch attracts a lot of idiots. No true and honest unixbeard is going to be running shell scripts from the internet without looking at them first (which is functionally what AUR does)

but hey whatever, time to put my troonsocks on and rice out my Arch install and give all my banking details to Slovenians
 
The Count of Monte Cristo said:
Arch Linux's website is the only one I've seen that removed the fag drawing and replaced it with a generic green checkmark.
Click to expand...
There are one or two nitter or redlib (I forgot wich one) instances that use their own branding.
I don't get it, why use tranny furry pedo-bait when you can have glorious KiwiFlare DDoS-retardation?
 
analrapist said:
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.
Click to expand...
If only there were some way to tell the mount command not to cache.
Code: 
MOUNT(8)                     System Administration                    MOUNT(8)
NAME
       mount - mount a filesystem
....
FILESYSTEM-INDEPENDENT MOUNT OPTIONS
...
       sync
           All I/O to the filesystem should be done synchronously. In the case
           of media with a limited number of write cycles (e.g. some flash
           drives), sync may cause life-cycle shortening.
If only, sadly he'll just have to rant about it.
 
You must log in or register to reply here.
Back
Top Bottom