SFaulken

@SFaulken@kbin.social
4 Post – 42 Comments
Joined 1 years ago

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

I mean, that's sort of what xdg is intended to accomplish, with making $HOME/.config be the place, but it's kind of up to the individual software developers to comply. (Yes, I know, this doesn't really apply to Windows/Mac OS) But yeah, it would really be nice if configs/config locations were even remotely standardized.

1 more...

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.

10 more...

I don't care about beeper one way or another, but that bloody image with the post, it needs to die in a fire.

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

1 more...

They do. It's called openSUSE Leap

1 more...

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

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.

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.

3 more...

I've been using openSUSE Aeon/Kalpa (Formerly openSUSE microOS Desktop) for close to 2 years now, and I don't see any good reason to return to a traditional distribution.

I will never claim they are authentic, or even great, but I will destroy the 2 for a buck tacos.

1 more...

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.

2 more...

That's XMMP different thing =P

Absolutely nothing. Fedora is upstream of RHEL.

1 more...

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

1 more...

This pretty much sums up my exact feelings about this whole thing. And saves me from having to write it.

It's still around. I'm using it right now, in fact. Makes for a pretty damn good phone service as well, in conjunction with JMP

Hot Damn, thanks. That should get me headed in the right direction anyway.

1 more...

As I understand it, no. I could be all wet, but RedHat isn't under any obligation, I don't think, to provide their sources to anybody that wants them, and is perfectly within their rights to only provide them to "customers" under the GPL. They just aren't allowed to withhold them from those same "customers".

But I'm not any sort of expert on opensource licensing.

Doesn't matter what distro you choose. I'd suggest picking one with a large support base, and not a niche distro.

But ultimately, pick one, don't become a distro hopper, or one of these folks that's always asking "what's the best distro".

As a new user, if you try out a distro for a few months and it's just not "clicking" for you, there's nothing wrong with trying something else out.

More than anything else, once you do find the distro that feels like home, learn to tune out the haters, because they're going to crawl out from under their rocks every bloody time you mention the distro you use, and try and tell you why what they like is better.

You'll notice I haven't mentioned which distro I use. And that's for a reason. I happen to think it's pretty damned fantastic, but there's at least one other person that will read this, and feel its the worst thing ever, of all time.

As far as tips go? Learn to read error messages, learn how to use a websearch, learn how to ask intelligent questions when you need help.

I highly recommend giving this a read: https://www.catb.org/\~esr/faqs/smart-questions.html Yes, it's old, but it's just as relevant as it was when Eric Raymond wrote it back in 2001.

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

1 more...

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

I've been daily driving openSUSE Aeon/Kalpa for the better part of two years now. I don't see any good reason to return to a traditional distribution for a desktop machine. I very much know what I'm doing as a linux user/admin, having been using it for years, and the no-fuss/no-hassle nature of an immutable system is exactly what I want for my workstations. And ultimately my servers.

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

In general, while it makes for convenience for end-users, I'm just not interested in hitching my buggy to another "single point" social media platform.

I already have a Discord account, I don't really need to sign up for a Discord clone based on a "Trust me Bro" sort of guarantee that they won't enshittify it in the future. Because nothing really stops the Revolt developers (and I'm not trying to imply any evil intentions, or even plans on their part) from deciding to accept VC money, or just sell the whole thing outright to $corporation_with_a_dumptruck_full_of_cash, and there's not a thing that a User can do about it.

It's entirely possible that with Matrix, that an individual matrix server administrator (lets call it matrix.foo.bar) could get up to shenanigans, but as it's a federated chat protocol by design, I'm free to take my custom elsewhere (matrix.bar.foo), and basically have the same access to all the things I did before. There is no single point of control, or failure for somebody to break, or sell.

The only reason I haven't gotten an instance spun up yet, is because I'm old, and set in my ways, and don't really understand how to configure and get kbin running with Docker. As soon as somebody that's better at this than I am gets some sort of "Docker for dummies wanting to setup kbin" up, I'll spin it up, I've already got a nice beefy VPS sitting there with Mastodon/Matrix/Nextcloud running on it, and plenty of resources left.

They're welcome to it. I haven't deleted my reddit account yet, but I did kill the tab in my browser. I just don't care anymore.

Negative. If the seat is that untrustworthy, I'll just find a different toilet.

1 more...

Wait a minute. Since when are LXQt and XFCE "Distributions" ?

I don't even know what that vaguely gear-like one in the top tier is, or the one next to the geeko in the second tier are.

(Just as a sidenote, as one of the openSUSE LXQt maintainers, and sometimes LXQt Upstream contributor, if we're providing our own distro somewhere, this is the first I've heard of it.)

2 more...

I shouldn't, but I'm going to…

Define "Bloat".

Seriously. What do you mean when you say "Bloat" and why is this an actual legitimate technological concern of yours?

(This comment has absolutely nothing to do with Manjaro, or any other distribution. It's got more to do with the use of the word "Bloat")

Ok, so it looks like I'm going to have to do a bit of jiggery pokery, as I don't need caddy, I've already got an nginx reverse proxy running on the host. (I think they both provide similar functionality?)

Hm.

Famke Janssen, if she's reprising her character from Goldeneye
Kate Beckinsdale, in her role as Selene from Underworld
Kathleen Turner, as Jessica Rabbit.

Yes, I'm a simple Man, with simple tastes =P

That's entirely possible. I never actually used, contributed, or developed for CentOS, so I might have some small details wrong.

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

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

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.

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.

1 more...

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?

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.

You misunderstand what kbin is, if you think there's A server that has to cover operating costs. kbin isn't a site, it's just server software, it's meant to be run in many many places, and those individual servers talk to each other.

3 more...

The performance issues will sort themselves out. The timing is just bad for kbin.social

But it's not a performance issue, so much as it is people learning how the Fediverse works. At it's best, there shouldn't be any megaservers where everybody is signed up. There should be many smaller servers, that are interacting with each other, via federation. It's a little different way of looking at things.

1 more...