Everyone is making jokes but the thought has occurred to me: Yes, we have an organisation in place that is ready to replace him. But, from what I understand, he IS the benevolent dictator, and he has used his power a few times to stop some changes that otherwise would be in the kernel right now. And I think that’s a good thing.
There will not be a Linus 2, but rather there will be a peaceful transfer of “power”.
Linus is not the Benevolent Dictator For Life of the Linux Kernel.
Linus has already stepped away from developing the Kernel. He did this after an incident to work on his professionalism & mannerisms towards people. Kernel development did not stop. Linus does not approve and merge every patch into the Kernel.
Rather it is more likely that the Lead Maintainer/Developer changes to Greg Kroah-Hartmon, and the project does not skip a beat.
Rest assured with something as important as the Linux Kernel: development will keep going.
I’ve been utilizing Fedora as my go-to server operating system for over a decade, starting around Fedora 13 and consistently progressing through the subsequent major releases. Throughout this journey, Fedora has proven to be a reliable choice, offering several noteworthy advantages.
One of the standout features of Fedora, reminiscent of its desktop counterpart, is the availability of up-to-date and cutting-edge packages. With the backing of Red Hat, compatibility with a range of software, including SystemD and FirewallD, enhances its appeal for server applications.
However, it’s crucial to consider Fedora’s rapid release cycle, with a new version emerging approximately every six months and a 13-month support window for each release. While this frequent update schedule ensures access to the latest features, it can pose challenges for server environments where uptime is critical, and system administrators may find it demanding to keep up with the pace while managing compliance, audits, and other business processes.
Despite these considerations, my personal experience with Fedora as a server has been exceptionally positive. The OS has demonstrated robust performance across diverse environments, seamlessly adapting to various setups, from bare metal and virtual machines to containers. The flexibility extends from smaller hardware configurations like the Raspberry Pi to more substantial servers with 40+ vCPUs and 1.5TB RAM.
SELinux, a crucial component for security, seamlessly integrates with most applications, but I have encountered some challenges with WINE headless server programs, particularly for hosting Windows-based game servers not originally designed for Linux. Additionally, compatibility with Debian-based Crypto wallets proved to be a stumbling block, requiring the use of a Debian VM for compilation and subsequent transfer to Fedora.
In terms of server redundancy and monitoring, I rely on three Fedora servers equipped with essential software such as Nginx, Grafana, Prometheus, Influxdb, and fping. Wireguard and Samba facilitate automated file transfers between another set of servers, contributing to an efficient setup.
Automation plays a significant role in my server management, with Ansible and Bash scripts streamlining tasks such as package installations, configuration adjustments, and firewall rule setups. Each Fedora server is configured for self-startup to ensure uninterrupted operation in case of power failure or manual reboots.
I’ve successfully integrated an LSI/Intel server RAID card into one of my Fedora servers, and the third-party RPM package for monitoring (storcli64) installed seamlessly. LSI card driver support is built into the Linux kernel, contributing to a hassle-free experience.
The only notable limitation I’ve encountered pertains to desktop gaming, a domain where I’m exploring transitioning to Fedora. For gaming servers requiring Steam/SteamCMD and Windows DLLs, alternative solutions might be more suitable, unless willing to navigate potential challenges with WINE and SELinux adjustments.
In conclusion, the suitability of Fedora as a server hinges on your specific use case. For web or Internet of Things servers, it stands out as an excellent choice. However, if your requirements involve gaming servers with Steam dependencies, alternative options may warrant consideration. As I’ve explored various Linux and *BSD systems over the years, Fedora has proven its versatility, offering a compelling solution for a range of server applications.
Wayland imposes new rules, and one of those rules being that programs can’t arbitrarily access keystrokes and mouse input. This is done to protect against keyloggers as they are used by malicious actors to gain a bevy of information like passwords, banking information, personal information, etc.
I’m unsure if it’s Firefox, the RMM or both, but the necessary permissions aren’t granted and that’s why it’s not working.
Podman is getting worse, for instance they recently deprecated systemd generate and tell you to use Quadlet, for running pods, you need to use Kubernetes. This greatly complicates my workflow.
SELinux, while secure, and easy to troubleshoot with Cockpit, is a major pain in the ass that prevents most containers from accessing their data directories. It can be corrected but is extremely frustrating.
Quadlet is extremely inconsistent, I can copy the working unit file for a container and it works, change the name and variables for another container, and one launches but the other won’t start. One will have the wrong name. Stupid things, like putting the name in quotes, reloading, removing the quotes fixes it. I have harsh words for the idiot who deprecated systemd generate.
something like Tiddlywiki, their documentation will put you in /var/www but Fedora uses /usr/www or something. You get used to the Fedora things but you can end up on a goose chase sometimes.
Those cons are starting to hit hard, and when I reimage this server next I’m probably going to Proxmox or Debian. Server 37 was good but I probably won’t bother with 39.
Fedora uses /var/www. Dunno what gonk you read or told you otherwise. There’s SELinux policies built in for that directory. You probably are confusing the default html files at /usr/share/html. These are separated intentionally. The /usr/share/html directory is managed by RPM, the other /var/www is content designated as web server files.
Based on opinion, but okay, I'll give you that one.
Ubuntu has terminal built-in, it's far from hidden. Most Android installs (average smart phone) don't include a terminal, you have to either use adb from a computer, or download a terminal from an app store.
Ubuntu's root user is not locked down. By default the user can run any command they want using sudo, and a basic google search will tell them how to enable root login fairly quickly. By comparison, just about any android smartphone has to be "jailbroken" using an exploit in order to access root. Some phones, especially in the USA, can't be jailbroken at all.
Ubuntu is pretty upfront about any telemetry and allows you to disable it easily. A lot of Android's telemetry can't be opted out of, unless you happen to have an unlocked bootloader and can install a privacy-focused custom ROM.
These are not the same, although I get the point you're trying to make. Ubuntu has a user-friendly interface, with a goal of making Linux accessible to all. But for anybody who wants to, it's fairly easy to dig into the internals and become a "power user." It certainly makes no attempt to stop you from doing so. Android, on the other hand, on MOST instances, locks down everything, with little to no overrides, even from the user, many times "in the name of security."
Ubuntus terminal isn’t really hidden. The root user not being usable (heavily advised against) is a good thing for almost all situations (something I wish windows would also do by default).
Android is built entirely for mobile devices. Ya sure you CAN get it running on other devices, but why?
Friendly interfaces, is subjective tbh. I think I get where you’re coming from.
If I’m not mistaken, I believe the 2018 J3 has a locked bootloader. The fact that I can’t find even a SINGLE custom ROM on XDA for this model means it’s highly likely that the bootloader is locked, and/or the device isn’t dev friendly (no kernel sources available etc).
so I guess doing the same on my smartphone wouldn’t be too hard.
Mate, you’ve no idea… Smartphones are a completely different ball game to desktops. You could try and compile your distro, but without the kernel sources and drivers for your specific model, nothings gonna work. You won’t even be able to boot the damn thing. And even if you did have those, it’s going to take a LOT of effort just to get basic OS functionality working. Forget getting actual phone stuff working, like making calls etc - that’s next to impossible. Even large projects like PostmarketOS struggle to get basic functionality going even on dev-friendly phones.
But you can stop dreaming about all the above if you can’t even unlock the bootloader.
Basically, what all this means is that there’s no point wasting your time on the J3. Stop right now and don’t waste any further time on this.
If you’d really like to run GrapheneOS / Linux on your phone, your best option is to sell your J3, and get a used Google Pixel from Swappa/eBay or something.
To be fair they’re ARM-based devices (most of them anyway) and linux works fine onthat architecture. The Raspberry Pi and others, Microsoft has Windows on ARM; as do the new M-series from Apple.
It’s all the obscure hardware, bootloading and vendor lock-in that kills it.
Android is a mobile operating system owned by one of the 3 largest tech companies in the world.
Ubuntu is an alternate desktop OS for users of x86 systems that can’t pay a licence, want to bring new life to old hardware or just want to use something other than Windows or MacOS.
linux
Active
This magazine is from a federated server and may be incomplete. Browse more on the original instance.