It’s literally in every display you see in the world. OEMs stopped fucking with Windows years ago.

Go to any fast food restaurants with those vertical displays? Linux.

Check-in kiosks that have been deployed in the past 5 years? Linux.

Your router, most platforms you interact with online, media devices, cars (they should be using RTOS, but many use Debian), movie theaters, POS systems…

Linux is the most deployed OS on this planet by far. I’m kind of annoyed when people don’t realize this.

I actually hate when engineers are just letting a desktop sit like this. It’s sloppy and unnecessary.

Vibe coded? You know how this works?

Good luck with that. I look forward to your future posts about it.

🤣

In Gentoo, emerge compiles packages from source on practically every machine you set up. matrixOS remedies this by building once and distributing binaries, so you skip the compilation wait entirely.

Okay, soooooo…basically disregarding the entire point and benefit of Gentoo? The entire reason you’d want to build from source on a specific machine or architecture is for the compiler optimizations done on that hardware. Just shipping binaries around is normal, so I’m not getting what the point is here.

Lolwut?

You think that’s why Canonical and RedHat make money, huh? 🤣🤣🤣

Symlinks are just links to a hard file. Unless you’re setting specific flags, you’re coming the hard files along with everything else. I’d run a dedupe script on your copied files and see if you didn’t happen to double up on some things.

Depends on how the code is using it. You could look deeper, but that’s not what OP is asking for help with.

It’s not about how big they are really, it’s about how many can be open at a time. Without sane limits, then anything is a ticking time bomb.

Reduce the number of active connections, or the total number of active transfers available at once, and that will lower that number.

If you’re POSITIVE your memory situation is in good shape (meaning you’re not running out of memory), then you can increase the max number of open files allowed for your user, or globally: https://www.howtogeek.com/805629/too-many-open-files-linux/

Again: if you do this, you will likely start hitting OOMkill situations, which is going to be worse. The file limit set right now are preventing that from happening.

You have a process holding open a bunch of FD’s. Instead of just blindly increasing the system limits, try and find the culprit with something like: lsof | awk '{print $1}' | sort | uniq -c | sort -nr

That will give you a list of which processes are holding open descriptors. See which are the worst offenders and try and fix the issue.

You COULD just increase the fd open max, but then you actually will more than likely run into OOMkill issues because you aren’t solving the problematic process.

Back up a bit because you’re conflating a number of things, so let me try to break it down:

1. If you’re using Hyprland, you’re losing all the power management features of the more fully featured DE’s like Gnome or KDE. This isn’t a flaw, it’s just an acceptance of the trade-off.
2. Unless you’ve directly intervened, the power profiles are set to whatever your distro installs and sets from the initial install. Which leads to…
3. There are different defaults for powered vs battery by default. If you’re on a laptop and you don’t have the DE helpers, you’re on your own.
4. The hardware power management built in to your laptop may be playing a role here, so check your BIOS
5. Check dmesg to see what live changes your hardware controllers might be making
6. Check the Framework forums for keywords related to “Hyprland” to see if somebody has easy scripts for you to help. Otherwise, just switch to a DE that manages power the way you’d expect.

Your power restrictions are preventing the higher power settings.

If you’re using Gnome or KDE, you can use the applets to just turn it up a notch and get more brightness.

Red Hat is the largest funder of the Fedora Projects because it serves as a base for other things they make and support aside from their enterprise distros. Being the largest single funder gets you the most pull on the direction of said projects. They also have Red Hat employees directly running or contributing to various projects and upstream commits.

The actual community boards and such are independent of Red Hat otherwise. Similar to how Valve suddenly has a bunch of pull in the direction of the projects they’ve been directly funding and contributing to the past few years, Red Hat informs the independent community board with commits and contributions.

This is how the FOSS community works in general though. ‘Project A’ could be widely used in the community, but generally have fairly slow development. ‘Company A’ comes in and offers to fund feature development or big hunts, or maybe directly contribute fixes because they rely on this project. That project then either has the choice to turn down that extra help that could greatly benefit the project, or take that help, and as part of that deal, accept that ‘Company A’ now has some pull in the direction of the project.

Kind of a majority rule via resource commitment.

Logs

Get a better job so you can afford better drugs. This is “Minimum Wage Methy”, and you want to be “Salaried Methy”.

Gotta say… This is not how you’d generally do any of this. Where you get this info?

It’s not the CPU. All that will do is consume CPU and raise your energy bill.

1. Get some sort of resource monitor running on the machine to collect timeseries data about your procs, preferably sent to another machine. Prometheus is simple enough, but SigNoz and Outrace are like DataDog alternatives if you want to go there.
2. Identify what’s running out of control. Check CPU and Memory (most likely a memory leak)
3. Check logs to see if something is obviously wrong
4. Look and see if there is an update for whatever the proc is that addresses this issue
5. If it’s a systems process, set proper limits

In general, it’s not an out of control CPU that’s going to halt your machine, it’s memory loss. If you have an out of control process taking too much memory, it should get OOMkilled by the kernel, but if you don’t have proper swap configured, and not enough memory, it may not have time to successfully prevent the machine from running out of memory and halting.

Mkay. So you’re just some person out here on the Internet who has zero concept of how this works as well I’m assuming?

Feel free to dispute any single point I’ve made.

Well, let me break it down for you since you don’t seem to work in this space:

1. A Roadmap is a strategic timeline of targeted goals that are estimated to be completed in a specific timeframe that is NOT nebulous. It’s done this way to provide consumers of a product some knowledge of where the product is going to entice them to buy-in to said product to allow them to estimate their own commitments to the project and adoption.

2. A backlog is NOT a Roadmap. I planned orchestration of tickets is a Roadmap. We create this to ensure users that problems they are experiencing will be resolved, and in what order to expect them to be resolved. This works for both for-profit engineering, and also FOSS projects. A great example of this is the Roadmaps provided by distros uses by Enterprise customers.

3. Your comment about “inflexible commitment” seems to say you don’t understand the above points. If you’re pushing a product which you want people to adopt, and you’re communicating to them why they should adopt it, the last thing you would want to do is say “Hey, we’re kiiiiinda going this way, but maybe not. We’ll see.”

4. Programming DOES work like an assembly in a sense. That’s why you have tickets, tags, classification, triage, status, and…backlog. What gets thrown in the floor is what I’m talking about.

Regardless of how you feel about the pace of the project, it’s absurd to throw out a bunch of ideas as tickets and expect them to all get done without a commitment. Or, dare I say, a roadmap.

It’s a wishlist of Open tickets. Wouldn’t necessarily even call this a commitment to a roadmap. 75% of Open tickets will never get resolved anyway.

https://gist.github.com/camullen/0c41d989ac2ad7a89e75eb3be0f8fb16

Just cut Windows out as much as possible and run everything in WSL. Setup everything to boot straight to all your WSL layers, and aside from the absolute shit Base OS, it should be the same.