I dont understand how redhat is going to police this policy of “we’ll keep source code open to paying customers, but reserve the right to cancel a customer that shares said source”.
Toss in GUID’s or randomly place identity files to anyone that downloads the RHEL source hoping they get accidentally published as an identifying attribute if someone does decide to publish it elsewhere.
And make sure that identifier scheme still works if different people on different subscriptions download the source and compare to filter identifiers like that out…
They could try that but I suspect it would be rather easy to find anomalies like that. These are ultimately patches to an upstream and already open-source project, so one can just diff the RHEL version with the release it’s based on and quickly notice that random GUID in the sources or random spaces/indentation. Or have multiple sources leak the code independently, and then you can diff them all between eachother to verify if you got exactly the same code or if they injected something sneaky to track it, and remove it.
Lots of companies in enterprise also want to host their own mirror because the servers are airgapped, so they can’t even track who downloaded all the sources because many companies will in fact do that. And serving slightly modified but still signed packages sounds like it would be rather computationally expensive to do on the fly, so they can’t exactly add tracking built into the packages of the repos either. And again easy to detect with basic checksumming of the files.
I don’t think that many companies have their shit together well enough to mirror the source code, besides the RHEL repos aren’t small, so that’ll cost.
The companies I’ve helped either had a minimalist mirror to reduce the surface area of what was installable or to save on cost.
It’s possible that a few enterprises do a full mirror of all RHEL sources, but i doubt it’s many
I don’t know, I’ve worked in Debian/Ubuntu companies mostly. Last two had thousands of servers and both had an apt-mirror custom repo including the deb-src ones. Otherwise we just get ourselves banned from the official mirrors when thousands of VMs pull updates from the same NAT IP.
Not sure how that works exactly on the RHEL side, maybe it’s not nearly as easy or common to do that.
This is not about an individual sharing the source. This is about near verbatim copy distributions like Oracle Linux. And they can easily see who contributes code from RHEL into those distributions.
I think Jeff has a point that a Linux distribution is a collective effort, but I honestly don’t see why he can’t just target Fedora which is for all intends and purposes the testing release for RHEL and most of the development work that Red Hat does goes directly into Fedora. RHEL adds little of value to that other than some compliance BS for large companies.
Fedora isn’t the testing distribution for RHEL, CentOS is. Fedora is upstream of CentOS and could be viewed as the bleeding edge in that regard. CentOS used to be downstream of RHEL, but that changed a few years ago when IBM did its first shitty thing at Red Hat. The tree is like:
Fedora (Top of code stream, “unstable” from a business perspective)
|
|
v
CentOS (midstream, much less frequent feature updates)
|
|
v
RHEL (end of stream, stable/predictable/reliable/etc)
And I couldn’t disagree more about RHEL adding little value. You’re not going to run a server on Fedora for something you want/need to rely on, and especially rely on not to change much/cause breaking changes. That’s what RHEL is for and it is the gold standard in that regard.
And that’s not even mentioning the fact that Red Hat support is some of the absolute best in the world. Motherfuckers will write a bespoke kernel module for you if that’s what it takes to fix your issue. Not sure if that’s still true after the IBM takeover though, but that was my experience with them before that.
You can absolutely run important services on Fedora server edition. Most of the stuff in containerized anyways, so having a more up to date version of the base system is actually an advantage.
It is really only those large corps with massive closed source lagacy applications and loads of compliance regulation that need a stale but long term supported distribution like RHEL.
I kinda like Helix, I just don’t really know what’s the point of it. Some of the Kakoune bindings are marginally better than the vim default but any efficency I might get with it I instantly lose when trying to re-learn things or getting confused when I hop on a vim terminal on an other machine.
Kind of the same with the editor, it’s like a ‘batteries included vim’ but I can just get that with a really light vim config and not mess up my workflow.
I guess it’s might be cool if you are getting into it as your first modal editor but even then, if you want to use other stuff or need to use some different tools getting a vim extension will probably be easier than getting a Kakoune one.
In my opinion, users who already use vim are not the primary target audience of Helix. I see the target group more among users who want to switch from a “normal” editor to a modal editor. The selection → action model and the easier shortcuts probably make the switch easier for many. I personally don’t like vim at all because of the handling (purely subjective view). Helix will definitely not be my default editor but I get along much better with it than with vim or neovim.
When I first tried Helix, my main concern (that prevented me from getting too far into it) was not going from Vim to Helix, but the other way around. Vim (or sometimes vi) is a standard editor on almost any Linux machine, so if I am ever working on a server if a VM, I would need to know/use Vim keybinds. That made Vim a more useful tool for me to learn at the time, as I could use the skills both on my machine and anywhere else.
My usual suggestion: Get a generation-old business or workstation class machine from one of the major manufacturers, as a refurb. Mostly meaning keep an eye on Dell Refurbished or Lenovo Outlet - sometimes you can also get a deal on a refurb via woot - for something that appeals to you. The stock is always changing at those, and there are almost always sales/coupons for around 40% off at the first-party refurb stores, so +/- a week of patience can save you a bunch of money.
Business or workstation class machines (think Dell Latitude or Precision, especially the ones with models that start with a 7, or Thinkpad) are typically mechanically much better built than their consumer counterparts, and usually full of reputable components that are connected in standard ways - low end consumer stuff sometimes has issues where they got weird less-common components or connected things in stupid ways to save a few cents per unit that will cause driver issues.
Waiting a generation gives time for mainline kernel driver support to fully mature to minimize driver problems, and drastically cuts the price.
I’ve had several machines following that advice, and I think the only driver trouble I’ve had with them has been with unsupported fingerprint/smartcard readers, which I …don’t care about anyway.
Or, if you want a way cheap beater and don’t mind some hackin’, grab a used/refurbished AUE Chromebook that is on the Mr. Chromebox Supported List. AUE means they no longer receive ChromeOS updates, so their price craters to like $50, and you can flash a normal UEFI payload and use them as a (feeble, storage starved, low resolution) computer. Not a good main machine, but they make fun beaters for experimenting. There are often batches of them being dumped via woot.
…also, don’t buy anything with an Nvidia GPU unless you have a specific compelling reason, it’ll be a pain in your ass for the life of the machine.
I have said and will keep saying this, Snap continues to be one of the worst things Canonical has tried to pass off as “production ready” at least in recent times, and every time they push more for it makes me consider them even more of an untrustworthy distro vendor.
My personal experience with it is that I had to nuke it off the computers I maintain last time we updated Ubuntu to the new release (unfortunately I don’t control what OS we’re using, otherwise Ubuntu would have been gone faster than you could say “Snap”), because these computers have user homes on a network drive, which isn’t under /home, and snap just flat out refuses to work when that is the case.
It wouldn’t even be such a problem if they hadn’t removed Firefox among other things from their repositories, but as it is right now, there’s no way to run Firefox on Ubuntu without mucking around with PPAs if your user home is not under /home. This bug about that has been open for 7 years!
That said, I think this is fine considering Flatpak is still going to be available in the repositories, just not installed by default. I’m much more a fan of “install what you need”, anyway. (But then again, that’s not the style of distro Ubuntu wants to go for.)
I tried it like a year ago maybe and it was a very interesting concept, but I couldn’t find what it really brings to the table over Guix or Nix. I’ve used Guix quite a lot since then and found that the separation of packages was afaict very similar, with the added bonus of having a completely reproducible system. Maybe Gobo brings something that Guix/Nix does not, but in my time of testing it I couldn’t find anything.
I have been using Debian for about 20 years now. Server and desktop. But I recently migrated all my server stuff to FreeBSD and I don’t think I will move back. Jails are great and provide me a convenient way to isolate my apps. On the desktop side I will stay with Debian.
NixOS needs what is IMO the killer feature of Arch: the wiki.
Comprehensive documentation on not only the OS but the additional packages that we use is what drew me to Arch, and the thing that makes me swear in frustration whenever I have to use Ubuntu/Debian.
NixOS is an excellent OS that has the promise of being every bit as hackable as Arch, but far more stable. Problem is, configuration is very different and needs extensive documentation to reduce that friction point.
The Arch wiki is pretty distro-agnostic (barring package names and pacman specific stuff). I’ve been distro-hopping for past decade and I’ve always used it as a reference for setting things up.
Maybe you should search for some rolling release distribution. I’m using Arch since many years and am quite happy with it. You rarely have to build anything yourself. Only if you have to use the AUR.
The crash started apparently out-of-the-blue, hitting thousands of Argentinian users on a Debian-based distro called Huayra, and specifically on version 5 which was based on Debian 10.
Everybody seemed to crash while searching for images on Google.
Google’s code was allocating 20000 variables in a single frame.
linux
Top
This magazine is from a federated server and may be incomplete. Browse more on the original instance.