Every Linux Distro Must Learn From XZ Backdoor

[@eliminmax]

Always good to see more awareness of Reflection on Trusting Trust. My first substantial work in C, and only substantial work in C to date, was implementing a compiler backdoor of that kind in a modified build of the Tiny C Compiler as part of a college project, and it's terrifying to me how easy to pull off it was for someone not particularly familiar with C. My EvilTCC only miscompiles the original TCC source and GNU Nano, specifically replacing the "Welcome to Nano..." help text with "Your nano has been hacked by an evil compiler." (I'm a neovim user with a weird sense of humor, and it seemed like a harmless way to see whether EvilTCC worked while dunking on Nano). I took steps to ensure that the EvilTCC compiler and all code I compiled with it stayed on my own personal laptop, but if someone with malicious intent were to do the same thing and spread it, then that would be bad.

[@yxtqwf]

That's fascinating! How would you detect whether what you're compiling is TCC - i.e. would it work on all versions of TCC? What if it tried to compile modified TCC source code?

[@absalomdraconis]

Trusting Trust is why it's important to maintain some boot-strapping capability- and by extension, why it's important to maintain some very primitive compatibility. In the extreme case, paper tape, FORTH (because you _will_ "need" that level of macro capability), and a discretes-based (meaning, you can realistically build it with individual components, including resorting to relays) bit-at-a-time processor that's nonetheless able to interface with "modern" technologies, even if slowly and through intermediaries. At the end of the day, you absolutely want to be able to intelligently reprogram at least EEPROMs, regardless of anything else.

[@DissociatedWomenIncorporated]

Nano is so much better than vim and emacs. If you’re a masochist, just use edlin.

[@eliminmax]

@@yxtqwf if the specific part of the source code I replaced was detected, it would regenerate my modified source code and replace the original unmodified version in memory before compiling. I had to do it like that because my modification could not contain itself, so I adapted a quine - a program that regenerates then outputs its own source code. As long as the part of the code I modified was unchanged, it would continue working.

[@eliminmax]

@@absalomdraconis but not everyone can do that, and as long as you have at least 2 different independent compilers for a language, you should be able to catch a "trusting trust" style self-perpetuating compiler backdoor using a technique known as "diverse double compiling" presented in computer scientist David A. Wheeler's PhD thesis from 2009. If you know to check and take the time, you can be reasonably sure that a compiler is not compromised.

[@noot1337]

Cows: can be milked for a decade XZ Backdoor:

[@Scoopta]

My brain saw cows and given the context was like "Dirty cow!"

[@joaomaria2398]

what?

[@nosotrosloslobosestamosreg4115]

holocaust: hold my soap!

[@EvanEdwards]

@@joaomaria2398 He's implying that this video, one of many by Brodie, is Brodie milking the topic -- there doesn't seem to be much new in this video. It's probably getting good numbers for his channel, but there's just not a huge amount of analysis here that he hasn't already covered.

[@joaomaria2398]

@@EvanEdwards Ohhhh, it makes sense now. My English is bad... Thanks, man!!

[@Bob-of-Zoid]

Kudos to all of the great people who not only make Linux, but keep it the most wicked OS of all by keeping us users in the know, and slaying the dragons of exploits!! You are Heroes!!

[@Vilvaran]

As an observation, this did actually 'bleed' into other Distros. I was building a custom ISO of Majaro in early March, and noted very 'odd' installer behavior during testing. The Calameres installer would usually show the number of files being unpacked; however I only ever got an ambiguous "Filling up filesystems." - no other status. After sharting myself during the XZ expose - I rebuilt my 'distro' to get rid of this threat, which I confirmed to exist by checking my packages list. Now the installer runs normally, with the usual "Unpacking file x of ##" counting up as it completes. Also, even though there was also a kernel update when I made this; the whole ISO is about 30MB smaller than it's 'infected' beta, but it's hard to isolate such a small change in a 5.4GB file...

[@SlinkyD]

I woulda spent a week looking at diffs of hexdumps.

[@locatemarbles]

