Discuss June 2005

discuss@lists.centos.org

197 participants
362 discussions

Re: Reboots -- LSB 2.1 Core Generic Section 8.5
by Bryan J. Smith <b.j.smith＠ieee.org> 03 Jun '05

03 Jun '05

From: Rodrigo Barbosa <rodrigob(a)suespammers.org> > There is nothing wrong with using X11 at runlevel 3. The only thing > that can't be present is a display manager (KDM, XDM, GDM etc). That's _exactly_ what I'm talking about. Run-level 3 starts xdm. Several Linux distros use 2 for multi-user, 3 for multi-user w/X. Run-level 2 as multi-user w/o networking or w/o NFS was introduced by Red Hat, and any Fedora-based (or RHL-based) distro uses it. > If it is, it is wrong, and doesn't comply with the unix standard (don't > remember exactly which, but I studied it when working for Conectiva). First off, it's not "wrong." Many distros established many different standards well before any standardization efforts. Even Linus admits that he based many things off of SunOS 4.1 (retroactively Solaris 1) and Solaris 2, and Solaris uses 2-3. [ Remember, Solaris was the original GNU platform. ] So in that regard, Debian is actually like Solaris in its use of 2-3, instead of Fedora-based 3-5. Secondly, you are referring to Linux Standards Base (LSB). Specifically, Section 8.5 in the General Section of the latest revision: http://refspecs.freestandards.org/LSB_2.1.0/LSB-Core-generic/LSB-Core-gener… And even this latest version states: "However, it is not required that LSB-compliant run-time environments use these run levels; the distribution-provided install_initd script may map the run levels specified below to whatever distribution-specified run levels are most appropriate." It should also be noted that not even Fedora Core's init scripts are fully LSB compliant, and Debian and SuSE do far better in many areas. LSB even declares RPM as the package standard. But at the same time, one might remember why LSB came into existance -- to try to get standards across largely FC/RHL forks and other RPM distros. As much as it attempts to be platform agnostic, some of its standards are heavily defaulting to RPM ones. > The standard is there. If a distro chooses not to follow it, > you can be very sure it will have acceptance problems. Not nit-pick, but your statement was _exactly_: "Also, run-levels are standarized, and should be the same on all unix-like platforms." Not only is there _no_ standard for System-V platforms, but pretty much LSB says even Linux distros can do what they want. There is _no_ "run-level standard" for "unix-like platforms." > When I have time later today (or tomorrow), I'll give out the > standard I'm mentoning and will give you a proper reference. > Sorry I can't provide it from the top of my head. LSB 2.1 Core Generic Section 8.5. Again, URL: http://refspecs.freestandards.org/LSB_2.1.0/LSB-Core-generic/LSB-Core-gener… Just to summarize, this thread was _not_ to "prove you wrong." It was just a reminder that not only do Linux systems vary wildly, but "UNIX-like" systems do as well and you should be careful with assumptions. ;-> -- Bryan J. Smith mailto:b.j.smith@ieee.org

3 20

Re: Reboots -- Short Answer
by Bryan J. Smith <b.j.smith＠ieee.org> 03 Jun '05

03 Jun '05

From: Prasad Pillarisetti <prasad.pillarisetti(a)gmail.com> > ***Do you perform downtimes just for the purpose of rebooting the systems? > ***Is there a recommended interval Linux system should be rebooted? Okay, here's my short answer: Regardless of OS, you should _always_ reserve dates/times for preventive maintenance on a regular basis. But I agree with most others, unless it is a kernel upgrade or GLibC change, there's no absolutely need to reboot. Not even during preventive maintanence should you feel compelled. -- Bryan J. Smith mailto:b.j.smith@ieee.org

4 6

rhel3 < centos3 updates
by Stephen M. Gava 03 Jun '05

03 Jun '05

Hi all, I've been approached by someone who has an installation of rhel ES 3 (taroon update 2) to see whether I can take over doing security and other updates for them (no current rhn subscription). What I want to know is, with a suitable yum setup can I use a centos3 repository to apply updates to this box? If so, should I source updates from centos 3.5? Does the whole box need to become a centos3 box to do this? They'd really like to disturb the existing box (I agree) as little as possible since it's a stable production server, and mainly just want important security related updates etc. done. Ok, tia for any answers, Stephen. -- Stephen M. Gava <smig(a)users.sourceforge.net>

3 4

Re: Vote For CentOS :) -- at this point, call the FSF ...
by Bryan J. Smith <b.j.smith＠ieee.org> 03 Jun '05

