• 0 Posts
  • 21 Comments
Joined 1 year ago
cake
Cake day: July 18th, 2023

help-circle


  • The flowchart is as follows:

    LibreOffice or OnlyOffice for desktop apps (no, they are not Microsoft apps, but yes they use Microsoft formats and can edit and save Microsoft documents/spreadsheets/etc). OnlyOffice is the closest of the two to the Windows experience.

    If you really aren’t open to using alternative software (which is strange given that you’re using Linux), then the web apps exist. I’ve heard they’re really close to the actual desktop suite, though I don’t have any interest in ever using them as we have very good free and open source alternatives available (see above).

    If the web apps don’t cut it for you, then you can run the official apps in a VM, or maybe through WINE. Here’s the WINE DB page for Microsoft Office, which lists various Office versions and their level of compatibility through WINE.

    Copilot will likely not be possible to secure on Linux in a standalone desktop app (unless someone somewhere hacked something together through Electron to use a web version). Another user said that Copilot is available inside Microsoft Edge, so I suppose you could install that, though I’d highly discourage that. Reliance on LLMs is quite frankly a plague to society, and often feeds incorrect, biased, or purely fabricated responses, as LLMs merely attempt to predict what word is most likely to occur next based on a set of training data, none of which was vetted for accuracy, racism, zionism, sexism, etc. LLMs like copilot do not have any form of intelligence, and do not understand what they are saying. I highly recommend you just use a search engine in your browser, because it’ll feed you the same info all the LLMs were trained on anyway.

    OneDrive recently received native support in GNOME, so I think you should be able to access it in your settings under accounts/connected services (whatever GNOME calls it nowadays)? I’ve never tried to use it, so other people will know better than I will there, but it should be possible to use.


  • Did you check the MD5sum? If you did (and it actually matches), try using a different media creator. You can use something like Rufus or Fedora Media Writer (yes, you can install non-Fedora ISOs with it, the only extra feature it has is that it will automatically download Fedora ISOs you want). If other media creation tools don’t work, try a different flash drive, as that’s the next most likely issue.



  • The only reason that the Fedora Project exists is for community development. There is simply nothing Red Hat could ever stand to gain from changing that model, as they’d lose the entirety of what they are paying for by sponsoring the project. In order to do anything, they’d first need to dissolve FESCo, which would make HUGE waves across the internet. You and anyone else in the community would see news and posts about it immediately. Once that happens, the project dies. Community members are not going to contribute to a project that betrays their trust, after all. So in trying to change anything, the only thing Red Hat would be doing is moving a project that they are paying a relatively small amount of money for (relative to the number of contributors) from community developed to Red Hat developed. That means that they have to personally invest money into maintaining and employing contributors themselves, completely defeating the point of Fedora existing in the first place. If they wanted to privately fund development, why wouldn’t they instead do it in RHEL, or CentOS Stream?

    Let’s analyze Red Hat’s current gains from Fedora one by one:

    1. Fedora is a place for Red Hat to test new features before they move to RHEL.

    This requires an active userbase, and by privatizing or taking over the project, that userbase would rapidly diminish. Red Hat cannot increase this benefit by any means, other than by leaving the project be as is.

    1. Fedora is community developed, so Red Hat can benefit from commits made by the community (people they don’t pay).

    Privatizing or taking over the Fedora Project would immediately end that community development. There’s nothing in this respect that Red Hat could possibly intend to gain from such an action.

    1. Red Hat’s image appears better by sponsoring a community developed project.

    It should go without saying that their image would only be damaged if they tried to modify their current relationship.

    These are the things that Red Hat is paying for by sponsoring the Fedora Project. A hostile takeover would have exactly zero potential gain and very high potential losses in each of these categories; thus it doesn’t make sense in the slightest.

    Now let’s analyze some new potential gains that Red Hat could get by a hostile takeover:

    1. Monetizing Fedora.

    This is Linux we’re talking about, attempting to sell a consumer Linux distro for money will not fly, and no one will buy it. After all, even when enterprises by RHEL licenses, they aren’t paying for the software itself. What they’re really paying for is the support package and direct hotline to Red Hat for any technical difficulties. Red Hat makes its money by offering support services, something that does not have any realistic market for the general populace, especially considering the userbase we’re talking about are Linux users.

    1. That’s really it.

    There’s just nothing else Red Hat would even stand to gain from any hostile takeover. The only potential motive is money, and Fedora is not a product that will ever generate them revenue. Consumers don’t want to purchase licenses, and enterprises don’t want consumer desktop distros with 6 month release cycles.

    Red Hat funds Fedora because it is of great benefit to them to keep it alive, and continue its development by the community. Changing their relationship with the Fedora Project would not only lose the exact benefits they are receiving, but also cost them money, as they will no longer have thousands of community members volunteering their work, and they would have to hire contributors to fill that gap. Additionally, why even bother speculating? It isn’t difficult to move distros nowadays, so if anything ever were to change, you can jump ship on any day of the week to another distro. We seem to live in a world where logic is challenged by a thousand “but what if?” statements that have no basis in reality. It’s quite a pointless endeavor, honestly. What if the distro you choose gets bought out by Google, or Microsoft? What if the distro you choose is secretly funding antisemitism with donation money? What if the distro you choose suddenly dies? These are all absurd questions to speculate on, all to no real end. They each have the very simple solution of “just install a different distro if that happens”. But what if a company tries to exploit a distro for money? There’s no point in even speculating that because there isn’t even any money to be made from consumer desktop distros. The money to be made from Linux is not in the consumer desktop platform, it is in the realm of businesses (enterprise software, embedded systems). There are far too many free options out there owned by nonprofits to ever consider marketing a consumer Linux distro like that. Even with stuff like Ubuntu Pro, you aren’t paying for a license to the distro; you’re paying for extra support.

    Why are we treating Red Hat like the most evil company in the world, anyway? As far as tech companies go, they’re pretty damn ethically sound. They’re not nearly as bad as Google, Microsoft, Amazon, Apple, IBM, or any number of other tech companies that release proprietary software with no access to source code, massively violate their users privacy, exploit consumers in harmful ad campaigns, etc. Google, one of the most unethical companies in the world owns Android, but we still have AOSP, which is the foundation for custom ROMs like GrapheneOS and LineageOS. If they believed that trying to shut down AOSP would make them money, they would have tried it years ago. Of course, doing so wouldn’t even be legal, as it would be violating GPL.

    I’m just not seeing what exactly you’re imagining Red Hat could take away from Fedora for their own gain. Nothing they could do that would have a negative effect on users would result in a gain for Red Hat, as they’d be losing everything they gain from the Fedora Project. In order to make any changes to the development of Fedora, they either have to pay developers to make those changes, or convince community members to do it for them (which is not going to happen if these changes are negative), and that’s assuming that they manage to dissolve FESCo to get these malicious changes approved.

    You don’t want to rely on a project that’s funded by corporations? Where do you think the funding for the Linux Foundation comes from? Companies like Google, Microsoft, Amazon, and IBM fund the Linux Foundation, so any OS that uses the Linux kernel will be financially dependent on corporations. That’s something you’re never going to be able to avoid.

    I don’t understand why this has been blown so far out of proportion. What’s the point in excluding a very good distro that suits your needs perfectly over a fear that some day, somehow, in the indeterminate future, that there would be some new financial incentive created out of thin air that would cause Red Hat to try to take over Fedora? What guarantees that same situation or one similar wouldn’t happen to any other distro you could choose? And to that end, why would Red Hat take over Fedora instead of creating a new fork that they could sell so they can still get all those benefits of community development? I don’t see how any financial incentive created by Fedora wouldn’t be possible to gain downstream.


  • There’s a question that I feel I don’t adequately answer in my previous comments, but I feel as if I should address.

    Does Red Hat implement their own features in Fedora, and what does that mean for the community?

    The short answer is yes, there are Red Hat developers who do work on Fedora. Just as Canonical developers contribute to Debian, Red Hat contributes to Fedora. There is a very important distinction between the development of Fedora and RHEL though, and it’s the same reason no one is up in arms about Canonical contributing to Debian. The changes that Red Hat makes to Fedora still have to be approved by FESCo, so they still have to represent the interests of the community. Red Hat can feel free to pay as much as they like into the development of features, but if those features would contradict the values of the Fedora Project or go against the wishes of the community, they wouldn’t be approved in the first place. Red Hat sees Fedora as a very valuable resource that they can use to test features before they arrive in RHEL. Unlike Canonical, however, they don’t push proprietary solutions, tracking, or pro subscriptions into a consumer desktop platform. Those changes would not be representative of the wants of the community, and would not be approved by FESCo (hence the benefit of a community elected board).

    There’s a related follow-up, as well:

    Are there Red Hat developers in FESCo? What does that mean for Fedora?

    Yes, there are a few Red Hat developers in FESCo, you can view their bios on the Fedora Project website. They were not placed there by Red Hat, however. These are still people that were elected by the community, who would not be there unless users (and other developers) trusted them to make decisions in the interest of the community. You can nominate and vote in the elections as part of the community if you wish.

    The biggest factor that I often see glossed over (and perhaps the most important reason Fedora has independence) is that Red Hat doesn’t have any reason to even attempt to corrupt it. Fedora users are not an audience they stand to make money from, and if Red Hat believed there was money to be had in the consumer desktop platform, they would already be selling a product. There is mutual benefit between Red Hat and the Fedora Project, and that gets passed onto the community. Red Hat benefits from the contributions of the community, while simultaneously being able to test new features in an audience that they aren’t interested in selling to, and the Fedora Project gets money and active development back from Red Hat as a result.

    Now I’d also like to clarify, because I could understand confusion as to what I meant when I said Red Hat doesn’t control the Fedora Project. Red Hat is allowed to make contributions to Fedora, so long as they meet the same approval criteria as any other merge request from any other person/entity. Red Hat, however, is not able to control how money is spent, or where the priorities of community developers are focused (the direction of the project). So they are free to make contributions to Fedora that benefit everyone (so long as their changes are approved), but not free to test RHEL specific features that don’t have a place in Fedora, for example. In fact, since Red Hat wants to keep their source code away from anyone that doesn’t pay them a subscription, they actually have a vested interest in keeping those RHEL specific features separate from Fedora, as to not make them easily accessible to potential competitors. This is how they’re addressing the competition posed by Rocky/Alma/Oracle Linux.


  • Excluding Fedora because it’s “too close to RH” doesn’t make any sense at all. Fedora is not controlled by or influenced by Red Hat, and Red Hat has no interest in a consumer desktop platform that they can’t sell. Fedora’s development is managed by FESCo, a community elected board that represents the interests of the community. They are kept intentionally separate from Red Hat’s development, and do not make any effort to target their development to Red Hats wants or needs (in fact they often do the opposite, as Fedora pushes for change in the way things are done, not stability, as can be seen by the exclusion of X11 from Fedora 40, for example). That stands in direct contradiction with RHEL’s goals. Red Hat’s entire business is in enterprise. There is exactly $0 in potential revenue from Red Hat trying to take over Fedora, it just doesn’t make sense. They can’t sell anything, and since Red Hat doesn’t employ the developers, such a takeover would simply result in a new fork. In fact, it would be against their interests, as Red Hat actively benefits from the developments of the community. Taking over control of the project would lose them all of the constant volunteer work put in by the community, which costs far less for them to sponsor than it would to employ a team a fraction of the size on salary. I’ve discussed this topic at length many times before, so I’ll just link to a few comments that explain the situation in more detail (including how the project is funded, managed, and separated from Red Hat).

    https://lemmy.world/comment/7490965

    https://lemmy.world/comment/7494803

    The best fit for your criteria is Fedora. If you want uBlue spins, you’re still getting Fedora, just a more opinionated version. All of the major development of uBlue’s images comes from Fedora though, as they don’t maintain their own distro, they just repackage Fedora.



  • It is certainly helpful in preventing issues caused by packages updating, as the whole base image should remain consistent (and you could always just roll back to the previous update from grub if necessary and revert a commit that broke your system). Since you were using Arch, I made a baseless assumption that you would want the ability to modify the root filesystem for configuration, but it was a baseless assumption, so if that is not the case, then atomic distros are great for users that don’t want to tweak tiny things in root directories like /usr. Granted, you can still overlay stuff if you wanted, so it’s not as if you couldn’t tweak stuff in immutable directories, it just requires a bit more work to do on atomic distros.

    If what you’re looking for is a standard desktop KDE experience with a distro that is more resistant to breakage, I’d highly recommend Kinoite. It requires a bit of learning, but not a whole lot. For instance, the typical order of priority for installing packages is flatpak (mostly GUI stuff) > toolbox (terminal-based packages like neovim that aren’t already installed) > overlay with rpm-ostree (basically the equivalent of installing through your package manager). The fewer overlays you have, the better your protection from spontaneous breakage is. Of course, there are packages you will have to overlay depending on the situation (like the proprietary Nvidia drivers), but almost everything I need was available as either a flatpak or was practical to install in toolbox (basically a containerized mutable root that lets you install stuff with dnf instead of rpm-ostree). You can add aliases to your .bashrc so you don’t have to type “toolbox run <cmd>” every time, as well. Just be aware that packages installed in toolbox live in a container, and they aren’t intended to be able to break out of the container (so if you open a terminal in neovim, which is installed in a toolbox container, it will open a shell inside the container, not on your host). Containers can access your home directory and a variety of different directories in your system, so this often isn’t an issue, it’s just something to keep in mind (for instance, you can’t enable systemd services on your host from inside a terminal).


  • I’m also going to echo the sea of comments praising KDE support on Fedora. I just switched to Kinoite/Fedora Atomic KDE (for the Fedora 40 release) after using Fedora Workstation for about 5 years, and I’ve loved the experience. My only gripes have been from adjusting to an atomic distro, and have had nothing to do with KDE implementation. It seems that Fedora works very well with KDE, though I suppose I don’t have a whole lot of experience with other distros using KDE.

    If you want to use KDE with a standard desktop experience, just use the KDE spin (the standard mutable version). If you’re interested in atomic distros (not trying to convert you, it’s very much a personal preference), then they have the atomic KDE spin as well. I don’t think you’ll be missing anything by using KDE on Fedora, and unless you wanted to experiment with GNOME, there’s no reason to really switch. Workstation and the KDE spin are both maintained at about the same level.


  • From your recommendation, I found a related project pandoras_pot that I am able to run in a Docker container, and seems to run more efficiently on my Pi home server. I now use it in my Caddyfile to redirect a number of fake subdomains and paths that are likely to be found by a malicious bot (of course all are excluded in my robots.txt for bots that actually respect it). Thanks for the recommendation!


  • TL;DR: Install Fedora from a liveUSB, as recommended in all the official documents and guides. If you have a secure boot issue, it’s likely because you installed from a VM. VMs run in BIOS mode by default, so the Fedora installer would install to your SSD without UEFI secure boot compatibility.

    It seems like you may be overcomplicating things here. Why install to your SSD from a VM? Why not just make a liveUSB, boot into that, and then install to the SSD? That’s the recommended install method, and is far less error prone. The UEFI error you linked is resolved in Fedora 40 (which releases on the 23rd), but I highly doubt that was your issue, it seems like quite the long shot. Additionally, you do not need a swap partition (swapfiles have been standard for a long time), and honestly I’d just recommend you stick to the default partitioning scheme if you aren’t already comfortable in Linux. Less room for error that way.

    If you believe secure boot to be an issue (like you seem to based on the issue you linked), then you should know that VMs all run in BIOS mode by default, not UEFI, so installing from a VM will not install with UEFI secure boot compatibility (hence why you should use the recommended method of booting from a liveUSB). This is why I don’t believe the issue you linked is related, as if secure boot were the problem, than the issue is the fact that you’re installing from a VM, since the VM will only know that it was booted in BIOS mode and do a BIOS mode install with no UEFI secure boot compatibility.

    Tails is meant to boot from a USB drive, it is not meant to be installed on your system, so I’m not sure why you wanted to partition for it. I’m not even sure that it has an installer, because all the official documents and guides only talk about using a liveUSB (how it’s intended to be used).

    I’m a bit confused why you chose to go this route to installing Fedora, as I’ve never seen a guide or any official documentation recommend a setup like this. Any guide you find online should tell you to use a liveUSB for installation, and that’s by far the easiest way. So I don’t quite understand the complaint about how “difficult” Linux is to install for the average user when you aren’t following any official way to install it. The “hoops” you jumped through all seem to be self-imposed. If you are actually experiencing a hardware-related issue, then the next step would be to try a different distro, but you need to try an official installation method before that, because that’s most likely your issue. Again, if secure boot is the issue, then you will experience the same thing from any other distro if you try to install it from a VM. That simply won’t work.

    Fedora’s official documentation has you go to this page to download the Fedora Media Writer for Windows (an alternative to Rufus/Ventoy that will automatically download the Fedora ISO for you). You run that .exe in Windows with a USB flash drive plugged in, and it’s self-explanatory. Then you boot into the liveUSB you created (you may have to go into your BIOS and enable USB booting), and follow the installer steps. I suggest you wait until Fedora 40 releases on Tuesday, as it’s less than a week away. If by some long shot that issue you linked was in any way related, it is fixed in Fedora 40. No need to rush things. Just follow the official installation instructions, don’t go off on your own, and see if it works. If it doesn’t, you have a hardware issue and you can try to install something like Debian to see if it has the same hardware issues.



  • It seems you’ve chosen a DE that is not particularly well-suited to this task. Cinnamon is meant to be simplistic, and offer an easy transition from Windows with its Windows-like layout. It is purposefully less customizable than many other DEs. I second the recommendation of KDE Plasma, as this is actually available as a shortcut without any extensions, but if you wish to customize your DE deeply like this, KDE is incredibly customizable. You can do essentially anything you want in it and get it to look however you want.

    Since you said that you’re trying out Mint, now would be a good time to switch distro so you don’t get attached to something that doesn’t suit your needs. Switching desktop environments can cause lots of issues, so it’s often best to just pick a distro with the DE you want. My personal recommendation is Fedora’s KDE spin (though there are discussions of Fedora’s default workstation switching to KDE in the future). If you’re invested into Debian, then I don’t really have any experience with Debian-based KDE distros, but I’m sure someone else could recommend you something. To be clear, the benefit of recommending Mint as a starter distro has gradually diminished as other distros have become more user-friendly. Fedora is a perfectly fine distro for someone new to desktop Linux (especially since you’re already experienced on the command line); you’ll just have to look up how to install Nvidia drivers if you have an Nvidia graphics card. AMD commits their driver to the Linux kernel, so no need to do anything if you have an AMD card. Try out some distros in a VM before you commit to anything though; it’s much less commitment than installing so it’s far easier to test distros out and see what best suits you.




  • I used Wayland for a couple years on AMD hardware and it was fine; I didn’t really have any issues. Since acquiring a laptop with an Nvidia card as a gift about a year agi (it was a hand-me-down), I switched to X11 because it is still more stable for Nvidia. I will be switching back to Wayland (with Nvidia) when Fedora 40 releases. Hopefully the support for explicit sync patch will be available by that time, but if not I won’t be heavily affected, as I am not playing games currently. I expect that patch to fix the black frame insertion during VRR that people have been complaining about, at which point Nvidia will be viable (for me) on Wayland.

    I’ve been on the Wayland train for quite some time now, it’s only really had issues with Nvidia because Nvidia refuses to adapt their graphics driver for it. We have to rely on the Wayland and XWayland projects to fix the incompatibilities that Nvidia is too lazy to fix themselves (like not supporting implicit sync). Luckily AMD is on top of things and has worked very well with Wayland for years now, so those with AMD hardware are better off.

    EDIT: Here’s a link to a Lemmy post about the explicit sync patch. Looks like Nvidia drivers plan to support it in the May 15th patch, so about a month after Fedora 40 releases.



  • Just to clarity the relationship between Red Hat, IBM, and Fedora, Fedora is only sponsored by Red Hat. They make all their own decisions, and while they receive financial support from Red Hat and Red Hat owns the Fedora trademark, their decisions and development are independent of Red Hat (and by extension IBM), with the single exception that they cannot risk violating the law (i.e. copyright infringement), else it risks Red Hat legal trouble (and Fedora would risk losing their sponsorship as a result). Red Hat benefits from Fedora’s development by the community, given that Fedora is RHEL’s upstream, hence why it continues to sponsor Fedora. But it isn’t Red Hat that is in charge of Fedora’s development, it’s FESCo, which is entirely community elected, and does not stand for the interests of Red Hat, but rather for the interests of the community.

    Eliminating Fedora from contention in that regard is essentially like eliminating Debian because you don’t like Canonical, who makes Ubuntu, a downstream of Debian. And yes, Canonical sponsors Debian, so it is essentially a 1:1 comparison.

    Add on top of that the fact that IBM and Red Hat are major contributors to the Linux kernel, and you absolutely cannot avoid connections to them while using Linux. I mean, that’s quite frankly a ridiculous exclusion criteria in the context of Linux. If you’re looking to avoid an operating system OWNED by Red Hat or IBM, then Fedora should not be included in that list. Neither of them have any say or pull in the development of Fedora, which is a completely community-driven project (no, owning the trademark doesn’t change that fact; if Red Hat tried to take over, the Fedora community would simply fork the project, rebrand, and continue on their own). Besides, Red Hat has no interest in controlling Fedora, because it doesn’t benefit them. Their only interest is in enterprise applications, which is not a good use case for Fedora. The only operating systems Red Hat actually has any control over are RHEL, CentOS, and any derivatives of those operating systems like Rocky Linux, Oracle Linux, and such (though Red Hat’s control over derivatives was only the result of those projects being downstream, not actual ownership).

    So with that in mind, I’d recommend the Fedora KDE spin if you want a normal, stable, snap-free, no DIY required distro with KDE, or if you want the immutable version, Fedora Kinoite is what you’d be looking for. And Fedora has the major advantage over Debian-based distros of actually receiving package and kernel updates regularly, so you can stay up to date and enjoy new features, all while maintaining stability.

    Fedora Kinoite is absolutely the best immutable distro fitting your criteria. Anything else will have a much smaller community and less support as a result. rpm-ostree has great documentation, and all of the Fedora Atomic Spins have a huge userbase available in case you ever have questions.