Kudos to Brodie for not letting Suse off the hook at the end. Truth of the matter is that where "many eyes" was present the backdoor was caught. Where "many eyes" was not present, i.e. the tarball and the non-human readable binary files, the backdoor remained unnoticed. Also distros need to stop blindly trusting upstream developers. They are humans and could turn malicious at any point, for any odd reason.

[@orbatos]

I actually read that security paper back in highschool it was a topic of discussion for good reason. Ultimately we do need improved chains of communication and verification, overlooking the tarballs should be embarrassing, but there are solutions. Remember, the community did respond to this despite the hurdles. In a corporate environment this could have been pulled from a pip repo and nobody would ever check.

[@rogo7330]

What we need is a book on how to build your system from scratch, starting with full wiped-out PC, and I mean FULL. Basically you will need to go and solder some stuff that can run from USB, boot into it, type the code and progressivly grow your own build environment.

[@__christopher__]

​@@rogo7330that's nolonger possble thanks to SecureBoot. You need a Microsoft-signed bootloader.

[@absalomdraconis]

​@@rogo7330: No, you need to be able to reflash the ROMs first, accessing via USB happens _after_ that. In the most extreme case, you need to build an "intelligent" (general-purpose CPU) flash tool from discrete components (though that _is_ pretty extreme). At the most extreme ends, paper tape is your friend, and FORTH is a matter of madness vs sanity. Once you've got ROMs flashed, then you want to port FORTH to your "real" machine (ideally going as far as to make it part of your firmware for a while), then build up. As for why FORTH, it's basically a command shell crossed with assembly, and individual commands can be written to take over the input stream, so it can be as high-level or as low-level as you want (also, you could have C, LISP, Pascal, and any other language that you can think of, be supported by taking over the text input if you wanted- it's _very_ flexible). Personally, I'm not fond of the syntax, but it's clear that FORTH is the most important software tool for this sort of thing.

[@theodiscusgaming3909]

@@rogo7330 solder what to what?

[@JessicaFEREM]

W Brodie switched to Firefox

[@xXRealXx]

What did he use before?

[@JessicaFEREM]

@@xXRealXx brave, the homophobic crypto browser

[@cosmicusstardust3300]

@@JessicaFEREM What the heck?! This is the first time I heard of this.

[@softwarelivre2389]

​@@cosmicusstardust3300Brave does use their cryptocurrency stuff, it's pretty wellknown

[@supercellex4D]

@@JessicaFEREM homophobia is keyed albeit

[@js6pak]

opensus indeed

[@Linkman8912]

NO

[@The472k]

Thanks for the cover of the article and your explanations! Appreciate it ❤

[@mskiptr]

I just have to say: Thank you Brodie for highlighting and going over these articles. Sometimes it just gives them more (deserved) attention, but for this one in particular I had it open in a tab for over a week now and was simply putting off reading it indefinitely lol

[@asdfghyter]

one way to get the money would be to treat the distros as a part of the supply chain as well and letting companies write contracts with them to process the same guarantees. a lot of companies depend on software that has no legal obligation whatsoever and many of them would probably like to change that if it was easy

[@absalomdraconis]

Yeah, that's probably the easiest way to approach it. It's even what RedHat realistically is doing already.

[@ToumalRakesh]

I still believe adding systemd dependencies into something vital such as openssh was a bad idea from the start. Also, certain core services should be subject to much more scrutiny when it comes to additions and changes. In fact, any service that typically runs as root should require rigorous review and design discussion before new dependencies are introduced.

[@noot1337]

non-systemd related programs having a dependncy on systemd is also a terrible idea because it leads to a less flexible system and instantly cauaes issues for non linux users. It should just not be a thing

[@orbatos]

You might want to look at what's actually happening. The systemd patch isn't an sshd dependency, it's a shim that isn't even necessary to run.

[@ImperiumLibertas]

​@@noot1337 that's why it was a systemd patch for openssh. It was added afterwards during build time not part of the base openssh. There is nothing wrong with systemd in regard to this exploit. The vulnerability was in the pipeline and the social engineering of the over extended maintainer. There was no bug. The application operated at expected given the compile inputs and options. What we need is provable reproducible builds that way if someone sneaks a patch in during a non build step it will get flagged.

[@ToumalRakesh]

@@ImperiumLibertas "that's why it was a systemd patch for openssh. It was added afterwards during build time not part of the base openssh" - Oh okay, that solves everything then. It wasn't added before, but later. So... why did a dependency of libsystemd make this an openssh vulnerability again? Because it's a dependency, not as in "openssh depends on it to function" but someone linked it in.

[@ToumalRakesh]

​@@orbatos You might want to check what actually happened. Quote: "openssh does not directly use liblzma. However debian and several other distributions patch openssh to support systemd notification, and libsystemd does depend on lzma." Then read what I wrote, and perhaps realize that it doesn't matter who does it, or when. The point is: It shouldn't be done, at least not without review and consideration. The fact that removing this dependency (Again, dependency as in linked code, not "depends on it to function") didn't break anything should really tell you something about how neccessary it was.

[@knghtbrd]

These lessons are important, and they're not the only ones. They're the "sexy" problems. But I don't think one response to this attack is going to prevent it from happening again. I can think of at least a couple of ways that two pieces of malicious code could communicate with each other that'd survive a code review and even perhaps a debugger when not actively being triggered, potentially with "not under a debugger" being one of the trigger conditions. The stakes are raised and the game has gotten a lot more interesting.

[@act.13.41]

This could have been way worse. As a Tumbleweed user, I am glad to know they took the initial warning as seriously as they did. The same goes for the Debian crew, although you don't have nearly as many people running Debian Sid. A lot of people got busy and took care of this quickly. @Brodie, were there any victims of actual hacks from this, or was it all caught and cleaned up in time?

[@AndersHass]

No known victims. So I would assume there isn’t any.

[@BrodieRobertson]

Unless somebody was running Tumbleweed or a development release of a few other distros in production it's very unlikely. Even then it wasn't made public until patches were already shipping

[@act.13.41]

@@BrodieRobertson That was my understanding as well. Thank you sir.

[@SirLightfire]

I had the malicious XZ package on my Arch system. Thankfully, arch doesn't patch openssh with systemd, so i wasn't "vulnerable" But still...

[@AClockworkHellcat]

OpenSUSE: "The way we've been doing things in the open-source community isn't inherently infallible and it's time to start talking about ways to improve it and prevent social engineering attacks in the future." Brodie: "That's very reasonable and it's good they're saying it." KZbin comments: "OK BUT WHAT ABOUT WINDOWS" What ABOUT Windows? State actors are trying to sabotage Linux now, and these guys still wanna fight over whether Tux could beat up Microsoft Sam.

[@yxtqwf]

well it would be trivial for this to be done with Microsoft Windows - and has been! (read about PRISM)

[@absalomdraconis]

​@@yxtqwf: No, _REALLY,_ what about Windows? This is a video about Linux distros, and those are fundamentally and massively different from Windows, this _is not_ the right place to be talking about Windows. For the purposes of this video, Microsoft Windows might as well have never had a version 3, much less all of the other stuff that came after. Windows doesn't matter.

[@asdfghyter]

the trusting trust thing is a good argument for trying to make the entire distros have reproducible builds. especially if you can build everything from scratch and using no blackbox binaries. in this case, opensuse could’ve rebuilt everything using a non-compromised system and see that nothing except xz itself would have changed

[@andreasbaumann6943]

I really appreciate your dissection of those issues and making those not easy understandable things easy to understand. 🙂

[@mskiptr]

One of the cool tech tree items we will unlock after completing reproducibility and bootstrappability is comprehensive source auditing. There's some activity like that happening for Rust and hopefully we will be able to achieve more in this field. Just imagine if all the distribution packages were clearly marked whether their entire dependency tree has anything unaudited in them (or how comprehensive and independent that coverage is). This is unfortunately almost impossible to complete, but getting it done for at least core packages would be awesome. To make it more feasible, we should really start using languages that help us reduce the amount of code that really has to be inspected. Rust (with its 'unsafe' construct) gets us a long way, but you can still write exploitable bugs in safe code. To truly minimize the attack surface, we would need capabilities | managed effects instead. There's also the auditable silicon thing, but that's sadly quite expensive. Unless someone like Google decides to invest into it or one of the smaller chip design companies tries to actually ride the hype train of RISC-V openness, we would basically need to crowdfund some low-performance CPU cores on old-tech fab nodes.

[@hoardingapples7083]

Reflections on Trusting trust is such a gigabrain idea. Insane that they already thought of this happening back in the 80s

[@Dylan-zm3ht]

What an interesting topic. Hadn’t heard of this xz security issue.

[@orbatos]

In a nutshell: Some state actor, we don't know who, orchestrated a long term social engineering attack on a lone developer, took over the project legitimately using a sock puppet account, then deployed a targeted attack Trojan against sshd through the xz tooling.

[@noderunner_]

Yeah, what is this xyz thing anyways?

[@YaySyu]

@@noderunner_ what is linux Edit: GNU slash linux

[@vendetta.02]

​@@YaySyuNo it's just "linux", not gnu+linux or whatever lgbtqabcdefg+ acronym you wanna give it

[@YaySyu]

@@vendetta.02 What kind of mental gymnastics does it take to turn one of the most common linux memes into "I don't like queer people" lmao log off bro

[@jamescobban857]

Heartbleed at al all massively impacted real users. It almost shut down the US and other governments because it was deployed in routers. XZ was found *before* any general release implemented it. And it was discovered precisely because of the open culture. The big problem is that there should be at least three maintainers on every project so there are enough eyes for a code inspection.

[@the-answer-is-42]

To be fair, a big part of the XZ issue is social engineering and anyone can be a target of that. Not saying you're wrong, I agree, just wanted to add the disclaimer that even when there are multiple maintainers, it's good to be vigilant.

[@YaySyu]

Been told already by several windows users that linux isnt more secure thanks to the xz situation.. So wrong on so many levels.

[@capn]

Thanks to all the eyes on open source software, this was caught before it actually shipped as stable. The only people affected were using unstable / testing repos and likely didn't have an exposed SSH port. I'd say the impact of this entire incident was next to zero. Windows fanboys should do more research :)

