Modern development environment on dated RHEL

2010-04-27 Thread Elazar Leibovich
Due to company's policy, our development desktop stations must have RHEL 4.7
installed on them.
However, RHEL's packages are extermely out of date (for instance, it still
have python 2.3, etc.), and we wish to use many up too date development
tools (I'm not aiming to the bleeding edge, however a stable release from
the last year seems to me a desirable goal).
We mostly need user-space software (editors, scripting environment, etc.).
What's the best method to

   1. Use reasonably new user-space software on RHEL 4.7
   2. Not to break too much the entire RHEL echosystem, or at least provide
   to ourselves a clear way to upgrade the foreign packages we'll install.

I'm not really familiar with managing Red-Hat distribution, so any advice
will be welcomed.
Thanks
___
Linux-il mailing list
Linux-il@cs.huji.ac.il
http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il


Re: Modern development environment on dated RHEL

2010-04-27 Thread Omer Zak
1. Is RHEL 4.7 still being supported by RedHat, and are security patches
still being made available?  If yes, when is this support due to end?

2. Do you wish to use the up-to-date tools only for development, or also
in software to be delivered to the customer and/or deployed in the
company's operations?

3. How about installing a VM in RHEL 4.7 and doing your development in
the virtual machine, using a more recent version?  This will at least
reduce the number of packages to be backported to RHEL 4.7 to those
which are needed for running the VM.

4. How difficult would it be to change company policy?



On Tue, 2010-04-27 at 09:02 +0200, Elazar Leibovich wrote:
 Due to company's policy, our development desktop stations must have
 RHEL 4.7 installed on them.
 However, RHEL's packages are extermely out of date (for instance, it
 still have python 2.3, etc.), and we wish to use many up too date
 development tools (I'm not aiming to the bleeding edge, however a
 stable release from the last year seems to me a desirable goal).
 We mostly need user-space software (editors, scripting environment,
 etc.).
 What's the best method to
  1. Use reasonably new user-space software on RHEL 4.7
  2. Not to break too much the entire RHEL echosystem, or at least
 provide to ourselves a clear way to upgrade the foreign
 packages we'll install.
 I'm not really familiar with managing Red-Hat distribution, so any advice 
 will be welcomed.

-- 
You haven't made an impact on the world before you caused a Debian
release to be named after Snufkin.
My own blog is at http://www.zak.co.il/tddpirate/

My opinions, as expressed in this E-mail message, are mine alone.
They do not represent the official policy of any organization with which
I may be affiliated in any way.
WARNING TO SPAMMERS:  at http://www.zak.co.il/spamwarning.html


___
Linux-il mailing list
Linux-il@cs.huji.ac.il
http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il


Re: Modern development environment on dated RHEL

2010-04-27 Thread Evgeny Budilovsky
Why not compile all the latest software on some shared directory and then
run it from there ...
My company have policy not to give root access on development stations so I
just compile all my development software in home directory and use it from
there ...


2010/4/27 Elazar Leibovich elaz...@gmail.com

 Due to company's policy, our development desktop stations must have RHEL
 4.7 installed on them.
 However, RHEL's packages are extermely out of date (for instance, it still
 have python 2.3, etc.), and we wish to use many up too date development
 tools (I'm not aiming to the bleeding edge, however a stable release from
 the last year seems to me a desirable goal).
 We mostly need user-space software (editors, scripting environment, etc.).
 What's the best method to

1. Use reasonably new user-space software on RHEL 4.7
2. Not to break too much the entire RHEL echosystem, or at least
provide to ourselves a clear way to upgrade the foreign packages we'll
install.

 I'm not really familiar with managing Red-Hat distribution, so any advice
 will be welcomed.
 Thanks


 ___
 Linux-il mailing list
 Linux-il@cs.huji.ac.il
 http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il


___
Linux-il mailing list
Linux-il@cs.huji.ac.il
http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il


Re: Modern development environment on dated RHEL

2010-04-27 Thread Oleg Goldshmidt
2010/4/27 Elazar Leibovich elaz...@gmail.com:
 Due to company's policy, our development desktop stations must have RHEL 4.7
 installed on them.
 However, RHEL's packages are extermely out of date (for instance, it still
 have python 2.3, etc.), and we wish to use many up too date development
 tools (I'm not aiming to the bleeding edge, however a stable release from
 the last year seems to me a desirable goal).
 We mostly need user-space software (editors, scripting environment, etc.).
 What's the best method to

 Use reasonably new user-space software on RHEL 4.7
 Not to break too much the entire RHEL echosystem, or at least provide to
 ourselves a clear way to upgrade the foreign packages we'll install.

 I'm not really familiar with managing Red-Hat distribution, so any advice
 will be welcomed.

