I didn't catch that bit of the announcement. It'll be interesting to see what actually happens in that regard, then. At any rate I think it will probably be a minor adaptation to get the sources from git instead of SRPMs and it should make tracking changes in the sources easier. Also it may be possible that the CentOS project itself will continue to release the sources which would be almost identical to the RHEL ones anyways.
Oracle is a less expensive RHEL,
No, Oracle rips off RHEL just like CentOS SL and others do, but Oracle doesn't add value to RHEL, instead they compete with RedHat and with less expensive you get a fourth party to the sources (after they have gone through the original project, then Fedora, then RHEL) trying to provide support for something they only cloned off of someone else, whereas RedHat are pretty much 2nd party to the sources and have a lot more knowledge on them, so you get what you pay for in terms of support or with Oracle even less than what you paid for.
Cent tends to lack security updates after RHEL releases,
CentOS has been pretty onto it as of late, 6.5 only took about a week after RedHat released (iirc) and they are very quick on updates, usually the same or next day. Also now that the devs are getting paid (by RedHat) for their time it should be even faster.
Scientific is dependent on government funding but gets security updates in what could be called a timely manner compared to Cent.
There have been times that SL has beaten CentOS and times that CentOS has beaten SL.
If this means Cent gets security updates in a timely manner after RHEL version bumps then it is a good thing.
My understanding form the original CentOS announcement is that CentOS will still have to build their own binaries from the publicly available sources (RedHAT won't allow them to use RHEL binaries) so that part won't change, but as I said above, the devs are now paid for their time which will make a huge difference, plus I imagine that they will have better access to RedHat for issues with rebuilding the sources. RHEL is not self-building and as such has always had difficulties trying to get it to build, especially after a new major release. Often times you can look at the sources and wonder how RedHat managed to get it to build. Now they should have better access to get help with these issues instead of having to figure it out for themselves.
I honestly don't think that was ever a concern. The CentOS community tends to have a dislike for Oracle almost as much as RedHat does.
Kind of, I think it's more like RedHat is targeting a certain kind of customer with their business. They want to get the big spending Enterprise customers who are willing to fork out a lot of money for a product with major backing behind it, RHEL is one such product but there are other companies that also sell enterprise Linux distros, not to mention all the other OSes out there that RedHat has to compete with.
They don't loose money on CentOS users because CentOS users generally do not fall into their targeted customer base, but many CentOS users have influence over that targeted customer base and if they are happy with CentOS then when they get the chance to make a recommendation that will be for RHEL. RedHat realizes this and so as a consequence they know that CentOS actually *helps* their business in the long run. I think that by supporting CentOS on a more official basis as they are now doing they can help to solidify that the recommendation really does point to RedHat when it comes around as well as giving something back to the community that has worked to actually help them for all these years. Don't discount the side benefit of being able to excersize a bit of control over CentOS either (although RedHat's track record with other projects that they control is that they usually are fairly benevolent and let the project do what they want within reason).
No, it's perfectly fine for switching between RHEL and CentOS as CentOS is fully binary compatible with RHEL (that is one of the project goals) so if it doesn't work for compatibility reasons then it is a CentOS bug.
SL is not quite as strict on compatibility, but it should still work fine even though it's unsupported.
Oracle Linux even provides a utility to switch from other EL distros to Oracle and all it does is switch the -release package and a couple other key packages over (although I don't recommend Oracle Linux).
What is usually not supported (and not a good idea) is to try to use yum to upgrade from one major release to another, switching from one variant of EL to another on the same version is generally just fine.
It's very easy to do. I've done the reverse (RHEL to CentOS) on a few occasions. It is generally as simple as installing a single -release rpm.
There is a major difference between chat, email, etc in ALL CAPS and filling out a form in ALL CAPS. I often times fill out forms in all caps due to the fact that many are scanned and OCR tends to work better with caps than lowercase letters. This is especially true for hand-filled forms. In fact I have filled out forms that *explicitly ask* you to use all caps when filling them in.
hrmmmm, makes you wonder if it was planned that way.
If it was 192.168.0.0/16 that's fine as it is reserved by RFC1918 for private use.
Even on older cars the default state of the clutch is engaged. Most cars have a hydrolic clutch which can fail due to a burst hose or failed seal, etc. Other cars have a manual clutch which is basically just a cable that can fail from fatigue (the clutch cable breaks). In either of these cases if the clutch fails it is left *engaged* which means that you cannot release it. The only case of a clutch failing and not leaving the engine engaged is when the clutch plate itself is worn out and then you get what is known as the "clutch slipping" (and eventually not engaging at all).
That's actually known as a "metric pint", and that's generally what you get when you order a pint in many countries that are on metric.
More and more cellphones today have batteries that cannot be removed by the consumer, though.
Which is why it's very important to monitor your disks using the tools and the SMART data on the disks themselves.
It's not as bad as it may seem. With disk speeds up to 15,000 rpm and higher areal densities means that data can be pulled off pretty fast. If HDD manufacturers were to implement technologies such as multi-track disk heads then IO speed could increase a lot more and would be limited mainly by seek times. What a lot of companies are doing nowadays is using 2" (laptop) drives in their servers, packing a lot more drives into the space, which means more smaller disks and therefore less to rebuild in the event of a failure as well as a lot more disk heads to increase IO even further (and help a lot with those nasty seek speeds when trying to access data in 200 different files at once). What we're really left with as the limiting factor is the electronics and if all else fails that can be dealt with by multiple parallel channels (first we had PATA, now SATA, anyone for PSATA?).
So yeah, Disk IO is a bit of a problem now but there really is quite a lot that can be done to eliminate that issue.