Re: [CentOS] SSD for Centos SWAP /tmp & /var/ partition
On Sun, May 22, 2011 at 2:40 AM, Steven Crothers wrote: > On Sat, May 21, 2011 at 6:29 PM, yonatan pingle > wrote: >> if you use the SSD for swap, don't put anything important on them, I >> have managed to destroy a drive which was used for heavy swap >> operations. >> (insane experiment with KVM virtual machines got to that situation ). >> the machines used the drive as RAM. ( that was an intel drive! ). > > I have to ask, how was your performance before death? I don't have a > sacrificial SSD laying around so I can't exactly test myself. I > imagine the gains had to be pretty high? > > Were you running a 3 or 6 gbps sata bus? > > -- > Steven Crothers > steven.croth...@gmail.com I was running on 3gbps sata bus, and the performance was great, it just dies in one big crash without giving any clues about it. -- Best Regards, Yonatan Pingle RHCT | RHCSA | CCNA1 ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] SSD for Centos SWAP /tmp & /var/ partition
> I was running on 3gbps sata bus, and the performance was great, it > just dies in one big crash without giving any clues about it. If only SSD's were a viable solution for long-term storage, we could theoretically increase our virtualization many times over. It's to bad the technology hasn't come far enough to be used that way though without costing an arm and leg. -- Steven Crothers steven.croth...@gmail.com ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] SSD for Centos SWAP /tmp & /var/ partition
On Sun, May 22, 2011 at 10:57 AM, Steven Crothers wrote: >> I was running on 3gbps sata bus, and the performance was great, it >> just dies in one big crash without giving any clues about it. > > If only SSD's were a viable solution for long-term storage, we could > theoretically increase our virtualization many times over. It's to bad > the technology hasn't come far enough to be used that way though > without costing an arm and leg. > > -- > Steven Crothers > steven.croth...@gmail.com > ___ > CentOS mailing list > CentOS@centos.org > http://lists.centos.org/mailman/listinfo/centos > the only way to go with SSD is RAID due to these reasons. it's unlikely that two disks will die at the same time, so it's possible to use and enjoy them , but don't forget to have a fresh backup and a raid array. ( that should be done also with an ordinary disk array anyways ). -- Best Regards, Yonatan Pingle RHCT | RHCSA | CCNA1 ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] SSD for Centos SWAP /tmp & /var/ partition
On Sun, 22 May 2011, yonatan pingle wrote: To: CentOS mailing list From: yonatan pingle Subject: Re: [CentOS] SSD for Centos SWAP /tmp & /var/ partition On Sun, May 22, 2011 at 10:57 AM, Steven Crothers wrote: I was running on 3gbps sata bus, and the performance was great, it just dies in one big crash without giving any clues about it. If only SSD's were a viable solution for long-term storage, we could theoretically increase our virtualization many times over. It's to bad the technology hasn't come far enough to be used that way though without costing an arm and leg. But it's going in the right direction now. -- Steven Crothers steven.croth...@gmail.com the only way to go with SSD is RAID due to these reasons. it's unlikely that two disks will die at the same time, so it's possible to use and enjoy them , but don't forget to have a fresh backup and a raid array. ( that should be done also with an ordinary disk array anyways ). That's EXACTLY what I was thinking. Two 40GB SSD drives in a RAID array would not cost much at all. Move all the disk intensive stuff to that. I only have two root partitions of 20GB each for my main install - everything else is on other partitions on 2 x 500GB E-IDE drives. So putting the root partion on a small SSD (possibly RAIDed) is another option. Like most new electronics components, as time passes the mass production cost fall dramatically, and the technology improves. Look at the way HDD technology continues to advance. Maybe in 5 years time the cost of SSD's will be alot cheaper? Possibly in another 15 years time HDD's with moving parts will be consigned to history and science museums? I'm watching this technology very closely, and I'm very tempted to buy a small 40GB SSD like OWC's. They keep performing at optimal speed according to the specs for that drive. The OWC SSD's are supposed to have a MTTF of 2 million hours, PLUS they do not degrade over time. So if an OWC keeps going until MTTF, that's 24 x 365 = 8760 HPY. 200 / 8760 = 228.31 years MTTF ? So why does it only have a 3 year warranty? - LOL For me anything on SWAP has to be better than a s/h drive thats had almost a years running time according to the SMART data on the drive: 9 Power_On_Hours 0x0032 090 090 000 Old_age Always - 7913 329 days running time already - let's see how long this one lasts before it kicks the bucket. Kind Regards, Keith Roberts - Websites: http://www.karsites.net http://www.php-debuggers.net http://www.raised-from-the-dead.org.uk All email addresses are challenge-response protected with TMDA [http://tmda.net] -___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] SSD for Centos SWAP /tmp & /var/ partition
On Sun, May 22, 2011 at 2:06 PM, Keith Roberts wrote: > On Sun, 22 May 2011, yonatan pingle wrote: > >> To: CentOS mailing list >> From: yonatan pingle >> Subject: Re: [CentOS] SSD for Centos SWAP /tmp & /var/ partition >> >> On Sun, May 22, 2011 at 10:57 AM, Steven Crothers >> wrote: I was running on 3gbps sata bus, and the performance was great, it just dies in one big crash without giving any clues about it. >>> >>> If only SSD's were a viable solution for long-term storage, we could >>> theoretically increase our virtualization many times over. It's to bad >>> the technology hasn't come far enough to be used that way though >>> without costing an arm and leg. > > But it's going in the right direction now. > >>> -- >>> Steven Crothers >>> steven.croth...@gmail.com > > >> the only way to go with SSD is RAID due to these reasons. >> it's unlikely that two disks will die at the same time, so it's >> possible to use and enjoy them , >> but don't forget to have a fresh backup and a raid array. ( that >> should be done also with an ordinary disk array anyways ). > > That's EXACTLY what I was thinking. Two 40GB SSD drives in a RAID array > would not cost much at all. Move all the disk intensive stuff to that. I > only have two root partitions of 20GB each for my main install - everything > else is on other partitions on 2 x 500GB E-IDE drives. So putting the root > partion on a small SSD (possibly RAIDed) is another option. Like most new > electronics components, as time passes the mass production cost fall > dramatically, and the technology improves. Look at the way HDD technology > continues to advance. > > Maybe in 5 years time the cost of SSD's will be alot cheaper? Possibly in > another 15 years time HDD's with moving parts will be consigned to history > and science museums? I'm watching this technology very closely, and I'm very > tempted to buy a small 40GB SSD like OWC's. > > They keep performing at optimal speed according to the specs for that drive. > > The OWC SSD's are supposed to have a MTTF of 2 million hours, PLUS they do > not degrade over time. So if an OWC keeps going until MTTF, that's 24 x 365 > = 8760 HPY. 200 / 8760 = 228.31 years MTTF ? > > So why does it only have a 3 year warranty? - LOL > > For me anything on SWAP has to be better than a s/h drive thats had almost a > years running time according to the SMART data on the drive: > > 9 Power_On_Hours 0x0032 090 090 000 > Old_age Always - 7913 > > 329 days running time already - let's see how long this one lasts before it > kicks the bucket. > > Kind Regards, > > Keith Roberts > > - > Websites: > http://www.karsites.net > http://www.php-debuggers.net > http://www.raised-from-the-dead.org.uk > > All email addresses are challenge-response protected with > TMDA [http://tmda.net] > - > ___ > CentOS mailing list > CentOS@centos.org > http://lists.centos.org/mailman/listinfo/centos > > I hardly swap to disk these days , and after the bad experience with ssd as swap only ... i would stick to RAM & sata. RAM is so cheap , just get extra ram , and use PAE if 32bit (?) adjust vm.swappiness ( sysctl ) to a lower value then 60 ( default ) , and you will be fine swapping on sata drives if and when needed. if you are afraid of memory fragmentation , don't be .. in most cases you will be rebooting the server when a new kernel update will come out as it is the main question is , which kind of applications are you planning to run on your machine, and what is your actual hardware *needs*, that only you can tell. also, for /tmp , you might like the idea of a ramdisk ( or tmpfs ) , it is a great way to speed up things without breaking the piggy bank. this is what i use in /etc/fstab for my home desktop as /tmp : /tmpfs /tmp tmpfs size=512M,nr_inodes=5k,noatime,nodiratime,noexec 0 0 does the job well. anyways - if it's for home usage Don't think twice get an SSD . -- Best Regards, Yonatan Pingle RHCT | RHCSA | CCNA1 ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] xferlog not rotating.
Lamar Owen wrote on 05/21/2011 04:25 PM: >> early in the thread, it was clear from a reply's content that >> > a locally installed 'ftpd' and not the CentOS vsftpd was >> > being used > Looking... don't see that. Perhaps I'm just missing it. Same here. The OP only replied once, and had the same default contents in /etc/logrotate.d/vsftpd.log that I have. Phil ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
[CentOS] Keep CentOS 5.5 from upgrading?
Thanks, I'm trying to keep CentOS 5.5 from upgrading to 5.6 because of my issue with the time sync. I thought I had it figured out till today. I have tried google for help but with no luck. Can someone point me to a page or link that will give me a good idea as to how to stop the upgrade but still allow me to update my 5.5 packages? This is what I tried, that is not working now. I edited "/etc/yum.repos.d/CentOS-Base.repo" to look as such. [base] name=CentOS-5.5 - Base ## name=CentOS-5.5 - Base mirrorlist=http://mirrorlist.centos.org/?release=5.5&arch=$basearch&repo=os #baseurl=http://mirror.centos.org/centos/$releasever/os/$basearch/ gpgcheck=1 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-5 priority=1 Brian. smime.p7s Description: S/MIME Cryptographic Signature ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Keep CentOS 5.5 from upgrading?
Mailing List wrote: > I'm trying to keep CentOS 5.5 from upgrading to 5.6 because of my issue > with the time sync. I thought I had it figured out till today. I have > tried google for help but with no luck. Can someone point me to a page > or link that will give me a good idea as to how to stop the upgrade but > still allow me to update my 5.5 packages? you cannot do that. it's centos 5. Updating a 5.x install will bring you to the latest of 5, which is currently 5.6 + [updates since the 5.6 release]. check out the centos FAQs, it's gotta be there. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Keep CentOS 5.5 from upgrading?
At Sun, 22 May 2011 10:22:24 -0400 CentOS mailing list wrote: > > This is a cryptographically signed message in MIME format. > > --===1683845214== > Content-Type: multipart/signed; protocol="application/pkcs7-signature"; > micalg=sha1; boundary="ms050101020400080101000304" > > This is a cryptographically signed message in MIME format. > > --ms050101020400080101000304 > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > Content-Transfer-Encoding: quoted-printable > > > Thanks, > > I'm trying to keep CentOS 5.5 from upgrading to 5.6 because of my=20 > issue with the time sync. I thought I had it figured out till today. I=20 > have tried google for help but with no luck. Can someone point me to a=20 > page or link that will give me a good idea as to how to stop the upgrade=20 > but still allow me to update my 5.5 packages? Is it just the time sync pagage (ntp-4.2.2p1-9.el5.centos.2.1) that is giving you trouble? In which case just add an excludepkgs= line in the updates. (Like this [from a C4 system using a CentOSPlus kernel and php packages]: .. #released updates [update] name=CentOS-$releasever - Updates mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=updates #baseurl=http://mirror.centos.org/centos/$releasever/updates/$basearch/ gpgcheck=1 gpgkey=http://mirror.centos.org/centos/RPM-GPG-KEY-centos4 priority=1 protect=1 excludepkgs=php* kernel kernel-devel kernel-doc .. > >This is what I tried, that is not working now. > > I edited "/etc/yum.repos.d/CentOS-Base.repo" to look as such. > > > [base] > name=3DCentOS-5.5 - Base > ## name=3DCentOS-5.5 - Base > mirrorlist=3Dhttp://mirrorlist.centos.org/?release=3D5.5&arch=3D$basearch&r= > epo=3Dos > #baseurl=3Dhttp://mirror.centos.org/centos/$releasever/os/$basearch/ > gpgcheck=3D1 > gpgkey=3Dfile:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-5 > priority=3D1 > > > Brian. > > > --ms050101020400080101000304 > Content-Type: application/pkcs7-signature; name="smime.p7s" > Content-Transfer-Encoding: base64 > Content-Disposition: attachment; filename="smime.p7s" > Content-Description: S/MIME Cryptographic Signature > > MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEH > AQAAoIITeDCCBjQwggQcoAMCAQICAR4wDQYJKoZIhvcNAQEFBQAwfTELMAkG > A1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNl > Y3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0 > YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDE1 > NVoXDTE3MTAyNDIxMDE1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T > dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZp > Y2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1h > cnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQAD > ggEPADCCAQoCggEBAMcJg8zOLdgasSmkLhOrlr6KMoOMpohBllVHrdRvEg/q > 6r8jR+EK75xCGhR8ToREoqe7zM9/UnC6TS2y9UKTpT1v7RSMzR0t6ndl0TWB > uUr/UXBhPk+Kmy7bI4yW4urC+y7P3/1/X7U8ocb8VpH/Clt+4iq7nirMcNh6 > qJR+xjOhV+VHzQMALuGYn5KZmc1NbJQYclsGkDxDz2UbFqE2+6vIZoL+jb9x > 4Pa5gNf1TwSDkOkikZB1xtB4ZqtXThaABSONdfmv/Z1pua3FYxnCFmdr/+N2 > JLKutIxMYqQOJebr/f/h5t95m4JgrM3Y/w7YX9d7YAL9jvN4SydHsU6n65cC > AwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEG > MB0GA1UdDgQWBBRTcu2SnODaywFcfH6WNU7y1LhRgjAfBgNVHSMEGDAWgBRO > C+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH > MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh > aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIw > J6AloCOGIWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWg > I4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMIGABgNVHSAE > eTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0dHA6Ly93d3cu > c3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 > d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEF > BQADggIBAAqDCH14qywGXLhjjF6uHLkjd02hcdh9hrw+VUsv+q1eeQWB21jW > j3kJ96AUlPCoEGZ/ynJNScWy6QMVQjbbMXltUfO4n4bGGdKo3awPWp61tjAF > graLJgDk+DsSvUD6EowjMTNx25GQgyYJ5RPIzKKR9tQW8gGK+2+RHxkUCTbY > FnL6kl8Ch507rUdPPipJ9CgJFws3kDS3gOS5WFMxcjO5DwKfKSETEPrHh7p5 > shuuNktvsv6hxHTLhiMKX893gxdT3XLS9OKmCv87vkINQcNEcIIoFWbP9HOR > z9v3vQwR4e3ksLc2JZOAFK+ssS5XMEoznzpihEP0PLc4dCBYjbvSD7kxgDwZ > +Aj8Q9PkbvE9sIPP7ON0fz095HdThKjiVJe6vofq+n6b1NBc8XdrQvBmunwx > D5nvtTW4vtN6VY7mUCmxsCieuoBJ9OlqmsVWQvifIYf40dJPZkk9YgGTzWLp > XDSfLSplbY2LL9C9U0ptvjcDjefLTvqSFc7tw1sEhF0n/qpA2r0GpvkLRDmc > SwVyPvmjFBGqUp/pNy8ZuPGQmHwFi2/14+xeSUDG2bwnsYJQG2EdJCB6luQ5 > 7GEnTA/yKZSTKI8dDQa8Sd3zfXb19mOgSF0bBdXbuKhEpuP9wirslFe6fQ1t > 5j5R0xi72MZ8ikMu1RQZKCyDbMwazlHiMIIGnDCCBYSgAwIBAgIDAbQKMA0G > CSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD > b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUg > U2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IElu > dGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcNMTAxMDExMTQyMTE3WhcNMTExMDEy > MDQ0ODA2WjCBkjEgMB4GA1UEDRMXMjcyNzYwLTZZaVo0QzljS0U2OTlaSVkx > HjAcBgNVBAoTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDEpMCcGA1UEAxMgU3Rh > cnRDb20gRnJlZSBDZXJ0aWZpY2F0ZSBNZW1iZXIxIzAhBgkqhkiG9w0BCQEW
Re: [CentOS] OT: RHEL 6.1 is out
On 05/20/2011 05:55 AM, Drew wrote: > An .1 release is basically a .0 release + patches so I don't see any > real difference. The hard part is reverse engineering the .0 release > build environment and the .1 follows pretty quick from there. You weren't reading the very long thread of the last week or so (I've forgotten when it started...) If that were true, then every .x release would "follow pretty quick". No reason has yet been given to expect 6.1 any more quickly than the average release time (about 6 weeks after 6.0 is released, so maybe 8 weeks from now). Expect it when it's done, and don't hold your breath. > Occasionally a .x release breaks the environment and you get > situations like 5.6 was. Who said anything about 5.6 breaking the environment? Everyone in the very long thread gave the excuse that it was done concurrent with other releases. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] SSD for Centos SWAP /tmp & /var/ partition
On 05/20/2011 01:26 PM, Keith Roberts wrote: > I'm wondering if it would be a good idea to use a new SSD > for moving all the disk i/o to, that Linux likes to do so > often. Yes, it's often a really good idea. If you're doing software RAID on Linux, you really should either disable disk drives' write cache or have the system on a UPS with monitoring and automated shutdown. Most people will opt for the latter. Using an SSD can boost write performance and reliability for other systems. I just found this write-up on the topic: http://insights.oetiker.ch/linux/external-journal-on-ssd.html > Plus putting SWAP onto a decent SSD should speed > things up somewhat. Well, only if you're using swap space. If that's the case, adding RAM to the system will probably be less expensive and a lot more effective. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
[CentOS] OT: RHEL 6.1 is out
On Sun, 22 May 2011, Gordon Messmer wrote: > Who said anything about 5.6 breaking the environment? Everyone in the > very long thread gave the excuse that it was done concurrent with other > releases. customary trolling by Gordon Messmer -- passive agressive, implying an unmet obligation ex·cuse /ikˈskyo͞os/ Noun: A reason or explanation put forward to defend or justify a fault or offense. Verb: Attempt to lessen the blame attaching to (a fault or offense); seek to defend or justify If CentOS does not meet your needs, Gordon, please use something else. In all cases, please troll elsewhere, if you feel you must troll -- Russ herrold ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] OT: RHEL 6.1 is out
On 05/22/2011 02:57 PM, R P Herrold wrote: > customary trolling by Gordon Messmer -- passive agressive, > implying an unmet obligation The only obligation that I think exists is for everyone to have reasonable expectations of the project. If I have ever implied otherwise, please point me toward it. I intended no such thing. Random people keep expressing their belief that 6.1 will, for reasons they do not state, be ready in short order. There is no evidence that 6.1 will take any less time than any other release. If users had more realistic expectations, there would quite possibly be less discussion regarding release dates. Instead we repeatedly see people expecting a short release and then long threads when that doesn't happen. I'd be thrilled if 6.1 were ready quickly. I just don't expect it. My obligation to the CentOS team is to observe the time that previous releases have required, to understand that there is a great deal of work involved, and to maintain an expectation that future work will probably be a lot like work that's been done before. I think every user has that obligation to the developers. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] OT: RHEL 6.1 is out
I think you're missing the point, if you read between the lines, the complaint I see is that CentOS (Community Enterprise Operating System) is not community based whatsoever. Displaying the self-righteous attitude you are doesn't earn you cookie points or make you look like you're important. What is important is that the CentOS project should have a different acronym, perhaps the Closed Enterprise Operating System? On Sun, May 22, 2011 at 5:57 PM, R P Herrold wrote: > customary trolling by Gordon Messmer -- passive agressive, > implying an unmet obligation > > ex·cuse /ikˈskyo͞os/ > Noun: A reason or explanation put forward to defend or justify > a fault or offense. > Verb: Attempt to lessen the blame attaching to (a fault or > offense); seek to defend or justify > > If CentOS does not meet your needs, Gordon, please use > something else. In all cases, please troll elsewhere, if you > feel you must troll > > -- Russ herrold -- Steven Crothers steven.croth...@gmail.com ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
[CentOS] OT: RHEL 6.1 is out
On Sun, 22 May 2011, Steven Crothers wrote: > I think you're missing the point, if you read between the lines, the > complaint I see is that CentOS (Community Enterprise Operating System) > is not community based whatsoever. I don't mind-read as to what a third party meant so well as you, it seems My intent with cAos (post fedora.us), and with CentOS was to keep available for the FOSS development community at large, the fruit of the distribution integration represented in the 'testers-list' non-public beta group for the former RHL, and the years of work represented there, by people both outside and inside Red Hat. It initially appeared that there would not be a binary form integrated distribution in RPM packaged form. Greg of cAos indeed re-worked a fairly initial installer called 'cinch' It was not at all clear that Red Hat would not threaten litigation to close such efforts down. They had made such threats previously to one of the other co-founders of the CentOS sub-project of cAos, as to a RHL rebuild and respin he had marketed To suggest that CentOS is 'not community based whatsoever' will come as a great surprise to the donors of bug triage effort, of mirroring effort, of wiki authoring, of forum participation, of live-CD 'mixing', and so forth But as hughesjr mentioned just last week, letting random people (seemingly a 'community of random and untrusted persons') feed content that would end up signed in the CentOS project's name, is simply not going to happen. CentOS has never been about that A 'vetting' and reputation system was proposed in some early design documents for fedora.us, but that project lacked the mass to make it work; cAos tried a variation of this, and encountered a problem with its v.2 when a novice packager inadvertently introduced a 'one way' library version bump, impairing the maintainability of that release going forward; The ATrpms v. DAG archive approach on pushing new versions of certain core packages shows two approaches, and the DAG non-invasive approach is clearly the mind-share winner -- We've [the third-party packaging community] (at least, I've been in projects that have) tried variants of 'anyone's code is welcome' distribution adjunct preparation before, and it does not work well CentOS binaries creation process is by and large is a very literal and non-creative effort If people want to start their own rebuild efforts, peace be with them, and good luck. But fostering spin-off's is not what CentOS is about -- and people railing to the heavens about how unfair it is that THEIR false expectations (based on some amorphous vision of how great something COULD be, if only ... ) are not met by the CentOS core team, are simply making noise here -- Russ herrold ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] OT: RHEL 6.1 is out
2011/5/23 R P Herrold
>
> A 'vetting' and reputation system was proposed in some early
> design documents for fedora.us, but that project lacked the
> mass to make it work; cAos tried a variation of this, and
> encountered a problem with its v.2 when a novice packager
> inadvertently introduced a 'one way' library version bump,
> impairing the maintainability of that release going forward;
>
considering how big were the conversations about what should {not} be done,
maybe you're around the critical mass point, and this idea should be
reconsidered for the benefit of both the project {developers} and the user's
community.
--
"The end is important in all things."
-- *Yamamoto Tsunetomo* / *Hagakure* / *Ghost Dog: The Way of the Samurai*
"The beginning is the most important part of the work."
-- *Plato
*
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
