CentOS Project has announced release of "rolling builds" for CentOS Linux.
CentOS Linux rolling builds are point in time snapshot media rebuild from original release time, to include all updates pushed to mirror.centos.org's repositories. This includes all security, bugfix, enhancement and general updates for CentOS Linux. Machines installed from this media will have all these updates pre-included and will look no different when compared with machines installed with older media that have been "yum updated" to the same point in time.
This includes iso-based install media, as well as generic cloud images.
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
(Score: 2) by isostatic on Friday December 05 2014, @06:16PM
My company has about 1000 ubuntu servers active on our internal network at the moment, all of them were bang uptodate when built as we build from the network (signed repository). Longest it's ever taken was 2 hours, and that was when I was on a 1.5mbit 250ms bit of string.
The windows people still like their 32GB pen drives with some concoction of WinPE to deploy their build, but that seems ridiculous. as they then have to apply a ton of patches and updates.
(Score: 2) by ticho on Friday December 05 2014, @06:56PM
Yes, if you have large infrastructure with lots of homogeneous servers, it's better to have your own way to deploy new servers, with desired patchlevel, e.g. network boot and custom repositories. I think this rolling release is more targeted at one-off users, which is nice.
(Score: 2) by frojack on Friday December 05 2014, @07:35PM
The whole idea of a "Release" dates from the days you had to burn CDroms for boxed sets.
It is an obsolete concept, one that needs to go away.
Linux is specifically designed so that you can replace just about any package without disrupting others, and careful packaging can assure this. The problem is that very few distributions bother with the level of testing needed to do this successfully. The excuse that it is a community project and no one is paid to test to that level, and its opensource so if you don't like the bugs introduced along the way then you can just fix it yourself.
But with proper packaging and update tools, a rolling release really is the way to go.
As more distros offer rolling releases the formal "release" will become a thing of the past, but with that comes an increased level of risk. Someone is bound to slip backdoors in user space programs of libraries and intentionally use the update channel in a monstrously large hack one of these days.
Still, its better than chasing updates and planning a re-install every two years.
No, you are mistaken. I've always had this sig.
(Score: 0) by Anonymous Coward on Friday December 05 2014, @07:48PM
s/is/was/
Systemd is specifically designed so to replace just about every package while causing maximum distruption.
(Score: 2) by Tork on Friday December 05 2014, @09:13PM
🏳️🌈 Proud Ally 🏳️🌈
(Score: 2) by novak on Friday December 05 2014, @09:03PM
I very much prefer standard releases over rolling releases. Updating some packages is one thing, but continuously upgrading the entire system is not really good if stability is your primary concern, and for most things I prefer having a stable, well tested system over the latest tools. You can upgrade packages within a system without using a rolling release. I strongly prefer having a static (or relatively static) repository so that I can guarantee that I can replicate systems later on without doing an extreme amount of work to get the versioning right.
For enterprise systems, they'll be even less interested in rolling releases, especially if it's in some setting where they need to support uncommon hardware configurations.
Currently I use crux on my desktop, which is sort of a hybrid between a rolling release and static releases, in that each release moves and updates packages until enough of the core is different (or should be different) that it's worth it to just make a new version. That's a reasonable compromise.
I think you're right that "releases" will become less common, but I neither hope nor think they will go away altogether, at least for a very long time.
novak
(Score: 2) by frojack on Friday December 05 2014, @09:24PM
I have several machines that are on rolling releases, (mostly gentoo) but that doesn't mean I let them update on their own schedule.
The only things I always update for are security fixes, (and not all of them either).
I never update anything on the road (while traveling), I never update anything in mid project.
I've been playing a bit with Opensuse Tumbleweed, but its not a true rolling release. I use Gentoo for file servers in a few places because its easy to roll it once in a while via ssh without having to go on-site. It never fails to reboot after a roll, because those guys live and breath rolling.
No, you are mistaken. I've always had this sig.
(Score: 2) by novak on Friday December 05 2014, @09:34PM
No, I understand that you can have good control of a system on a rolling release but that doesn't mean it's easy to go back if something goes wrong, especially if what you really want is to load something from back about five years. You usually don't want to, but I have been in that situation before.
novak
(Score: 2) by frojack on Saturday December 06 2014, @03:52AM
True enough, I've rolled right into a pile of dog shit at least once. Gentoo had a famous episode of this.
I'll be happy when opensuse's rolling tumbleweed setup gets to the next big step and comes with Btrfs, so a roll back becomes merely irritating, and no longer impossible.
No, you are mistaken. I've always had this sig.
(Score: 2) by khedoros on Friday December 05 2014, @10:37PM
But with proper packaging and update tools, a rolling release really is the way to go.
With a regular versioned "release", I can put together a build server that uses the exact same pieces of software at the exact same version levels of our existing build servers. For legal reasons, if my employer builds a product using open source software, we need to be able to provide the exact source packages used in any software that we distribute, and we need to be able to perfectly re-build past software releases. Rolling releases make that somewhere between difficult and impossible, unless we put together a build machine and store an archive of its disk image somewhere.
(Score: 2) by ticho on Saturday December 06 2014, @10:13PM
Yep, I totally agree, both approaches have their uses - different horses for different courses.
(Score: 0) by Anonymous Coward on Friday December 05 2014, @08:50PM
The windows people still like their 32GB pen drives with some concoction of WinPE to deploy their build, but that seems ridiculous. as they then have to apply a ton of patches and updates.
Only if they're incompetent. All those patches and updates can be rolled into an pre-created image along with all your drivers, shell tweaks, etc. You then periodically update that image as you need to. We manufacture hundreds of Windows servers daily to ship to clients without ever needing to run patches and updates after imaging.
(Score: 0) by Anonymous Coward on Friday December 05 2014, @11:43PM
hm, guess I'm incompetent, how exactly could one do this? please elaborate ac
(Score: 2) by digitalaudiorock on Friday December 05 2014, @06:44PM
That's actually a nice change. I recall going through the whole hundreds of updates thing with binary distros in the past...especially once they've been out for a while.
CentOS has been a great server distro. It's a shame really...and I'm not trying to flamebait here...but CentOS 7 is just a non-starter as far as I'm concerned, having systemd and all. Whatever anyone thinks of it otherwise you'll never convince me it has any place within 1000 miles of a server. It's going to get more and more difficult to even find a good server distro I'm afraid.
(Score: 2) by frojack on Friday December 05 2014, @07:47PM
It's going to get more and more difficult to even find a good server distro I'm afraid.
OR...
Systemd will get the security audit it needs, and become trusted, documented, and stable.
Remember, that systemd was never designed for Joe Sixpack. It was designed for guys who have monstrous server farms and. It is precisely SERVERS that it was designed for. The rest of us desktop users are simply unwilling beta-testers. (This is pretty much true of all Linux Distros that also sell server-grade supported versions, Like RedHat, Suse, Ubuntu. These companies constantly abuse the individual user as a test bed for their commercial packages).
Servers come in all flavors, and it doesn't take much of a system to handle being a file server or even a mail server. You can swap in a BSD machine into those roles with just a minimal amount of reading.
No, you are mistaken. I've always had this sig.
(Score: 3, Insightful) by digitalaudiorock on Friday December 05 2014, @07:54PM
Wow...you have got to be kidding. In my book a server arguably isn't even a place for DBUS let alone systemd. If it was in fact "designed for servers", then it was "designed for servers" by people with no clue whatsoever. Maybe someone else will join in on this, but I find this statement almost too absurd for comment.
(Score: 0) by Anonymous Coward on Friday December 05 2014, @08:06PM
Yeah, and who'd have thunk remotely upgrading a stupid IPC mechanism pulled in as a dependency could require a site visit? Once every other month for kernel upgrades and now with systemd under rolling release, an ever increasing number of packages not being upgraded until the maintenance window comes around. Or until we complete the "upgrade" to FBSD.
(Score: 2) by frojack on Friday December 05 2014, @08:36PM
I find this statement almost too absurd for comment.
And yet, you DID comment!
Look, even systemd's most ardent opponents [ewontfix.com] realize it was aimed at servers:
Many of the selling-point features of systemd are server-oriented. State-of-the-art transaction-style handling of daemon starting and stopping is not a feature that's useful on desktop systems. The intended audience for that sort of thing is clearly servers.
Redhat wants it for their large server commercial packages, which they push strongly into Virtual Machine space.
Systemd was never designed for Joe Linuxuser. It was intended for large installations.
No, you are mistaken. I've always had this sig.
(Score: 2) by digitalaudiorock on Friday December 05 2014, @09:26PM
I never read that before and I just flat out don't get it at all...at least not that part of his assessment. Those "selling points" may the spin coming from the idiots that designed it, but I can't imagine who'd buy into that. For one thing, I've never administered server that needed anything more than service dependencies as you have in OpenRC for example. Never mind that I'm endlessly reading about people unable to get NFS to even wait for the network with systemd...yea....really "state of the art". Don't even get me started about all the boot time and parallel startup nonsense.
systemd will mean the same endless upgrade reboots just like windows...something that I agree with on that ewontfix site. There's something we're all clamoring for on our servers.
(Score: 0) by Anonymous Coward on Saturday December 06 2014, @01:19AM
Systemd was never designed for Joe Linuxuser. It was intended for large installations.
Bullshit.
How come a few short months ago, the rallying cry was that it *was* meant for joe linuxuser and "year of linux on the desktop" and freedesktop.org and fastbooting for laptops and GNOME and mobile devices and pulseaudio and all that rot?
System D fanbois are politicians of the worst order.
(Score: 0) by Anonymous Coward on Saturday December 06 2014, @02:05AM
The surprisingly vehement resistance and fork (http://devuan.org/) surprised the SystemD-bags enough that they're changing their strategy.
Most desktop users are already locked in and resigned to the inevitable tight coupling of their desktop applications with the system, now it's time to go after those stubborn resisters...
(Score: 2) by frojack on Saturday December 06 2014, @04:00AM
Well I don't disagree with you about systemd fanbois, we've been sold a bill of goods, and NONE of those things it promised have come to fruition.
Its not faster, its not easier, and its much harder to manage.
The best possible thing I can say about systemd is that opensuse stepped up and protected me from most of it, by making long established commands invoke the systemd equivalent. At least I could use them till I learned how it was supposed to work.
As for the perennial Year of the Linux desktop, that predates systemd by at least a decade. Fastbooting also predates systemd. GNOME? Not on my machines! Pulse? Yes, true rot, but again that rot preceded systemd.
No, you are mistaken. I've always had this sig.
(Score: 2) by forsythe on Saturday December 06 2014, @05:27AM
Look, even systemd's most ardent opponents [ewontfix.com] realize it was aimed at servers:
Many of the selling-point features of systemd are server-oriented. State-of-the-art transaction-style handling of daemon starting and stopping is not a feature that's useful on desktop systems. The intended audience for that sort of thing is clearly servers.
Redhat wants it for their large server commercial packages, which they push strongly into Virtual Machine space.
Systemd was never designed for Joe Linuxuser. It was intended for large installations.
Did you even read the paragraph above the one you quoted? That article is claiming why systemd is unfit for the desktop OR the server, and that the feature set is aimed at both. The bit you're quoting is pointing out certain elements of systemd that don't make any sense on the desktop. Note that what you quoted explicitly says ``Many of the selling-point features'' and ``that sort of thing''. Many other features of systemd are desktop oriented.
(Score: 0, Troll) by Anonymous Coward on Friday December 05 2014, @07:21PM
Arch was great before systemd started infecting everything and made the whole rolling release thing a much bigger PITA than using traditional point-release distros.
(Score: 0) by Anonymous Coward on Friday December 05 2014, @11:03PM
Too bad the source isn't available for people to modify to meet their own needs
(Score: 0) by Anonymous Coward on Saturday December 06 2014, @12:31AM
Yeah, sorry I just upgraded your car to randomly veer of the road. I know it wasn't broken and I wasn't fixing anything but really it's all for your benefit. If you're unhappy, here's the drawings so you can put your life on hold for 6 months and build your own.
(Score: 2) by novak on Saturday December 06 2014, @02:22AM
Too bad the source isn't available for people to delete
FTFY. Seriously, the people who dislike systemd don't wish they could make a couple adjustments to it, they just don't want it. While they are able to do this, many parts of the system are simultaneously moving along with systemd which is why everyone got angry.
The best example of this is probably when systemd pulled in udev as part of it- there's no reason for that, udev worked for years without systemd- but now you either lose device hotplug or roll your own. It gave systemd proponents a good laugh at how backwards all their opponents were, sacrificing features that had been in linux for a decade over a philosophical issue. People that actually had their heads on straight got a rude awakening to just how nasty systemd was going to be. And, of course, we now have eudev which is basically what udev used to be.
novak
(Score: 2) by fnj on Saturday December 06 2014, @03:50AM
I haven't seen any comment that realizes this yet. The announcement is not of a "rolling release", and the phrase is not even used in the announcement. Come on, guys. Rolling release means something. It means individual package version numbers are tracking the latest development versions in close to real time. Like Arch linux. You are constantly getting completely new versions of everything, including the kernel. That is complete anathema to a professional enterprise grade server/workstation OS.
RHEL and CentOS are going to continue to be the way they always have been. The kernel version and versions of all packages are set at major release time (RHEL5, 6, 7) and never change until the next major release. In the interrim, security patches and some limited enhancements are fitted, always in the form of patches which do not change the version numbers. So you always have stable APIs and your tools and apps are not undergoing changes in behavior all the time.
E.g., the kernel at every point in the lifespan of RHEL5 is stuck at 2.6.18; RHEL6 is 2.6.32; RHEL7 is, I understand, 3.10 (7 is the first version I am never going to use since they have abandoned reason and adopted systemd).
All the CentOS announcement means is that installation snapshots of the latest security-patched state of the release will be provided periodically. Saves a lot of time patching fresh installations. And that is all.