Greg KH Favors Rolling Release Distros

jones_supa writes In an interesting Google+ post, the lieutenant Linux developer Greg Kroah-Hartman mentions him fully moving to rolling-release Linux distributions: 'Finally retired my last 'traditional' Linux distro box yesterday, it's all 'rolling-release' Linux systems for me. Feels good. And to preempt the ask, it's Arch Linux almost everywhere (laptop, workstation, cloud servers), CoreOS (cloud server), and Gentoo for the remaining few (laptop, server under my desk).' What's your experience? Would in the current situation a rolling-release operating system indeed be the optimal choice?

Comments

Uh

[Chess_the_cat]

Don't bother clicking the link. The *entire* post is contained in the summary.

Re:Uh

[Anonymous Coward]

That's hilarious. I had to click just to verify you're right.

You are.

Re:Uh

[AikonMGB]

Shit, I accidentally RTFA then =(

Re:Uh

[Jose]

hah, what a newb.

I really wish Greg would have told us which distro he is using though.

Re:Uh

[Anonymous Coward]

That's jones_supa's primary MO - copy-paste, no interesting editorial/submission oversight/creativity, etc.

Slashdot is turning into the same garbage that Soylent beat them at becoming.

Re:Uh

[Anonymous Coward]

He is on Arch.. most likely

So much for stability and uptimes...

[TWX]

There was an era, probably inherited from the big-iron computing model, where we strived for stability and long uptimes. We didn't install things that we didn't need (with the exception of Fortune perhaps) and locked-down the box at the network stack. Granted, it required a lot of knowledge at the beginning to make sure that the box was indeed secure, but we were proud of setting up a good, usable box that didn't need a lot of maintenance after the fact.

I guess that era is now gone, with rapid-release and lots of little things constantly needing the system to restart.

Re:So much for stability and uptimes...

[Anonymous Coward]

I guess that era is now gone, with rapid-release and lots of little things constantly needing the system to restart.

systemd is not lots of little things it's just one big thing that does it all.
long life linux NT

Re:So much for stability and uptimes...

[gstoddart]

Some of us still work in environments where constant restarts are strictly not allowed, and software which expects to be on a constant release cycle is shunned.

We had a vendor once, who wrote a component for a large enterprise system ... they released builds pretty much weekly and thought that was grand.

We filed a bug once, and they said "we don't support that version because it's a month old, and therefore 4 versions out of date, you need to upgrade". We said "you'll be hearing from our lawyers because we don't take a prod outage every week just for you idiots". Needless to say, they quickly realized they were going to lose that fight.

Sorry, we need a lot more stability, and we don't care if you think you're on an agile cycle. It takes around two months to promote something through to Production ... we simply don't care that you want to build weekly.

Not all places (specifically most regulated industries) have the ability to have stuff constantly changing underneath them, and they certainly haven't got the patience for some company who thinks a product lifecycle is measured in weeks.

Continuous releases often have the effect of making your customers your beta testers. And we can't do that for you.

Re:So much for stability and uptimes...

[jythie]

Over the last decade or two, both developers and users have simply become to a certain, rather low, level of stability being normal. The economic prize tends to go to companies that play fast and lose, more conservatives ones that are careful end up not being 'sexy' enough and wither.

Re:So much for stability and uptimes...

[Anonymous Coward]

Yes many prople grew up and realized that bragging about their laptop's uptime was silly epeen wagging.

Re:So much for stability and uptimes...

[jythie]

While many consider it gouging, this is why I like support contracts. A nice signed piece of paper saying 'yes, we WILL support the version you are using even if our active development moves on'.

Re:So much for stability and uptimes...

[Anonymous Coward]

Wow, sounds like a lot of anger for a non-issue. As a desktop user rolling releases are just superior, as _I_ donâ(TM)t have the time to constantly reinstall a whole OS every 2 years (but I do have lots of time to fix breakage :).

In reality, if you use a rolling release distro for production, you are either a moron, or doing the work a traditional distro package everything up yourself when you feel like it (which is also crazy, but does help keep you informed of possible security updates if you do roll your own).

But really, just use/consider BSD if such stability is required, Linux has to many 'rebels' working/replacing core packages far too often for far too dubious of reasons.

Re:So much for stability and uptimes...

[armanox]

I don't think the OP was talking about his laptop.

Re:So much for stability and uptimes...

[TWX]

Yet, those rapid release cycle groups are becoming problematic. Case in point, Instructure Canvas. Three week release cycle, significant dependency on third-party repositories and on patches to stock components, and yet doesn't support the current-stable OS, relying on an old-stable. Also takes 90+ hours a week just to keep it running properly.

Instructure is trying to get people to use Instructure's cloud hosting, not to use a self-hosted model. I expect that contributes to their customers' migration to the Instructure-hosted version even at $10/student.

Re: So much for stability and uptimes...

[Anonymous Coward]

Using separate apps and libraries which have strict and unavoidable dependencies between them isn't "modularity".

Modularity requires those components to be very loosely coupled.

For example, GNOME consists of many separate libraries, apps, and scripts, but it isn't modular. Installing just one small GNOME app means you have to pull in tons of libraries and other apps, because they are tightly coupled.

Systemd is similar to GNOME. It's an all-or-nothing situation, which obviously isn't modular.

Traditional UNIX software generally is modular. I can easily change my shell, for example, without affecting the other software on the system. I can even install a different C compiler, and none of the other software on the system would even be aware of the change. That's true modularity.

Re:So much for stability and uptimes...

[jythie]

One of the things that really ends up concerning me is that dependency tree and how it can quickly branch off in all sorts of unexpected directions as packages bring each other in.

One thing I really loathed about using maven in a production environment was the younger developers looking at the fact you could set the version numbers you wanted as a panacea against needing to worry about what an update will do.

Re: So much for stability and uptimes...

[Anonymous Coward]

don't forget that they're adding a bootloader now too... I can just see it now:
systemd bug report:
Missing kitchen sink.

Anyways, I'd been planning to move away from Ubuntu for some time, and went as far as experimenting with Fedora Core 20/1, and HAD been toying with the idea of moving to arch.

I ended up installing arch on a new a10-7850k build as I wanted to toy around with HSA and since support is really just rolling out the last few months, I needed something a little more bleeding edge than the "traditional" distros. All I have to say is that arch was a PITA to setup(1st time only hopefully) and brought back nightmares of days long gone by, bootstrapping gcc, re-compiling kernel, building X11, circular dep hell in Redhat, building custom kernels again later, etc. before I finally threw up my hands and moved on as I was wasting too much time building, customizing, and trying to fix borked dep systems. Still ran yellowdog on ppc systems(pretty much only choice other than debian IIRC) and tried opensuse(actually flirted with this several times I remember when they used to sell opensuse retail with a massive(and useful) tome of documentation(this was back in the fuzzy time of tldp just starting and dox just kind of vague and fuzzy if there were any)), and Debian on x86 machines until Ubuntu came around, but the last few years Ubuntu has been moving off somewhere that I don't want to go for the ride with it -> looking around at other distros, tries linux mint and some others(Ubuntu derived) as well.

I also tried the I guess arch derived "distro" that tries to tack on a GUI installer, but that thing did NOT like my system at all, so instead of wasting time, I went and installed arch the PITA way that it's meant to be installed. Christ! It's worse than installing(CLI) *BSD. ...and for the guys that need a long term constant/consistent OS that's what the LTS traditional distros are for. The rest of us are probably really better served by the roilling distros, or at least to an extent, or perhaps one of the *BSDs.

Re:So much for stability and uptimes...

[swb]

And if you're lucky, the people you deal with are all seasoned veterans with the version you want support on, know all the fixes and troubleshooting info.

If you're not lucky, the people providing support for your version are clueless newbies who've never seen your version in active production and are relying on the internal KB and decision trees they stumbled across on an old file server.

And you could blame the vendor for being douche bags and that might be true, but then again, maybe the seasoned veterans want to work on the current release or need to be fed new and interesting stuff in order for the vendor to keep anyone competent in their support department. Which then makes the vendor non-douchy at least to some of their employees while still being frustrating to their customers.

Re:So much for stability and uptimes...

[Anonymous Coward]

How come every systemd update on Debian makes the next system shutdown a collection of random things if the systemd was so modular and allowed online updates? After systemd update, the power button may not bring the confirmation dialog (to select from hibernate, restart or shutdown) but it initiates shutdown, NFS unmount may halt the system, etc. The "best" part of this behaviour is that the systemd disables first the possibility to jump to virtual teminals (ctrl-alt-fXX), then it puts the screen black and only after that it select between the failure sequence to do. So the debugging can be done after next reboot, if the binary log files just survived from the hard shutdown usually needed.

Re: So much for stability and uptimes...

[funky_vibes]

The one thing that keeps me from using obsd is that each time I remember the close to non-existing fs support even for the most common ones such as ext3.
no journal, no deal for me.

Re:So much for stability and uptimes...

[TWX]

Correct. Right now I'm more thinking of the syslog server. Kinda needs to be running.

Re:So much for stability and uptimes...

[gstoddart]

But really, just use/consider BSD if such stability is required, Linux has to man

Spoken like a clueless AC who mindlessly suggests open source for everything.

BSD and Linux do not usually have functioning, enterprise software for a lot of things.

So your little toy won't cut it, doesn't have the same kind of software, and what you say is utterly meaningless.

This is precisely the difference between corporate production environments than what some smarmy little twit thinks can be solved with "just use BSD or Linux".

Re:So much for stability and uptimes...

[jythie]

In such cases I would label the vendor either an, as you say, douche bag, or less than competent. Generally companies that want to support long contracts like that have to find some sort of balance where developers are spread around and doing both new development and older support. Put someone in either category too long and bad things tend to happen.

Re:So much for stability and uptimes...

[radish]

You know it's interesting. I used to work in finance. We, like you it seems, had a very locked down production environment with huge amounts of testing - pushing builds through multiple stages, reviews and signoffs. Once every month or so we'd shut everything down for a few hours in the middle of the night and roll the world forward. Stability was everything. Downtime was OK if scheduled, a disaster if not.

Now I work at a web company. We push to prod multiple times per day. There's a process, there are reviews and approvals, but it all happens much more quickly and at a more granular level. Change is constant but small, as opposed to infrequent but total. What's more we're a 24/7 operation so no downtime (as visible to the user) is acceptable. We simply can't schedule a few hours to do our rollout - everything has to happen live.

You know what I've noticed? We're no less reliable, overall, than the bank was. Yes we have issues, but they tend to be noticed, and fixed, much much faster. When you change everything all at once you run the risk of not being able to figure out what broke when inevitably something does. Rollback is painful because you have so many interdependent changes - in the end you have to pull the whole release to avoid one small issue in a single module. When you roll frequently the scale of change is small so isolating the bug is trivial, and rolling it back the same. Now of course there are huge differences in risk when you're handling people's money vs their cat photos, but I think the view that people working on an agile schedule don't care about stability, and that the only way to achieve stability is through reducing the frequency of change, is demonstrably wrong.

Re: So much for stability and uptimes...

[Barsteward]

"don't forget that they're adding a bootloader now too" - its OPTIONAL like everything else (bar journald), do some research

Re:So much for stability and uptimes...

[Barsteward]

Speak to Debian about their configuration, they may have not yet got it right. Red hat, opensuse, arch etc seem to be okay

Re:So much for stability and uptimes...

[swb]

But then again, there are douche bag customers, too, who refuse to update and insist on running grossly outdated software. Usually it has nothing to do with grizzled, old-school IT vets and their deep regard for mainframe era stability but super douchy business owners who just want to cash checks.

I *just* did a project for a customer like that. They built a brand-new infrastructure (which is quite good in terms of actual hardware) so they could install "new" 2003 r2 x86 servers and run an old x86 version of Metaframe and their ancient x86 ERP software the vendor barely supports.

There was some loose talk about new ERP software requiring some workflow changes, but it kind of seemed to boil down to just not wanting to spend any money.

Re:So much for stability and uptimes...

[bluefoxlucid]

I think we can conceptually do a rolling release without trouble. I've even written up how to do it: add DT_RUNPATH into each binary in a package pointing to /usr/packages/$PACKAGE/$VERSION/lib; install any compatibility packages into their own /usr/packages/$COMPATPACKAGE-$VERSION/; and symlink those binaries from /usr/packages/$PACKAGE/$VERSION/lib/liboldshit.so.1 to /usr/packages/$COMPAT-PACKAGE/$VERSION/lib/liboldshit.so.1.

When the binary loads, it'll look for every library in /usr/packages/$PACKAGE/$VERSION/lib first. If it finds nothing, it'll look in the usual places; otherwise, it'll load that library. gtk2-2.1.3 breaks shit that works with gtk2-2.0.1, but they both install to /usr/lib/libgtk2.so.2 and so can't be installed together? Well, install gtk2-2.0.1 to /usr/packages/gtk2/2.0.1/lib/libgtk2.so.2, and symlink to it from /usr/packages/oldshit/1.3.9/lib/libgtk2.so.2; when the user runs /usr/bin/oldshit, it'll load libgtk2 from the latter path, instead of loading it from /usr/lib/libgtk2.so.2.

The DT_RUNPATH can be left in place always. If a package becomes incompatible, upgrading a library may involve moving the current library's files under /usr/packages, creating symlinks for the broken program under its /usr/packages tree, and then installing the new version of the library. When a newer version of the incompatible program has been tested and vetted, you can upgrade it and use the new library; likewise, brand new programs requiring new libraries that break 90% of the system can use those libraries in the same way, rather than replacing the system library--until that library is considered system-stable.

You can go by degrees. You can, in fact, say that parts of this rolling release are stable, but other parts are not, and so those other parts will be left at an older point until well-tested. You can essentially mix together various incompatible stages of release.

Re:So much for stability and uptimes...

[0ld_d0g]

The problem with your first company was the process itself. Downtime was OK? Hello! What? Also, a rollback should be an extremely rare event (for either schedule). Lots of rollbacks/downtime shows that people managing the project are not serious about uptime/stability/etc - in which case, the point is moot.

Re: So much for stability and uptimes...

[Anonymous Coward]

There are scripts on the Arch Wiki that alleviate most of the PITA aspect of Arch. I found them after I had done what you did, though I can't say I found it terribly difficult to set up as long as I followed the steps in the wiki, then again this was after a few days of trying to get other stuff just to run at all on my system so it's all relative. I've been looking to jump into BSD as a storage distro, sounds interesting based on your description. Personally I found Arch to be far more pleasing and user friendly than Fedora, which I'm currently using.

Re: So much for stability and uptimes...

[Anonymous Coward]

Using separate apps and libraries which have strict and unavoidable dependencies between them isn't "modularity".

Except that the old crusty init shell scripts have similar dependencies.

Re:So much for stability and uptimes...

[Archangel Michael]

I've been in the industry long enough to have seen plenty of "customers" demanding to save money by short changing long term decisions, only to pay more money in the long run to still have a non-viable system in place, because ... well they don't want to spend the money to do it right.

Your post just reminds me of spending good money on bad ideas in the name of saving money that is never saved.

My current philosophy is to help guide people into doing things right, even if it costs a little more now, with the assumption that doing things right now, will save a lot more in the long run. Too many people are only looking at today, and cannot see tomorrow even when we show it to them.

Re:So much for stability and uptimes...

[Anonymous Coward]

All I'm going to say is that we have some clients who refuse to move off of Windows 3.5 because the cost to upgrade wouldn't be worth it. Makes me cry a little.

Re:So much for stability and uptimes...

[Anonymous Coward]

We use linux and BSD in our production software, so don't most major corporations with servers. Maybe you want to evaluate who thinks what are toys and who it is that is mindlessly spewing stuff.

Re:So much for stability and uptimes...

[Anonymous Coward]

Actually that's pretty wonky. Please file a Debian bug report.

Re: So much for stability and uptimes...

[Anonymous Coward]

that's not true. You need the libraries, not the apps. Gnome is a bunch of little C libraries and a bunch of apps that use them.

KDE is as you describe. It is a morass of C++ code that everything touches everything else. However, since KDE is still a desktop environment and Gnome doesn't know what it is...

Re:So much for stability and uptimes...

[Crazy Taco]

There was an era, probably inherited from the big-iron computing model, where we strived for stability and long uptimes. I guess that era is now gone, with rapid-release and lots of little things constantly needing the system to restart.

I don't think it's gone completely. For the consumer, yes, it's over, because they want the latest and greatest NOW regardless of possible flaws. I think the only reason consumers ever had a non rolling release model is because tech originally started with the enterprise and for the enterprise, and trickled down to the consumers. It wasn't until later that things became so consumer centric with a consumer driven model like rolling release.

But enterprise hasn't ceased to exist, and there is still a lot of money there. And that money goes first and foremost to companies who provide functional, stable products that don't require a lot of maintenance or upgrades for a while. Because in enterprise IT, upgrades and maintenance cost more than the software, and minimizing those costs are paramount.

So I think non-rolling releases will continue in the enterprise, and I think for evidence of that you can just look at all the companies that dumped Firefox and went back to IE when Firefox switched to rolling release. Many large IT shops had spokespeople saying new releases of Firefox were coming out so fast that they couldn't certify app compatibility before the next one dropped, and Microsoft jumped on it, pointing out that they were still doing non-rolling releases. Microsoft's market share has dropped off a cliff with consumers of course, but if you look large enterprise's, IE is absolutely everywhere, probably as much as it has ever been. No one does long term, stable support of old stuff like Microsoft's Enterprise and Compatibility browser modes, and there's still a demand for that.

Re:So much for stability and uptimes...

[Anonymous Coward]

What were your SLAs at the bank, and what are your SLAs at your web company?

My company has SLAs (necessary to sell the product) that would cause millions of dollars loss per hour of unplanned downtime, although they have many allowances for scheduled downtime and (very) occasional emergency maintenance downtime. Even one minute is accounted for not just by us, but by them, and is billed accordingly (seconds cost thousands of dollars when hours cost millions).

A bank likely has a certain time of day they have either told their customers the service won't be available (and thus customers can work around that) or they have told their customers the maximum queue time will be X minutes. Rolling those about randomly is not going to be acceptable. Customers attempting to use bank services during maintenance periods can and do expect issues.

As an example, a finance company debits my account on Friday just before midnight. This is during downtime for my bank. I was wondering why the transaction did not show up on Monday, so I called them. They said it is normal due to the conflict and that it will show up within a few days. Lo and behold, it did. The finance company, despite not getting their money "on time" every single time they bill me doesn't get upset precisely because they know they Friday's transactions are during a maintenance window and thus they are at fault. This is a solid 1 out of 5 customers which experience this, but due to the well defined nature of the issue, everyone is happy. If they have 10,000 loans, that's 2,000 that are always paid in arrears but never sent to collections nor reported as the problem is well defined.

In your case, a certain percentage of their transactions (let's say 0.05%) will randomly fail. Out of 10,000 customers, that's 5 random customers in arrears. My finance contract dictates in 3 days they will begin collections. In my above example the transaction appeared Tuesday night. That's 5 random customers that have collections calling them who aren't at fault. A typical loan for them is probably 5 years, paid bi-weekly. 5 * 26 * 5 = 650 upset customers. 6.5% of your customers being bothered for nothing is not cool.

Re:So much for stability and uptimes...

[Anonymous Coward]

Your company should have done a better job determining the update cycle of the product they bought into. Figures you'd threaten them with lawyers for your mistake in not researching the situation properly.

Re:So much for stability and uptimes...

[Anonymous Coward]

Tech changes way too fast for it to be viable anymore, outside of specific sectors like finance or government. "Stability and long uptimes" have shifted to "Resilience and availability" for good reason, IMO.

Re:So much for stability and uptimes...

[Sri Ramkrishna]

Stick toa long term release.. Arch Linux is probably more suited for desktop users. Nobody in their right mind would use Arch for enterprise stuff.

Re: So much for stability and uptimes...

[sjames]

But my app doesn't require a specific version of glibc. I just updated my glibc (only) a week or two ago.

If you include re-compiling, it can use a number of other libc implementations as well.

Re:So much for stability and uptimes...

[Anonymous Coward]

And if you're lucky, the people you deal with are all seasoned veterans with the version you want support on, know all the fixes and troubleshooting info.

If you're not lucky, the people providing support for your version are clueless newbies who've never seen your version in active production and are relying on the internal KB and decision trees they stumbled across on an old file server.

Or, you know, they could be competent and have a proper release branch for each released version in their source repository. This solution to this problem has been around longer than most of us have been alive. CVS was released in, what, 1979? I was born in 1980, and I haven't been an industry "newbie" for several years now.

Any company that doesn't know the benefit of using tools that, in some form or another, have been around for 35+ years is a company that deserves to be replaced by one more capable of doing the job correctly.

Re: So much for stability and uptimes...

[Anonymous Coward]

I'm sure it will be "optional"... just like how systemd is "optional" in RHEL 7. Yes, it can be disabled... but you won't have a UI.

Nothing like forcing an entire userland of untested, potentially insecure code that has network stack functionality and all runs as UID 0 into the enterprise. Has this mess been audited? Not that I've seen. Has it been tested (not random "testing", but real code audits to deal with security)? AFIAK, nobody has even checked to see if a "if (x = y)" is present instead of if (x == y)" in the security sensitive stuff.

systemd may be a great product, but it really needs a year or two of people scrutinizing the code to find any potential security issues. Otherwise, it is a enormous remote root hole waiting to happen.

Re:So much for stability and uptimes...

[Anonymous Coward]

Exactly. There are also businesses which have a test cycle where any new releases are run on a testbed that mirrors production for a bit to ensure nothing horrific will happen when it goes live.

This is part of Windows administration as well. One doesn't just configure WSUS to auto-approve updates (or worse, have all production boxes automatically suck their updates from MS and reboot when they feel like it.) One does at least some testing to see if it will take down the application stack before it goes live.

Other environments are even more demanding. I worked at one place that only allowed certified code levels of Windows with not a single change allowed from that configuration [1] other than a user's data was allowed to be stored. It took weeks to a month of vetting before the internal lawyers, auditors, and other people would sign off on any changes to the OS and core applications. They even disallowed Administrator access for any reason by anyone without a trail of paperwork to back it up (the AD admins had both a user account and an account with AD admin rights, and the AD admin right account had to have a paper trail from the second it was logged on to when usage stopped.)

As for rolling releases. For an OS that will never see production use in a serious enterprise, sure thing. Running emerge world as a cron job is just fine for a test bed or someone's playground. However, for operating systems that have to be tested and vetted, they have to have distinct releases, even if it is like Solaris with a date release with updates, or AIX that releases tech levels on an annual basis.

What I'd like to see are two sets of releases. A gestalt that is a set of patches at a certain time/date that has been extensively tested as it is, then an alias to the absolute latest releases. This way, on development/test systems, they can have the latest and greatest, while in production, I can show the auditors what exactly what certified version stuff is running on.

[1]: I ended up getting the software licenses approved and using Thinstall/Thinapp so software like Web browsers and Microsoft Office could be updated without touching anything on the actual machine. I copied some shortcuts pointing to the encapsulated programs sitting on a share, and updated the programs there. This allowed the machine images to remain at the certified specification... but still allow things that needed updating to be updated. The Powers that Be actually liked that mechanism and kept it after I moved on, because there was absolutely no access to anything with windows administrative rights whatsoever by people, and the only program changes were allowed to be done by SCCM.

Re:So much for stability and uptimes...

[localhost8080]

Had to reboot two production machines last night, their uptimes were 696 and 694 days :(

Re: So much for stability and uptimes...

[Anonymous Coward]

untested

Untestd
FTFY

Re:So much for stability and uptimes...

[Darinbob]

Right. If it ain't broke, don't fix it.

Re: So much for stability and uptimes...

[Anonymous Coward]

That's why you should use FreeBSD... the first OS other than Solaris to offer ZFS. Add GELI and you've got full dist encryption. Linux is going sideways with their ZFS implementation, and frankly not even close to production or features with their BTRFS non-equivalent to ZFS.
OpenBSD is only good for the security at ALL costs freaks (which is still unobtainable security) and the [multiplatform] minimalists, not for a balanced approach that addresses all areas well.

Re: So much for stability and uptimes...

[Anonymous Coward]

If you like Arch, you'll love FreeBSD, it's so simple and streamlined. Yeah, you have to edit some config files, but the examples are well commented and they have manpages and a good handbook. I put all my music and movies on ZFS.

Re:So much for stability and uptimes...

[Anonymous Coward]

I know right. I had one Linux distro all configured for one window manager they said they were staying with. Then they swapped them out claiming new design paradigm. Users decried for a year over that, they said they were not going to change. So I re-optimized again. You know what? Those rebels switched back 1.5 years later. Two major switches for NO real reason whatsoever. That's why I use FreeBSD now and for the last four years. They don't do stupid childish stuff like that. In fact, they don't even consider themselves as having a default choice of managers anymore. You just pick whatever you want from ports and install it.

Re: So much for stability and uptimes...

[Anonymous Coward]

Don't bother arguing with Barsteward. He's a systemd zealot, who barfs out shit whenever the topic of systemd comes up. The fact that he defends systemd should tell you everything you need to know about how worthless his opinions and thoughts are: pretty fucking worthless!

Re:So much for stability and uptimes...

[Anonymous Brave Guy]

I hope you're not recommending OpenBSD as an alternative for better long term support.

More than a year old? You're out of luck.

Re:So much for stability and uptimes...

[Anonymous Brave Guy]

I agree with almost everything you wrote there. A month ago, I could watch Flash videos just fine in Firefox. Firefox update comes round, then install a couple of security updates for Flash, and now roughly half the time I play a Flash video the browser locks up and I have to kill the process. Given that I've spent much of this week watching training/conference material on sites using Flash videos, I'm no longer able to use Firefox for work. (Bonus snide remark: If the Firefox team spent more time fixing fundamental architectural flaws that need some real work and less time redecorating for the seventeenth time this week to make my desktop browser less usable but more like a mobile browser no-one uses, at least those hangs wouldn't take out all my other tabs at the same time.)

Something I've written before and will no doubt write again is that if Microsoft actually played to their strengths in terms of long term stability, and then added a transparent fee for continuing compatibility and security fixes after some reasonable initial period of free support so they were making real money in return for keeping things like Windows 7 running indefinitely, I think they would absolutely clean up with business users. Every Apple user I know seems to be fed up of Apple messing up their previously working gear with OS "upgrades". I'm not sure I even know anyone who still relies on ever-changing web apps for professional work any more -- they're obviously popular in some quarters, but software-as-a-service is already over around here, having utterly failed to live up to the hype and proven in practice to be a combination of recurring charges and frequent unwanted minor changes. What do lots of business people I know actually run? Windows 7 and Office (the locally installed version).

People with real work to do couldn't care less about rapid release cycles, agile development processes, and proudly telling interview candidates that you'll push code into production on your first day. They just want software that helps them to do whatever they need to do, and that will still be helping them to do it tomorrow.

Re:So much for stability and uptimes...

[Anonymous Coward]

We had a vendor once, who wrote a component for a large enterprise system ... they released builds pretty much weekly and thought that was grand.

We filed a bug once, and they said "we don't support that version because it's a month old, and therefore 4 versions out of date, you need to upgrade". We said "you'll be hearing from our lawyers because we don't take a prod outage every week just for you idiots". Needless to say, they quickly realized they were going to lose that fight.

When you say that, I read, "I was too stupid or too lazy to perform due diligence and secure adequate support contracts for software that's integral to my critical enterprise systems, so I had to go threaten people with lawyers."

Shame on you for not reading the fine print when you purchased the software.

Re:So much for stability and uptimes...

[msim]

It makes the product sound like a steam "early release" rather than a production system and totally impractical for a live business environment. Some of this stuff is just too "seat of the pants" material.

I remember working in system admin and the product testing hoops that had to be jumped through by the testers was phenominal. They'd have products in test for three or more months before they'd even start raising notions of sending it out to get approval/review for sending to a live system. Hell I treat my mythtv system at home like a production environment as it isn't worth the wrath of my wife and two year old if it breaks and he cannot watch Peppa Pig.

Re:So much for stability and uptimes...

[msim]

This isn't just in business, most political decisions made don't consider looking past the next election, let alone looking into how it will impact ten let alone thirty years down the line. Smart decisions like that require someone to be brave, and brave doesn't win more votes than "shiny thing, here's money" that most political promises seem to have.

Re:So much for stability and uptimes...

[msim]

The magic words here are "accountability" and "Support contracts". Some people are willing to either do things with open source software and wing it with the potentially marginal support they get. Others do things in-house and have support agreements with their support teams, with virtual money flowing in between groups to provide the support. Others are happiest with support contracts so that they can lever the supporting groups to MAKE them find a solution if they have to.

I'm not saying "linux isn't for the big boys", there are versions of linux that are at the enterprise level (i.e. RHEL), but there are significant differences between those willing to fly by the seat of their pants, and those whom take these risks seriously.

Re: So much for stability and uptimes...

[Barsteward]

delete glibc completely then see what happens

Re: So much for stability and uptimes...

[Barsteward]

facts get up your nose then?

Re: So much for stability and uptimes...

[Barsteward]

thats down to the developers of the UI concerned, not the systemd developers. if any app becomes dependent on systemd, its down to the apps developers.

Re: So much for stability and uptimes...

[thegarbz]

Systemd is similar to GNOME. It's an all-or-nothing situation, which obviously isn't modular.

*sigh* Do you get all your systemd knowledge by reading Slashdot posts? Systemd has some 50+ modules. There are 3 modules in the core system which are critical dependencies, launchd, dbus, and udev. The rest are optional. The rest are mostly dependent on just the systemd core.

You want to run systemd without any fancy network crap? Go right ahead.
You want to run systemd-ntpd without systemd? Seek professional help.

But to say it isn't modular and comparing it to the shitload of inter-dependencies of gnome is just absurd at best and intentional FUDmongering at worst. /I'm not defending systemd, but pick on it for legitimate reasons, don't make things up.

Re:So much for stability and uptimes...

[Anonymous Coward]

That is typical, unfortunately, and not only in debian. I've seen the same exact behaviour in Arch, and many times you don't even have to update systemd to have those crashes and hangs at shutdown. All you need is a network filesystem that won't unmount cleanly.
Ah, and give up any hope of having any hint of what went wrong in the logs - they'll be corrupted beyond repair, most of the times.

Captcha: suffers. How strangely appropriate...

Re: So much for stability and uptimes...

[Anonymous Coward]

I guess the continued repeat of propaganda that you, thegarbz, and Peter hs, do here is getting up everyone's nose. Half truths, FUD, and constantly repeating your prophet's words will make people start ignoring you...

Re: So much for stability and uptimes...

[Anonymous Coward]

You're not defending systemd? I have yet to see one of your posts that isn't a pro-systemd tirade, and denying that systemd is a clusterfuck of dependencies on the worst gnome tradition is just par for the course.
It is correct that for now installing one systemd module like login "only" brings along pid1, binary logging horror, and udev, as well as libsystemd. For now, and that is already too much interdependence to still claim systemd is modular. But according to the prophet's road map, it will soon also mandate the boot loader, and if his vision of forcing a TiVo like, fully signed systemd os, comes to pass, then it will include all modules that are semi-independent for now.
And after the promises regarding udev independence from system week broken, no one in his right mind will trust any other promise regarding any tool absorbed into the systemd repository.

Re: So much for stability and uptimes...

[thegarbz]

No I'm not. Fell free to read my post again if you disagree. I urge you to find one piece which is either opinion or factually incorrect.

I defend systemd alot against the hate on here, but right now I'm just fighting dumbarse second hand misinformation.

If you think that 3 components requiring each other out of 50 separate modules is not modular then please go find yourself a white room with soft walls, because by god you need it.

Re:So much for stability and uptimes...

[Anonymous Coward]

I think the expression "Downtime was OK if scheduled" doesn't really reflect the process, but more the fact, that downtime has to be scheduled and planned in order to retain data consistency. A single transaction lost on just one of the systems in the toolchain can have dire consequences. That's not normally the case for web-centric businesses

Re: So much for stability and uptimes...

[Anonymous Coward]

Modularity requires those components to be very loosely coupled.

Yes, but that can happen in many ways. Your example is good for simplicity and small programs (which is not a bad thing) but not so
good for systems as a whole, or software that must be portable.

The TLDR version: the number of libraries something depends on does not correspond to how modular it is or not.

You tell me; which is more modular or less modular:

I) magic_math, hard-coded to use lib_gmp for bigint support
II) numinous_numbers, hard-coded to use lib_openssl for bigint support
III) valuable_values, links against lib_bigint_wrapper

lib_bigint_wrapper is a wrapper around bigint functionality; it depends on one or more child backends;
there is a child backend that uses lib_gmp and a separate child backend that uses lib_openssl, and so forth...

lib_bigint_wrapper needs at least one of its child backends present to function (child backends can be statically-compiled or loaded dynamically, does not matter for this discussion), but lib_bigint_wrapper does not require more than one child backend to be present (and hence, at minimum,
lib_bigint_wrapper only depends on one more library)

at run-time, application code can specify which lib_bigint_wrapper backend to use; e.g. it can prefer openssl then
fall back to gmp if it wants; it can require gmp and fail if that backend is not available; application code uses the wrapper functions so
it is not dependent on gmp or openssl unless the user, at run-time, decides they want a specific child backend used

note that III) in this case depends on, at minimum, 2 libaries (since the wrapper library is mandatory) -- dynamically or statically does not matter here, it needs 2 other libraries to function.

