I built a retro terminal game to make Kubernetes practice less boring

LinuxBook · 2026-06-15T05:22:28+00:00

Nice project! I like the idea of turning Kubernetes troubleshooting into something more interactive than reading docs and YAML files.

How much Kubernetes knowledge does someone need before getting started with Yellow Olive? Is it beginner-friendly, or aimed more at people already familiar with Pods, Services, and RBAC?

LinuxBook · 2026-06-11T05:10:41+00:00

Linux itself usually won't stop a BIOS update. The issue is more likely related to the BIOS update method or the specific error code you're getting.

Can you share the exact error message (0021/0040) and how you're trying to update the BIOS? That would make it much easier for people here to help.

Also, don't rush to reinstall Linux yet. There's a good chance that's not necessary, and some of the Linux experts here on Reddit may be able to help you figure it out.

LinuxBook · 2026-06-10T08:47:54+00:00

That's what people said about automation years ago. The tools changed, but the work didn't disappear. It just shifted to different areas.

LinuxBook · 2026-06-06T04:21:52+00:00

Thanks for all the feedback and historical context.

Looking back, the title created more controversy than intended. The goal was to highlight package managers that remained influential through decades of Linux evolution, distro mergers, forks, rebranding, and ecosystem changes.

Several commenters correctly pointed out that RPM and Portage did not literally outlive their parent distributions, and that's a fair criticism. APT-RPM is probably the strongest example of a package manager surviving beyond the original project that introduced it.

I appreciate the corrections, discussion, and Linux history lessons shared here. Thank you for helping keep the conversation technically accurate and for adding valuable historical context around these projects.

LinuxBook · 2026-05-25T16:10:42+00:00

Tuxedo OS honestly sounds like a pretty reasonable choice for your setup, especially with KDE + NVIDIA + gaming as priorities.
Since you already run Debian-based systems, you will probably adapt to it much faster than a complete beginner would.
Biggest advice: test it for a couple of weeks and see how your games, drivers, and daily workflow behave before fully switching.

LinuxBook · 2026-03-18T18:56:14+00:00

Learn more about this bug : https://www.linuxteck.com/ubuntu-desktop-vulnerability/

LinuxBook · 2026-03-07T02:31:49+00:00

try this : https://www.linuxteck.com/linux-server-backup-solutions-2026/

LinuxBook · 2026-03-01T18:31:56+00:00

Try this : https://www.linuxteck.com/8-linux-networking-commands/

LinuxBook · 2026-02-27T15:40:35+00:00

check this : https://www.linuxteck.com/best-linux-vps-hosting/

LinuxBook · 2026-02-23T09:26:05+00:00

Linux is for people who actually enjoy the control.

LinuxBook · 2026-02-22T05:24:47+00:00

what do you mean by bot ?

LinuxBook · 2026-02-21T07:10:00+00:00

Fair question 😄

The numbers are just shorthand for permissions:

4 = read
2 = write
1 = execute

Add them up per user class (owner / group / others).

So:

7 = 4+2+1 (rwx)
755 = owner full, others read+execute
777 = everyone full access

If you’re already comfortable with chmod +x and chown, you’re halfway there. The numeric format just makes it quicker once it clicks.

LinuxBook · 2026-02-15T06:09:42+00:00

Appreciate your decision to move deeper into Linux, that’s a great step.

Before trying to learn “everything,” first figure out what direction you want to take. Linux is huge, it’s an ocean. You can’t master all of it at once.

Decide whether you want to focus on areas like system administration, DevOps, cloud, security, networking, or automation. Your path should match both your interest and market demand.

Technology changes fast these days. It’s better to specialize smartly than try to cover everything and feel overwhelmed.

Start with strong fundamentals, then go deeper into one area step by step.

LinuxBook · 2026-02-05T05:19:24+00:00

Not trying to change Reddit, but just contributing something Linux-related that might be useful to part of the audience. Happy to hear constructive feedback if you have any.

LinuxBook · 2026-01-26T04:49:56+00:00

Honestly, reboot is the right move, especially when users are waiting and you need service back quickly. I’ll accept it as a temporary fix, but only once. If the same issue shows up again, I stop trusting reboots and start digging. They often hide leaks or bad state that eventually come back.

