I have an issue with the way udev and pipewire handle hardware failure. There is two computers, one based on an old Asus parentboard (Intel b150 chipset) and another is build on newer asus board (AMD A520 chipset). The first system has issues with malfunctioning usb cardreader. I don't remember log messages (maybe I will be able to find them with journalctl). The second system has a problem with faulty webcam. Pipewire freezes after connecting the webcam, but it's still running according to systemctl. The kernel log contains messages like ```3:1: cannot get freq at ep 0x84``` and ```usb_set_interface_failed(-32)```. Multimedia playback is completely nonfunctional until the camera is removed.

I've had an idea for some time for a fully distributed OS across multiple hosts for virtualization.
1.) I can script but I cant do any level of programming to the level of C that seems to be needed to accomplish this.
2.) I am trying to gauge the realistic possibility of this so feel free to poke holes.
3.) If I over simplified anything please fill in any gaps I may have missed. I want to understand the challenges as well.

Lore: I work a lot with VMware at work and KVM at home. I have little experience with Hyper-V but the main take away I have found with most hypervisors is that VMs run on hosts and they can be moved between hosts If a host becomes overloaded then the VM has to be moved to another host to move that workload off the problematic host. In my experience in larger clusters there are often available CPU/GHZ that could be utilized for compute operations here and there.

End Goal: I've been researching different technologies like Infiniband and PCI Fabrics. The thought of removing the idea of dedicated hosts and storage cropped up. In the end you extrapolate the CPU and RAM from each host to then be accessible as a pool of resources in a cluster. Allowing for processes to be ran across the cluster not tied down to a single host.

My Research: My original thought was possibly getting involved with modifying the CPU scheduler but this is not remotely in the realm of an achievable idea after looking into it. I then realized that KVM and VMware allocate resource based off NUMA nodes. If there is a way to get a single host to detect the NUMA nodes of remote hosts then any sort of resource scheduling should be able to allocate CPU cycles across other hosts.

A big concern is latency, From my understanding the L1 cache on processors can have a latency of 1-4µs. InfiniBand seems to manage that same level of latency however I do not know if its 1-4µs from Interface card to interface card using RDMA. RDMA though is remote memory access. No telling what added delay could occur if RDMA could interact directly with the remote processor and the path it may have to take and the added latency.

Ive asked this same type of question on r/HPC about this and folks mention ScaleMP and Plan9 but I am not entirely sure if these accomplish what I thinking about. Not atleast from what I have read.

If you read this far....Thanks!

I took the plunge, I distrohopped quite a bit, settled for now on Ubuntu (I know, very mild choice... It just works though, and im content with it. Probably will change in a while)

Of course i dual boot between windows and ubuntu, but i spend most of my time in the later. In fact I havent booted up windows in a week which is surprising since i am always on my PC. I love how customizable it is, even ubuntu, i love the gnome shell with the blur my shell extension and the green wallpaper with the forest and the aurora. And what makes me even more happy is the fact that i spent some time editing bashrc and messing around with the terminal and i got it to give me a cow with a random fortune in random lolcat colors every time i open it. It makes me want to study computers more in depth and how they work.

Hey r/Linux I'm the developer of Tiling Shell, a GNOME extension for advanced window management. It's highly configurable and offers different ways of tiling and managing your windows. The focus is on delivering the best user experience, highest stability, and full customization. Give it a try! Link for download.

https://i.redd.it/81dxhrbrajge1.gif

It also works with multiple monitors (even if they use different scaling), comes with a number of tiling layouts built-in but there is a layout editor to allow you to create and save customs layouts.

Tiling Shell also features the Snap Assistant, borrowed from Windows 11: just move a window to the top with your mouse and the Snap Assistant slides in and you can place the window where you want and how you want.

• I've implemented automatic tiling as well
• Fully customizable keyboard shortcuts to tile, move windows, change focus and more
• You can also move the window to the edge of the screen to tile it
• Right click on the window title to place the window where you want and how you want it
• Coming soon this week, Windows Suggestions: after tiling a window you get suggestions for other windows to fill the remaining tiles

There are other features but the list is too long for a short reddit post. Tiling Shell supports GNOME Shell 40 to 47 on X11 and Wayland. See you on https://github.com/domferr/tilingshell for documentation, demonstration videos, feature requests and bug fixes!

This might not be the regular post up here but hear me out: My wife received a drawing tablet as a gift 6 years ago. She decided to use it again on her new laptop. Pressure sensitivity would not work and I could not find any drivers for it anymore. I told her: wait, I'll try Linux. I booted a very popular beginner distro on her laptop. One calibration later, Gimp worked perfectly with it! Including pressure sensitivity and pen buttons. That is a big win!

