User: Password:
|
|
Subscribe / Log in / New account

Update on Scientific Linux

Scientific Linux takes a look at what the Red Hat/CentOS merger means for them. "There are still many questions to pursue as the details of CentOS Special Interest Groups continue to evolve. The anticipated release of Red Hat Enterprise Linux 7 presents an opportunity to consider forming/joining a CentOS Special Interest Group and producing Scientific Linux 7 as a CentOS variant The variant structure may allow greater flexibility in adapting the distribution to scientific needs. The framework and relationship structure of CentOS Special Interest Groups is still under heavy discussion on the CentOS development list. This is only being evaluated for Scientific Linux version 7." (Thanks to Scott Dowdle)
(Log in to post comments)

Update on Scientific Linux

Posted Feb 3, 2014 23:13 UTC (Mon) by hadrons123 (guest, #72126) [Link]

Does it mean SL wants to be a Scientific spin in centOS group?

Update on Scientific Linux

Posted Feb 4, 2014 18:17 UTC (Tue) by andrel (guest, #5166) [Link]

It means they're looking into it. Which makes a lot of sense. Other than unbranding/removing The Upstream Vendor's trademarks, the changes from upstream are minimal in SL6, and could easily be included in a CentOS variant.

The main value that SL6 had over CentOS6 is that SL has a transparent funding process for the security updates. As an end user, it is invaluable to know that the SL security team are being paid to work on this full time, who is paying them, and that they coordinate vacation schedules so someone is always on call. Now that CentOS is on secure financial footing, that advantage is greatly reduced. (Apologies to the CentOS crew if I've misunderstood how things used to work. I have the impression that the Red Hat merger transitioned you from unpaid volunteers to paid staff. Which is wonderful!)

Update on Scientific Linux

Posted Feb 5, 2014 19:54 UTC (Wed) by mbanck (subscriber, #9035) [Link]

AS I unterstand it, most/all core CentOS developers were offered a position at RedHat, but not everybody accepted it. Still, this should indeed improve things along this way.

Update on Scientific Linux

Posted Feb 4, 2014 0:49 UTC (Tue) by philh (subscriber, #14797) [Link]

It seems a shame to me that they're squandering effort on this cargo-cult, where they slavishly follow Red Hat, whether it suites them or not.

They could instead create a Debian Blend, with less effort than it takes them now, and get something that matches their needs much more closely, with the added benefit that it would be possible to upgrade sensibly (so you might not have vast swathes of the Grid stuck on ancient versions of not-quite-RedHat because everyone's too scared to try an upgrade).

Not that I'm expecting them to notice any of that, given that those facts have not really changed since before SL started.

Update on Scientific Linux

Posted Feb 4, 2014 0:59 UTC (Tue) by dowdle (subscriber, #659) [Link]

So you want to use this opportunity to remind us that Debian offers an easier upgrade path from one major release to the next. Ok, I'll buy that.

SL picked RHEL as a base on purpose so I don't know if that one feature you mention plays into it much or not.

RHEL/clone is easily updated between minor versions and their support cycle is roughly 3x that of Debian's... so it is sort of apples and oranges.

I've not really found the process of migrating data and service configs from one RHEL/clone major version to another overly challenging. I guess if you don't know what you are doing, the process could be scary... but to troubleshoot upgrade or migration problems on either system you should have a good understanding how how things work.

Update on Scientific Linux

Posted Feb 4, 2014 1:04 UTC (Tue) by dlang (subscriber, #313) [Link]

The problem is that a Debian derived system would not be binary compatible with RHEL and the software vendors and management that choose to only support RHEL (which sometimes, reluctantly support CentOS and SL) would not support the result.

It's never been about a technical issue, it's always been a vendor support issue.

Update on Scientific Linux

Posted Feb 4, 2014 2:20 UTC (Tue) by hadrons123 (guest, #72126) [Link]

I thought Debian had more packages in the repository as well as outside their official repository( from vendors) than RHEL.

Update on Scientific Linux

Posted Feb 4, 2014 2:23 UTC (Tue) by aryonoco (guest, #55563) [Link]

There are huge swaths of proprietary software that only supports RHEL, and sometimes SUSE, but that's about it.

Update on Scientific Linux

Posted Feb 4, 2014 3:07 UTC (Tue) by bbockelm (subscriber, #71069) [Link]

Or, in the case of the CERN and FNAL experiments, it's not about the openness of the code (heck, CMS is on github - https://github.com/cms-sw/cmssw) but the size (about 10 million lines of code across the entire stack). Some running, well-funded experiments keep their code functioning on multiple platforms as using alternate platforms / compilers is often helpful in uncovering bugs. Some experiments - especially the ones which are no longer running - simply don't have the manpower or interest to port.

It's also slow to move so many organizations that participate in the experiments. The LHC experiments have just finished a push to port the majority of their resources to SL6; the last SL5 resources will probably disappear in 2015. And that's a *simple* upgrade.

Don't forget they've also probably spent tens of CHF over the years on training sysadmins, professors, technicians, and students on using RHEL clones.

Never underestimate the power of inertia; HEP's decision to go with RedHat probably dates back to the mid-to-late nineties and is fairly well-embedded in the field.

Update on Scientific Linux

Posted Feb 4, 2014 5:05 UTC (Tue) by drag (subscriber, #31333) [Link]

> I thought Debian had more packages in the repository as well as outside their official repository( from vendors) than RHEL.

Debian's repository is useless unless they happen to support the versions of software you need. If you are lucky then you can pull the deb-src file and use that to compile your own version.

Depending on what you want to do repositories can be fantastic, 'meh', or even can cause you problems.

Anyways EPEL has most of the important things you want and this teaming up with CentOS and Redhat should make doing some things that are very difficult much easier.

Update on Scientific Linux

Posted Feb 4, 2014 5:12 UTC (Tue) by dlang (subscriber, #313) [Link]

well, the version in the repository argument can cut both ways.

but what packages are in the repository is not significant, the issue is support, and support that management (and grant managers) can see and pay for if they want. That requires RHEL or SLES. In the US, most proprietary software companies support RHEL only.

Getting help for problems with opensource software is not hard (as long as you are willing to run current versions), but _paying_ for support so that management is happy is _much_ harder.

Update on Scientific Linux

Posted Feb 4, 2014 8:15 UTC (Tue) by misc (subscriber, #73730) [Link]

There is also the whole point of certified hardware. We used debian at one of my previous job, and while this was easy to use, we still faced from time to time hardware support issue. We would likely have the same for most distributions, but since we didn't have a list of hardware that would be supported and tested, we did hit a issue at least once.

After rebuilding the kernel to a newer version, that was solved, but what if we had to rely on external patch ( like stuff for afs, etc ). That's also case where entreprise distribution do add values, you know what to take as hardware, and the distribution aim to support that hardware, with a rather predictable schedule. While I know why Debian packagers say "release when it is ready", that's not a very helpful thing to answer when there is a huge project of some computing grid involving various vendors and teams.

And yeah, lots of people are also update-averse, so the whole point of "but there is a upgrade path" is moot. Especially when the upgrade path is not automated on configuration file conversion ( like apache 1 to apache 2, to give again a real life example ). That's easy to do when you have the people in house and when they have time for that. But most of the time, the 2nd point is the problem and first one is more and more a issue.

Update on Scientific Linux

Posted Feb 5, 2014 1:58 UTC (Wed) by mrdocs (guest, #21409) [Link]

This is so true. I worked in an HPC lab where the default was Debian. They were in my eyes masochists, but it was the ideology too.

I remember vividly, experienced staff struggling to get vanilla HP and Dell systems working because of missing firmware and none of the vendor tools worked on Debian only RH or SLES.

In the same time they got one machine installed, I had a small cluster up and running on SLES - because of those were fully certified for the version of SLES I was using. Ten minute installs with autoyast and a USB key.

Update on Scientific Linux

Posted Feb 5, 2014 2:40 UTC (Wed) by dlang (subscriber, #313) [Link]

unfortunately, HP servers are far from vanilla. They are a textbook case for why binary drivers are a horrible idea.

I've had far fewer problems with whitebox 2nd tier vendors than with HP. Dell has been somewhat better, but still not as good as generics.

Update on Scientific Linux

Posted Feb 4, 2014 11:29 UTC (Tue) by vonbrand (guest, #4458) [Link]

The problem was stated earlier: I've seen cases of software (for astronomy) distributed as a tarball including everything from a prehistoric version of g++ through a matching version of emacs as the only supported build environment, all of it running on a Red Had past end-of-life (and even on that environment the toolchain was already obsolete). Ran into trouble when there was no way to replace the machines as hardware handled by the kernel was no longer made... Getting any kind of help for such software is totally out of the question. Even for current versions more often than not the first suggestion is to try the latest stable version, a unreleased test version, or lately grab it from git.

Update on Scientific Linux

Posted Feb 5, 2014 2:00 UTC (Wed) by mrdocs (guest, #21409) [Link]

Reality check: SLES actually has more ISV certifications than RHEL. Its all publically available info.

Update on Scientific Linux

Posted Feb 5, 2014 2:38 UTC (Wed) by dlang (subscriber, #313) [Link]

# certifications is only somewhat related to the probability that the software you need to run is certified.

Unfortunantly in the US, a lot of software is RHEL only.

and one Oracle trumps 1000 small vendors (Oracle may now support SLES, but there was a time when they didn't, see the inertia discussions above)

Update on Scientific Linux

Posted Feb 4, 2014 17:09 UTC (Tue) by SEJeff (subscriber, #51588) [Link]

You are misinformed. It is quite the opposite actually. Many vendors (I'm not kidding) will laugh at you when you ask for Debian/*buntu support.

Update on Scientific Linux

Posted Feb 4, 2014 3:13 UTC (Tue) by jhoblitt (subscriber, #77733) [Link]

Speaking as a employee of a research institution and as heavy user of SL, It's based on RHEL for a reason. Academic/research/scientific code tends to be tweaked for performance over other considerations, written by scientists [who typically do not think like engineers], brittle with respect to dependencies, and poorly maintained due to the funding model. This class of application [unfortunately] needs a fairly stable platform. To drive this point home we actually still have SunOS4.2 boxes in use that are tied to instruments (not to mention the half of a PDP-11 and some microvax IIs).

Upgrading between major versions is red-herring issue as this is fairly trivial with configuration management tools. The real pain is in getting software forward ported.

The other issue in HPC environments is having a platform that is fully supported by your vendor. Eg., IBM GPFS NSDs on licensed RHEL nodes with SL compute clients.

Update on Scientific Linux

Posted Feb 4, 2014 4:55 UTC (Tue) by drag (subscriber, #31333) [Link]

> It seems a shame to me that they're squandering effort on this cargo-cult, where they slavishly follow Red Hat, whether it suites them or not.

If you want to make a OS that specializes in scientific stuff the worst possible approach you can take is to start off by making your own operating system.

Instead it's VASTLY more efficient just to take something that already exists, that somebody else job to maintain, then you can spend your time on stuff that actually matters to you.

RHEL is a good operating system, supported by a lot of third parties, with lots of documentation and people with experience floating around. It would be of the highest level stupidity to throw all that away for no good reason.

Update on Scientific Linux

Posted Feb 4, 2014 7:18 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link]

Why?

Debian doesn't bring enough advantages. It has much better package repository than RHEL+EPEL, but most complicated scientific projects build their own stacks almost from ground up.

Also, lots of CERN projects work for many years, gathering and processing data. Even Debian's release cycle is too short for that.

And besides, having some actual adults making decisions instead of the endless CTTE soap opera might actually do some good for RHEL clones.

Update on Scientific Linux

Posted Feb 4, 2014 20:49 UTC (Tue) by HelloWorld (guest, #56129) [Link]

> And besides, having some actual adults making decisions instead of the endless CTTE soap opera might actually do some good for RHEL clones.
The vast majority of debian developers are not CTTE members, and judging debian as a project by the CTTE's behaviour doesn't seem entirely fair to me. Also you don't know what's happening behind closed doors at Red Hat. There may be some Ian-Jackson-like figure hiding there as well, but you don't get to see it.

Update on Scientific Linux

Posted Feb 5, 2014 8:09 UTC (Wed) by farnz (subscriber, #17727) [Link]

I don't see why the technical committee's behaviour isn't representative of Debian as a project; the technical committee is a part of Debian's formal organisational structure, and if Debian Developers feel that the committee is not behaving in a way that's representative of the project as a whole, they can use the powers set up by the Debian Constitution (GRs ordering the PL and CTTE to replace the problem members if their behaviour doesn't improve, perhaps) to make it clear to problem members of the committee that their behaviour is not what Debian expects.

If Debian has no way to formally indicate as a project that it considers the CTTE's behaviour to be out of line, then that in itself is a sign of problems with project governance - there should be no way for a committee that's part of Debian's Constitution to get so far out of control that Debian's Developers can't reign it back in.

Note that this differs from (say) a Debian "OpenRC Rules!" Committee; such a committee is not part of Debian's formal governance structure, and its behaviour reflects on its members, not on Debian as a whole.

Update on Scientific Linux

Posted Feb 4, 2014 11:10 UTC (Tue) by ewan (subscriber, #5533) [Link]

"the added benefit that it would be possible to upgrade sensibly"

This is the sort of thing that might benefit an individual with a desktop PC. For a cluster system, upgrades are not part of the plan, one simply nukes the box and re-installs. Debian's upgrade capabilities are not nearly as interesting as Red Hat's kickstart.

Update on Scientific Linux

Posted Feb 4, 2014 12:46 UTC (Tue) by ovitters (subscriber, #27950) [Link]

I don't see the point of easy upgrades. You might break things. So instead you rather just have a new server/VM deployed with Puppet, then migrate like that. For RHEL the support period (security fixes, etc) is very long, so really no need to upgrade anything. And actually RHEL does get its upgrades, the .x versions.

Say your distribution upgrade went totally smooth. However, your custom software was installed as tar.gz, linked against some library that changed .so version, etc. That's a realistic example you could have IMO. Totally crappy and idiotic, but that's why you pay for RHEL to just make such scenarios work anyways.

Update on Scientific Linux

Posted Feb 4, 2014 13:50 UTC (Tue) by ewan (subscriber, #5533) [Link]

"For RHEL the support period (security fixes, etc) is very long, so really no need to upgrade anything"

That too. The quarterly point releases are very safe, and it's entirely possible to deploy hardware with a particular major release and have it supported with minor updates and security patches until the hardware is decommissioned years later. A server might have warranty cover for five years, and maybe an extended lifetime to seven or so, but a RHEL major version can live for a decade.

Update on Scientific Linux

Posted Feb 4, 2014 16:08 UTC (Tue) by jhoblitt (subscriber, #77733) [Link]

^^^This. Rolling out EL .X releases is almost shockingly free of issues. I've occasionally seen odd kernel regressions and once (in all of el5.x) there was a update to tcsh that broke floating point expressions in some utility script (written by a data ingest operator) because it started forcing that at least one constant in the expression had to be a flooat. Eg, add '.0' to the end of it.

Update on Scientific Linux

Posted Feb 4, 2014 15:18 UTC (Tue) by fandingo (subscriber, #67019) [Link]

As others have pointed out, major upgrades are not that important to most SL users. Nonetheless, one of the significant features of RHEL will be an official 6-->7 upgrade tool, which is based on fedup.

Update on Scientific Linux

Posted Feb 4, 2014 3:18 UTC (Tue) by xxiao (guest, #9631) [Link]

I sincerely recommend Debian here.

Update on Scientific Linux

Posted Feb 4, 2014 17:14 UTC (Tue) by HelloWorld (guest, #56129) [Link]

Why would anybody care?

Update on Scientific Linux

Posted Feb 4, 2014 7:16 UTC (Tue) by _xhr_ (subscriber, #92665) [Link]

I worked for over five years in a research institute doing HPC. And yes, there is a reason why SL is not based on Debian!

* Most commercial software needed by physicists, chemists, biologists is not available and/or licensed for Debian/Ubuntu. The researchers need to software so the operating dept has to support it. Is that simple :)
* CentOS/RHEL/SLES has muuuuch longer support intervals than Debian. There is now Ubuntu LTS but when I started working there, there was not LTS.
* And if I look at the current debate within the Debian community whether to choose systemd, upstart or OpenRC ... *brrr*. If you operate thousands of the nodes you simply do not have the time to deal with politics like that.

Update on Scientific Linux

Posted Feb 4, 2014 16:17 UTC (Tue) by foom (subscriber, #14868) [Link]

All those points make sense except the last...why would you involve yourself in politics, even if you used Debian. Just take whatever they decide, like you do with rhel... Just because you dont get to SEE the politics in RHEL doesn't mean it's not there, and just because you can see it in debian doesn't mean you need to get involved.

Update on Scientific Linux

Posted Feb 4, 2014 16:39 UTC (Tue) by _xhr_ (subscriber, #92665) [Link]

I do not plan to involve myself in Distribution politics :) Unfortunately, I see that Debian wastes too much time in politics. It's not only the init-debate, there have been a number of examples in the past (Firefox vs. Iceweasel, the hassles to get a SUN JDK running, Licence issues, ...). And all these debates IMO slow the technical progress down.

Update on Scientific Linux

Posted Feb 5, 2014 8:40 UTC (Wed) by misc (subscriber, #73730) [Link]

Sure, like democracy slow down society because people discuss rather than working under the leadership of 1 person. Or like startups waste time doing bad product instead of just doing the one that works.

There is nothing wrong in discussion, people who want to make technical progress are free to not participate, or free to give their input and get back to work.

In the case of the init system, people are free to make all debian systemd-aware ( ie, adding unit, activating systemd support, etc ) without any issue. They can work upstream, they can provides patchs. So the debate do not stop anything for most of the work. And even if systemd is not the default, people can still install it, and so you still need to add support.

Update on Scientific Linux

Posted Feb 4, 2014 17:14 UTC (Tue) by SEJeff (subscriber, #51588) [Link]

Much of the "politics" in RHEL are quite open and public in RHEL's upstream... Fedora.

Update on Scientific Linux

Posted Feb 4, 2014 17:23 UTC (Tue) by vonbrand (guest, #4458) [Link]

RHEL's politics are their own, mostly behind closed doors. Fedora is an independent distribution.

Update on Scientific Linux

Posted Feb 4, 2014 18:15 UTC (Tue) by johannbg (subscriber, #65743) [Link]

Some of us strive to make Fedora an independent distribution but in reality Red Hat does what it can with it just look at .next and the WG's were Red Hat's products get "primary" status and community made products ( like spins and whatever is not part of the WG nor ever can be ) become secondary...

Update on Scientific Linux

Posted Feb 4, 2014 22:11 UTC (Tue) by rodgerd (guest, #58896) [Link]

Because sometimes the politics bite you. Running systemd with encrypted LVM on Wheezy currently has a problem where the owner of the LVM package refuses to accept a bugfix because (a) he hates systemd and (b) he's a fucking loon who insists hardware should never change post-boot probe.

Happily, if you're a RHEL customer or CentOS user and something they advertise as supported doesn't work, they'll fix it, not drag it into a multi-month saga that requires CTTE intervention to fix.

Update on Scientific Linux

Posted Feb 4, 2014 23:57 UTC (Tue) by HelloWorld (guest, #56129) [Link]

> Because sometimes the politics bite you. Running systemd with encrypted LVM on Wheezy currently has a problem where the owner of the LVM package refuses to accept a bugfix because (a) he hates systemd and (b) he's a fucking loon who insists hardware should never change post-boot probe.

You mean this bug?
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=728486
Yes, it's quite sad :-(

Update on Scientific Linux

Posted Feb 5, 2014 7:06 UTC (Wed) by drag (subscriber, #31333) [Link]

It is really bizarre.

* It is clearly preferable to have a configuration that can react to events as they occur rather then 'just wait for a period of time then flush events and hope that is all the events we will ever need, ever'.

* It only affects users that use systemd and lvm; the reason it only affects users using systemd is because part of how systemd configures and manages lvm was left out of the Debian version.

* The Debian maintainer declares that systemd 'must fix it itself' and go back to the old way of doing things that depended on a static configuration of 'hope and timeouts' instead of just including the part of systemd that should of been there since the beginning and clearly works very well in other distributions.

Update on Scientific Linux

Posted Feb 5, 2014 14:44 UTC (Wed) by farnz (subscriber, #17727) [Link]

There's an attitude you see in all sorts of projects (not just open source) that boils down to "you didn't need that 40 years ago and we still got useful work done, why do you need it now?".

In this case, it comes down to the fact that Unix-like systems of 40 years ago (1974) rarely had hotplug disks; those that did hid them behind things like RAID controllers that faked a permanently attached disk; why should this change now that we've got desktops with hotplug SATA, USB, iSCSI etc? After all, we got useful work done without hotplug disks.

Update on Scientific Linux

Posted Feb 5, 2014 20:19 UTC (Wed) by philh (subscriber, #14797) [Link]

The bug mentioned is actually closed BTW (as of last month) -- yes, it took longer than it might, but it did reach what seems like a reasonable conclusion.

Likewise, regarding the init system decision, the Debian process maybe somewhat undignified, but at least there's a decent chance that it will conclude with something that people can live with, which is more than Red Hat managed with their apparently tidy process resulting in a detour through upstart before arriving at systemd.

Not that most people really care what's running as process 1, unless it fails to boot, but I don't suppose the extra transition was particularly helpful to Red Hat folks (or any of the people who choose to use them as upstream, without getting any chance to influence their closed decision making process -- like SL -- he says in a feeble attempt to get this back on topic).

I think I'd rather go for slow and noisy rather than quick and wrong.

Update on Scientific Linux

Posted Feb 5, 2014 20:51 UTC (Wed) by vonbrand (guest, #4458) [Link]

When Fedora/RHEL decided on upstart that was the best available init; when something substantially superior (systemd) appeared, they decided to switch again. Quick and right, instead of fooling around for two years before even acknowledging a decision is due.

Update on Scientific Linux

Posted Feb 5, 2014 21:37 UTC (Wed) by raven667 (subscriber, #5198) [Link]

To put it another way, Fedora was able to switch _twice_ with less time and effort spent than Debian has spent just to not even yet make a decision, let alone plan and execute a migration. I'm not even sure that the time Fedora spent on Upstart was wasted, they had the benefit of a better init during that time and probably learned a ton about how to successfully execute a migration strategy. The tools are battle tested now, so Debian gets to walk into a more mature technology.

Update on Scientific Linux

Posted Feb 5, 2014 23:39 UTC (Wed) by Wol (guest, #4433) [Link]

Plus, while it might not be reality, it certainly seems that systemd was only started BECAUSE Fedora tried upstart and it didn't work.

As others have said, upstart is an improvement on SysVInit, not that that appears to be hard, but it has its own faults. Systemd builds on lessons learnt from both.

Cheers,
Wol

Update on Scientific Linux

Posted Feb 6, 2014 1:15 UTC (Thu) by vonbrand (guest, #4458) [Link]

Not just Fedora. Check the blog for details, a lot of non-(Fedora|Red Hat) people were on board from the beginning (or came on board soon after the project started). And it certainly wasn't designed in a vacuum, nor is it a NIH result.

Update on Scientific Linux

Posted Feb 7, 2014 12:52 UTC (Fri) by ebassi (subscriber, #54855) [Link]

Plus, while it might not be reality, it certainly seems that systemd was only started BECAUSE Fedora tried upstart and it didn't work.

there were various factors; the biggest one was that Upstart is under CLA, so Lennart and Kay could not contribute to it in order to fix its architectural issues, found at the time of Upstart's adoption into Fedora and RHEL. in the end, the cleanest "fix" was to rewrite it from scratch as a separate project.

another massive failure of Canonical's CLA (or a win, if the end goal is to create division in the free and open source software world).

Update on Scientific Linux

Posted Feb 11, 2014 18:06 UTC (Tue) by Zixxt (guest, #95496) [Link]

I think systemd itself has done much more than any CLA could ever do in dividing the Linux/Open source world. Systemd is a cancer that is killing the spirit of Linux

Update on Scientific Linux

Posted Feb 11, 2014 18:18 UTC (Tue) by pizza (subscriber, #46) [Link]

> Systemd is a cancer that is killing the spirit of Linux

I've always wondered what TheOfficialSpiritOfLinux(tm) is. Would you care to enlighten me, and please provide citations.

Update on Scientific Linux

Posted Feb 12, 2014 14:38 UTC (Wed) by Wol (guest, #4433) [Link]

I think TheOfficialSpiritOfLinux is summed up in the attitude of Linus (an engineer, by the way) - "whatever you do, DON'T F*SCKING BREAK USER SPACE!"

Which, actually, I think systemd tries to adhere to.

Although systemd does have Lennart's bloody-minded attitude to bugs - "if it's not my bug, I'm not going to fix it here!". Linux tends to be a lot more accommodating.

The end result is a system which is solid, reliable, and works, even if it does bring a bit of pain along the way.

Cheers,
Wol

Update on Scientific Linux

Posted Feb 12, 2014 16:35 UTC (Wed) by pizza (subscriber, #46) [Link]

> Although systemd does have Lennart's bloody-minded attitude to bugs - "if it's not my bug, I'm not going to fix it here!". Linux tends to be a lot more accommodating.

Linux is more accomodating only when fixing the bug would mean breaking *previously-valid* userspace.

> The end result is a system which is solid, reliable, and works, even if it does bring a bit of pain along the way.

That attitude is also why Wireless Networking is now a rock-solid, JustWorks proposition under Linux.

And Sound too. I can't remember the last time I had a sound-related problem that wasn't related to hardware failure.


Copyright © 2014, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds