@SFaulken@kbin.social avatar

SFaulken

@SFaulken@kbin.social

openSUSE Developer/Maintainer/Member/Whatever.
I do things with openSUSE. Not that I'm particularly good at any of them =P

Este perfil es de un servidor federado y podría estar incompleto. Explorar más contenido en la instancia original.

Blog about some various Linux stuff (sfalken.tech) en

Just wanted to drop there here, in case anybody finds it useful. I started doing some blogging, mostly with the intention of archiving how in the hell I've done things on Linux, in the past, so I know where to find them the next time I need to do them. There will probably be other stuff there, with time, some of it not linux...

The Maintainer Of The NVIDIA Open-Source "Nouveau" Linux Kernel Driver Resigns (phoronix.com) en

Hours after posting a large patch series for enabling the Nouveau kernel driver to use NVIDIA's GSP for improving the support for RTX 20/30 series hardware and finally enabling accelerated graphics support on RTX 40 'Ada Lovelace' GPUs, the Red Hat maintainer has resigned from his duties.

SFaulken,
@SFaulken@kbin.social avatar

That is indeed the big question, if there's nobody willing to put in the work, then there's nothing to release.

Maintaining something like Leap, with the contributor base that has historically existed, isn't sustainable, long term, especially when the upstream is going in a different direction.

SFaulken,
@SFaulken@kbin.social avatar

Correct, SUSE, the corporation is no longer providing a traditional linux distribution, after the SLE-15 EOL.

openSUSE, which is a community project, and not controlled by SUSE, is currently debating as to whether we have the contributors interested in doing so, and in sufficient numbers, to continue to provide a traditional point release distribution.

Tumbleweed (the rolling release) is not going anywhere. The community has not yet decided if the interest and manpower is there to use the ALP sources provided by SUSE to create A) A traditional linux distribution, akin to what Leap currently is, B) a "Slowroll" version of Tumbleweed, that has a slower release cycle, or C) Nothing at all, because there isn't the community there to support the development of it.

SUSE != openSUSE

SFaulken,
@SFaulken@kbin.social avatar

Mostly because they're uneducated fools, that haven't any actual idea what the hell they're talking about.

Unless you're pulling sources, and building everything yourself, everything you get from most major distributions is "pre-compiled".

People hate anything new, they fear change, and they like drama, that's all it is.

SFaulken,
@SFaulken@kbin.social avatar

Fedora Silverblue or openSUSE Aeon, I'd probably say.

Stupid Beginner Question: What Linux Desktop Environment works well or has an output mode for NTSC/PAL resolution? (kbin.social) en

Yes I am thinking of using my little TV (composite AV input only (from an HDMI-to-composite dongle)) as my second display. Going command line-only would be ok if I don't have a choice, but then I watch miniDV and VCD footages sometimes. My Mint machine was broken so i didn't have a chance to test that. So not sure if it could go...

SFaulken,
@SFaulken@kbin.social avatar

The dsektop environment really doesn't have anything to do with it. That's up to the video drivers and display server, be it X11 or Wayland. I haven't any idea which desktop might offer you the best tools for configuring those things though. Just as a rough guess, I'd guess KDE Plasma, perhaps XFCE?

A distro and desktop environment recommendation for an old laptop (Read all of it, please.) (kbin.social) en

'sup? So, I am a beginner that has an old Samsung laptop from 2013 with an i3 4005U, a GeForce 710M, 500GB HDD (I will probably upgrade it to an SSD, but not for now.), 4GB 1600 MHz DDR3L RAM (the same for the HDD, will probably upgrade to 8GB some time.). It currently has Windows 10 Home but Linux is probably lighter (right?)...

SFaulken,
@SFaulken@kbin.social avatar

I'd probably drop openSUSE Tumbleweed with LXQt on it. But that's my preference for low-spec machines. There's any number of distros with "lightweight" GUI's that you can use. XFCE/MATE/LXQt probably being the ones that will give you the least headaches.

SFaulken,
@SFaulken@kbin.social avatar

No, nothing RedHat is doing affects Nobara. Nobara is based on Fedora, which is upstream of RedHat. Nothing is changing.

SFaulken,
@SFaulken@kbin.social avatar