Here is one: EPEL - https://fedoraproject.org/wiki/EPEL

Just grab the yum repo details and go.

Note though that you may find that you need to update half the system,
including compilers, basic libraries like glibc, whatever depends on
glibc version, etc. This may not be  a problem, or it may be,
depending on what the limitations imposed by the company are.

-- 
Oleg Goldshmidt | o...@goldshmidt.org

___
Linux-il mailing list
Linux-il@cs.huji.ac.il
http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il


Re: Modern development environment on dated RHEL

2010-04-27 Thread Yedidyah Bar-David
On Tue, Apr 27, 2010 at 12:33:33PM +0300, Evgeny Budilovsky wrote:
 Why not compile all the latest software on some shared directory and then
 run it from there ...
 My company have policy not to give root access on development stations so I
 just compile all my development software in home directory and use it from
 there ...

If you go this route, you might consider using some package manager
for this, such as stow (or one of its clones) or gobolinux.
-- 
Didi


___
Linux-il mailing list
Linux-il@cs.huji.ac.il
http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il


Re: Modern development environment on dated RHEL

2010-04-27 Thread Kfir Lavi
Hi,

I'm a Gentoo user and did it a lot of times, though using chroot.
It is basically installing Gentoo into a directory. So you follow the Gentoo
installation manual. You finish before the Grub installation section.
Its a very straight forward procedure. Then you will have a very strong
environment for a developer.

If you choose to try this path, feel free to email me with any questions.
I'll gladly help and share my experience.

Regards,
Kfir

On Tue, Apr 27, 2010 at 12:55 PM, Yedidyah Bar-David 
linux...@didi.bardavid.org wrote:

 On Tue, Apr 27, 2010 at 12:33:33PM +0300, Evgeny Budilovsky wrote:
  Why not compile all the latest software on some shared directory and then
  run it from there ...
  My company have policy not to give root access on development stations so
 I
  just compile all my development software in home directory and use it
 from
  there ...

 If you go this route, you might consider using some package manager
 for this, such as stow (or one of its clones) or gobolinux.
 --
 Didi


 ___
 Linux-il mailing list
 Linux-il@cs.huji.ac.il
 http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il

___
Linux-il mailing list
Linux-il@cs.huji.ac.il
http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il


Re: Modern development environment on dated RHEL

2010-04-27 Thread Elazar Leibovich
1. Yes it is
http://press.redhat.com/2008/07/24/red-hat-enterprise-linux-47-released-today/

2. Only for development. We have a specific environment for deployment,
compiling and testing the end product (which is a good idea anyhow IMHO. You
don't want the customers be affected by a specific build issue a single
developer has).

3. I'm afraid running everything with a VM will be too slow. I'm
occasionally running an Ubuntu on a 2 years old laptop with Vista, and user
experience is not so great.

4. I'm not sure. It's problematic since ClearCase 6 is only supported by IBM
on RHEL 4.7, and we don't have new CC licenses.

On Tue, Apr 27, 2010 at 9:24 AM, Omer Zak w...@zak.co.il wrote:

 1. Is RHEL 4.7 still being supported by RedHat, and are security patches
 still being made available?  If yes, when is this support due to end?

 2. Do you wish to use the up-to-date tools only for development, or also
 in software to be delivered to the customer and/or deployed in the
 company's operations?

 3. How about installing a VM in RHEL 4.7 and doing your development in
 the virtual machine, using a more recent version?  This will at least
 reduce the number of packages to be backported to RHEL 4.7 to those
 which are needed for running the VM.

 4. How difficult would it be to change company policy?



 On Tue, 2010-04-27 at 09:02 +0200, Elazar Leibovich wrote:
  Due to company's policy, our development desktop stations must have
  RHEL 4.7 installed on them.
  However, RHEL's packages are extermely out of date (for instance, it
  still have python 2.3, etc.), and we wish to use many up too date
  development tools (I'm not aiming to the bleeding edge, however a
  stable release from the last year seems to me a desirable goal).
  We mostly need user-space software (editors, scripting environment,
  etc.).
  What's the best method to
   1. Use reasonably new user-space software on RHEL 4.7
   2. Not to break too much the entire RHEL echosystem, or at least
  provide to ourselves a clear way to upgrade the foreign
  packages we'll install.
  I'm not really familiar with managing Red-Hat distribution, so any advice
 will be welcomed.

 --
 You haven't made an impact on the world before you caused a Debian
 release to be named after Snufkin.
 My own blog is at http://www.zak.co.il/tddpirate/

 My opinions, as expressed in this E-mail message, are mine alone.
 They do not represent the official policy of any organization with which
 I may be affiliated in any way.
 WARNING TO SPAMMERS:  at http://www.zak.co.il/spamwarning.html


 ___
 Linux-il mailing list
 Linux-il@cs.huji.ac.il
 http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il