03 Jun '05

From: Les Mikesell <lesmikesell(a)gmail.com> > Can you get the product without being bound by the restrictions? > That is, can one user purchase one and resell copies without the SLA > or with their own? Not with the trademark, that is mis-appropriation. If you want to complain about Red Hat doing this, then you'll want to complain about a number of distributors well before Red Hat who are far worse. > The GPL covers anything that can be considered a derivative work under > copyright law. That certainly includes binaries. Now you're mixing things. The GPL does _not_ address binaries, just what is required -- availability of source, and no restrictions on that source for things that are required for that source to work -- _regardless_ of what is redistributed. It also states that you can't use GPL source with someone non-GPL that requires it to function. Trademarks do not. The software functions the same regardless whether or not you have the trademark. > No one is obligated to provide them, but they cannot prohibit copying > or redistribution as long as the requirement to include or offer source is > met. No one can prohibit restricting the _source_. Again, you are mixing things. I can restrict whatever I want on the binaries, as long as I'm abiding by the other terms of the GPL on the source. That means I don't redistribute anything in any form, unless the source for that is freely available in a way that is unrestricted that the software works the same. SuSE, Dan's Guardian and other distros/software go farther in not even making source packages available. Red Hat at least dumps out _all_ SRPMs, even the overwhelming majority they could point to Fedora for. > No, it covers all derivative works. No, copyright law does. If a copyright holder explicitly states that he/she will not allow trademarks to be bundled with the software, or any installer or other "helper" software, then he/she has the right to do that. But the GPL itself does _not_. > Otherwise it could not prohibit distribution of something that must be > linked to a proprietary dynamic library to function. But trademarks are _not_ required for the software to function exactly the same. That's the difference! Again, you're mixing things. > Typically the FSF has claimed that anything linked into a binary > becomes part of the derivative work. [ The BS watches Les drop off the deep end ;-] > I don't particularly agree with it You don't particularly seem interested in realizing that Red Hat is the _least_ of our problems among commercial companies. And you don't seem to be interested in Trademark Law, and the whole concepts of why it exists. Red Hat's "goodwill" severely crippled their ability to deal with some companies who have no problem with trashing their name. I don't think you realize that Microsoft could have flooded the market with an ultra-crappy "Red Hat(R) Linux" that would have destroyed mindshare overnight. Sun was basically on their way to doing it too, which pissed a lot of us off. Because of Sun and others, Red Hat had to vehemetly defend their trademark to the anal power, and projects like CentOS are stuck with dealing with that as a result. Red Hat is the _only_ major commercial Linux entity that allowed redistribution of its trademark on a scale large enough that it could have been declared "public domain" by the USPTO. Red Hat lives with that now. *NO* other commercial vendor will attempt it in the future either. [ The only exception seems to be SuSE(R), which Novell seems to be turning into a "Fedora-like" trademark. ] > - I'm just reading what it says, and 'no additional restrictions' > seems pretty clear. Take "Red Hat(R)" out of the GPL software and it works _exactly_ the same. If you really have a bug up your ass about this, ask FSF lawyers. ;-> Red Hat can only say they've cleared it with the FSF so many times before people who don't want to believe will _never_ believe (like yourself). The maintainer of Dan's Guardian regularly gets ignorant pukes who complain he is "violating" the GPL by not making the source available on his web site. Same deal, he's got things cleared with the FSF and Stallman, but people want to assume things. The GPL is _not_ about "free" -- it's about "freedom." The "freedom" to modify source code and keep software alive, well after the copyright holders might be dead or don't care. It doesn't give you the right to mis-appropriate trademarks. And unlike patents, trademarks are _not_ required for the software to function legitimately and exactly. > If someone adds their trademark to something that becomes a > derivative work of something carrying the GPL, they should either > not be able to distribute at all, or they have to allow redistribution. If the GPL 3.0 says this, then pretty much not only will _all_ commercial distributions die, but pretty much all support avenues for Linux. I don't think you realize the precedent you're asking for. > Things that aren't embedded in a GPL work would be different, You _can_ "bundle" anything with GPL that it doesn't require. > like artwork that happens to be on the same disk and there is no > requirement to make it easy to separate the 'merely aggregated' > parts, though. What do you mean by "embedded"? RPM is merely just a USTAR 5KB block size (cpio System-V) archive. Even an ISO9660 "Yellow Book" track (data CD) can be considered an "archive." Do you _really_ want to open up that "subjective" door? At this point, ask the FSF. I think you're just going to argue this until you get the answer you like. Good luck with the FSF. -- Bryan J. Smith mailto:b.j.smith@ieee.org

