Sponsored Content
Full Discussion: Should I learn RHEL???
Operating Systems Linux Should I learn RHEL??? Post 302694513 by fpmurphy on Friday 31st of August 2012 12:44:46 AM
Old 08-31-2012
You would also use CentOS which is essentially RHEL without the branding. CentOS is free.
 

10 More Discussions You Might Find Interesting

1. UNIX for Dummies Questions & Answers

Where to Learn About HP-UX

can someone give me the link to any site that deals on HP-UX system administration?? Please do not refer me to buy or borrow any books, i just need a free site to learn some quick info from (1 Reply)
Discussion started by: TRUEST
1 Replies

2. Programming

Learn C or C++

Hi, Apologies if this question has been asked before. I would like to know which language is better to learn in terms of programming in unix? is C dying out and being replaced by C++ or is it a combination of the 2 or just mainly C? Thanks C19 (2 Replies)
Discussion started by: c19h28O2
2 Replies

3. Red Hat

Difference between RHEL 3 AND RHEL 4

Anybody, let me know major differences between RHEL 3 & 4 . (2 Replies)
Discussion started by: sakthi_13
2 Replies

4. UNIX for Dummies Questions & Answers

I Want to Learn HP-UX!

What's the best free system to learn HP-UX on? The closest system, hardware requirements and installation instructions. I'm a newbie but determined. Any tips would be great. (6 Replies)
Discussion started by: networkguy
6 Replies

5. Red Hat

cannot ssh (use NFS) on RHEL box, but can mount external & ssh out of RHEL box

Ok, Im trying to get NFS working on my RHEL 5 box, apparently i can use the box as a client, but not as a server. If it helps i cant ssh into the box (server), but as a client ssh works fine. Ive configured server: /etc/hosts.allow: all : all all :all@all setup my /etc/exports file... (4 Replies)
Discussion started by: drs.grid
4 Replies

6. Red Hat

Does RHEL 5 provide a command to collect RHEL system log in single compress file?

Hi, I heard a command that can collect all RHEL 5 log in a single compress file before I forget. Does any body know...What the command is ? Thanks. (4 Replies)
Discussion started by: nnnnnnine
4 Replies

7. Red Hat

Error throwing while installing vsftpd package in rhel 6. using rhel 6 dvd.

Hi all, Im studying rhcsa as of now, so yum installation and dependencies are messing me to not workit out. i have dual os, win 7 & rhel 6. i have tried this installation of vsftpd package with rhel 6 dvd in VM rhel 6 in win 7 as well as host rhel 6.still the same issue. below error... (6 Replies)
Discussion started by: redhatlbug
6 Replies

8. Red Hat

RHEL 6, Spacewalk 2.3 unable to download RHEL 5 repo data

Hello all, I am having a bit of an issue on my Spacewalk installation. Some amplifying information is that it is Spacewalk 2.3 installed on a RHEL 6 machine and I am attempting to install/update a RHEL 5 channel/repository. I am fairly new to Spacewalk so I am still learning but this is what I... (3 Replies)
Discussion started by: jstone4646
3 Replies

9. UNIX for Dummies Questions & Answers

Windows->RHEL->RHEL X11 Forwarding?

I know this question might have been asked a lot but couldn't find anything that worked. From a windows machine 'A' I can only SSH into Linux server 'B' from where I can SSH into another Linux server 'C'. I need to be able to run GUI interfaces on server C which run on my Windows machine. I... (3 Replies)
Discussion started by: hr.prasan
3 Replies

10. Red Hat

Is it possible to install RHEL 7 on top of RHEL 6?

Hi We have RHEL 6.7 on an HP physical server and want to install RHEL 7 (not upgrade) on top of it by means of virtualization. Is it possible to install/configure RHEV/KVM virtualization on base RHEL 6.7 OS instance and then install RHEL 7 as a VM guest on it? If yes, could you please guide me... (1 Reply)
Discussion started by: magnus29
1 Replies
Moose::Manual::Support(3)				User Contributed Perl Documentation				 Moose::Manual::Support(3)

