4·
7 hours agoAnd is this already where it goes wrong with people trying to use “AI”…
melroy
- 0 Posts
- 119 Comments
Joined 1 year ago
Cake day: June 20th, 2023
You are not logged in. If you use a Fediverse account that is able to follow users, you can follow this user.
Here is the GitHub page: https://github.com/MbinOrg/mbin
Nice… We welcome all users to the fediverse. Try mbin!
KIDDING! aaaaaaaaaaaaaah
Let’s ask ChatGPT! ahhaah just kidding… kidding…
I do understand why. Due to all the heated discussions with Rust in Linux, it does makes a lot of sense to rebuild a kernel in Rust from scratch. However, it will take a long time to get on the same level of Linux (read: 30+ years).
after much work, many heated discussions, and several rejected proposals, a compromise was reached earlier this year.
So what was the compromise with print_k??
1·3 days agoAlso try to use Firefox (or a fork of Firefox) together with uBlock origin.
Let’s just ditch that MacOS.
Yes I know about GPD 10 inch laptop. If you what “super compact”, then go for 7 inch right :P
Agreed. It’s 100% worth to me as well as software engineer. But maybe not for everybody. Then again, it’s the best 13 inch laptop out there for running Linux. Especially considering the 2.8k display variant with 2x scaling works great under any distro.
Yes this one. The 7 inch: https://gpdstore.net/shop/gpd-handheld-gaming-pcs/gpd-win-mini-2024/ . You wanted really really compact?
Framework laptop 13 is just a bit above 1kg. It’s 1.3kg… It is worth weighing this choice (you get the joke? hah, guhmm). If you really need something super compact and very light, maybe a old-school “netbook” will do.
Like the GPD WIN Mini (7 inch, that is super compact, right?)… But really get a Framework laptop hehe.
3·8 days agoThat is very correct. SELinux is an alternative to AppArmor. But SELinux is much more secure but that comes with a cost. And that is the cost you just described. SELinux is much more advanced and gives you much more control.
I see. Interesting. In my case AppArmor seems to be enabled by default under Linux Mint. As well as under my Ubuntu Server. I might need to look into this better, it looks like an important topic that many people overlooked.
It says for example “107 processes are in enforce mode”. But also… 4 profiles are in complain mode…
it seems like AppArmor isn’t from Ubuntu, so that is great news. So that feature alone it doesn’t require snap. But I’m now talking only about AppArmor.
But this whole ‘fine-grained access control blabalba’ does require Snap indeed…!
is that what they mean by that? I also know it reads: “Ubuntu’s AppArmor implementation". But I didn’t knew it need additional “implementation”. I can just run:
sudo aa-status. I still think it’s just a standalone module, and Ubuntu or Debian literately doesn’t need to implement anything extra afaik. Maybe only some configuration files at: /etc/apparmor.d (and most of these files are most likely also not coming from Ubuntu xD)
I still believe Framework laptop 13 is the best choice when going with 13 inch.
I got this back from ChatGPT (most likely false info!):
ChatGPT response (you have been warned)
The compromise for integrating PREEMPT_RT into the Linux mainline kernel, including the handling of printk, required several changes and concessions over time. These compromises made it possible to finally integrate real-time (RT) capabilities while maintaining the overall philosophy and structure of the Linux kernel. Key Compromises Made:
Soft-Real-Time Focus:
One of the biggest compromises was accepting that Linux would focus on soft real-time capabilities instead of hard real-time guarantees. This was crucial for widespread acceptance in the mainline kernel, as hard real-time guarantees were too difficult to meet without significant changes that would have disrupted the kernel’s general-purpose use cases. PREEMPT_RT was designed to offer deterministic behavior with reduced latencies, but it doesn’t provide the strict guarantees of traditional hard real-time systems like VxWorks or QNX.
printk Latency Handling:
Non-blocking printk: One compromise involved updating printk to avoid long blocking during logging operations. It was changed to be more asynchronous, reducing the impact on real-time scheduling. Deferred printing: Another approach was to defer the actual printing of log messages to avoid introducing large latencies in time-critical paths. The goal was to prevent printk from stalling critical tasks, especially those with real-time priority.
Voluntary Preemption Points:
Voluntary preemption was introduced, allowing kernel code paths to insert preemption points that allow the scheduler to preempt running tasks, improving latency. However, this does not guarantee immediate preemption, which is another compromise compared to true hard real-time systems. These preemption points had to be carefully placed to balance performance and responsiveness without destabilizing the general-purpose kernel.
Threaded Interrupts:
Another significant compromise was the conversion of hard IRQs (interrupts) into threaded interrupts. While this allows real-time tasks to take precedence over hardware interrupts (which would traditionally have a higher priority), it involves some overhead and performance trade-offs. Not all interrupts could be threaded easily, and this change required reworking many drivers to ensure that they were compatible with threaded interrupts.
Preemptible Spinlocks:
Spinlocks in the kernel traditionally prevent preemption. To enable real-time preemption, spinlocks were made preemptible, allowing real-time tasks to preempt even code holding spinlocks. This change wasn’t trivial, as it involved significant reworking of kernel locking mechanisms to ensure the system remained stable and avoided deadlocks, without degrading performance in non-real-time scenarios.