cases I) and II) only need 1 other library.

(well, they all probably need libc and maybe libm, etc. -- those are assumed equal)

yet, I would still say III) is "more modular" than I) or II) because it is more flexible; your application gains modularity by using
this intermediate wrapper/abstraction, not loses it

just because you link against one more library or not does not automatically mean the application is "less modular";

in this case, linking against this wrapper library INCREASES the modularity of the application

multiply this for 50 different applications, it would not be modular if they each individually depended on lib_openssl
or libgmp or whatever...

it would not be modular at a big picture level either, if they each included their own "wrapper" functionality built-in to each
application (nor would such a thing be maintainable) ....

you can argue how this is best accomplished, but the wrapper libraryi n this case makes code that links against it MORE
modular than hard-coding a gmp or openssl or whatever dependency.

now, multiply this for x different things, not just bigint functionality...you might end up with 20 "wrapper" libraries for various things,
but application code is quite flexible.

the number of libraries something depends on does not correspond to how modular it is or not.

in general, that perhaps is a start, but there is no such correlation.

as you say, traditional UNIX software is modular, at the user level:

- you can change your shell and not break everything

- you can use a different C compiler and just call `make CC=my_new_cc ` and things will "just work"

however, there is developer-level modularity too. from the developer side, especially someone who wants to write portable
software, wrapper libraries is one way to get "more modular" software.