[@KeithBoehler]

Maybe they need to be reminded of the Solar Winds hack a few years back.

[@vendetta.02]

windows has spyware and malware in it that isnt viewable because microsoft was forced by governments to put it in there, and it will probably remain there far after win 10+win 11 death until it inevitably gets a source code leak and we are able to see the backdoor Windows is less secure cus u have to trust microsoft to not adhere to what governments force them to do to their software, i guarantee that the FBI or CIA or some other three letter agency told microsoft to put a backdoor in windows thats unviewable.

[@CosmicCleric]

​@@capn Honestly, this seems more like Linux got lucky and dodged a bullet at the last second, than "the system is working as intended" (aka, "everything is fine, nothing to look at here" /leslienielsen). Fanboying can go both ways, and doesn't help solve problems.

[@capn]

@@CosmicCleric "last second"? I think you should brush up on the timeline at play: The backdoor was discovered almost immediately and wasn't shipped in any stable distros. Compare that to the vulnerability that Microsoft left unpatched for months at the NSA's request (presumably as a backdoor), resulting in WannaCry getting spread across critical infrastructure and wreaking havoc. I think the Linux backdoor incident was much more favorable. Obscurity doesn't work.

[@darthcabs]

My humble opinion: Wanting to take measures to prevent it from happening again is correct, but we have to be careful not to take the exception for the rule here. This web of trust that he mentions could very well cripple the most beautiful advantage of open-source: Everybody can contribute. If only a handful of people (or even worse, companies) are trusted to contribute, it will become very bureaucratic for newcomers to do so independently