Morale of the story: If someone is on Windows or something else and stuck with old hardware that won't work with it anymore, Linux might just help them out!

Mostly asking cause 1. Thought it might be a good project to simple learn how Linux works (especially if I go through LFS) and 2. Mainly cause I am curious why there are different Linux distributions out there.

From a couple of people I talked to, mostly it not worth the time unless you just want to experiments. However considering there are variety of different Linux distros to download and with the development of distros like Steam OS. I got curious as to what reason there would be to actually build one yourself.

Experimentation with different packages/programs? Design philosophy you are trying to achieve? Maybe make something you think would work better outside the conventional options for Linux?

Edit: ngl I find it hilarious how like 15-20% of the comments are like “ahh it’s a good learning experience and fun to experiment” and the rest is simply “idk, bored? Go for it but expect to rip your hair out”

tl;dr

• many employers don't like linux
• advantages / disadvantages of other systems

Many employers require using one of those, allowing only for virtualizing Linux if you'd like to, sometimes not even that. I worked in VM the last three years, but I'm a bit tired of poor system performance (and always-running ThinkPad fans, lol).

Windows is a pain in the ass, especially these corporation versions are unusable, but well… it's still Windows that is supported by almost everything.

MacOS has more in common with Linux, especially a better terminal. On the other hand, I never used one, and I'm uncertain if it's as capable as Windows.

What do you think? What advantages and disadvantages do you see in both - and, ultimately - what would you decide?

My context is data science / software engineering.

When I search about the problem, I see that there are pages and pages of questions.When I search about the problem, I see that there are pages and pages of questions:

https://www.google.com/search?q=GCVM_L2_PROTECTION_FAULT_STATUS%3A0x00000000

nvidia drivers are known to cause problems with the initial installation. So would it make sense to struggle a bit with the initial installation and get more comfortable in daily use, or are the drivers from both companies equally problematic?

I can't talk that technical, but I don't think it first takes technical knowledge to think about what you want Linux to do in order to be a secure system.

What is there to do, the best to do, regarding sandboxing programs? How can I manage every single permission of every program, and be certain that one program won't possibly, even under compromise, be able to interact with the system, if the app doesn't normally need to.

There are some good and accepted arguments about how Linux sandboxing is a lot weaker than that of Windows.

A note to myself is Secure boot, which I find out is a way to only run the things you choose to be ran, making sure nothing else happens, which is something I wish to explore more later.

I wish to get a guidance, tutorials, and tips that will make me understand what do I need to do and why, especially for sandboxing.

Also isn't being able to use sudo command a way to compromise root access? Again I am not that technical but I want to note that this is also something that bothers me, taking care of root.

https://www.nvidia.com/en-us/drivers/details/240524/

Release Highlights