you may never see such a thing unless you compile things yourself or change application defaults (e.g. gmp might be quicker on large numbers, so you tell your application to prefer that if it is present) but there is more than just "user level" modularity.

i agree with you, you are correct, but that is just one part of th

Re: So much for stability and uptimes...

[Anonymous Coward]

i agree with you, and think what i say is nothing new and you are well aware, i just dont want anyone getting the impression
"many separate libraries" automatically means more modular or more tightly-coupled software;

that really depends on the library in question...

Same thing the other way.."many separate libraries" doesnt mean less modular or loosely coupled either, necessarily.

it depends on the library in question.

are gnome and systemd really that bad, or is that just package maintainers turning everything on by default and those are the binaries
most people see?

Re: So much for stability and uptimes...

[Anonymous Coward]

in my example, applications are tightly-coupled to the wrapper library, but as long as the API is sane, you can
easily just write a backend that even e.g. calls some other library, and writing another backend to use another bigint
library should not be difficult; it can happen without a recompile of the applications or even the wrapper library if done right.

Now, for your "shell" and "c compiler" example this may never come up;

if your shell only runs on UNIX, or even is hard-coded for some particular UNIX and kernel / system calls...no big deal.

so you may never see a need for modularity within the shell itself...it is just one self-contained chunk of code that can be compiled
with little fuss, depends on nothing (except maybe system-specific system calls, or POSIX/UNIX stuff).