[@georgeindestructible]

I think a good amount of people in the Linux community became complacent from the nature of open source software rules like the one that says that, if it's in the open anyone can see it so no one can f with it, which while true in principle, as we can tell from what happened with XZ it's not necessarily true all the practice. Like something can be in front of you, you might be able to see it perceive it but you may not be aware of it, maybe because some trickster was too good at hiding it or you simply wasn't paying attention, which is the problem that we have with things being open ANYWAY, we must never drop our guard basically and fundamentally always keep up with good practices which prevent such things from happening in the first place, i think we might need either better tools and/or rules for the open type software to ensure things like XZ don't happen again or happen way less or for way too insignificant things at least (some additional mechanisms might be required to be added tbh, specifically to maintainers and creators as well as maybe, i am not sure, impose an apt implementation of function verbosity as a part of any tool that doesn't already have it or is like that by nature, just to capture bad stuff as early as possible, like everything having a debugger basically, i don't know the implications of things so i might be suggesting crap, even though that can kinda be achieved if you launch programs from the terminal as far as i know).

[@elzabethtatcher9570]

Big projects likes DEs and Distros are at most danger from bugs and exploits at small projects, and should definetely invest time into reviewing them. Possible even managing some of the pmost important yet underdeveloped projects.

[@nomadhgnis9425]