3 2

Re: [CentOS] Vote For CentOS :)
by Bryan J. Smith <b.j.smith＠ieee.org> 03 Jun '05

03 Jun '05

From: Les Mikesell <lesmikesell(a)gmail.com> > Of course. What does an SLA have to do with restricting copying or > redistribution? Because you're paying for services, not a product. > What kind of restriction would be excluded by the GPL if not ones that > restrict copying, installing on additional machines, or redistribution? Public redistribution of the _binaries_ is prohibited because of the trademarks. There is _no_ term in the GPL that mandates that anyone provide you with binaries or otherwise packaged software that is "ready-to-use." This is the GPL. At the same time, as long as the additives are not required for the software to function, Red Hat, SuSE, Novell, Mandrake, etc... are free to bundle whatever art, trademarks, etc... with the software, even the source code. The GPL still only guarantees you the right to _source_ code redistribution without restriction. If you want to play the trademark card, then you're going _outlaw_ pretty much _every_ major commercial company from producing GPL software. And Red Hat is the least of our concerns. ;-> -- Bryan J. Smith mailto:b.j.smith@ieee.org

3 2

Re: Reboots -- everything's a file
by Bryan J. Smith <b.j.smith＠ieee.org> 03 Jun '05

03 Jun '05

From: Rodrigo Barbosa <rodrigob(a)suespammers.org> > Actually, there is another neat trick for rpm based systems. > You see, rpm, prior to removing anything, will rename that to ${NAME}.OLD. > So, libc.so.6 becomes libc.so.6.OLD, and then removed. > As we all know, if that library is currently open by any running process, > it won't be imediately removed (even tho you can't see it with a 'ls'). > The trick is pretty simple: lsof | grep OLD > That, of course, only aplies if you are doing everything using RPM > (yum, redhat-update, apt-get). That's because open file handles work in inode number, not filename. So you can rename things out-of-the-way for existing file handles, while creating a new file that will be opened for any new ones. Devices, processes, etc... in UNIX pretty much have the same logic as files. Which is why I love UNIX -- everything acts like a file, with similar meta-data, etc... -- Bryan J. Smith mailto:b.j.smith@ieee.org

2 1

Reboots
by Prasad Pillarisetti 03 Jun '05

03 Jun '05

***Do you perform downtimes just for the purpose of rebooting the systems? ***Is there a recommended interval Linux system should be rebooted?

9 17

Re: Vote For CentOS :) -- assumptions based on branding ...
by Bryan J. Smith <b.j.smith＠ieee.org> 03 Jun '05

03 Jun '05

From: me(a)prestoncrawford.com > They could not do the latter as far as I understand it. Because > Fedora Core is not the source code (letter for letter) of RHEL. From: "Bryan J. Smith <b.j.smith(a)ieee.org>" > Every RHEL package as a 1:1 version to Fedora, typically Fedora > Core, possibly Fedora Development (as it seems MySQL 4 was). > This is fact. Nothing goes into RHEL without going through > Rawhide/Development first -- if not into Fedora Core. > If you read Red Hat's own development and lists, packages that > have "EL" are typically subsets of the FC version. Most of the > time, it's due to locale -- Red Hat strips out unsupported locale. > In other cases, there might be supersets, like the kernel. In those > rare cases, yes, Red Hat needs to redistribute those source changes. BTW, assumptions such as yours is entirely based on "branding." It's a common thing that people do, and goes to the heart of the trademark matter, as well as gross mis-representation and lack of attention to detail by many. People assume something is "Red Hat(R) Linux" because the "Red Hat(R)" trademark is on it. They assume it is completely different if the trademark is not. It doesn't matter if completely modified packages for an architecture Red Hat never supported, and the packages are even completely SRPM _incompatible_, people believed it was still "Red Hat(R) Linux." Ironically, people assume "Fedora(TM) Core" has nothing to do with "Red Hat(R) Enterprise Linux" -- or is at least completely different in its relationship with RHEL than "Red Hat(R) Linux" was -- merely because of the "branding." In training courses, I've taken people completely through an entire rebuild of core packages, down to version, of Fedora Core and Red Hat Enterprise Linux, as well as SuSE Linux and SuSE Linux Enterprise Server, and it's amazing to see that FC and RHEL differ far less than SL and SLES. If the RPM version is the same for a package of Fedora Core and Red Hat Enterprise Linux, they _are_ the same from the standpoint of GPL source code. Things that are modified have "EL" attached to the version, and in many cases, it's actually a locale subset consideration for RHEL. -- Bryan J. Smith mailto:b.j.smith@ieee.org