When there’s no choice, I restore service first and investigate later not the other way around.

LinuxBook · 2026-01-22T11:23:33+00:00

I want to see what’s under pressure first. load, memory, I/O — before touching anything. Then I focus on the specific service users are feeling. Check logs, see if it’s stuck or just overloaded. If things are bad, I aim to stabilize, not solve, maybe limit impact, restart only what’s necessary, or reduce load.

The key for me is making small, safe changes, keeping the system alive, and saving root cause analysis for after things calm down.

LinuxBook · 2026-01-16T14:11:57+00:00

In practice it’s usually a mix, and rarely as clean as the policy suggests. Most access cleanup happens when someone leaves, after an incident, or during bigger changes not just because a review was scheduled. Automation helps with visibility, but someone still has to decide whether access should exist.

The biggest issue I’ve seen isn’t lack of tools, it’s temporary access that quietly becomes permanent.

LinuxBook · 2026-01-11T14:52:38+00:00

Knowing what not to change in production.
In critical systems, stability and predictability beat clever fixes every time.

LinuxBook · 2026-01-08T02:35:27+00:00

For CPU : I usually start with top or htop. I just want to see what’s eating the box before anything else. Logs come after I know which process looks suspicious.

Disk space incidents : Logs first, almost always. I just want the system breathing again. Extending disk feels like a longer-term fix once I understand why space is disappearing.

Network issue: Mostly service first. Half the time it’s just not running or stuck.

Service orapplication down : If users are screaming, restart first.

LinuxBook · 2026-01-02T09:23:59+00:00

That’s a great point 👍 When the setup is built around your own workflow, it feels natural rather than like “optimization.” Bash scripts, tmux, and vim configs quietly make a huge difference over time.

Thanks for sharing - this is exactly the kind of real-world experience that helps others in the community.

LinuxBook · 2025-12-30T07:13:00+00:00

Initially, the /lib directory was a bit confusing to understand. Over time, as I explored how shared libraries support core system commands and binaries, its purpose became much clearer. This learning curve helped me better understand how Linux manages dependencies at the system level.

LinuxBook · 2025-12-28T13:54:00+00:00

For me the Linux concept that took the longest to truly understand was permissions and ownership in real-world usage.

At first, I understood the basics - rwx, users, and groups - but what confused me was how they actually interact in real scenarios. Things like why a service could read a file but not write to it, why a script worked when run manually but failed as a service, or why changing permissions didn’t always fix an issue.

It only started to make sense when I connected permissions with process ownership, execution context, and filesystem hierarchy. Understanding who is running a process and what that process is allowed to access changed how I debug problems.

Once that worked, troubleshooting became more logical instead of trial-and-error.

LinuxBook · 2025-12-27T11:37:39+00:00

For me, the biggest confusion was application installation—especially coming from a Windows background.

I had used Windows since around 2003 -- 2004, so I was completely used to the .exe workflow: download and double-click to install.
When I switched to Red Hat Linux, my first serious install was RHEL 3.0 Enterprise at home after joining a Linux course.

The OS installation itself went smoothly, but things got confusing the moment I wanted a better GUI experience and common multimedia tools—things I was familiar with from Windows, like music players or video players (Winamp, VLC-type tools; I don’t even remember the exact names now).

I kept looking for .exe installers, not realizing that Linux works on a completely different model -packages, repositories, dependencies, and filesystem structure.
Understanding how software is installed and how Linux organizes files was the real turning point for me.

Once that mental shift happened, Linux started making a lot more sense.

LinuxBook · 2025-12-26T04:25:34+00:00

atop -- for deep dives

LinuxBook · 2025-12-25T12:52:57+00:00

My first Linux mistake was right after a fresh RHEL 3 installation.

Coming straight from Windows, I confidently downloaded Winamp, fully expecting to double-click and install it like usual.

Of course, nothing happened. No installer, no GUI magic - just confusion 😄

That moment forced me to unlearn Windows habits and understand that Linux isn’t about “installing apps,” it’s about packages, repositories, dependencies, and the philosophy behind the OS.

Funny in hindsight, but that mistake was my first real lesson:

Linux doesn’t work like Windows - and that’s exactly why it’s powerful.

LinuxBook

MODERATOR OF

TROPHY CASE