I think the linux communuty need to own its mistakes. Do not try to hide back doors like a certain commercial operating system.

[@insu_na]

I think people should be more ready to pay for the linux distros they use (pay for as in donate some amount the user is comfortable with). If enough people (but especially corporations) were doing this, the distros might be able to pay upstream developers (better).... Basically rehashing what the suse article guy already wrote, but yeah.

[@rogo7330]

It would be enough at least participate in wiki and forums of the projects literally on any topic that you think you can provide alternative to what already written. For example, I fully ditched NetworkManager from my laptop and replaced it with wpa_supplicant + dhcpcd + iw and some homegrown scripts to create network device for AP on my wifi card, and now its even more flexible than doing everything through NM on one single network device that created by default for single wifi-card because I can broadcast AP and be connected to another AP as a station at the same time.

[@Scoopta]

The heck is a left pad...gotta look up that one. EDIT: Ahhh...node, no wonder I hadn't heard about it, I avoid that whole cluster with every fiber of my being. There are only 2 runtimes I refuse to install or engage with, .NET/mono and node. Anything else is fair game but those two shall never run on my systems.

[@bigpod]

have you ever played a unity game

[@JaegermeisterCoomerstein]

​@@bigpod​imagine being over the age of 16 and still be playing games. manchild behaviour

[@Scoopta]

@@bigpod in a privilege restricted container, yes. I have a systemd container for steam games. It has UID mapping and no access to any of my files. Also has its own X server...mainly because I don't have XWayland normally so that container provides XWayland and gamescope for steam games. It does have direct access to my systems compositor in order to run gamescope n such but that's just something I have to accept. Fully aware unity is mono, I hate it...was so mad when godot went that direction too. EDIT: 🤔 I just realized I could probably use the cage compositor on my host and pass that into the container. Might give that a try actually, that will prevent the container from being able to directly access the host compositor. As long as cage can correctly lock the mouse, that's why I don't nest sway for that.

[@absalomdraconis]

​@@Scoopta: If you ever decide your current setup isn't enough, then try to find a way to initialize a drive inside computer A from computer B while A is turned off, that way you can have virtually complete sandboxing (maybe even force the network connections through a VPN so the Steam box can't even see your network). I can't think of how to do the drive gimmickry, but even an "escape the sandbox" attack could be rendered mostly (RIP Steam account?) irrelevant through that route.

[@Scoopta]

@@absalomdraconis I just need to use WoL to power on the machine when I need it and then stream the games over my lan, honestly definitely could work, seems expensive though. I'm sure this was meant to be sarcastic but I can't help but appreciate it since my current setup is ridiculous and I am fully aware of that. Should I also mention the fact that said container runs a CLAT for 464XLAT because my network is pure IPv6 and steam hates that...am I a walking tech meme? Maybe...not quite sure tbh but I love my ridiculous setups.

[@CRYPTiCEXiLE]

Why is JiaT75 been un suspended for weeks now on github?

[@jfolz]

Wait what

[@ruroruro]

Huh. It's possible that github locked him out and re-enabled the account so that people could research his previous contributions. But this is 100% speculation on my part.

[@CRYPTiCEXiLE]