___
Linux-il mailing list
Linux-il@cs.huji.ac.il
http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il


Re: Modern development environment on dated RHEL

2010-04-27 Thread Elazar Leibovich
It will waste a HUGE amount of time. Compiling basic software suite takes at
least a single day, and it has a mental cost of managing the dependencies by
hand.
And you have to do that every time you update your software.

It's even worse than windows non-package management system.

On Tue, Apr 27, 2010 at 11:33 AM, Evgeny Budilovsky bud...@gmail.comwrote:

 Why not compile all the latest software on some shared directory and then
 run it from there ...
 My company have policy not to give root access on development stations so I
 just compile all my development software in home directory and use it from
 there ...


 2010/4/27 Elazar Leibovich elaz...@gmail.com

 Due to company's policy, our development desktop stations must have RHEL
 4.7 installed on them.

 However, RHEL's packages are extermely out of date (for instance, it still
 have python 2.3, etc.), and we wish to use many up too date development
 tools (I'm not aiming to the bleeding edge, however a stable release from
 the last year seems to me a desirable goal).
 We mostly need user-space software (editors, scripting environment, etc.).
 What's the best method to

1. Use reasonably new user-space software on RHEL 4.7
2. Not to break too much the entire RHEL echosystem, or at least
provide to ourselves a clear way to upgrade the foreign packages we'll
install.

 I'm not really familiar with managing Red-Hat distribution, so any advice
 will be welcomed.
 Thanks


 ___
 Linux-il mailing list
 Linux-il@cs.huji.ac.il
 http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il



___
Linux-il mailing list
Linux-il@cs.huji.ac.il
http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il


Re: Modern development environment on dated RHEL

2010-04-27 Thread Tzafrir Cohen
On Tue, Apr 27, 2010 at 02:12:41PM +0200, Elazar Leibovich wrote:
 1. Yes it is
 http://press.redhat.com/2008/07/24/red-hat-enterprise-linux-47-released-today/
 
 2. Only for development. We have a specific environment for deployment,
 compiling and testing the end product (which is a good idea anyhow IMHO. You
 don't want the customers be affected by a specific build issue a single
 developer has).
 
 3. I'm afraid running everything with a VM will be too slow. I'm
 occasionally running an Ubuntu on a 2 years old laptop with Vista, and user
 experience is not so great.

It wastes resources. But lets you do the real work in a sane way.

 
 4. I'm not sure. It's problematic since ClearCase 6 is only supported by IBM
 on RHEL 4.7, and we don't have new CC licenses.

AHHH!

Only RHEL4.7 is supported. However do you think a completely modified
(in a non-reproducable way) RHEL 4.7 is supported?

I suspect a VM is the cheapest way.

Is the problem only ClearCase itself, or the complete development
environment?

If only ClearCase: do you actually use it in the filesystem-like method?

-- 
Tzafrir Cohen | tzaf...@jabber.org | VIM is
http://tzafrir.org.il || a Mutt's
tzaf...@cohens.org.il ||  best
tzaf...@debian.org|| friend

___
Linux-il mailing list
Linux-il@cs.huji.ac.il
http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il


Re: Modern development environment on dated RHEL

2010-04-27 Thread Elazar Leibovich
Thanks for your comments.