NAME
Moose::Manual::Support - Policies regarding support, releases, and compatibility. SUPPORT POLICY
There are two principles to Moose's policy of supported behavior. 1. Moose favors correctness over everything. 2. Moose supports documented and tested behavior, not accidental behavior or side effects. If a behavior has never been documented or tested, the behavior is officially undefined. Relying upon undocumented and untested behavior is done at your own risk. If a behavior is documented or tested but found to be incorrect later, the behavior will go through a deprecation period. During the deprecation period, use of that feature will cause a warning. Eventually, the deprecated feature will be removed. In some cases, it is not possible to deprecate a behavior. In this case, the behavior will simply be changed in a major release. RELEASE SCHEDULE
Moose is on a system of quarterly major releases, with minor releases as needed between major releases. A minor release is defined as one that makes every attempt to preserve backwards compatibility. Currently this means that we did not introduce any new dependency conflicts, and that we did not make any changes to documented or tested behavior (this typically means that minor releases will not change any existing tests in the test suite, although they can add new ones). A minor release can include new features and bug fixes. Major releases may be backwards incompatible. Moose prioritizes correctness over backwards compatibility or performance; see the Deprecation Policy to understand how backwards incompatible changes are announced. Major releases are scheduled to happen during fixed release windows. If the window is missed, then there will not be a major release until the next release window. The release windows are one month long, and occur during the months of January, April, July, and October. Before a major release, a series of development releases will be made so that users can test the upcoming major release before it is distributed to CPAN. It is in the best interests of everyone involved if these releases are tested as widely as possible. DEPRECATION POLICY
Moose has always prioritized correctness over performance and backwards compatibility. Major deprecations or API changes are documented in the Changes file as well as in Moose::Manual::Delta. The Moose developers will also make an effort to warn users of upcoming deprecations and breakage through the Moose blog (http://blog.moose.perl.org). Deprecated APIs will be preserved for at least one year after the major release which deprecates that API. Deprecated APIs will only be removed in a major release. Moose will also warn during installation if the version of Moose being installed will break an installed dependency. Unfortunately, due to the nature of the Perl install process these warnings may be easy to miss. BACKWARDS COMPATIBILITY
We try to ensure compatibility by having a extensive test suite (last count just over around 5123 tests), as well as testing a number of packages (currently just under 100 packages) that depend on Moose before any release. The current list of downstream dependencies that are tested is in "xt/author/test-my-dependents.t". VERSION NUMBERS
Moose version numbers consist of three parts, in the form X.YYZZ. The X is the "special magic number" that only gets changed for really big changes. Think of this as being like the "5" in Perl 5.12.1. The YY portion is the major version number. Moose uses even numbers for stable releases, and odd numbers for trial releases. The ZZ is the minor version, and it simply increases monotonically. It starts at "00" each time a new major version is released. Semantically, this means that any two releases which share a major version should be API-compatible with each other. In other words, 2.0200, 2.0201, and 2.0274 are all API-compatible. Prior to version 2.0, Moose version numbers were monotonically incrementing two decimal values (0.01, 0.02, ... 1.11, 1.12, etc.). Moose was declared production ready at version 0.18 (via <http://www.perlmonks.org/?node_id=608144>). PERL VERSION COMPATIBILITY
As of version 2.00, Moose officially supports being run on perl 5.8.3+. Our current policy is to support the earliest version of Perl shipped in the latest stable release of any major operating system (this tends to mean CentOS). We will provide at least six months notice (two major releases) when we decide to increase the officially supported Perl version. The next time this will happen is in January of 2012, when Moose 2.06 will increase the minimum officially supported Perl version to 5.10.1. "Officially supported" does not mean that these are the only versions of Perl that Moose will work with. Our declared perl dependency will remain at 5.8.3 as long as our test suite continues to pass on 5.8.3. What this does mean is that the core Moose dev team will not be spending any time fixing bugs on versions that aren't officially supported, and new contributions will not be rejected due to being incompatible with older versions of perl except in the most trivial of cases. We will, however, still welcome patches to make Moose compatible with earlier versions, if other people are still interested in maintaining compatibility. Note that although performance regressions are acceptable in order to maintain backwards compatibility (as long as they only affect the older versions), functionality changes and buggy behavior will not be. If it becomes impossible to provide identical functionality between modern Perl versions and unsupported Perl versions, we will increase our declared perl dependency instead. CONTRIBUTING
Moose has an open contribution policy. Anybody is welcome to submit a patch. Please see Moose::Manual::Contributing for more details. perl v5.12.5 2011-09-06 Moose::Manual::Support(3)
All times are GMT -4. The time now is 03:43 AM.
Unix & Linux Forums Content Copyright 1993-2022. All Rights Reserved.
Privacy Policy