So I saw this comment on a post in r/arch. The comment was a reply to some guy shitting on Arch that it was unstable, due to the research you need to do to make sure nothing breaks, and he replied with, I quote:

"is a nuclear reactor unstable because in order for it to be stable you have to research and identify what you need to do?"

Now- me being me, as expected of my greatness UwU, saw that analogy and thought- it was off. And that- I can definitely-, whole heartedly-, do better ᗜωᗜ /lh

And therefore, using my very very limited knowledge of Arch, linux, nuclear engineering, logisics ngl- limited knowledge in everything- (I don't know much), tried to make better analogy. Emphasis on tried...

I gave up in the end. Cuz I'm hungry boi right now :'3

That and I think the mood swings are finally coming...

Anyways- here is my thread. Do share you own analogies! For... whatever reason •w•

Wrote it in obsidian.

***

I mean- if we go that route, base linux kernel is kind of like when they give you the basic materials, raw uranium, and underlying concepts you need with some refinement, and you're kinda left to figure out how to make it work.

And yeah- you could argue ita stable, but its not really a "nuclear reactor," since- well... run it and you're fucked. That or it doesn't even run. You'd have to implement it first.

Theoratically you can tho-. The underlying concepts are straight forward enough: nuclear fission -> heat -> super mega hot gaseous water -> spin turbine -> spin rotor -> electricity. But in the end, you'd have to put in more and more work, i.e. designing your nuclear reactor (be it novel or an existing one, that you yourself have to come up with

to building up the safety mechanism,

and you're not really guarenteed to stability unlike a nuclear reactor managed by thousands of people who has fail-tested the components that they made.

Though- the difference is- like... If we similarly have hundreds of people testing individual components. I guess it works though. Like- every arch user has their own unique nuclear reactor they themselves made and have battle-tested. So it worked for them. But hey- who knows. Maybe the way you set-up your nuclear power plant, with a FUCKING turbine

So like fedora as an example, here from the guy. Their whole- thing is kinda... more. Its more standardised you know. So everyone who gets fedora gets the same exact nuclear reactor... kinda... =w= (actively judging you fedora spins. Swear to god I had more issues on sway spin. Actually wait- nah... i think that was just me being stupid. I remember doing some dumb stuff. Man the good ol' days, when I was still 16 years young UwU—I say when its only been 2 years. FUCK! I'm fucking 18 now. Pisses me off omg- I wanna go back to being 17 = n=).

Anyways- if I were to foolishly keep making this analogy more and more complicated, i.e. defeating the whole purpose of using an analogy, I would say... or fedora users, it'd be like having control over the layout/inside of the nuclear reactor, the planning and inner-workings, the shifts, rules, etc. Oh- and also being able to choose what type of nuclear reactor you want. You want a pressurised water reactor or-... idk- fuck. I forgot my reactors. Fuck it- start with the basic resources (linux kernal) and make a resource renewable boiling water reactor. Unless someone what made that already... i wonder what distro would that be? Furthermore, would distros be- ah... Hm-... I see a fault in the analogy.

Nuclear reactors seek to achieve one thing: make energy. Well- no... Thats a nuclear power plant. A nuclear reactor is for making and sustaining a nuclear fission reaction. And like... yeah. So... unlike linux, where the purpose is kinda up to you, (we ignore semantics like: "oh~ butt Ashhhh!! Distros doo! Serve one common goal. It's to serve the user's needs!" Or whatever extra stuff. None of that matters, because I said so- and I'm amazing like that UwU). That means, Arch would still be a "viable nuclear reactor" despite the fact that it is literally a skeleton (no offense). Sure! It is VIABLE, if you stretch it far enough. But that's where the analogy... though-... hm. Is there a way for me to bullsht my way through this?

I guess it depends, on how you differentiate the distros.... like- imagine this. Fedora, ubuntu and- idk- maybe mint. With all of their fluff, their kinda like a-... a- fast neutron reactor, pressurised heavy water reactor, and uh.... Idk- boiling water reactor. Debian, being a pressurised water reactor. (Yes I chose that one for a reason. And no- I will not take it back. And yes I am biased. Who isn't >:3 (tho ngl- I only love it dearly cuz it was my first distro, paired with i3. That shit was good tho- it felt like home. Safe. Kinda hard to replicate it now adays, actuallt speaking of which, yall know any like good- Hyprland rice- where the colours are muted but not too muted with low and high contrast? And also feels like home, but not too clearly home? Yk-. Ik it sounds odd but like- on god... I miss my i3 config TwT (thay shit was simpe af tho-. Althiugh ngl so is my hyprland config. I spent more time on functionality than aesthetic. I still got the basic background. But hey at least I'll be able to get dynamic on-demand workspace rules hehegehegeh). Oh yah- make it minimal too.) Anyways- uhm... yeah! So imagine that, and imagine Arch as some like.... uh... Idk- maybe an old- well... no that still wouldn't work. Because it isn't old. I need a way to represent a completely functional, viable nuclear reactor with modern systems, but- more minimalistic in it's design. I don't think you can tho- nuclear reactors are built and designed with worst-case scenarios in mind. Yk- "oh estimate of pi? 5. Nah. 6", or "1 + 1 = 67". Yk- fault tolerance type shi (my friend gonna be so mad when she finds out I've become hip once again UwU (she hates it I try to be relatable to the new kids >:3). Anyways, your analogy is ass! (sarcasm)

But, dropping the bs, I get what you're saying though (and yes I know how analogies work). I just found it funny that you chose nuclear reactors. ᗜωᗜ

Tho- you could literally just so this with anything in engineering and software. software engineering.... OH FUCK- I'm gonna fail my computer science A-levelsss. Ahhhhhhhhhh.

Okay I'm calm now •w•

Man... this is what I get for spending so much time in my hole. Shit outside world too bright man.

But yeah anyways- the same way the components... actually ngl- you can think of the components and basic resources being suplied the same as the linux kernal, with a strict standard and only supplier, therefore you're working with like the same underlying materials, for all nuclear reactors (wow- amazing, we're back to the whole linux software-stack now. All roads lead to fucking abstraction- god fucking damn it. Arghgh!! I keep abstracting away my obsidian notes. It was fun though) of a nuclear reactor are stable (disregarding the fact that you now just have kgs of shit: boron whatever fuck-ass coolant they give you, high-con. uranium-235 (at least you didn't need to mine it yourself tho-, look at the bright sides of life ^w^), and... machinary, in your backyard- wait... just sitting out there with ya, though ain't like it is dangerous anyways. Hut- better keep it contained din't . actually-... Huh-! I wonder... if a DIY nuclear reactor kit were to exist would they sell it like a framework? Wait no that wouldn't work. You'd need different frames for each one. Maybe they'll just opt for a pwr. Tho- ngl, would be cool if they make a series of nuclear reactor diy kits. Would they sell it with prepacked fuel rods with pellets already made, or would it be just pellets? Furthermore, I feel like I remember hearing about a cute mini nuclear reactor model).

Anywyas- back to the topic, it is kinda where, as the user/maker of said nuclear reactor (distro/system/OS/fuck ass tag database with abstractions galore, it would be their job to keep it stable as they build it up. But yk- that's kinda the case for all systems. But it is easier to create something unstable with less restrictions. Much easier to accidentally stall the reactor after an immergency shutdown and dropping the control rods when you hooked up the nuclear reactor's grid to itself, without a backup generator or battery, all cuz you thought it was "more efficient" and so now your safety mechanism are fucked, the whole system is down, and you just costed us millions =n=

So... yeah. Arch is stable. I think.... I don't know. I just use Arch for my local-only server. I haven't updated it nor touched it in months. uwu

I did have a vm- tho. That shit was a pain. First time using a vm. At least installing arch repeatedly drilled it into me. Fucking bitch....

But anyways- it sounds stable. Its just that, we as users, enshitify the systems we have, and thus, we- actually no. YOU! Made your system unstable, fedora boi. (no offense btw- I'm daily driving fedora too—right now at least lol ᗜωᗜ. Lelele! Arch is on it in a vm tho-)

I guess, for systems that can easily be made unstable, its kinda better to call it volatile. actually wait- no that is still unstable. wait is it? I'm thinking, when I say volatile, its the tendency for a liquid to turn into a gas. But also emotionally volatile would be unstable by most. FUCK WAIT NO. ITS SEMANTICS AGAIN!!

Actually wait- most times its not that easy to break your linux system (says the guy who has done it multiple times). But like... i'd say its stable.

Welp- tldr: I agree ᗜωᗜ

Edit: nah actually!! I've only ever had an update break my system once. Sure, some specific softwares, here and there. Wh- that's expected, but not really something like that. Maybe I haven't fucked enough stuff up yet.

Oh well- I kinda moved from Arch to Gentoo.

Oh wait- I didn't re-read anything. First paragraph, I state the kernel is like providing raw uranium. That would be incorrect. Kernel is more like providing uranium oxide pellets. Or... fuel rods. Idk- which ever you choose. I guess that's software for you.

Raw uranium is more like the hardware ngl. Kinda useless without software to control it. Wait- well not really useless. You could probably play around with it.

Actually wait maybe not- if distros include throrium based reactors, then the linux kernel would be more closer to the mining- well... I guess the kernel can do both in this scenario. Mining and processing or whatever. That way you can still be served a plateau of tasty options like... water, boron, graphite, plutonium or ceramic pellets uranium, some zircanium tubes to put them in. And... uh. Idk for your coolent. Ah fuck it- water for your coolant. Pick and choose, you- WAIT NOOOO!!! The processing IS the distros.the kernel gives out everything. Earth is the hardware. Because the whole thing with the varying distributions, is to basically have the ability to pick and choose. And- you are essentially choosing your resources. And ARCH is like- as if.... you have the option to extend your processing. Yk- like- oh shit I want to process the uranium into little kernel pellets so I create the most bat-shit insane temperatures. You can! You just have to built your hight-temp. Gas-cooled reactor ^w^

oh- and process all the extra stuff. But dw- you got your fellow arch users who have one that. ᗜωᗜ

So the nuclear reactor analogy still works!! I give it my approval, signed by a guy who barely knows half the shit he talks about UwU

As to why I didn't choose the first and second options for modelling linux as a nuclear reactor plant is cuz… there were issues…

Tho before that-, the first attempt, ubuntu should've been the PWR, and mint be a derivative design inspired or based on the PWR. Tho- the reason why I didn't was cuz I didn't know where to but debian in that stack.

Now why did I think that didn't work? Because realisitically, there is nothing stopping you from changing a fuck ton of shit, effectively "changing" reactors…. you can't do that with reactors though… you'd have to take it alll apart and start from scratch. Each design is tailored to the location. And changing reactor types… Uh. Maybe there was one case? I can't remember. But in my head it doesn't make sense =n= (which ngl is all I need cuz I'm amazing like that, ehehehe) And if a distro is defined to be the reactor *itself* then you

There is also the issue with the fact that all those distros, work and are viable, and can be used for more than just… A single purpose. but if you define distros to be, again, the reactor itself or the components of said reactor, you come into an issue where some distros (nuclear reactors) are just… NOT viable…. they don't do shit!

But-! If we define the distro as the underlying processing, refining and production of components/compounds or products, from raw materials, you're not bounded by any restrictions on what you can and cannot build. Break down the reactor that X distro pre-built for you—you bitch >:(

You'd still exist within that distro. Cuz you still have the infrastructure that actually processes and refines the materials for you, and create the components/building blocks. And you can pick and choose which reactor you'd like to build (all infrastructure is maintained by them)

With arch- its just smaller. You build your own processing plants for which arch does come with, if you need to make something. And yk- when that happens- and the main-processing plant distro thingy- decides to change, and fuck up whatever interlopping design you created for your own thing… It breaks.

Which-… actually really just sounds like what linux just is… way to re-invent the wheel ig- :'3

Alas, I must cast my verdict upon your statement; and with great dismay-

Ah who am I kiddinggg. Nay! With utmost, thrilling pleasuree!!! >:3

And said verdict is that your analogy, is SHIT! As shit can be uwu

Well- I gues shit is by definition the most shit. I... wonder if there is a meta joke here. Cuz your analogy did serve it's purpose, in that it highlights the seperation between the user and's responsibility and the- software? Eh- Arch's responsibility.and if shit is shit, doesn't that mean its goood? Or is this an english thing? Its an simile no? Similes compare similarities... ah so it does work. Nice :P

But anyways- if I were to give a better analogy... hm....

I have a few, but I wouldn't say that they are nuclear reactor related, nor do they highlight the connection between the meme and what you were trying to highlight, whilst simultaneously capturing the mental model of linux as part of nuclear engineering (and its surrounding logistics.

You wouldn't blame your manufacturer.... for making. Hm no. You well I guess I can try making multiple analogies for each trait, and combine them.

Say a pharmacy compounds drug X. Actually no- lets use lisdexamfetamine since I'm taking it. Actually just make it dextroamphetamine (easier to remember and write). Now, remove the many different ways you can administer it (like pretty sure you can take it as a liquid or something. Which is kinda iffy but also cool.) They specifically compound pills with precise doses- actually nah fuck that.

I should try to show some fairness; and thus, we assert that Arch is stable (to show that whether Arch is stable or unstable, and showing that the issues would still exist, either way. Now! Tell me, how would one represent a stable processing plant compared to an unstable one, you might ask? >:3

I don't fucking know 💀, none of this shit is my field. I WANTED TO BE A THERAPIST!!! AhhhhhhNnn!! I should be studying for ezammsss I'm gonnaa comp science and physicssss!!! TwT

Okay I'm calm now •w•

Anyways- you'd want it all to be rather standardised. High reliability, with high concentration (usually that's what you want. You can dilute it later), and output rarely, if ever, goes down. But! Say Arch exists in some kind of... environment with low water supply. Their cabilities of supply is limited- yk...

So kinda like... if you tried to make- well... I can't say that, it was as if you- were to make a nuclear reactor outside the resource budget. So I can't say you're a dumbass (I say cutely uwu) because- well your system DID work.

But say you went out of your to AUTOMATE the whole process of maintaining and running your nuclear reactor (some fuking how), but you forgot to Idk- put a limit on how much uranium you are inputting into the reactor (i.e. shifting responsibility of checking towards Arch. Also yes I know that's not how nuclear reactors work. You can't just shove uranium in there(unfortunately :<) but hey- remember. This reactor was built from the ground up, through patch-work. So it all checks outtt~ ᗜωᗜ),

I CAN call you! fedora boi; a dumbass (again, very effectionately. Or not… idk who you are =n= ), if you decided to make an unnecessarily big pressurized water reactor, with a once through system, that chugs water like Zuck's wet dream data center planet, yet SOMEHOW the water is provided remotely through a long ass pipe from the other side of the world (if you think this stupid and crazy, I'd argue so is most patch-work linux environments), that that's on you, the moment your water provider goes down, or the lake got fucked over or anything else (you can say that, THAT is unstable), cuz who knows- maybe you also built the intake system in a night while half-lucid and drunk, scripting in fucking perl, cuz wozza- wtf why not. (I'm losing my sanity cuz I've been writing for so long) orOR, alternatively, back to the uranium, you built a nuclear power plant that has no limit in how much fissle material it puts into it, with limited absorbtion capabilities, accidentally giving it a one way ticket to causing a nuclear meltdown, and all the safety mechanisms you implemented, if you even did implement any, fialed cuz they got fucked over by your or someone else's stupid PERL script, SOMEHOW. Okay- wait why Perl…? Oh yea- cuz of that one time!! Nah- that one was on me uwu.

perl isn't so bad. Its cool. But ngl I don't know any like-… safe-to-shit-on scripti- oh! JavaScript. Hell yeahhh dunking on js. Hate that language UwU (never ever programmed anything in js) /j

Also- I won't be shitting on php. For 2 reasons and 1 excuse. The excuse is, is that I never touched it (never been a reason that I didn't shit on a language for the sake of shitting on languages: C supremacyy yeaahhyyy!!™ :P). The 2 other reasons is kind- actually wait no. 3 reasons. My father once said its not bad for what it was built to do, but people tried to use it for things it was just never intended for. Not sure how true that is, but ngl- I relate. I ain't gonna dunk on a twin ᓀ‸ᓂ. second reason, my friends like php. She is amazing. So what she likes must be amazing. /lh

And 3rd actual reason is- cuz… wait what was the other reason again? I forgot…

Eh whatever. 2 reasons, 1 excuse- oh wait!! Yeah!! I remember now. 3rd reason is cuz I forgot PHP existed until I randomly scrolled on reddit and saw PHP mentioned.

But that's kinda unrelated though- like… Really unrelated. Where was I at? Oh yeah!!

That analogy is to show that it is the user's responsibility in the end, especially in making the choice of choosing a distro, that only gives you uranium, plutonium, thorium, and complain it doesn't give you Mother's Earth blue balls.

Though maybe I have exaggerated a tadddd-bit. But mgl- I kinda lost track of what I was doing cuz- (not afraid to admit it) I had to look up how much water do-…. boiling water reactors draw and- what was the other one? Oh yeah- AI data centers. And now that I have established a somewhat make-sensy analogy, it shall pave the way to my new and improved analogy. The one above may been dogwater, but at least it wasn't dogshit >:3

Thus!! One can reuse dog water- Right?? You just need to distill it- ah watever.

Now… I guess… if this is the underlying model… then the person who failed to do "research", would the designer… Hm. An analogy where you are the designer. And Arch… will be at the beginning of the nuclear reactor's supply chain. Arch can provide water, but yk- if you want more… You gotta processs more and make moree so I can…

Ah-! Then I know ^w^

Its like blaming the suppliers you yourself chose, and complaining they don't meet the standards of the entire system (to some extent—particularly on the reactor core itself or the logistics surrounding it), to which you designed, despite them being clear of what you should expect and not expect. It is your responsibility, to make it work, with what you got and make it work well.

Hm… that didn't work well… That analogy kinda ass… hmmmmmmmm…………. i'm hungry TwT

Tldr: the kernel mines the Earth. The distro's main function is to refine raw resources into materials + extra stuff. And you, as the designer, it is your job to make a working nuclear power plant UwU

it is actually easy to use and you can use it anywhere because I wrote it with python so what it does: it just generates .desktop files yeah thats it. its easy actually it just asks and you type what you want

git repo: https://github.com/sbusiedcake7945/desktop-file-generator

it is licensed under MIT license btw

(*) Terms and conditions apply. See post for details.

Specifically:

• x86_64. Sorry ARM enthusiasts!
• Uses apt, which is probably true for ~every Debian-derivative.
• Currently the Debian-derivative must be using SystemD. I know ZFS includes scripts that work in sysvinit, but I'm not familiar with how Debian-derivatives add those scripts to rc directories; help from a Devuan native wanted.
• The Live ISO MUST use a specific layout and install technique. Most Live ISOs use Casper to create an in-memory Live filesystem overlay, and then use Calamares to install the distro.
  • Most Casper uses have a directory casper/ in the Live ISO, containing filesystem.squashfs as the root filesystem, and optionally filesystem.manifest-remove for packages to remove after installation.
  • Most Calamares uses will just copy the root filesystem underneath the Casper overlay into the new root partition on the persistent storage, then uninstall Live packages (sometimes listed in the filesystem.manifest-remove file). Usually the distro only changes the Calamares branding.
  • Live ISOs which use the above pattern, which is nearly all Debian- and Ubuntu-derivatives, can be used with the ...FromISO option.
  • SlimbookOS and especially TUXEDO-OS (Ubuntu-derived version) have a variant of the above technique; the script detects when those variants are in use and will adapt to their Live ISOs automatically.
  • Ironically, neither Debian nor Ubuntu use this technique for their Live ISOs; instead they debootstrap into the new rootfs, indicating the on-USB apt cache as a (temporary) repository. Some Debian installers even forget to remove the temporary repository after installing.
  • You can just select Ubuntu26.04 or Debian13 on the directly-supported distro list if you want those; they use the classic debootstrap technique.
• The script automatically detects the ZFS situation of your distro:
  • ZFS in kernel package --- does not separately install ZFS, only its utility tools.
  • ZFS in zfs-dkms package in distro repo
  • No ZFS in distro repo --- compile OpenZFS from source.
• The script automatically handles signing of installed kernels and DKMS kernel modules for Secure Boot.
  • You need to install a Machine Owner Key once, on first reboot. Just "Enrol MOK" when prompted and select "Continue" then enter your password.

 __ ___ _  __        .    ,
 '/ |_ (_' |_)    |_ |\  /| _ _    -INSTALLER
 /_ |  ._) |_)()()|_ | \/ |(=| ||_|

The script is intended to be used primarily for daily-driver laptops and personal / family desktops.

You might think "isn't ZFS for big servers and won't I need tons of ECC memory and at least three disk bays?" But you get SNAPSHOTS, and for a typical modern daily-driver system with an SSD, you can get away with a small zfs_arc_max of 10% of your memory or less (1Gb ARC max is fine for a typical SSD daily-driver).

The script provides direct support for:

• Ubuntu26.04 / KUbuntu26.04 (Resolute)
• Debian13 (Trixie)
• SlimbookOS26
• Pop!_OS24.04
• TUXEDO-OS 2026/09 (Ubuntu version)
• PureOS11
• elementaryOS8

For everything other than Ubuntu / KUbuntu and Debian13, the script actually just downloads and validates the .iso file and then uses the "install from ISO file" path internally.

In addition, it has been tested (in a virtual machine) to be able to install from the following Live .iso files:

• Zorin-OS-18.1-Core-64-bit.iso
• linuxmint-22.3-cinnamon-64bit.iso

Note that the script makes an effort to remove grub and os-prober, both of which will annoy you with warnings when they can't find a Grub bootloader in the ESP every time you apt upgrade the kernel. Unfortunately, some distros make them a strong dependency of their distro-specific packages:

• tuxedo-base-files
• zorin-os-desktop

If the distro has such strong package dependencies on grub and/or os-prober, the script does not remove them as this can lead to broken installs. You'll just have to tolerate the nagging.

Pop!_OS24.04 Cosmic has a known issue where auto-login will disable screen locking until you log out and log in again. Please ask System76 to fix it.

The script automatically installs zfs-auto-snapshot, because automatically-managed snapshots are AWESOME. If you want to disable it completely:

• On distros where ZFS is available either in-kernel or in zfs-dkms, just sudo apt remove zfs-auto-snapshot.
• On distros without ZFS, zfsbootmenu-installer will install zfs-auto-snapshot-activate and zfs-auto-snapshot-deactivate scripts to completely activate or deactivate zfs-auto-snapshot. Run those as root.

Na última vez que postei aqui, consegui renderizar dois triângulos como um quadrado.

Bem, agora ele consegue rodar o GLXGEARS 💀

Isso está rodando no PowerVR SGX535 do meu Dell Inspiron Mini 12 de 2008, com um Atom Z520 e 1GB de RAM.

Está renderizando continuamente em 1280x800, a resolução máxima suportada pela tela embutida do laptop.

Ainda estou trabalhando na performance e corrigindo alguns problemas de renderização, mas fomos de um único triângulo para o GLXGEARS em algumas semanas lol. E sim, ainda estou desenvolvendo isso em um Galaxy Tab S7. O Mini 12 é só para testar no GPU real.

Edit1: I'm looking for people with Intel GMA600 or Sony Vaio P with Z520 or Z530 processors to test resolutions and drivers! And I'm looking for people to help me with optimization sugestions (this is very necessary)

Vídeo do Youtube: https://youtu.be/QRpV8xq82_g?is=SErZhPAOYDTcGnim Github: https://github.com/gabrieelgama/SGX535-reMESA

None of the substantive code was written by AI.

I used AI to help with the mechanical parts of porting (e.g. translating autotools to CMake, replacing ioctl calls with tcgetwinsize, translating the C structs into Rust), as well as to write some of the smoke tests (e.g. cairo-test, mesa-test).

Where Claude really shines though is in reviewing your own commits. You give it a hash, and it tells you about the silly memory leak or deadlock that you left in, before you can make a fool of yourself.