Extremely uninterested in sharing them with the general public. Don’t want rancid comments about my family, friends, or myself. So I stick to YouTube for all my uploads.
So, YouTube (and cloud) is just somebody else it’s computer. A computer which a large company with millions of dollars behind it, that is the main difference.
YouTube is still very big and used a lot. LBRY/Odysee tried but failed. I hope PeerTube will succeed and I really wish more tech Channels will move to PeerTube as well.
I also believe the web has to become too centralized around Google, YouTube, Reddit, Amazon and alike. The only way to open up the full potential of the internet is to use and promote these platforms. Individual forums as well as software like PeerTube. People will regret if we continue to centralized the web.
Nice to see PeerTube getting used more and more.
What are the odds?
And exactly the same type of the RedHat hats with a black line… What a coincidence?
While his statements are true. His red hat, seems like a RedHat fan. RedHat moved the Linux kernel behind a paypal. So don’t use RedHat, that is for sure.
Roger that
Nobody knows about Mbin yet?
It’s not my app.
yea correct. This app seems to be interacting with Invidious. Keep in mind that Google is changing their videos to embed ads soon in their video streams.
Also it’s NOT an Electron app haha.
This app is written in Rust and freetube is written in JS. But what is wrong with alternatives? https://rustytube.rs/
Here you go:
-`
.o+` user@intel4004
`ooo/ ----------------
`+oooo: OS: Arch Linux BCD oriented
`+oooooo: Host: Intel 4004 @ 740 KHz
-+oooooo+: Kernel: 0.0.1-custom
`/:-:++oooo+: Uptime: 3 hours, 12 mins
`/++++/+++++++: Packages: 3 (pacman)
`/++++++++++++++: Shell: sh 0.5
`/+++ooooooooooooo/` CPU: Intel 4004 (4-bit) @ 740 KHz
./ooosssso++osssssso+` Memory: 0.64 KB / 8 KB
.oossssso-````/ossssss+` Storage: None (Using Paper Tape)
-osssssso. :ssssssso. GPU: None (Terminal Only)
:osssssss/ osssso+++. Display: None (TTY Only)
/ossssssss/ +ssssooo/- Network: None (Hand-delivered punch cards)
`/ossssso+/:- -:/+osssso+`
`+sso+:-` `.-/+oso:
`++:. `-/+/
.` `/
Your files seem to be broken or not found.
I got this back from ChatGPT (most likely false info!):
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.
And is this already where it goes wrong with people trying to use “AI”…
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).
Just in time for FOSDEM :P