1 0

Re: Vote For CentOS :)
by Bryan J. Smith <b.j.smith＠ieee.org> 03 Jun '05

03 Jun '05

From: me(a)prestoncrawford.com > I blame it for a lot already, thanks. :-) In reality, there are good reason for it. E.g., people who had Cobalt systems assumed they were running Red Hat Linux. They were not, just running a heavily modified version. So when people tried to patch and update, they got upset with Red Hat. When the reality was that the distro should have _never_ had Red Hat's name on it. This was just one example. I still hear non-sense from Cobalt users on this. It's funny to see them come full circle on the logic. > This is what I don't get, though? What's the difference between internal > and external? Whatever the lawyers can prove it is. ;-> In a nutshell, there is no "cheat sheet" to respecting IP -- be it copyrighted GPL, trademarked IP or patents. You must document before you distribute. If you are using something like GPL, trademarks, etc... "internally" -- you must guarantee they won't be redistributed to guarantee you won't be distributing something without a license. That's all. No different than any other software. The GPL does not trump copyright or any other IP law, although copyright holders are free to clarify what is and isn't allowed. > I know, I know, it's all about the trademarked logos, names, etc. > But at the end of the day, the source code is still the source code. And we have Red Hat to thank for a lot of it too. > And it's still GPL. So they have to provide (assuming they're distributing > a GPL product) if you ask for it, regardless of whether it's internal to your > company, external, whatever. Whomever you distribute it to is the only one you are required to give the source code to. And you can't put any restrictions on that source code, or anything required for it to work. If I do something within my company, my company isn't going to consider it redistribution. My company is aware that I am using something under circumstances that are not public. So there is no need to abide by the GPL license in how I use it, and no need for a trademark license either. But once I start redistributing that outside the entity I work for, then that's when the legal issues mount. If I am redistributing additional code with the GPL software that modifies it in a way that it works differently, then the original copyright holder, under the granted terms of the GPL, says I have to offer the source code of those modifications under the same terms, without restriction. If I don't, then I am distributing the copyright holder's work without a license, and he is due damages. Same deal with trademark. Once I start redistributing Red Hat's trademark publicly, I am doing so without a license. And they are due damages. Lack of Red Hat's trademark and artwork does not prevent the GPL software from being used the same as with it. That's the difference. Red Hat -- like other distros -- are merely branding their work, into a packaged unit. > Once they've distributed GPL-based software, they have to offer the > source. Period. Yes, and they do. They could claim that Fedora Core SRPMS are everything, except for maybe the kernel and a few other SRPMS. That's what other distros do. Most commercial distros have 2 versions: 1 redistributable, 1 non. The commercial distros then only redistribute the source packages for the redistributable version, and not for the non. Red Hat is one of the very few that do for _both_, so things like CentOS can exist. And it depends on who you redistributed it to. That's why I used the term "publicly" redistributed. Because unlike the MPL1.0 (or is the opposite, and 1.1?) and many GPL-incompatible licenses, the GPL does _not_ require you to return any modifications to the copyright holders _unless_ you redistribute it. The MPL and most off-shoots _do_. GPL gives you the right to do what the heck you want with it -- even merge it with proprietary source code. But if you redistribute that modification outside of our own, internal uses, then that's when it becomes an issue. > They can ask that you not include the trademarks, On a "public" redistribution. What is done internally is not a violation of Trademark Law. I'm not mis-representing some product or service I redistribute as "Red Hat(R)" by merely using it. So there is no redistribution of the trademark without a license. > but that aside, they can't tell you that since it's "internal" it can't be > redistributed. Huh? I think you are confused on what I meant by internal/external. If you use it internally and don't redistribute it, then you are free to install RHEL on as many systems as you want. You can even have a field day and put "Red Hat sucks" all over their trademark. Unless Red Hat can prove that you are misappropriating their trademarks _publicly_ -- their mark in the trade -- then they can't prevent you from installing it on as many systems as you want, and doing what they heck you want. At least on the GPL/LGPL portions. MPL, IBM CPL/IPL, Sun SCSL/etc... will differ. > That's not my understanding of the GPL when it comes to source. GPL source code has nothing to do with this. The GPL source code does not require the Red Hat(R) trademarks to operate. You can freely bundle anything you want with GPL as long as it's not required to work. So for all intents and purposes, there is nothing wrong with bundling GPL source code with Red Hat, SuSE, Mandrake, etc... I can even take the SRPMS, rebuild them, and install them on my systems, with_out_ removing the Red Hat trademark. But if I'm providing services for others -- at cost or not -- with Red Hat's trademark, then it gets a bit more messy. Why? Because Red Hat can claim I'm mis-appropriating their trademark. That's what got Red Hat into trouble before. They let everyone freely use the Red Hat(R) trademark, and it came back to bit them when they tried to get select vendors (Cobalt, Sun, etc...) to stop leaving it on massively modified versions. It was killing the value of their trademark, because people were assumed something was Red Hat Linux when it was nothing of the sort. But that's when Sun barked back and used Trademark Common Law against Red Hat. Hence why Fedora(TM) became a reality. The other aspects to Fedora Core were already established in Red Hat Linux in years prior. > Understood. But their trademark is different from the other > 99.99999% of the distribution, which is Open Source code. The trademark is bundled with the GPL code, but it is not required for it to operate. > I never said anyone had the right to binaries. I'm simply confused > as to how you can put licensing restrictions on source code simply > because it's "internal". That is the issue in question, I believe. There is _no_ "licensing restrictions" because it is "internal." You can use Red Hat trademarks as you see fit as long as you are _not_ proliferating their "mark" in the "trade." The latter is "external"/"public" redistribution. Which is where you can get into legal trouble. > They could not do the latter as far as I understand it. Because > Fedora Core is not the source code (letter for letter) of RHEL. Every RHEL package as a 1:1 version to Fedora, typically Fedora Core, possibly Fedora Development (as it seems MySQL 4 was). This is fact. Nothing goes into RHEL without going through Rawhide/Development first -- if not into Fedora Core. If you read Red Hat's own development and lists, packages that have "EL" are typically subsets of the FC version. Most of the time, it's due to locale -- Red Hat strips out unsupported locale. In other cases, there might be supersets, like the kernel. In those rare cases, yes, Red Hat needs to redistribute those source changes. > So they HAVE to make the RHEL source code available somehow. > Even if it's "pay us for the CDs". Nope. Not at all. As long as the package is the same between Fedora Core and RHEL, no need. One of these days I'm going to finish a book on Red Hat Configuration Management and show an _exact_ lineage of a RHEL release built on Fedora Core. Trust me on this, I've built Fedora Core systems that were _exact_ package equivalents to RHEL -- with the only real exception being the kernel. I typically had to "hold back" on versions from what was "current" in Fedora Core, as well as align up the Fedora Core version to RHEL. But they are 1:1 -- versions are everything. SuSE does the same thing for SuSE Linux v. SuSE Linux Enterprise Server. They don't redistribute a lot of the latter. Xandros is the same on many of its details, etc... > I agree. What I don't agree with is this idea that once the SRPMS > are out there in the wild that somehow Red Hat can put restrictions > on the distribution of the source. There is no redistribution restriction on the source. But there are redistribution on the trademarks if you rebuild from source. > They just can't, as far as I understand the GPL. If you outlaw any bundling with GPL code, then you're going to outlaw 99.999% of the GPL distribution in existance. > Once the source has been made available to SOMEONE, regardless > of whether it's internal, external, whatever, it can be passed on. Yes, without any IP that are not required for the software to function anyway. > That's good that they stick "closer" to the letter. I'm not so sure > they're following it completely, though. They are. Ask the FSF. Too many people put Red Hat under the microscope when there are other distros are doing far, far less "community friendly." It's a double-standard I quite tire of. -- Bryan J. Smith mailto:b.j.smith@ieee.org

1 0

CentOS 4 in Virtual PC for Mac 7.0.1
by T'Krin 02 Jun '05

02 Jun '05

Hey all. Has anyone been able to successfully install CentOS 4 in Virtual PC on the Mac? I have tried numerous times in both gui and text install mode w/ and w/o package customization and minimum and everything install. The install dies just when packages are beginning to be installed or very shortly thereafter. I don't get a full screen of errors to share as they pass by the screen too far and end w/ a message saying the installation has died unexpectedly. Any ideas? Thanks, ~Dan

4 5

← Newer
1
...
30
31
32
33
34
35
36
37
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Discuss June 2005