Distro Disclosure didn't happen?
If they told the Kernel Security team on the 23rd of March. Why didn't they tell the distros security teams?
I thought they normally tell them?
174 publicly visible posts • joined 24 Sep 2009
I used to run everything RH and RH like (RHEL ws/server work production), Centos (home server and test), Fedora (see what was coming and enterprise testing this) but to be called a freeloader by them.
I refuse to use Fedora and help them for free improve their product like I used to submitting bug reports and howtos, no matter how good.
Yup pretty much everything doesn't need SysV init scripts (everything has switched).
But rc.local is really useful for a few lines to fix up a few boot funnies.
In my case, SELinux funnies with NFS daemons and a USB stick for LUKS keys.
Without putting in a ton of effort to dig into root cause of these minor issues.
Also there isn't really a better place to put qdisc setup.
I guess I'll be copying /lib/systemd/system/rc-local.service to /etc/systemd/system/rc-local.service before the next upgrade.
The big issues always were, this was the next big thing in the '80s for a while.
Optical wavelengths are just too big for today's circuits, so not very high density.
Hence today's chip layouts can't be seen by an optical microscope any lithography no longer uses visible wavelengths.
A bigger issue is heat. An electronic transistor when off no current flows.
An optical transistor when off essentially goes black, so just generates heat.
That's a big problem with upping density.
Are we in the territory of two bald men fighting over a comb?
Not saying it's not good, just that Ruby doesn't need more roadblocks.
It's like the other great Ruby project puppet, being closed further by it's owner Perforce, it was fighting for it's existence before....what are the thinking?
All true, however there are a very large number of sites that don't use these VMWare features, they just bought VMWare as it was the safe, nobody got fired for buying VMWare, option.
Not sure RHEV/oVirt skill are so problematic as they are all KVM and this is a pretty common skill, any half decent Linux admin can work with this. If I was a VMWare admin I would be learning those right now.
Bigger sites, I'd be looking at Nutanix and cloud, as in the next few years you will be in milking territory for Broadcom.
Other things to consider.
If you can take the price rises great, but remember, Broadcom has cut off a lot of resources from home labs/self learners.
This will start to make staff availability harder as the years drift by.
VMWare is on the path to be a legacy technology, it will be like mainframe technology. Still super reliable but no one is interested in this.
Also you do have to ask yourself how many 3rd party software and maybe more importantly Hardware vendors will be interested in supporting
this if market share starts to disappear. Could we see a day with Broadcom's own hardware being required because of it being too hard for them to support
from every server vendor? This isn't Linux they have to maintain their own kernel.
These aren't going to be a problem now, but looking out 5-10 years ? Not so long in enterprise terms.
This was a dynamic ecosystem, it isn't now.
All I'd say, just keep your eyes open and look beyond today's value provided to ensure you don't get technologically marooned.
I think this looks more like a display driver issue or something else going on.
I've being playing DVD ISOs since the Pi3 era and Pi4 was happy doing full 1080 blu-ray ISOs.
I'm happily running H265 4K video files on my Pi5.All with plenty of CPU headroom left.
I'm likewise using a LibreELEC Kodi to be TV friendly but should still be capable on a RaspberryPi OS.
Reducing your exposure to the windows pathogen seems the correct approach. I have a Linux host with 95% of the apps I use , and a Widows VM for the few apps I can't get.
Continuing to fight to keep windows just opens you up to being data harvested to death (forced MS accounts) and now forced HW upgrades.
I'd wonder more about the impact of these changes on the technology.
Will the products on each side be impacted by being disconnected from advancements in the other.
Even if they have an intellectual property sharing deal, having say, desktop as no longer being part of VMWare will mean no (a lot less) consideration to this being paid by VMWare to this when making changes.
Couldn't agree more!
I have been a Red Hat user, supporter and customer of Red Hat Linux (not RHEL) from about 5.x.
As a customer of RH I benefited from the large install base Centos brought, vendors providing their software in RPM, but mainly the benefits were third party repos and FAQs/howtos made largely by Centos/Alma/Rocky people.
I too have migrated my home servers all to Debian from Rocky, a bit of a pain but I got there.
I used to provide bug reports for Centos (checked on RHEL) for things I spotted at home, to make RHEL better.
But more importantly I provided early testing of Fedora in corporate environments (plus at home), in the hope that when the RHEL release came it would be more bug free in a corporate setting. I also would benefit at home by these improvements trickling down to Centos/Alma/Rocky.
Now why should I help Fedora to just be largely called a thief by Red Hat. Thanks for that...Not a nice thing to call your customers who often used Centos for prototyping before buying the real thing under RHEL. My desktops and laptops switched to an Ubuntu spin.
Red Hat you largely had a nice symbiotic relationship going with Fedora and downstream Centos. I believe a massive own goal! Short term gain at the price of the long term.
This has been resisted for so long, and was so obviously needed.
I have .lan at home mainly as OpenWRT uses this and it's quicker to type than .internal.
To be honest I'd reserve common ones used (identified in the report) and not just one, then just move on.
i.e. .home, .internal, .lan, .corp, .localdomain
I can see it actually being more sensible for an AD domain to be companyname.{corp|lan|internal} than a real (as recommended by MS).
Companies often forget to renew real domains (then your are stuck).
I hear you, but most broadband issues do still seem to be Openreach.
All the issues I have had in different places are Openreach. A dodgy shotgun style cable being left by Openreach when it should have been replaced when we had broadband installed. A bad connection in the cabinet,tech showed us a bad plastic covered join.
A horribly congested link from the Exchange (we were told, where Zen had no direct presence in that Exchange), it would be great during the day (65Mbs) but would drop top 0.1 Mbs in the evening even though the syncing speed was still very high.
And of course they have the hardest job to provide broadband on an ancient physical infrastructure.
I used to test Fedora on my company's enterprise environment (AD, NFSv4, WiFi etc) and home desktop, and reported issues back to Red Hat in the hope of getting these fixed before they became issues on new RHEL releases. I was a large RHEL customer. I used to benefit personally by having CentOS/Rocky at home. Nice symbiotic relationship.
Now with being called a freeloader and worries about the viability of essential 3rd Party Repos on RHEL, I see no reason to help RH improve their distro, given they are freeloading off my efforts!
Home is now Debian 12 Servers and Ubuntu based.
Maybe someone can help me with this...
What direction/philosophy are they taking with this?
Is this going to be an effective new distro tree that is developed independently (that the members will derive from)?
OR
An effective new distro tree that is using Centos Stream patches (that the members will derive from)?
OR
Just a new name for the upstream RHEL sources?
Personally after using RH and RHEL for decades professionally (and recommending to many people and the companies I've worked for), and using Fedora and Centos/Rocky at home. Contributing bug reports and enterprise experience of their product back. This was only practical at work and home by use of 3rd party repos to make this practical, largely maintained by Alma/Rocky/Centos people. For us all to be called leeches, thanks for that.
I'm now done with them and have already moved my home stuff to Debian and work will likely follow!
I wonder if just a directive from their corporate Daddy to increase profits after they splurged on buying Red Hat. This will likely come back to bite them, but those C levels will have had their bonuses by then and moved on. RH themselves used to say if we make money from bits we aren't doing it properly....
Sadly I think you are right.
I have used RHEL commercially and recommended buying it (and have run a very large RHEL subscription account). Wanted to run the same thing at home (so used Centos later Rocky).
As a RHEL subscriber benefited many times from the many eyes of Centos (howtos, bug reports, forum posts) and the repos with essential third party software built with Centos (e.g. certbot, vlc, nvidia driver rpms, ). The extra audience provided by Centos gave me more 3rd party software availability. Additionally, just a few weeks ago I had a bug I found in Rocky ( I tested on RHEL to report), pushed upstream and has been fixed.
Without all this RHEL just became a whole lot less useful and usable. If you run a single commercial app maybe not, but in the real world RHEL just now looks hard to use as a general purpose distro.
I have used RHEL systems for many many years (decades) and contributed to this ecosystem (many many bug reports, howtos, occasional patches)
And to Fedora, I run this as a desktop (home and work) to see what was coming up in RHEL a few years down the line and to help stabilise it for this point. So my RHEL and my home Rocky deployments would be improved.
Why would I do this now? I just don't feel like doing this anymore. If my home servers head to something else my desktop will too.
RH you have utterly destroyed the ecosystem you have built. On some short term hope of gain.
At the weekend I downloaded Debian for the first time in decades and I have started playing with this in a VM. I have decided what desktop system I may use, maybe Debian maybe something else Debian based.
It's all very sad.
BTRFS seems to have had issues with things like RAID 5/6 forever, but not really something I know about the reasons on priorities of BTRFS.
The Bcachefs patreon page has some discussion. Not sure on the validity (or the other side of the argument) but it's interesting:
https://www.patreon.com/bcachefs
ext4 - which works - mostly - but is showing its age. The codebase terrifies most filesystem developers who have had to work on it, and heavy users still run into terrifying performance and data corruption bugs with frightening regularity. The general opinion of filesystem developers is that it's a miracle it works as well as it does, and ext4's best feature is its fsck (which does indeed work miracles).
xfs - which is reliable and robust but still fundamentally a classical design - it's designed around update in place, not copy on write (COW). As someone who's both read and written quite a bit of filesystem code, the xfs developers (and Dave Chinner in particular) routinely impress me with just how rigorous their code is - the quality of the xfs code is genuinely head and shoulders above any other upstream filesystem. Unfortunately, there is a long list of very desirable features that are not really possible in a non COW filesystem, and it is generally recognized that xfs will not be the vehicle for those features.
btrfs - which was supposed to be Linux's next generation COW filesystem - Linux's answer to zfs. Unfortunately, too much code was written too quickly without focusing on getting the core design correct first, and now it has too many design mistakes baked into the on disk format and an enormous, messy codebase - bigger that xfs. It's taken far too long to stabilize as well - poisoning the well for future
I do hope this gets merged soon, it looks like a decent Next Generation filesystem architecture that might replace the muddle we have at the moment without ZFS licensing issues or BTRFS (alleged) architecture issues. And has data integrity checking without the layering nightmare of stratis.
They never seem to get that the reason I called is that the website didn't allow me to do the more complex thing I'm trying to do.
As an example, I have a locked out account just now with MS and I can't get a number anywhere to talk to a human being, the automatic reset doesn't want to play with this account. Stuck at the moment!
To be honest following the link to Fedora on this they say removing NIS(+). So presumably/possibly the biggest issue was removing NIS support, as opposed to NIS+ support.
NIS+ being nothing like NIS at all.
I can imagine a number of sites might still use NIS, was used a lot in HPC. Can't imagine NIS+ is used now by anyone, no one really used it when it launched. Sun Solaris originally only provided a NIS+ server, but so few people used it later versions came with a NIS server too.
When you look at most Google Open Source projects, there is no real community directed activity.
It's just Google chucks it over the wall.
Android is like this
Another example. Chromium has no ability to sync passwords, bookmarks, passwords etc to anything that isn't Google's cloud.
Bugs for this are just closed for Chromium,
But only to share Windows files out for Linux desktop users. So light usage. It was okay for this (maybe very okay), but the lack of reasonably handling of filename case issue would prevent me from doing anything deeper with it.
One thing was there is no group ownership file that you can set in the GUI even though this is stored in NTFS and used by their NFS. I had to write my own chgrp in PowerShell :(
Would have been easier if they had just exposed the NFSv4 ACL's mapped from NTFS ACL's (they are pretty identical), but they only map ACL entries for owner, group and other (everyone on NTFS) to basic unix perms. Hence the need for a chgrp.