I have no idea who signs his paychecks, but no, none of the announcement about the RHEL Sources affects Fedora in any way, unless Nobara is pulling sources from RHEL (which it isn't) this doesn't affect it at all. Nobara isn't an official Fedora, or RedHat product or project.

SFaulken,
@SFaulken@kbin.social avatar

This is nice for Oracle to say. That being said, Oracle are not "The Good Guys™" and never have been. They might be legitimately honest about Oracle Linux and their commitment to being open and free, but they're horrible about so many other things, and always have been.

SFaulken,
@SFaulken@kbin.social avatar

Honestly, I wouldn't make any specific recommendation. Because when you do, you instantly become most peoples personal support technician, when they can't sort something out.

I'd probably make the general suggestions of Fedora/Silverblue/Kinoite, openSUSE Tumbleweed/Aeon/Kalpa, and maybe Pop!_OS if somebody put a gun to my head. But no recommendations.

Open source developers - have the recent moves by RedHat changed your opinion of using non-GPL licenses? (kbin.social) en

The new license terms for RHEL are structured to stop subscribers from exercising their rights under the GPL. For now they are still providing source code albeit in a less convenient form, but technically they only need to do this for GPL licenses packages and they could remove code for BSD /MIT / Apache licensed packages....

SFaulken,
@SFaulken@kbin.social avatar

No, this changes nothing for me.

Reminder that RedHat makes A LOT of money already. The results of the 2019 fiscal year show that RedHat spends twice as much money on ads and sales people than on developers. (businesswire.com) en

Our subscriptions mostly pay for the salesmen and the ads. They sell ads first, IT second. So I'm not gonna cry for RedHat. The image of the poor developers working in a cave, struggling to make money is only in our mind. They had a perfectly functional model but decided to sabotage some of it to try to squeeze even more money....

SFaulken,
@SFaulken@kbin.social avatar

They aren't. None of this affects their submissions back upstream to things like the Linux kernel, GNOME, Systemd, or any other software they include within RHEL/CentOS Stream

SFaulken,
@SFaulken@kbin.social avatar

Just for completeness, KDE offers the same for their applications, which generally integrate well into any Qt based environment https://apps.kde.org/

CentOS Stream for HPC work? (kbin.social) en

I've been running an HPC system for a science group for a while now and have built a couple of different systems based on common HPC infrastructures (ROCKS or Open HPC). These have been built on top of the rebuilt RHEL distros (mostly CentOS), but I don't really need the level of stability that these provide and would actually...

SFaulken,
@SFaulken@kbin.social avatar

I'm not entirely certain about the actual HPC stuff, but there's no good reason CentOS Stream wouldn't do what you need.

SFaulken,
@SFaulken@kbin.social avatar

I mean, if you know the software you need to have, to make it work on RHEL, It might take a bit of work on your part, but I can't imagine getting it installed on CentOS Stream will be that onerous a task.

SFaulken,
@SFaulken@kbin.social avatar

RedHat creates a product called RHEL (Red Hat Enterprise Linux) that is a paid support product, mostly targeted at businesses (and things like Academia/Laboratories/etc).

At one point, there was a Wholly seperate product, created outside the RedHat umbrella, called CentOS, that quite literally took the sources of RHEL, removed the RHEL branding, and rebuilt it, allowing folks to "mostly" be able to use RHEL, without paying RedHat for a support contract.

In 2014, the CentOS Project/Product was "purchased" by RedHat, and then in 2020, RedHat decided that CentOS would no longer just be a "rebuilt" RHEL, but instead would become the development space for RHEL, called CentOS Stream. This made many people very unhappy, and they decided to start the Rocky Linux and AlmaLinux projects to provide roughly the same product that prior versions of CentOS had provided.

Additionally (I don't actually know exactly when), at some point, Oracle started doing basically the same thing that CentOS had been doing, and rebuilding the RHEL sources, and selling it, as "Oracle Linux"

So net effect of what this means, is that RHEL sources will no longer be publicly available at git.centos.org, and will only be available to RedHat customers (i.e. you must have signed up for an account/license with RedHat for RHEL). This may make things more difficult for Rocky, Alma, and Oracle, to provide the same "Bug for Bug" compatible product to RHEL.

Most of what people are upset about, is because they're willfully misreading the GPL (GNU Public License) which covers an awful lot of the RHEL sources.

The GPL requires that if you distribute software, licensed under the GPL, that you also must provide the folks that you distribute that software to, with the sources you used. It doesn't specify how you have to provide them, you could make them available for download, you could mail folks a DVD with all the sources on it, (honestly, I think you might be able to just print them all out and send them on dead trees, and still be compliant).

What most of the folks are upset about, is there is a clause within the GPL, that says something about providing the sources "without restriction on redistribution" or some such. And they view that RedHat can choose to terminate your license to RHEL, if you redistribute RHEL sources/software as violating the GPL. But the GPL cannot dictate business relationships. Redhat cannot stop one of their customers from distributing sources that they are licensed to have. But they are well within their legal rights to terminate that license, and provide no further access, if you distribute them. (i.e. you have an RHEL license, and version 1.0 of a library is covered under that license, you redistribute that source, and RedHat must allow that, but they're under no obligation to continue that business relationship, and provide you continuing access to version 1.1)

That's a rough rundown on the history. What does this mean for the average linux user? Nothing, really. Unless you happen to use Rocky Linux, AlmaLinux, or Oracle Linux. It doesn't affect Debian, or Ubuntu, or openSUSE, or Arch, or anybody else. RedHat will continue to contribute back upstream to projects like the linux kernel, or GNOME, or what have you, they will continue to sponsor and hire developers, they just will no longer be providing free and open access to the RHEL Sources.

It's not a question of legality really, but more one of an ethical nature. It sort of depends on you, as to whether or not you're bothered by RedHat doing this or not.

SFaulken,
@SFaulken@kbin.social avatar

No, this doesn't affect Fedora in any meaningful way. Fedora is upstream of RHEL.

SFaulken,
@SFaulken@kbin.social avatar

They do. It's called openSUSE Leap

SFaulken,
@SFaulken@kbin.social avatar

Absolutely nothing. Fedora is upstream of RHEL.

SFaulken,
@SFaulken@kbin.social avatar

I am only peripherally involved in Fedora as a contributor, but as I understand it, yes there is governance and infrastructure in place.

SFaulken,
@SFaulken@kbin.social avatar

Uh. The relationship between CentOS Stream and RHEL is a bit murkier to me. I'd be lying to you if I said I fully understood how that code flow works.

For openSUSE the flow is "openSUSE Tumbleweed" -> "SUSE Linux Enterprise" -> "openSUSE Leap"

Everytime SUSE creates a new version/service pack of SLE (SLE 15 SP4, to use an example) the sources for that version are provided to openSUSE, and a new version of Leap is released (openSUSE Leap 15.4)

I don't actually work on Leap much, nor am I a SUSE Employee, so there are probably some minutae in that process that I'm missing, but that's the basic workflow.

SFaulken,
@SFaulken@kbin.social avatar

I'd say I'm disappointed, but I'm really not. I knew this was basically how this was going to play out. I've already been called a paid shill, and stupid a handful of times today elsewhere, for not wanting to burn RedHat to the ground for this decision.

People need to get outside and touch some grass.

SFaulken,
@SFaulken@kbin.social avatar

It was meant to be dismissive. Happy to clear that up for you.

SFaulken,
@SFaulken@kbin.social avatar

I feel perfectly fine. I have no idea what you're on about.

SFaulken,
@SFaulken@kbin.social avatar

That's a very emotional take indeed, you obviously feel strongly.

What, exactly, is RedHat stealing here? Are they deleting code from upstream git repos?

I mean, if you have a moral issue with the way RedHat chooses to structure their customer agreements, you're more than welcome to not use their products. I generally feel like this is a mistake on RedHats part myself, but it doesn't affect my life in any meaningful way.

RedHat is going to continue to contribute back upstream, they're going to continue to support Fedora, and provide CentOS Stream for to community to use.

Rocky, Alma, Oracle and other projects that were rebuilding RHEL sources will have to sort out how they want to proceed.

There are a hell of a lot more evil things happening in the world to get pissed off about.

SFaulken,
@SFaulken@kbin.social avatar

That is your reading of the GPL. You may be right, I read it differently, and while I might find what RedHat is doing to be distasteful, I don't find it to be violating the GPL. I might be wrong. I'm not a legal expert, are you?

SFaulken,
@SFaulken@kbin.social avatar

That's how you read the GPL, you might be right.

When I read the GPL, and I have read it a number of times over the years, while I might find what RedHat has chosen to do to be distasteful, I don't find it in violation of the GPL. It's entirely possible that I'm wrong.

But I'm not a legal expert by any stretch of the imagination, are you?

SFaulken,
@SFaulken@kbin.social avatar

No, it really doesn't. Anybody is welcome to start their own seperate flatpakrepo. Fedora already does this. Any organization could do the same, if they chose to.

SFaulken,
@SFaulken@kbin.social avatar

Most projects haven't found any value in maintaining their own flatpak repositories. We considered it at one point for openSUSE Aeon/Kalpa, but decided it's un-necessary duplication of work.

  • Todo
  • Suscrito
  • Moderado
  • Favoritos
  • random
  • noticiascr
  • CostaRica
  • Todos las revistas