| |||||||||||||
New sloganNew sloganPosted Apr 21, 2010 14:50 UTC (Wed) by danieldk (guest, #27876)In reply to: New slogan by yodermk Parent article: RHEL 6 beta version available
Grin :). I can understand that enterprisy distributions are great administration-wise, especially on a server. But I hate to have it forced on workstations (or clusters for that matter), since it's always a pain to deal with the old version of libstdc++ (I want my TR1-style hashmaps), boost (there I lost my hope of using the boost implementation) or gcc (where has -Wextra gone?). You usually end up with a partial copy of Boost (thank bcp!), and a lot of hacks around the staleness. This all makes Debian Stable feel refreshing (unless someone happens to be running Debian 3.1).
I used to like enterprise distributions, maybe because it was nice in theory. But since I have mostly been on the development/research side of the fold, I can only hope they die sooner than later ;).
Fortunately, my employer is mostly on Debian 5/Ubuntu 9.10 these days.
(Log in to post comments)
New slogan Posted Apr 21, 2010 14:58 UTC (Wed) by djf_jeff (subscriber, #62173) [Link]
I guess that's the beauty of Linux, you are not stuck with one OS for all your needs.
At our current job, we do a lot of Red Hat (RHEL and their other products) but our web servers run on Debian. The reason for this is that we run TYPO3 and it need a recent version of PHP, something RHEL lacks.
The only problem with this hybrid approach is that it's harder to find a solution to centrally manage everything from one place.
Linux with caveats Posted Apr 21, 2010 15:09 UTC (Wed) by pboddie (subscriber, #50784) [Link] I guess that's the beauty of Linux, you are not stuck with one OS for all your needs. You are if your place of work only "supports" one particular flavour. Usually, such regimes are quite happy to throw money around on supporting the latest Windows versions, too. Make of that what you will.
Linux with caveats Posted Apr 22, 2010 1:03 UTC (Thu) by gmagklaras (guest, #65547) [Link]
As part of the "regime", I do not really understand why you are stuck, when your RHEL 5.5 workstation could easily KVM/xen your favourite distro on which you can base your development environment.
As a side note for the latest windows versions, well, I was never in favour of NT/2000/XP or Vista, but 7 is a lot better to administer and run than all previous versions.
GM
Linux with caveats Posted Apr 22, 2010 14:55 UTC (Thu) by pboddie (subscriber, #50784) [Link] As part of the "regime", I do not really understand why you are stuck, when your RHEL 5.5 workstation could easily KVM/xen your favourite distro on which you can base your development environment. Some things for my friendly sysadmins to do when they get back, then. :-) What motivated my remark was that claims to support "Linux" which amount to only being able to run one particular "blessed" distribution often undermine the benefits of Linux, one of which was articulated in the comment I responded to: you can always find a distribution which suits you best. Of course no-one wants to have to support every distribution out there, but when the "regime" is happy to indulge Windows users with the latest and greatest, but they won't even entertain a second choice of well-regarded Linux distribution, one can't help feeling that one has drawn a very short straw indeed.
Linux with caveats Posted Apr 22, 2010 19:35 UTC (Thu) by nevyn (subscriber, #33129) [Link]
> Of course no-one wants to have to support every distribution out there,
> but when the "regime" is happy to indulge Windows users with the latest > and greatest, but they won't even entertain a second choice of > well-regarded Linux distribution
But these are not the same. In many ways the difference between RHEL-5 and RHEL-6 will be significantly less than the difference between RHEL-6 and Ubuntu-10.4, even though they'll be released within months of each other (as against years).
Linux with caveats Posted Apr 23, 2010 12:51 UTC (Fri) by pboddie (subscriber, #50784) [Link]
The most blatant differences are surely in things like packaging and update delivery, but in a sense, these things are what you rely on the vendor for (if they can be bothered to fix stuff, that is). Meanwhile, having all the infrastructure hooks in place is going to be more work for the "regime" in question: how the software uses the existing authentication systems, and so on.
Even if it's not the case now, over time the goal of the distribution vendors should be to make their products fit in with the minimum of local effort. Once upon a time, having huge numbers of local customisations and packages would have been the norm, but effectively saying that "Red Hat's package for XYZ isn't as good as our local package" can be regarded as making a bold claim indeed, at least for software where Red Hat can bring a lot of top-level expertise to bear.
I've worked in places where the "regime" even felt the need to have their own special Windows distribution, much to the annoyance of colleagues who found stuff mysteriously disappearing and having "fresh" stuff copied in on a regular basis, so if the support burden starts to stack up to "double the work", my experience tells me to review what the nature of some of that "support" is. I can well imagine that an mindset of maintaining lots of "special" software (from the days when people had to deliver stuff in a heterogeneous environment where the target platforms - stuff like Ultrix, IRIX, HP-UX, Tru64, SunOS, Solaris, AIX - had no decent repositories of their own) persists in many institutions and is not always adequately reviewed.
But anyway, the deployment of different distributions shouldn't be radically different. Although vendors may see some benefit in having things that way, or selling management tools to smooth over the cracks, it's certainly not in the spirit of giving end-users the choice, which is what many people see (perhaps implicitly) in Linux.
Linux with caveats Posted Apr 23, 2010 15:43 UTC (Fri) by nevyn (subscriber, #33129) [Link]
> The most blatant differences are surely in things like packaging and
> update delivery, but in a sense, these things are what you rely on the > vendor for
Yes, but that's a huge difference on it's own! The next big difference is that the bits coming from those updates are very different.
> But anyway, the deployment of different distributions shouldn't be
I guess this depends on your definition of "radically different". Some of the components are the same or similar (say, the version of vim, coreutils or maybe perl). But a _lot_ is different.
Configuring network is radically different between debian/ubuntu and Fedora/RHEL, a bunch of other configuration is almost as bad. As you said, all the package tool are named differently, act differently and have different feature sets. Packages are named differently, split differently
If you hit a kernel bug in one distro. there's no guarantee it'll be in the other one (even with 10.4 vs. 6, the backport work is _huge_ on the 6 side ... and there are a bunch of changes from debian in 10.4). If it is in both you'll need to open two support tickets, and they'll almost certainly have different resolution timelines etc.
All of which is why I said it'd be nearly double the work, to support both.
> it's certainly not in the spirit of giving end-users the choice, which
There is choice ... you just have to choose given a number of differences.
Even if you forked from RHEL-6 beta tomorrow, by the time RHEL-6 came out you are guaranteed to have "more than one difference". If the user liked some differences on one side and some on the other, they'd have to choose the least worst.
Linux with caveats Posted Apr 24, 2010 16:13 UTC (Sat) by pboddie (subscriber, #50784) [Link] Yes, but that's a huge difference on it's own! The next big difference is that the bits coming from those updates are very different. So, Debian and Red Hat split things up differently. It'd be interesting to see, once you've installed all the necessary packages, which differences there actually are. And why should it matter? Back in the day, you'd have your institution's private repository giving out packages, albeit all built from source and more or less the same on every platform, but underneath all that the differences would be profound. Configuring network is radically different between debian/ubuntu and Fedora/RHEL, a bunch of other configuration is almost as bad. As you said, all the package tool are named differently, act differently and have different feature sets. Packages are named differently, split differently and often go into different places. Things like multi-minor-versioned python are std. in debian but not in Fedora. I don't deny that it could be confusing, but as an individual it's possible to remember how the networking is configured on different distributions and where the Python packages go, so I struggle to see how it should be an insurmountable burden for an organisation dedicated to managing this kind of stuff. And weren't there tools for handling at least stuff like network configuration? Once upon a time, people swore by stuff like Webmin, and before Caldera was subverted for lawsuit purposes they even had a project going to try and standardise this stuff. If you hit a kernel bug in one distro. there's no guarantee it'll be in the other one (even with 10.4 vs. 6, the backport work is _huge_ on the 6 side ... and there are a bunch of changes from debian in 10.4). If it is in both you'll need to open two support tickets, and they'll almost certainly have different resolution timelines etc. Isn't Launchpad supposed to solve this problem? No, you don't have to answer that. ;-) All of which is why I said it'd be nearly double the work, to support both. For one specific kernel-related bug, yes. For the entire Linux support activity, I'm not completely convinced. Either way, vendors should be working towards standardising much of the administrative interface, and those deploying Linux should be attempting to take advantage of the choice the Linux ecosystem offers, not taking one particular vendor's flavour and pretending it's something like HP-UX.
Linux with caveats Posted Apr 23, 2010 13:59 UTC (Fri) by nix (subscriber, #2304) [Link]
Quite so. I just had to spend a day adding workarounds because of a crash bug in zsh, introduced in 2002, fixed in 2003... still there in the ancient RHELs some of our customers insist on.
New slogan Posted Apr 21, 2010 15:53 UTC (Wed) by danieldk (guest, #27876) [Link]
Well, that assumes that there is the opportunity to choose. Our university has a standard Windows and UNIX workplace, and that's what you get. I am not complaining, because it is actually useful to have the same environment everywhere, and a recent Ubuntu version is used for the workplace (and Debian on servers). Fortunately they have banned old (but supported) Red Hat and SUSE versions.
However some computing resources with a lot of cycles use old RHEL/CentOS/Scientific Linux versions, e.g. one particular cluster has just migrated from RHEL4 to RHEL5 (which is not really stellar). Compiling our codebase there is always a drag, where you have to bring things four or five years back in time.
New slogan Posted Apr 21, 2010 16:52 UTC (Wed) by horen (subscriber, #2514) [Link]
Funny... OUR university group has standardized on RHEL, almost solely because of its aggressive approach to security updates.
As an old(er) Unix maven said to me, some twenty years ago, "Once you've secured your network against the Bad Guys on the outside, you can begin to defend it against those on the *inside*."
Some things haven't changed. The bulk of those probing and banging on our systems are this university's own students.
Yup, we run RHEL/5.5, and we're quite happy when RedHat pushes out yet-another security update.
Of course, YMMV.
boost updated post RHEL-6 beta Posted Apr 21, 2010 15:28 UTC (Wed) by bkoz (guest, #4027) [Link]
I feel your pain on this issue.
Please note that the RHEL-6 beta released today has an older version of boost than the 1.41.0 version that will be in RHEL-6 final. (Ie, RHEL-6 will sync with F13 for libstdc++/boost.) The F13/RHEL-6 packaging has some notable improvements over RHEL-5 versions.
It would have been very nice to have GCC 4.5.0's libstdc++ in RHEL-6 (especially if we are going to have to live with it as "top of RHEL tree" for another 4 years on the server!) but the release dates didn't sync, sadly. And the backport to 4.4 based gcc's isn't feasible.
If you care about this kind of stuff please let your RH reps know.
boost updated post RHEL-6 beta Posted Apr 21, 2010 16:01 UTC (Wed) by danieldk (guest, #27876) [Link]
Having the latest and greatest new helps a bit. However, within two years g++ will probably support many more C++0x features than it does now, but since RHEL7 probably won't be rolled out until 2015, you can't use them for a window of three years when the rest of the world has moved on. I am emphasizing on C++ here, because that's what I use mostly, but I am sure that the same applies to Python or Ruby. I like turnaround times of two year max ;).
Before someone points out that Windows has even longer release cycles: that's true, but the Windows 'userland' isn't tied as much to the base system as a Linux distribution. Try to replace Gtk+ in CentOS 5 to a newer version, it is a pointless exercise. On Windows you can install the latest installment of Visual Studio and enjoy new features.
boost updated post RHEL-6 beta Posted Apr 21, 2010 16:47 UTC (Wed) by danpb (subscriber, #4831) [Link]
There's no need to replace existing versions of apps. It is entirely possible to install multiple extra versions providing you compile them with non-clashing install prefixes. I know people using RHEL whom have as many as 5-10 different GCC/G++ toolchain versions, each in /opt/. Likewise you can do this for other libraries like GTK. Perl / python is doable too, though you might need to change #!/usr/bin/perl in scripts to reference a binary with a specific alternate version number
RHEL 7 when? Posted Apr 21, 2010 20:43 UTC (Wed) by dowdle (subscriber, #659) [Link]
Why do you think RHEL 7 won't hit until 2015? I would imagine that RHEL development will be back on track (18-24 months) after RHEL 6 is released. Even if not, 2015 is 4.5 years away and even RHEL6 won't take that long.
New slogan Posted Apr 21, 2010 16:23 UTC (Wed) by jspaleta (subscriber, #50639) [Link]
So your employer.... are they a paying Canonical any thing for support customer for those Ubuntu 9.10 installs? Are they paying the $10k+ to have Landscape satellite server on premises?
-jef
New slogan Posted Apr 21, 2010 19:22 UTC (Wed) by danieldk (guest, #27876) [Link]
I do not know whether they paid for customer support, I guest most support requests are too specific (lots of third party software). But they do use Landscape... (I'd guess local)
New slogan Posted Apr 21, 2010 19:33 UTC (Wed) by jspaleta (subscriber, #50639) [Link]
Can you get a confirmation about the existence of a local landscape server?
And ballpark how many nodes on Landscape? We talking hundreds or tens?
The published rate for Landscape is $150 per node annually before undisclosed volume discounting. And if you are running a local Landscape server that's a reported $8k on top of that.
-jef
New slogan Posted Apr 21, 2010 20:21 UTC (Wed) by danieldk (guest, #27876) [Link]
Yes, they run a local Landscape server. A 2008 report estimates ~900 Linux desktops in the university (yes, universities are Windows shops as well). As far as I know, the intention is to migrate all Linux desktops to the centrally provided Linux environment, as they did with Windows desktops long ago. I have totally no clue about the (volume) pricing, as I am just a user.
|
|||||||||||||