@@ruroruro not sure but i notice weeks ago and been questioning it for weeks now and wondering why nobody is talking about about this... it makes me wonder man.

[@mskiptr]

Maybe they want to see if he logs in and leaves more digital footprints? A successful de-anonymization would be pretty nice in this case.

[@tero.kinnunen]

5:30 "and that did not have corresponding updates in the test framework or in the project code, so these were “unused”." That is incorrect, they are used. As Lasse noted: "Note that tests/test_files.sh uses globs to pick the files. So just adding files means that a decompression test will be done with them.".

[@Dungeonseeker1uk]

So, if I understand properly, the code was hidden in a tarball and when you go to build on a system depending on systemd aimed at deb or rpm the build would pull the tar instead of the source code hence pulling the backdoor in without the builder knowing. So then I'd ask, why are the package maintainers not diffing the tarball vs the git repo before build and returning !=0 if the diff fails? Git does this pretty easily and its not exactly taxing on the system, sure I guess it would add a fairly big chunk of time onto a build when you're literally building a full distro but it also would have caught this instantly.

[@sellicott]

Real question. Is this validation of the BSD model of OS development where all the core parts of the system are developed by a single core group of developers?

[@TheTransporter007]

I daily drive openSuSE15, and when I saw ~800 packages come up for update under "zipper up" on my test (Tumbleweed) box, I knew this was what happened. What a f'ing disaster.

[@rashidisw]

My suggestion is to look at line of codes that employ obfuscation technique. Using such technique did not make any sense in Open Source environment.

[@xzaratulx]

Native Linux games work really well. Tho at some point there a system library is updated breaking the whole game in the end. Developers of closed source are not really known to keep an eye on it and do continuous updates. In the end I download the windows version and play with proton. Wouldnt it be better to ship the games or any closed source with their necessary libraries ? Also Gnome is bad😝

[@alex-oc1wo]

Btw what is going on Wayland side any news from wayland ?

[@adjbutler]

yes, but NixOS video when???? WHEN!!!!

[@syrefaen]

I have seen xz that I did not call on arch. Using 99% cpu, it was not pure arch but I reinstalled instant. Hmm scary stuff your describing there. Should just put on the tinfoil hat sometimes and be wary.

[@bapril51]

openSUS

[@elzabethtatcher9570]

Am I hearing static behind Brodie's voice, or am I crazy? It's either his microphone or my earphones are dying.

[@BrodieRobertson]

You're the first to mention it so it may be an issue on your end

[@elzabethtatcher9570]

@@BrodieRobertson ty, will investigate

[@BrunodeSouzaLino]

Sadly they can't because they're too focused on other BS like CoCs. Maybe if we ask the xz developers to make a really shit one, they'll listen?

[@c5on]

What is that weird static in your sound?

[@MelodicMethod]

your sound went crackly about 16 min into the vid

[@uuu12343]

This also got covered by SANS Lmao

[@tomaintaround]

Firefox? Hmmm

[@RegularTetragon]

This created a bit of a stir with nix. It takes about a week for nix's CI to complete, so that's the minimum amount of time between unstable releases. If nix had shipped a flawed xz binary it would have continued shipping a known bad binary for over a week and there was nothing anyone could have done about it but wait

[@bulbyvr]

a week of computation time? wild

[@ruroruro]

First of all, the initial estimate of "a week" was conservative. It "only" took three days to complete. Second, it doesn't "take a minimum of a week for the CI to complete", replacing the normal package doesn't take any longer to complete than on any other distro (actually, it can probably be even faster than even other rolling distros, because they don't really have "releases" so to speak, they continuosly build on every commit and every commit pushed to nixos-unstable has already passed CI). The only reason why this particular rebuild took such a long time is that XZ is included in the stdenv alongside bash, gcc, make, etc. Basically, stuff you need to build other stuff. So when you change any package in the stdenv, you need to "rebuild the world" and that (understandably) takes a long time. You'll notice that this is basically exactly what OpenSUSE did when they noticed that their GCC was potentially compromised. Except unlike OpenSUSE, NixOs didn't have the benefit of a pre-public-disclosure warning. Additionally, the community quite quickly identified that NixOs was not actually affected by this exploit, because nixpkgs doesn't include the sshd patch that links it to systemd. And even if it did, NixOs still wouldn't be vulnerable, because the build logic in xz actually checks a bunch of environment variables to identify if it's being built as an RPM. Since the environment variables aren't present in the nix sandbox, the resulting xz/liblzma binaries don't actually contain the malicious payload. And even if all that wasn't true and the xz/liblzma actually was vulnerable, there are a bunch of ways to mitigate this problem without actually doing the "rebuild the world thing", for example you could use the `system.replaceRuntimeDependencies` NixOs option. Also, if NixOS was actually identified as vulnerable, I suspect that instead of just replacing the stdenv.xz with the earlier version, the security team would either "surgically" replace xz in important/affected packages first (such as sshd) to get those updated quickly and only then replace it in stdenv (potentially leading to the long rebuild). Since no package was actually vulnerable, there was no real incentive to spend time patching individual packages for faster rebuild. And if all else fails, you could just roll back your installation to an earlier generation, which didn't have the new xz version. You know, atomic generation switching, you might have heard of it, it's only like one of the DEFINING FEATURES OF THE DISTRIBUTION.

[@bigpod]

WTF week for a CI pipeline what the hell are they doing

[@ruroruro]

​@@bigpodrebuilding ALL the packages, because xz is included in the standard build environment (see my earlier comment in this thread for the reasoning). Also, keep in mind that nixpkgs (arguably) has more packages than even the AUR. If anything, the "world rebuild" was surprisingly quick.

[@agun214]

susOS

[@justanotheruser8271]

Why is JiaT75 hasn't been sentenced for the crime?

[@ruroruro]

Because they are most likely not a single person, but a team, possibly state sponsored.

[@cameronbosch1213]

​@@ruroruroYeah. Good luck trying to extradite a Russian or North Korean hacker _sponsored by their governments._

[@aeghohloechu5022]

did you just assume cops already know where Jia tan lives and could've just arrested them

[@uiyx4379]

no views in 28 seconds 💀 bro's channel fell of

[@no_name4796]

17 views in 2 minutes. And 2 of those view are here rn

[@mqb3gofjzkko7nzx38]

You have to watch the video for more than 28 seconds before it gets counted as a view.

[@chromacat248]

25 likes in 1 hour 💀 bro fell off

[@dashinblu]

Our little comedian

[@teyathebirb8922]

3100 in 3 hours, bro's getting up there

[@autistadolinux5336]

To be honest, every distro should only care about being usable, debian must only have packages for keeping its desktop usable, for example, it shouldn't even ship "user" programs like ncmpcpp and libreoffice, these could take from the internet or even other deb sources. Every linux distro should only care at being usable and stable enough so other developers can take it as a platform to build on (just like on Windows, or even better than Windows if we consider the deb sources)

[@supercellex4D]

Because F having convenient package management, right? We GOTTA copy proprietary oldware!

[@rockpods4498]

Windows does have a store, but it sucks so nobody uses it. Most Linux distros have a good enough store, so people use it. I think most people would use the Microsoft Store if it was good. People do not want to download everything from the the internet from random sources, they just are forced to because Microsoft Store is not good.

[@kuhluhOG]

that's kinda what the "atomic" desktops build towards

[@autistadolinux5336]

@@supercellex4D No, we gotta have a stable platform that doesn't change much, from kernel space to userspace, so software developers, even opensource devs, can have time to build software on it. That's how Windows did, hell, even Android, a fucking OS that uses linux as a kernel, did, why linux desktop has to be different? Are you fucking retarded? And i've said: there's the deb sources that you can add to keep updating with the rest of the system.

[@autistadolinux5336]

@@rockpods4498 None of the app stores are good, or they are already filled with viruses (which people learn how to avoid it), play store is in this category, or they simply don't have updated programs, and stable distros fall on the second category. For me, those things should work like emacs: emacs offer a package manager, and then you put whatever source you want to get packages from (MELPA, for example). The "official" package source should only contain the stable operating system, so the other sources can base their dependencies on that.