• Fixed a bug that caused the nvidia-settings control panel to crash when querying VRR attributes on some monitors.
• Updated the nvidia-settings control panel to use NVML rather than NV-CONTROL to control GPU clocks and fan speed. This allows related functionality to work when using Wayland, where the NV-CONTROL X extension is not available. Note that as a result, some operations which were previously available to unprivileged users, due to the privileges of the X server, may now require elevated privileges.
• Added support for VRR on systems with multiple displays.
• Added an application profile to improve performance on Indiana Jones and the Great Circle.
• Added an application profile to resolve a corruption issue on Assassin's Creed Valhalla and Assassin's Creed Mirage.
• Implemented support for the VK_KHR_incremental_present extension.
• Fixed a bug that could cause some Vulkan applications to crash when responding to window resize events.
• Updated GPU overclocking control to be available by default in nvidia-settings, for GPU boards that support programmable clock control. Previously, this was only available when bit 3 was set in the "Coolbits" X config option.
• Disabled a power saving feature on Ada and above generation GPUs for surfaces allocated with the DRM Dumb-Buffers API, for example, when using a DRM fbdev. The power saving feature could cause black screens for DRM Dumb-Buffers which use front buffer rendering instead of KMS flips.
• Fixed a bug that could cause some multi-threaded OpenGL applications, for example Civilization 6, to crash when running on Xwayland.
• Added support for querying Dynamic Boost status via the 'power' file in /proc/driver/nvidia/gpus/*.
• Enabled 32 bit compatibility support for the NVIDIA GBM backend.
• Added a new kernel module parameter, 'conceal_vrr_caps', to the nvidia-modeset kernel module. This parameter may be used to enable usage of features on some displays such as ULMB (Ultra Low Motion Blur) which are incompatible with VRR. See the "Direct Rendering Manager Kernel Modesetting" (DRM KMS) chapter of the README for further information.
• Fixed a bug that could cause games to crash when the "PROTON_ENABLE_NGX_UPDATER" environment variable was set to a value of "1".
• Added /usr/share/nvidia/files.d/sandboxutils-filelist.json which lists all the driver files used by container runtime environments such as nvidia-container-toolkit and enroot.
• Added support for the systemd suspend-then-hibernate method of system sleep. This feature requires systemd version 248 or newer.
• Enabled the nvidia-drm fbdev=1 option by default. When supported by the kernel and the nvidia-drm modeset=1 option is enabled, nvidia-drm will replace the system's framebuffer console with one driven by DRM. This feature can be disabled by setting fbdev=0.
• Implemented a feature that allows low latency display interrupts to be serviced even when the system is under heavy contention. This is especially useful for reducing stutter when using virtual reality. This feature is experimental and disabled by default. This feature can be enabled by loading nvidia.ko with the `NVreg_RegistryDwords=RMIntrLockingMode=1` kernel module parameter.
• Fixed a bug, introduced in 555.58, where some DVI outputs would not work with HDMI monitors.
• In Linux kernel 6.11, drm_fbdev_generic was renamed to drm_fbdev_ttm. Use drm_fbdev_ttm when present to keep supporting direct framebuffer access needed for Wayland compositors to present content on newer kernels.
• In linux-next commit 446d0f4849b1, output_poll_changed is removed from struct drm_mode_config_funcs. Do not implement the function pointer member when not present to ensure the driver can compile with newer kernels. The driver now supports enumerating modes on hotplug events through the DRM fbdev API.
• In linux-next commit 446d0f4849b1, intended to be included in Linux kernel 6.12, output_poll_changed is removed from struct drm_mode_config_funcs. Do not implement the function pointer member when not present to ensure the driver can compile with newer kernels. Populating modes for DRM connectors during hotplug events will not be supported with r535 and kernels containing the relevant commit.
• Fixed a bug that could cause external displays to become frozen until the next modeset when using PRIME Display Offloading with the NVIDIA dGPU acting as the display offload sink.

So there I was, excited to dive into WSL, thinking, "Wow, Microsoft is really embracing Linux! This is a great way to get Windows users to dip their toes into the world of open-source without the fear of accidentally nuking their C drive!"

And honestly? WSL is pretty great. Want to install Linux packages? Easy. Want to access your Windows files? No problem. Want to spin up a development environment without dual-booting or running a VM? Chef’s kiss.

But then, in my infinite wisdom, I thought: "Hey, let’s access a USB drive."

Oh. Oh no.

I naively assumed I could just plug in my flash drive and, I don’t know… mount it? Like a normal person? But no, WSL looked at me like I had just asked it to solve world hunger.

A quick dig around, and apparently, if you want WSL to see your USB device, you might need to:

1. Jump through a series of PowerShell commands.
2. Install some third-party software.
3. Sacrifice a goat.
4. Maybe—just maybe—rebuild the Linux kernel on Windows.

At this point, I started to think: Is this deliberate?

Microsoft wants us to try Linux. They want us to get comfortable. But then, just as we start feeling at home, they throw a curveball: "Oh, you wanted to access a USB drive? That’s adorable."

Next thing you know, frustration sets in, you're sighing and thinking, "Man, maybe I should just use Windows for this one thing..." And BOOM. That’s how they get you. The long con. A bait-and-switch. Linux was the carrot, but Windows was the stick all along.

I can’t prove this, but I'm not sure it can be disproven either...

DISCLAIMER: this is my PERSONAL opinion. I tend to have peculiar taste, so please don't get offended if I didn't appreciate your distro/DE of choice.

My linux journey started around 2 years ago. For almost a year, I've tried most distros there is. For some reason, I've never felt at home on "main" popular ones. Ubuntu, Fedora... those are great, but to me they feel too "corporate" and have nothing outstanding (no dedicated set of tools, optimized kernel and such).

In the end and in the past year, I've settled on Solus, OpenMandriva, CachyOS and MX Linux. I also had great experiences with KaOS, PCLinuxOS (only on older hardware) and openSUSE.

I don't find the appeal of "big main" distros. For exampple, Debian 12 is great but MX Linux (which is Debian based) provides an amazing set of tools out of the box, as well as AHS Kernels for compatibility with newer hardware. Arch is nice, but CachyOS provides an easy installer, optimized kernel and nice tools too. OpenMandriva ROME has been the most stable rolling distro I used (even compared to Tumbleweed) and their community forums has been the friendliest. Lastly, Solus has been hands down the best NVIDIA experience on a few of my computers, and it felt the most straightforward and polished.

I could say the same things for DE. KDE Plasma being the exception, as I found it the absolute best. But in my opinion, Budgie is way more polished and easy than Cinnamon, which feels quite "amateurish".

Anybody else had a similar Linux journey and tends to prefer smaller projects and linux distros?