On Tue, Apr 27, 2010 at 3:07 PM, Tzafrir Cohen tzaf...@cohens.org.ilwrote:

 On Tue, Apr 27, 2010 at 02:12:41PM +0200, Elazar Leibovich wrote:
  1. Yes it is
 
 http://press.redhat.com/2008/07/24/red-hat-enterprise-linux-47-released-today/
 
  2. Only for development. We have a specific environment for deployment,
  compiling and testing the end product (which is a good idea anyhow IMHO.
 You
  don't want the customers be affected by a specific build issue a single
  developer has).
 
  3. I'm afraid running everything with a VM will be too slow. I'm
  occasionally running an Ubuntu on a 2 years old laptop with Vista, and
 user
  experience is not so great.

 It wastes resources. But lets you do the real work in a sane way.

What hardware did you try that on? We're not having a very new hardware.
There are other issues of course, such as interop with the real
environment, etc. Although virtualbox allows you to share filesystem items
between machines quite nicely. And surprise surprise, it *is* supported on
RHEL 4!


 
  4. I'm not sure. It's problematic since ClearCase 6 is only supported by
 IBM
  on RHEL 4.7, and we don't have new CC licenses.

 AHHH!

 Only RHEL4.7 is supported. However do you think a completely modified
 (in a non-reproducable way) RHEL 4.7 is supported?

Well, if I manage not to change glibc, how can it know I'm having (say) a
brand new KDE with some Qt IDE? Or that I'm using reasonably recent version
of mercurial version control (yes I'm using both an agile version control
which is more convenient to quickly keep many small changes, and to search
through history with, and I move big baselines to the clearcase when I'm
done). Or scons to build the release.
I believe you can get a reasonably modern development environment to live
within the RHEL space. The only thing I fear is managing it.


 I suspect a VM is the cheapest way.

 Is the problem only ClearCase itself, or the complete development
 environment?

No, just Clearcase.


 If only ClearCase: do you actually use it in the filesystem-like method?

Do you mean the MVFS? Yes we do, but I'm by no means a ClearCase expert, so
I'll be glad to hear of other methods.


 --
 Tzafrir Cohen | tzaf...@jabber.org | VIM is
 http://tzafrir.org.il || a Mutt's
 tzaf...@cohens.org.il ||  best
 tzaf...@debian.org|| friend

 ___
 Linux-il mailing list
 Linux-il@cs.huji.ac.il
 http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il

___
Linux-il mailing list
Linux-il@cs.huji.ac.il
http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il


Re: Modern development environment on dated RHEL

2010-04-27 Thread guy keren

Elazar Leibovich wrote:


On Tue, Apr 27, 2010 at 3:07 PM, Tzafrir Cohen tzaf...@cohens.org.il 
mailto:tzaf...@cohens.org.il wrote:


 
  4. I'm not sure. It's problematic since ClearCase 6 is only
supported by IBM
  on RHEL 4.7, and we don't have new CC licenses.

AHHH!

Only RHEL4.7 is supported. However do you think a completely modified
(in a non-reproducable way) RHEL 4.7 is supported?

Well, if I manage not to change glibc, how can it know I'm having (say) 
a brand new KDE with some Qt IDE? Or that I'm using reasonably recent 
version of mercurial version control (yes I'm using both an agile 
version control which is more convenient to quickly keep many small 
changes, and to search through history with, and I move big baselines 
to the clearcase when I'm done). Or scons to build the release.
I believe you can get a reasonably modern development environment to 
live within the RHEL space. The only thing I fear is managing it.



I suspect a VM is the cheapest way.

Is the problem only ClearCase itself, or the complete development
environment?

No, just Clearcase.


If only ClearCase: do you actually use it in the filesystem-like method?

Do you mean the MVFS? Yes we do, but I'm by no means a ClearCase expert, 
so I'll be glad to hear of other methods.


clearcase has two major modes of operation. one of them allows you to 
see any changes made to the repositories instantly as they are made - 
this requires your development OS to be supported by clearcase. this 
form uses clearcase's kernel code to show you a virtual file system that 
takes its files from the clearcase repository on-the-fly.


the other reuires you to work like any other source control software - 
perform a rebase or checkout or other operations to see the changes 
made to the source. in this later case, you get copies of the code onto 
a normal file system.


in the later case, you can use clearcase on other systems, or 
alternatively, export the file system from a RHEL 4.7 system, via NFS - 
and so run the development tools on a different machine.


in the former case - i don't know if clearcase supports exporting its 
special file system via NFS to clients. if it does - this might give you 
the option of running the dev tools on a newer system, and only run the 
build operation on the RHEL 4.7 system.


--guy

___
Linux-il mailing list
Linux-il@cs.huji.ac.il
http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il