at a big picture level (supporting multiple OS and multiple kernels) say you are writing a shell, you can do various things:

- write system-specific shells for every platform
- have one codebase with portability goo
- that's not my department -- each OS should follow POSIX (or whatever) and have a shell already there for me.

or the openssh/openssl approach "do both as separate releases" ... a "system-specific" branch and a "portable" branch.

what is "modular" depends on where you are and where you must run.

your approach does not scale to other OS and other kernels necessarily.

a "UNIX shell" can be implemented many ways...depends on where it needs to run.

portability != modularity per se either, but they can be related. depends on what you are after, what kinds of modularity you need.

there is more than just "user level" there are lots more views of things.

if i can't "swap out the kernel" (run my shell on another OS) how "modular" is that?

if my applications are all stuck to UNIX, how "modular" is that?

now, systemd and gnome it seems do not exactly care about portability anywhere besides linux, so I am inclined to think
they are doing it wrong (or just don't care about such things).

for a typical shell and c compiler, you probably want "As simple as possible" and systemd as well...minimal dependencies, self-contained
programs, simplicity is highest priority (not the same as modularity, although related -- the simpler something is, the easier to swap something
else in its spot).

for something like gnome and bigger projects, i would be more open to a somewhat different approach. I don't think you can compare
unix shell + c compiler to gnome or systemd...apples and oranges.

systemd of course, seems to be many things, and have more far-ranging goals than "init system"...

which tells me they should stick to "higher level" stuff than init systems, or write their own OS and call it what it is...

part of the frustration seems to be they seep in/takeover so much.....if they had just started a new OS project, things would
be much less controversial i think..........

aside from code design and modularity: systemd goals are simply not "traditional unix" (or go beyond it) and whether this is good or bad...
i don't think it helps anyone to pretend otherwise.

UNIX-wise you are correct...however, the world is not entirely UNIX.

some software must run elsewhere too.

whether a single codebase or "native" everywhere you want to run, is better or worse or more or less modular...depends.

there is the java / virtual machine approach. unless the whole OS is java, writing a shell in java is perhaps very odd.
(unless e.g. you gcj compile it down to a native static binary w/ no dependencies...even java, can be compiled down to "native code, no outside dependencies" despite the fact a typical JVM likely has many dependencies on various libraries.).

even "how is C implemented" varies....UNIX it may be part and parcel, intricately linked.....
on e.g. multics it was an add-on later.

one can say "tying UNIX so closely to C" is not mod

Re: So much for stability and uptimes...

[Anonymous Coward]

The future of development and IT infrastructure is unit and integration testing. Pace of progress (or ("progress") is too fast, and even if it wasn't, the only way to ensure software works correctly is testing. Thus, rolling release is not a big problem in this aspect. But effective testing of everything of relevance is still far from most IT departments...

Re:So much for stability and uptimes...

[rdnetto]

You know what I've noticed? We're no less reliable, overall, than the bank was. Yes we have issues, but they tend to be noticed, and fixed, much much faster. When you change everything all at once you run the risk of not being able to figure out what broke when inevitably something does. Rollback is painful because you have so many interdependent changes - in the end you have to pull the whole release to avoid one small issue in a single module. When you roll frequently the scale of change is small so isolating the bug is trivial, and rolling it back the same. Now of course there are huge differences in risk when you're handling people's money vs their cat photos, but I think the view that people working on an agile schedule don't care about stability, and that the only way to achieve stability is through reducing the frequency of change, is demonstrably wrong.

This is something that all Gentoo users know, either intuitively or from experience. Gentoo is an interesting case study as it's a rolling release distro (so no discrete releases) where updates have a non-trivial cost (compile time), relative to other distros. The result of this is that users delay non-critical updates significantly, which means that the Gentoo community has a fair bit of experience on the trade-offs of different update granularities. (I believe most people follow a weekly cycle.)

The short version is that the more time passes between upgrades, the more likely a bug is to occur and the more difficult it can be to identify and fix. You can upgrade as often as you'd like, but the longer you put those upgrades off the more maintenance debt accumulates, and eventually you might not have a choice if a security fix is only released for newer versions.

Re: So much for stability and uptimes...

[Rakarra]

Your contribution, as little as it is, is unnecessary, AC.

Re: So much for stability and uptimes...

[funky_vibes]

That's the thing, the features that interest me, are high amounts of code auditing = security, and good multiplatform which also proves a high level of workmanship and modularity of the code.
That's also why I like ext3, which is among the most well audited code in Linux. It actually goes further to protect you from many types of buggy drivers and disk hardware implementations.
ZFS and btrfs style multilayer filesystems only interest me insofar that they offer online dynamic multidrive spanning, but these types of features are still much lower priority for me.

G+

[fph il quozientatore]

The real news is, someone is still using Google Plus.

Re:G+

[Anonymous Coward]

It seems to be popular among kernel developers. This guy uses it too...

Re:G+

[Rob Riggs]

The real news is, someone is still using Google Plus.

Why? What do you use? The facebook? (snicker)

Re:G+

[Anonymous Coward]

Google+: Pretty much anything technical.

FB/etc.: Today I broke my little toe, I walked the dog, I smoked pot, etc.

Re:G+

[praxis]

The real news is, someone is still using Google Plus.

Why? What do you use? The facebook? (snicker)

It is inconceivable that the man uses nothing?

Re:G+

[Archangel Michael]

https://www.youtube.com/watch?....

Re:G+

[Anonymous Coward]

Naw, we can break this down more granularly Google+: Pretty much anything technical FB: Today I broke my little toe, I walked the dog Twitter: Today I smoked pot / soon to be featured on CNN Snapchat: Dicks! Dicks everywhere!

Situation Dependent

[jythie]

This really strikes me as something that is going to heavily depend on what the systems are actually doing, how tied to the distro-supplied software the usage is, and how often the releases are.

Even within 'rolling release' distros there is a huge variation in exactly what that means in terms of changes, updates, frequency, which parts are rolled vs versioned, user control over backdating. This combines with a bit of a matrix of use cases for one to find exactly how much manpower using such a distribution within an organization will eat up. So yeah, 'it depends' pretty much sums it up.

How critical is stability?

[davidwr]

For a machine that you would just blindly take updates for anyways, rolling releases are probably convenient.

For mission-critical systems where every change should be tested first, it's probably a bad idea unless rolling back is very easy, as it might be in a VM-with-easy-snapshots environment.

Re:How critical is stability?

[TWX]

When things are that critical usually there's more than one production box, and usually there are development and testing boxes too.

Re:How critical is stability?

[varag]

Do you really believe that "mission-critical" systems don't have outages?

Re:How critical is stability?

[DigiShaman]

At what level? Rolling back a VM means not just rolling back the OS, but Apps as well. What happens if you already upgraded the SQL database? You can't exactly roll that back too. Well, at least not without a restore. When dealing with database driven application in a clustered environment, you simply can't pushed the VMWare "oops" button. Doesn't work that way.

Re:How critical is stability?

[RavenLrD20k]

Of course they do, on a schedule, when the system is minimally used. Where I work this usually means that the updates get pushed into production on a Sunday (branch offices are guaranteed no business on Sunday) after they've been verified to not crap out on the Model environment. And Model doesn't get the rollout until the update has been verified in the Test environment for at least a week. Also, on mission critical systems, updates are only rolled out once a month at the fastest for only the most critical security updates. Other updates occur once per Quarter. Outside of this plan, if the main system and its redundancies go down any other time, someone's head is going to roll. The Data Center is not to go completely down during production hours for any reason, whatsoever.

Re:How critical is stability?

[Anonymous Coward]

it does if your DB is on a VM!

Re:How critical is stability?

[Grishnakh]

I'm no database expert by any means, but isn't it possible to put the database (its data store I mean, not the application) on a separate partition or drive, and mount that at boot-up time? Shouldn't that solve this problem?

Re:How critical is stability?

[Anonymous Coward]

The problem is if the database format changes. If you change the structure of your tables for your save format, then revert the changes that read those new formats, you're fucked because now you can't read any of your data.

One of the companies I worked for handled it by always pushing out the loaders first. Before users could save in the new formats they could read in those files. This helps test the loaders in a live environment before changing the save structure. Once that structure changes, you can't go back unless you took the time to write backwards conversion tools.

I use Gentoo - but not for much longer

[QBasicer]

I've been using Gentoo for many years, and temporarily switched to Funtoo on my personal laptop. I've since graduated and don't spent nearly as much time on my laptop as I used to, which these days mainly runs MythTV.

I don't think I'd continue with Gentoo - it takes too much time to sort through updates, figure out which packages need to be masked, etc. I'd rather go to Arch next, although I was considering Debian unstable.

Recently, my video card stopped being supported by the newest nvidia graphics, and the newer versions of Xorg weren't compatible. My masked list is growing as more and more packages have deeper dependancies on newer versions of Xorg. I always figured Portage should honour my masked packages and keep everything at the latest version without stepping on my masked packages, but it wants me to do everything manually. If package 1.2.3 is incompatible with my Xorg, I'll mask 1.2.3 and newer. There is a slight chance, however, that 1.2.4 will be compatible, but it doesn't matter, since Portage made me masked out 1.2.3 and newer, I'll never even know.

Re:I use Gentoo - but not for much longer

[zwede]

If package 1.2.3 is incompatible with my Xorg, I'll mask 1.2.3 and newer. There is a slight chance, however, that 1.2.4 will be compatible, but it doesn't matter, since Portage made me masked out 1.2.3 and newer, I'll never even know.

Gentoo lets you mask only a specific version of a package with =package-1.2.3.

Re:I use Gentoo - but not for much longer

[Anonymous Coward]

Switching to another distro is not going to fix that the newer binary drivers do not support your video card, nor that newer Xorg releases are incompatible. In a year or so no distro at all will support your material, when they all have updated to newer versions of the drivers or xserver. Gentoo however, is the only distro that lets you mix several major revisions. Of course it takes time -- there is no free lunch.

Note that you don't need to mask anything if you use the stable branch. Just Gentoo is kind enough to let you jump to more recent versions or keep some obsolete. But then you're on your own to keep the system coherent.

Re:I use Gentoo - but not for much longer

[Anonymous Coward]

I've gone from running Gentoo on 3 desktop systems to Fedora/CentOS, and I am extremely happy with it. In fact I now realize how insane it is to run a source-based distro on my desktop with so many packages taking so long to compile and imposing insane hard-disk space requirements (I'm looking at you, webkit). It's refreshing to just do "yum install X" and within seconds I'm good to go, rather than having to wait for it to compile.

I really did like Gentoo, I still do, I think it's standpoint on user-configurability and not making decisions for the user is good, and I've loved working with portage, even running my own overlay with some patches here and there. I really miss it, but the pain of dealing with the occasional compilation issues and the amount of time it takes to do a full system update just wasn't worth it anymore. I really feel liberated now, even if all this stuff with RPMs and repo's is still a bit strange to me

Re:I use Gentoo - but not for much longer

[QBasicer]

Yep, very true, but if 1.2.4 *isn't* compatible, you'd need to keep upping the versions, and that's way too much manual intervention. I might as well to to LFS if I wanted that.

Re:I use Gentoo - but not for much longer

[QBasicer]

I cringe every time Firefox or Chromium recompile, because I know it's going to be hours before it's done.

Re:I use Gentoo - but not for much longer

[Anonymous Coward]

I agree with you on binary vs. source distros.

Not on CentOS or Fedora, though. CentOS gives you a bunch of ancient packages; fine for server purposes but totally unacceptable on the desktop. And after years of Debian, using Fedora is like a bad joke, things just don't work right out of the box.

Re:I use Gentoo - but not for much longer

[Anonymous Coward]

If you are masking a lot of packages, you probably shouldn't be on "arch". Masking a lot of packages means that you are most likely using ~arch and receiving updates for everything on the system. I also don't see how Arch would solve your issue since you on Arch you basically only have one option, and that's HEAD. So you would be in the same situation but basically without the ability to mask a package.

Re:I use Gentoo - but not for much longer

[Anonymous Coward]

What kind of machine do you have? I have a 4 year old desktop and chromium takes 45 min to compile.
Sure it's a lot of time, but it's not hours. Even LibreOffice takes less than 1 hour. Did you forget to set MAKEOPTS=-j4 in make.conf?

For firefox, just use firefox-bin. There is very little interest in locally compiling firefox except if you debug it.

Good for developers ...

[gstoddart]

I think rolling releases are good for developers, and gives you that whole agile thingy ...

But really what it instills is a culture of "almost got it" where you'll run the risk of breaking your user's systems and then just say "whoops, we'll fix that next time".

I think it leads to sloppy release engineering (because, after all, it's just a build), and will be fundamentally incompatible with how companies need to do IT.

And every time I see Firefox telling me "It is strongly recommended you upgrade to this version" what I really see is "holy crap, did we inject some garbage in that last one".

I think in general the "continuous release" says "we're not worried that people in the real world can't do this, and we don't care ... we'll fix it on the next release ... maybe".

So, for your personal desktop, or a sandbox, or a toy ... sure, have at it. But for a real machine, doing real work ... I think "continuous release" is a terrible idea.

Because in the real world, we're not prepared to patch Prod system just because you committed some new changes -- we have bigger issues to deal with than constantly updating software to keep you happy.

I should think nobody in a corporate environment is a fan of that. And if you're a small shop of 20 people who are risk takers ... you're not in what I'd call a corporate environment.

Re:Good for developers ...

[Anonymous Coward]

To be fair: Corporate users probably have more money than mere home users, and should be properly paying software developers to have a real test-freeze-release cycle, and to retroactively apply security updates to older releases. Indeed, that is Redhat's business model.

Re:Good for developers ...

[jythie]

I wonder how much of it is a case of web developers gaining more status within computing and their priorities seeping into other areas. Rolling releases tend to sound rather webapp inspired to me.

Re:Good for developers ...

[Zontar The Mindless]

Rolling releases are *not* good for developers when an update breaks your build environment. What known good previous version do you roll back to?

Re:Good for developers ...

[varag]

This is the exact scenario where you end up with people still using XP machines and IE6 (seen just last week).

Re:Good for developers ...

[pz]

I run a small scientific laboratory (3-5 people depending on the season) that is very much like a startup. Our primary product is scientific output, and stability is paramount for us, even though we're small. We have standardized (by edict from me, The Boss) on one version of Word, one version of OpenOffice, one version of Matlab, one version of Windows (well, two, because we have some older XP systems used in data collection), etc. The versions selected for standardization shift, but only slowly (ie, it's about time to update from Word 2003, but we'll probably stick with Word 2010). Although I use Fedora for my desktop and laptop systems all of the other Linux boxes are CentOS.

For me, Fedora's 18 month support cycle is really too short ... so I end up going well past EOL and only update to the most recent version when critical things stop working well.

Rolling releases? NFW.

Re:Good for developers ...

[Anonymous Coward]

Don't you think that for example Debian unstable and testing are instrumental to the quality of Debian stable? Or Fedora to RHEL etc.

Re:Good for developers ...

[Anonymous Coward]

Yay, the no true corporate environment fallacy. \o/

Re:Good for developers ...

[Anonymous Coward]

The one you had installed previously, which is clearly there in the log, and if you set your gentoo box up right you won't even have to compile anything to switch back as it will keep binaries of all previously compiled packages.

Re:Good for developers ...

[Grishnakh]

Oh please. People are still using XP/IE6 not because of a particular cycle, but because their company is using some shitty internal web app that only works on IE6.

Re:Good for developers ...

[Zontar The Mindless]

I guess that means that all of us who don't happen to run Gentoo are just SOL, then?

Re:Good for developers ...

[Anonymous Coward]

I think it leads to sloppy release engineering (because, after all, it's just a build)

What does that even mean? Do you even know?

Done "right," continuous delivery / continuous integration should lead to much more formalized and well-structured releases, because they are *automated*, not something that "Bob down the hall" kicks off once every few months, then crosses his fingers and hopes that nothing in the environment and infrastructure has changed since he did an official release last.

A CD process should be entirely automated, with feedback loops tied in throughout. And the only thing that should require human interaction is clicking the "promote to next environment" button. Your gross misunderstanding of agile and continuous delivery simply underscores your own ignorance, not a systemic flaw.

I worked for 15 years in a "big, slow enterprise" finance shop. The model of "we build and deploy once every 6 months" is fundamentally fucked, because it guarantees that shit will have broken, been forgotten, or otherwise skewed between releases, and nobody will realize it until your entire release is delayed 3 weeks because of an unexpected issue rolling into production that caused you to have to roll back. CD has no requirement that "today's checkin ships by 6 pm," it simply says that you should be delivering a steady, small stream of updates to production, through a series of increasingly rigorous automated test suites.

Build -> unit test -> functional test -> system test -> integration test -> performance test -> other tests -> prod staging burn-in -> prod could mean that my checkin today doesn't get into prod for 6 months. But it also means that I'm automatically deploying small sets of changes from environment to environment on a frequent basis, which means the change set is small, and the opportunity for skew between deploys is small - which means when something shits the bed, it's easier to find the issue.

As far as "big enterprisey systems with zero downtime requirements," learn how to use a load balancer, and you'll be amazed at what you can do to a "live service" while maintaining 24x7 uptime.

Re:Good for developers ...

[Anonymous Coward]

I'm at work and our computers are all still on XP (they are paying Microsoft exorbitant quantities of money for the privilege) and they only went from i.e. 6.5 to 8.0 just over a year ago. I can see them sticking to this for the next two years before they even consider jumping up another revision.

And yes, only going to 8 was partly restricted by "some" people running crappy web apps that were non functional past 8.0.

Great for the thin desktop and home user ... only

[Anonymous Coward]

This is fine for the thin desktop and home users. As long as libreoffice and the browser work, that's fine. It's in fact, good, because it's a constant "upgrade" instead of security patch. However, this isn't at all adequate for servers running any sort of custom software, or, for that matter, desktops running corporate software. Rolling releases break software just the same as block releases, less often per "release" but just as often per evolution of the software.

Gentoo works for me

[Dan Ost]

I've been using Gentoo on all my personal machines for the last decade or so.

Works fine as long as you pay attention.

--dost

Re:Gentoo works for me

[halivar]

I may be a masochist, but I feel kind of sad when I do an "emerge -uDp world" and nothing comes up. I start feeling like should install more stuff.

Re:Gentoo works for me

[Anonymous Coward]

You can always re-merge webkit, that one never lets me down

Re:Gentoo works for me

[SupahVee]

I've alo been using gentoo on my desktops for about the same amount of time, it's by far my favorite of all that I've tried. And while the ricer-level make options don't have as much effect on performance as they used to, I still like the configurability of the whole thing.

That being said, I wouldn't run Gentoo is a prod environment for any amount of money, it's debian or a redhat-based distro, all the way. The nuances of the portage tree from week to week just lend themselves to too much instability on what might get installed when you're trying to pull in an update.

Things like "Oops, we green-lit perl-5.16 when it should've been 5.18", and all your modules are broken and perpetually rebuilding for the next week, or "We migrated everyone from grub to grub2 and renamed the original grub to 'grub-static' and didn't tell anyone, sorry about any systems that don't boot"

I like to tinker on my desktops, I have zero desire to do so with production systems.

Re:Gentoo works for me

[neurovish]

I may be a masochist, but I feel kind of sad when I do an "emerge -uDp world" and nothing comes up. I start feeling like should install more stuff.

I don't think I've dnoe that in over a year....I'm kind of afraid to at this point.

Re:Gentoo works for me

[danomac]

It helps if you do an "emerge --sync" first!

Re:Gentoo works for me

[Anonymous Coward]

Why should I pay attention? It's the computer's job to keep track of things for me.

Re:Gentoo works for me

[Anonymous Coward]

You could extract a stage 3 in a chroot and use that chroot as an identical environment to see what will happen if you do update the main system. I do that for my server and laptop and it works great. In the chroot I also use it to build binary packages and distribute them to other machines (FEATURES="buildpkg")

http://xyinn.org/gentoo/

Arch Linux is the alpha-testing distro

[Anonymous Coward]

So glad we have another high quality alpha tester that happens to be a kernel dev and likes fixing everyone else's stupid bugs!
Users (and devs) of stable distros will be grateful ;)

Debian SID

[raxx7]

I've been using Debian unstable in my personal computers for years. Occasionally, something breaks.

But I prefer the long term support of Debian stable and CentOS for internet facing servers and lab workstations.
Here, it's important to be able to get security fixes without fear of breaking anything for years.

Re:Debian SID

[jythie]

I think the 'for years' part is where the disconnect between the two professional use cases (or camps) tends to happen. The people really pushing rolling distributions are not really thinking about production systems that will be running for the next 5-10+ years, but instead on rapidly changing stuff that you do not have to plan more than a few months in advance.

Home USE !=Business Use

[bigdady92]

Congrats you can upgrade your latest hot shite box to the latest hotness. Fantatsic. Now what about those servers that have millions of people trying to contact your business through? Hell to the No.

You want your systems to be running stable, known working, and reliable code. Who cares if it's version 10 and not version 10.0.4134. Let the dev monkies play with the updates in the background and when a service release is out test it further.

Unless there is a positive gain (security, feature release, or annual patch) then the old code is just fine. It works, don't touch it, leave it the hell alone and go play with your crap in your lab.

Another reason I hate the DevOPS movement. Combines the worst of habits of a Dev Monkey and a System Admin.

Re:Home USE !=Business Use

[bomb_number_20]

I'm not sure how far you're going in your thoughts here, but I know I care about the version and there are lots of occasions when the old code ain't fine.

Falling too far behind can turn into an even larger problem down the road when you need to update software A to resolve an issue but you can't because you're too far behind and there's no longer an upgrade path because they've done something major (like switched from MySQL to PostGreSQL) on the backend. Better yet, sometimes software A (which is already behind) depends on software B (or vice versa) which is maybe even further behind. Now you're really stuck.

I think it's important to not confuse stagnant with stable; there's a point where 'stable' can become it's own enemy. Positive gain from just staying up to date with your software might include lower-risk changes months or years from now when you are forced into a hurried, unplanned upgrade to address a security need or get a new feature that you desperately need to resolve some other issue and continue your work.

Re:Home USE !=Business Use

[msim]

r.e. falling behind, yes that sucks.

My old employer fell so far behind on cisco call manager that the version they had were out of support and cisco would only touch their issues when billed at a T&M rate (i.e. it ran on windows). Their system was so big complex and unwieldy that it took the better part of 18 months planning to even update to a version of ccm that was even remotely current. I left shortly before that mess went live, that would have been a shitty teething period.

Some of us run businesses on Linux

[Anonymous Coward]

Some of us run businesses on Linux. At the company I work at, the product we give to customers is delivered using Linux platforms. We are too busy making money with Linux to be spending all day figuring out if a given software update for some unstructured "rolling release" breaks some program our business needs.

This "rolling release" nonsense is a euphemism for "we're too lazy to properly test, package, freeze, and take responsibility for a given version of our software". No, I don't want to add 20 features with potential security bugs just to fix a single security hole.

That is why we use CentOS for most of our critical servers at work. There's something to be said for 10-year support cycles.

Re:Some of us run businesses on Linux

[jythie]

Good example of 'toy' vs 'tool'. With toys, expecting things to go wrong and spending time to investigate and learn is a fine thing. For tools, time spent making the tool work is time spent not using it to do work.

Re:Some of us run businesses on Linux

[bill_mcgonigle]

That is why we use CentOS for most of our critical servers at work. There's something to be said for 10-year support cycles.

The trick is that then the upgrade at 8 years is a nightmare.

The real problem is that people don't know what they've installed, how they've configured it, and how to upgrade it. Devops really is the answer. My puppet modules work at least on CentOS, CentOS -1, and Fedora/Fedora -1, so I figure out changes on Fedora, and eventually retire the CentOS -2 releases. My CentOS 5 is all gone, just about everything works on CentOS 7 and can be deployed when I get a chance. If you're up against year 8 and you don't know what's on your 8 year-old box, the first thing to do is to be able to replicate it, and then you can think about upgrading.

This makes the idea of a rolling release less desirable, except to get new features/fixes faster. The sad part is that traditional distros take absolutely no responsibility for upgrades - there's no community expectation of a standard - something dovecot has done this poorly and MailScanner has done this wonderfully. If a million people have to upgrade dovecot to get from CentOS 5 to CentOS 7 then a million people have to figure out how to do the upgrade. That works against the idea of why distros were formed.

Since you still have to do it all yourself, at least devops makes it manageable. It would be neat if you didn't have to do it all yourself. That's an inevitability.

"Rolling Rease"? It's called CI somewhere else.

[Qbertino]

In software development, especially server-side web development this is called continuous integration (CI for short). I have nothing against it, if automated testing, instant rollback and other things are in place. And if the distro has solid quality control and feature management. ... Somehow I doubt that though.

If a distro crew knows what they are doing, I'd trust them with rolling releases. ... Maybe I should try this Arch Linux thing out. Any experiences? Any advice?

Re:"Rolling Rease"? It's called CI somewhere else.

[Anonymous Coward]

Continuous integration is great for sw development, but not for the whole system, where rolling back is not so easy as just re-installing from a last known good package. If a broken package has updated dozens of other packages and their dependencies, how on earth does one roll back? Is there a similar concept as git tag on those rolling distros, which allowed going back in time one day a time until the system works again?

Re:"Rolling Rease"? It's called CI somewhere else.

[Dr_Barnowl]

That was going to be my response... I think rolling release is probably a good idea, having lived through the nightmare of enormous organizations that spend 4 or 5 years upgrading from Windows XP / IE6 to Windows 7 and the huge inertia of all that. The shitty old mire of horrendous hacks that you have to dig through to move this sisyphean rock of organizational code, and then everything breaks anyway because no-one actually tests things *properly* when they do their migration plans.

An environment that carefully migrated each change and made sure they all worked is clearly the alternative.. but it only works if you adopt practices like actually enforcing that *automated* tests are run for all the apps that your organization depends upon, if only for the reassurance value it provides to risk-averse upper management.

Re:"Rolling Rease"? It's called CI somewhere else.

[Anonymous Coward]

Arch is great. As things change little with each update the chances of a major breakage are lower, at the price of a higher chance of small problems. A few times a year manual interventions are necessary, but there's always a warning and the steps you should take on the news page.
There is an Arch-based distro that comes with a desktop environment (ArchLinux is bare-bones). I didn't like it, but it might be worth a look. On the archwiki, you should read the beginner's guide, the installation guide and the pacman rosetta. The installation process is retarded (there is no installer anymore) but using the system afterwards is not.
Old packages are kept in /var/cache/pacman/pkg, so if anything goes wrong you can always reinstall the old version from there.

Don't bother with Debian.

[Anonymous Coward]

I was a Debian user for many years. Most of them were quite good. But Debian has fallen apart since they adopted systemd some time ago. Its quality has dropped. Its community is divided and in tatters, with the systemd advocates treating long-time Debian users like total crap. It no longer lives up to its reputation. So I suggest you don't waste your time with it. I know I don't. I've moved to FreeBSD, and I couldn't be happier. FreeBSD is a lot like Debian used to be, before it was "infected" by systemd and the systemd advocates.

Perl version inconsistencies

[Anonymous Coward]

Perl, and Python, and Ruby, and PHP, and *anythinthing* that randomly updates individual components without ever testing them against all the old components deserve to be shot through the head. This is no better. The random upgrade, and enforced dependency hell of components that are mismatched and never tested are *why* operating systems have releases.

Most of us don't have all night in our mommy's basement to sort out the unmentioned library update dependencies. Fedora is going through this right now with the Python3 update, and god knows I've had it with Apache, glibc, postfix, TeX and RT. When I have a paying job, I don't have the time to go fix this myself all day.

Wow...

[Anonymous Coward]

Wow so fascinating. I hear that yesterday Ted T'so farted.

gotta agree.

[nimbius]

rolling release, while in the case of Gentoo initially more tedious to set up than just 'click install' is a refreshing departure from packaged distros. from a devops standpoint its no more or less manageable either. I create a base gentoo image and DD it to servers. afterwards salt takes over and doles out configuration. port tree zaps, use, and merge can also be controlled and if some security vulnerability is found in a compiled option for an application, you can command your servers to recompile the affected package without that option instead of waiting for a workaround or patch, which might not be feasible in a production environment.

Re:gotta agree.

[Anonymous Coward]

You could do the same thing with every other distro, stable or not, bleeding edge or not. What's so good about Gentoo or Arch?

No surprise

[Anonymous Coward]

Greg was an active Gentoo developer.

Void Linux

[Anonymous Coward]

Try Void Linux, a rolling distro that doesn't suck:

- System-wide LibreSSL by default (maybe the first linux distro to do so)
- runit instead of systemd
- multilib aware ... and more.

Even when it's not broken, it's different, needs t

[raymorris]

Agreed. Also, even if it's not _broken_, I don't want things constantly changing under my feet without even being able to meaningfully talk about what changed in different versions.

It's good to be able to say "here are the major changes between "Windows 7 and Windows 8". It's definitely good to be able to say "this software works on Windows 8", rather than "this software works on versions released between 2013-10-12 and 2015-01-03".

Arch for a while, FreeBSD for life

[Anonymous Coward]

I personally prefer rolling release.
I used to use Arch, until they started trashing their ecosystem. Giving up KISS by adopting systemd, moving /bin, etc. It became a bitch to maintain with all the breaking changes imposed.

Ultimately I found FreeBSD's ports to be amazing rolling release system. Far more stable than Arch, you don't have to break your junk if you don't want to. And that makes me happy. The kernel moves in increments, everything else you compile or download binaries. I end up with a much more optimized and stable system than if I had stuck with Arch. Yet everything on my box is up to date.

Each has its pros and cons. I've had to use Slackware and Ubuntu for my work. They're practically zero maintenance which is probably a good thing for ~generic~ computer users.

Re: Arch for a while, FreeBSD for life

[Anonymous Coward]

It's hilarious how every comment here that points out how much better FreeBSD is these days than Linux is gets downmodded. One or more mods here just can't accept the truth!

Re:Arch for a while, FreeBSD for life

[Anonymous Coward]

FreeBSD is great. I'm on 10-stable now. I use ZFS with snapshots on each FS, explicitly /usr/local. For packages I just do for i in pkglist do pkg add pkg ; done ; snapshot. If I ever discover any breakage in the new packages, guess what? I just roll back the /usr/local snapshot. It's beautiful. Can't believe more people haven't discovered the simple admin bliss of FreeBSD.

Ubuntu devel channel

[Anonymous Coward]

I run Ubuntu devel on all my laptops and desktops (though still LTS on servers). It's a rolling release. I haven't had an update break a machine in a couple of years.

and I favor...

[Anonymous Coward]

overthrowing the government and establishing the dictatorship of the proletariat! GNU/USA NOW!

Depends on the target user...

[gwolf]

I am absolutely not surprised by this: A well-known kernel hacker has enough systemwide understanding for the ocassional glitch to become obvious. He also uses most probably a very specific subset of programs for his day-to-day activities — I (a very far cry from his skill levels) haven't changed my main tools in over ten years. I mean, a tiling window manager, Emacs, a browser... Specific little tools can vary, but they won't jeopardize my system's overall behaviour — This means, it won't mean me spending time head-scratching to keep working.

Now, a developer is a far cry from a systems administrator. A sysadmin values stability over all things. I don't want a random upgrade to become a lost hour understanding the new configuration format of foobard.

And of course, casual users... If my wife desktop had changed from GNOME 2 to GNOME 3 without me preparing her, I'm sure she would not have appreciated it.

Who's doing what now?

[wonkey_monkey]

the lieutenant Linux developer Greg Kroah-Hartman

The what? Did he develop "lieutenant Linux," with a small L? Or is he a lieutenant like Columbo?

Other than that, what should I know about who this guy is? Because the summary (which is, I'm told, also the article) tells me nothing.

Re:Who's doing what now?

[Dr_Barnowl]

He's a kernel lieutenant. Which means that he's one of the guys that Linus Torvalds trusts to shepherd patches into the main line of the kernel. In other words, he's one mean code-farmer. Not your average user.

Re:Who's doing what now?

[Anonymous Coward]

Other than that, what should I know about who this guy is? Because the summary (which is, I'm told, also the article) tells me nothing.

Err, he is essentially Linus Torvalds' left hand man. :)

Read the Linux Kernel Mailing List to keep tabs on what is happening in Linux development.

Re:Who's doing what now?

[eihab]

Other than that, what should I know about who this guy is? Because the summary (which is, I'm told, also the article) tells me nothing.

2007: https://www.youtube.com/watch?v=L2SED6sewRw

2014: https://www.youtube.com/watch?v=fMeH7wqOwXA

Arch... Ugh.

[Anonymous Coward]

Arch breaks. Often. Breakage is the trouble with rolling release distributions, and an intolerable problem for anyone not wanting to spend the time un-breaking things.

Loyal but naive Arch users are always quick to defend it, "my system has never broken" "you must be doing something wrong" etc. but these discussions are always about semantics. Just because it's a one-liner to fix doesn't mean that it isn't broken. If it requires my attention to keep working, then it's broken. Just because it is fixable doesn't mean I want to spend time fixing it.

Arch is a great way to learn Linux, and the Arch wiki is a great resource not exclusive to just Arch. But you'd have to be out of your mind to use it for anything in production. The Arch FAQ makes it pretty clear: YOU, the user, is responsible for keeping your system updated, functional and stable; but the more packages you have installed, the more likely you are to get broken when upstream updates something.

Also from Arch docs:
Warning: Do not be tempted to perform partial updates, as they are not supported by Arch Linux and may cause instability: the whole system should be upgraded when upgrading a component. Also note that infrequent system updates can complicate the update process.

Translation: You want to update package foosicle-1.2 to foosicle-1.3 because it has a security problem. Oh, you don't want to update X, Firefox, KDE, and the kernel? I hope you do want instability then. BTW, stay on top of your updates unless you want to get really hosed.

No thanks.

I use Ubuntu LTS releases on my computers at work for three reasons:
1. Reading the Arch wiki to un-fuck Java after I updated my system to fix a security issue for a different package is not a good use of my time.
2. Not a good use of my time to compile from source because the distribution ships with something ancient or doesn't have it at all (I'm looking at you, RHEL).
3. Will keep getting updates for the lifetime of the hardware.

Re:Arch... Ugh.

[Anonymous Coward]

Arch doesn't break often though and most of the recent breakage I've seen has been caused by systemd.

Warning: Do not be tempted to perform partial updates, as they are not supported by Arch Linux and may cause instability: the whole system should be upgraded when upgrading a component. Also note that infrequent system updates can complicate the update process.

Not supported doesn't mean don't do. There was a time when we knew exactly what could be upgraded without requiring a system restart - systemd changed that somewhat and not keeping it upto date makes matters worse. So now I upgrade everything and reboot only when I'm feeling brave. I'll selectively apply updates for things like php, nginx or postfix though.

Re:Arch... Ugh.

[Anonymous Coward]

Actually, FreeBSD-STABLE is really the definition of that word. I've been tracking that monthly for 8 years and it's only bit me three times, twice because I failed to read the mailing list where someone else discovered the issue first.

Bad experience

[JohnFen]

My experiences with rolling-release software has been unpleasant, so I will continue to avoid it to the best of my ability.

Slashdot editors: READ YOUR OWN LINKS

[Anonymous Coward]

Greg Kroah-HartmanFeb 3, 2015 +3
+Josh Sabboth "moving"? I've been using Arch for quite some time now (2 years or so), it's not new to me at all...

Seriously, slashdot is becoming worse and worse...

Not all RR are created equal.

[Anonymous Coward]

Some distros do rolling release better than others. I found that stuff broke under Arch after a 'pacman -Syu' often enough to be annoying. Under Debian testing I could recklessly do dist-upgrades and nothing broke....at least until systemd shit starting leaking in...

I like LTS releases personally. I'll go out of my way for particular bits to be new. PPAs generally help with that.

Who's doing what now?

[Anonymous Coward]

He reports to colonel Panic and general Protection-Fault :)

Remember his background

[houghi]

He comes form a S.u.S.E., SuSE, SUSE and openSUSE background where the rolling release are not that old yet. I believe they started in the 12.x or even the 13.x with it.

Before that it was a new version every 6 to 8 months and a service period for 2 to 3 years (or 7 if you had the pro with support)

Meh

[Sin2x]

Rolling-release should have been default for desktop distros from the start. Maintainers have no moral right to claim what is stable and what is not, since they do not write the code and are rarely proficient enough to judge its quality. It's the developer's prerogative and a task they manage to perform sufficiently, without the need for additional bureaucracy. Server distros are a whole different world, obviously.

Great for Desktops

[Tepar]

IMO, rolling releases are great for desktop/laptop machines, but not so great for servers. There's something to be said for installing and configuring your OS on your work machine exactly once, for the life of the machine, and then it just stays up to date. No more twice a year upgrades that bork everything (I'm looking at you, Ubuntu) and make you reinstall anyway, no more "backport" repositories if you want to run the latest KDE or LibreOffice or whatever. Small, incremental updates are actually a lot easier to manage than giant upgrades that replace almost everything on the system.

I'm currently using Manjaro (related to Arch Linux), and I'm not looking back.

Re:Great for Desktops

[JohnFen]

IMO, rolling releases are great for desktop/laptop machines, but not so great for servers.

I would have said exactly the opposite. I strongly dislike rolling releases in general, but my experience is that they're less annoying on servers than on end-user machines. Rolling releases mean that you have to put up with unexpected UI changes, which is what makes them hurt.

Good for him?

[Guspaz]

I don't. I like predictably scheduled releases. Ubuntu's release strategy particularly pleases me, with predictable releases every 6 months, and long term support releases every 2 years, with support for upgrading either from regular release to regular release, or from LTS release to LTS release.

Of course, I don't run Linux as a desktop platform, so Ubuntu still works nicely for me in a server environment. I tend to run only LTS releases on important servers (typically waiting until 6 months after an LTS release before upgrading to it, and regular releases on unimportant servers (like my home server).

Not for production use

[iamacat]

Rolling distros are great if you are a technology enthusiast and completely manage your own machine. If you are supporting a large number of users or servers, you want to test a fixed configuration and deploy it to everyone once a year. In general the key to stability is to branch a code at some point and focus on bug fixes rather than new features/cleanup/refactoring.

Debian 'testing'

[Anonymous Coward]

You're only about a decade behind Anthony Towns' work on the Debian 'testing' distro.

Packages are promoted from unstable into 'testing' automatically, by a rule-driven script which looks for certain stability criteria.

It's not foolproof, but in its day, it was a huge step in the right direction for people who didn't want huge amounts of breakage, but didn't want to run ancient history either.

Another idiot on the ignore list

[Khyber]

He's apparently abandoned the idea of a long-term stable box.

Since he's abandoned that idea, everything he says has just become useless advice at several of my IT jobs, where we depends upon long-term stability and reliability.

*AND* he's using Arch as a primary. Nope. Too much bloat.

Mark down yet another useless person to listen to on the list.

Appropriate captcha: Detached - as in this idiot is detached from reality.

Re:Another idiot on the ignore list

[Gavagai80]

You want your kernel developers running something old and stable? I sure don't, I want him running something fresh where he finds the bugs before they get to me.

Re:Another idiot on the ignore list

[Anonymous Coward]

"You want your kernel developers running something old and stable?"

Yes, because then they have a SOLID base to work from. Kernel changes every month/3/6 just makes for less time for things to be found and fixed before rollout, and also ensures that all the custom software many rely upon has a greater chance of breaking upon upgrade.

Fuck your "ask"

[Anonymous Coward]

The word is "question".

Why Gentoo

[Anonymous Coward]

Is Arch not enough? Does it not do everything Gentoo does? Performance? Curious.