Forgot your password?
typodupeerror

Comment: Re:Odd... (Score 1) 186

by PAjamian (#45902941) Attached to: Red Hat To Help Develop CentOS

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.

Comment: Re:Odd... (Score 2) 186

by PAjamian (#45895935) Attached to: Red Hat To Help Develop CentOS

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.

Comment: Re:Odd... (Score 1) 186

by PAjamian (#45895291) Attached to: Red Hat To Help Develop CentOS

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).

Comment: Re:Odd... (Score 2) 186

by PAjamian (#45895247) Attached to: Red Hat To Help Develop CentOS

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.

Comment: ALL CAPS (Score 1) 362

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.

+ - Fedora 19 to Stop Masking Passwords 1

Submitted by PAjamian
PAjamian (679137) writes "Maintainers of the Anaconda installer in Fedora have taken it upon themselves to show passwords in plaintext on the screen as they are entered into the installer. Following on the now recanted statements of security expert Bruce Sheiner, Anaconda maintainers have decided that it is not a security risk to show passwords on your screen in the latest Alpha release of Fedora 19. Members of the Fedora community on the Fedora devel mailing list are showing great concern over this change in established security protocols."

Comment: Re:It's called the key (Score 3, Interesting) 1176

by PAjamian (#42904385) Attached to: Driver Trapped In Speeding Car At 125 Mph

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).

Comment: Re:More capacity, but what about I/O? (Score 1) 293

by PAjamian (#40081225) Attached to: 60TB Disk Drives Could Be a Reality In 2016

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.

Kill Ugly Processor Architectures - Karl Lehenbauer

Working...