Re: [Mageia-dev] Mirror layout
On Thu, Dec 16, 2010 at 04:47:07AM -0500, Ernest N. Wilcox Jr. wrote: | ands, or buts, about it. If the Mageia community chooses to opeate as a | criminal organization, I will have nothing to do with it. | I don't agree on most of the above, and i believe the last sentence to be | offensive, but i will not retaliate lest it becomes a flame war. I do not see how that statement is offensive. It is a simple statement of fact. I am not really sure about US laws, but in some country, like mine there are two very distinct law body criminal law, and civil law. So here the term criminal organizations leads to think of things like mafia, large scale drug dealers, murderers etc. And i loathe to be included in the same group. The variety of laws that exist is not the issue, the fact that they do exist is, and this is why I think PLF is a good place for questionable software. It really is. As Romain pointed out the sum of every law in the world might result in an empty environment. (silly real world example) In some countries it is illegal for women to wear a bourka in public In some countries it is illegal for women _not_ to wear a bourka in public. Now how would you please both? besides my personal belief being women should be allowed to wear anything they chose and not be judged for that (and please if what i said is criminal, then call me that) main Mageia distribution. I have no problem with such software being distributed where it is legal. I simply want to make it easy for end users and miror hosts to exclude this software where it is illegal. I will not enter This is the object, but it cannot be achieved 100%. 1) What about if a particulary restrictive country mandates that all communication software shall contain a mean for the government to eavesdrop such communication? shall we move ssl to plf? 2) Not infringing on any patent would require enormous effort, just to list every possible patent, not to speak of analyzing every software to ensure it does not do anything covered by a patent. into the argument that it is not illegal untill the patent holder comes after you. To my way of thinking, that feels very similar to saying that stealing is not a crime untill you get caught. NO First, single patents are not laws Second, iirc your law requires patent holders to prove the validity of their patent in trial. this is the exact opposite of catching a thief. It is the patent holder that has to prove the property was his before claiming damage. L. P.S. I do not like the word 'tainted' for this kind of repository because it just encourages parallels with theft like Ernest is making here. L. -- Luca Berra -- bl...@vodka.it
Re: [Mageia-dev] Mirror layout
On Thu, Dec 16, 2010 at 10:47, Ernest N. Wilcox Jr. ewil...@bex.net wrote: If the Mageia community chooses to ignore the laws of some countries for any reason (even if the community can not be prosecuted), I want nothing to do with it. So you do already. The common subset of laws of all countries in the world is like... almost empty. The global tendency in the past decades is to grow this common subset but it's far from being achieved (and may as well reverse, history showed us). As a matter of fact, Mageia as an organisation fostering free software and innovation through collaboration is likely to ignore/refute/fight, by whatever mean and at whatever relevant scale, laws that would censor/prohibit, as such: - reverse-engineering - cryptography tools - freedom of speech - user privacy - to name just 4 of them. See? There are significant countries in this case. Obey the law is not rule #0 in life (even more if unbalanced). If it were, we would mostly all be slaves, instead of free citizens. A strongly stated position, honestly presented should never cause offense to any one. You cannot please everyone. Law of life. If I havce offended you, I appologize as that was not my intent, but I will not appologize for my beliefs. And you should not. :-) As long as things are said with respect. The variety of laws that exist is not the issue, the fact that they do exist is, and this is why I think PLF is a good place for questionable software. If we choose to provide such software ourselves, then it should be in a tainted listing or repo. Yes. But this is still an imperfect solution as the frontier between what should be in tainted and core will vary according to the territory you are in. So we have to decide on a _reasonable_ frontier, that will not match strictly everyone anyway. I have no problem with such software being distributed where it is legal. I simply want to make it easy for end users and miror hosts to exclude this software where it is illegal. We can't do it totally for three reasons: * law is not universally the same; * law changes, wherever it is. What is legal today may be illegal tomorrow. What was illegal today may be legal tomorrow. * patents may be invalid or have expired (although properly registered). So again, that does not help us but realize that we cannot have a stable layout policy for what comes under core, non-free and tainted. This is a matter of finding a reasonable balance, regarding a given set of laws (likely, European/US laws). Because, otherwise: * as soon as someone claims having a patent anywhere on some methods implemented in some software of core, it should move to tainted (with all consequences). * as soon as a patent expire (or its invalidity is revealed through a court decision), all related tainted packages may move into core or non-free. So indeed, we've got to build this tainted repository and fill it with what we think it should reasonably be with; that means having a policy (list of questions to ask to qualify the package/software to enter tainted or not). I proposed one earlier, that was extreme (that was the goal). We should have a similar one, amended. I will not enter into the argument that it is not illegal untill the patent holder comes after you. To my way of thinking, that feels very similar to saying that stealing is not a crime untill you get caught. Do not map physical/concrete world metaphors to immaterial world. It is not the same. Not the same rules apply. And thinking/law is lagging a lot in this regard, as for any new/young stuff. Cheers, Romain
Re: [Mageia-dev] Mirror layout
Romain d'Alverny a écrit : Le 13 déc. 2010 à 13:50, Philippe DIDIERphilippedid...@laposte.net a écrit : The creator of a software can be prosecuted on the basis of patents even if they were registered later Of course, nothing new here. That does not, however, prove that the motive of the prosecution (hence the prosecution itself) is valid. Because of unprecise/unvalid registration, prior art, fuzzy/broken status of software patents in the EU, or other reason that would have to be demonstrated during a trial. So whatever you do, as soon as you publish/release some hot technology, you have to be aware of the environment; it is a matter of risk management, and of provisioning the means for such a trial (legal counselling, money, communication, disclosure), should it happen (that is, should it be reasonably worth it for someone to initiate). Cheers, Romain An additional problem with patents, which are supposed to protect techniques or methods developped by the patenter, it that they are issued after searches for conflicting patents, but not after verifying the existance of prior art, or even that the technique/method actually works. (At least that is how it works in the U.S./Canada.) Patents are not supposed to cover logic as such. Which becomes problematic with software, which is basically logic fashioned into algorithms, to accomplish some task. Which is why countries such as Canada don't issue patents for software. And why most software patents will not be enforceable, even where they do exist. Note also that even an enforceable software patent only gives the patent holder a civil right to demand compensation for the use of the methods of the patent. A patent holder is not required to demand such compensation, and in many cases, it will not be in their interest to do so. Such as free/open source software where there is no opportunity to collect royalties, and where engaging pursuits against such usage will likely lead to the development of alternate solutions, which lessen the chance of collecting royalties from other users. my 2 cents :) André
Re: [Mageia-dev] Mirror layout
Hoyt Duff a écrit : On Mon, Dec 13, 2010 at 2:44 AM, Ernest N. Wilcox Jr.ewil...@bex.net wrote: People who break laws are criminals - no ifs, ands, or buts, about it. Although I disagree with your conclusions (which I will explain further down), your post does bring up an important point. Mageia would better avoid alienating potential users who might mistakenly associate Mageia with illegitimate activity. Which makes including a set of Mageia repositories specifically for constrained (or tainted) software problematic. Although having such repositories for Mageia on a site like PLF shouldn't cause problems, as there would be a clear distance between them and Mageia. People who break _criminal_ laws like murder and assault are criminals. People who break _civil_ laws like traffic or zoning are not usually considered criminals by the general public. So, not all laws are alike and not all people who break laws can be reasonably labeled as criminals. And in the case of alleged patent vioations, users may be violating the patent holder's civil right to demand compensation for the use of their patent. Where it can become illegal, and only in the civil law sense, is if the alleged violator refuses to pay the compensation demanded, and subsequently a court decides that the patent applies and the compensation demanded is reasonable under the circumstances. (At least, that is how it works in the U.S.) So we are talking about something that is less illegal than jaywalking. (Luckily here in Canada, as in many countries, software patents don't exist.) Note also that for free/open source software, where no possibility of collecting royalties exists, there is generally little interest for a patent holder to restrict Linux users and thus encourage the development of alternate solutions, which could then be adopted by those currently (or potentially in the future) paying royalties to the patent holder. When there is dispute in the larger world community as to whether or not some behavior rises to a criminal nature, one cannot assign it some moral value and enforce it world-wide with any significance. Exactly. If the Mageia community chooses to opeate as a criminal organization, I will have nothing to do with it. Rest assured, no-one is proposing that. You may not be aware, but (as I have recently learned) both Debian and Ubuntu openly distribute packages constrained by software patents, and have many mirror sites in the U.S. - without any apparent problems. ... In other words, if the taint is available to you, and you believe to touch the taint is bad, don't do it. But don't force others to follow your rules. Very true. As Richard Stallman says, free software is about freedom. Let's keep it that way. The PLF approach has been a good one because it allows the specific option of touching the taint or not while accepting the official distro defaults. I think so too. PLF packages also enable many options which are somewhat incompatible with the free/open source philosophy, but not necessarily legally constrained. So there is a role available for PLF that would probably not be as well served by a set of constrained repos on Mageia. - André
Re: [Mageia-dev] Mirror layout
Daniel Kreuter a écrit : On Mon, Dec 13, 2010 at 8:44 AM, Ernest N. Wilcox Jr. ewil...@bex.net mailto:ewil...@bex.net wrote: As I see it, we already have a usable mirror lay-out (posted earlier in this thread). The only real discussion that should remain is whether to include the tainted branch in the official Mageia tree, or to offer it in an alternate repository such as PLF (my earlier suggestion). -- Ernest N. Wilcox Jr. Registered Linux User 247790 ICQ 41060744 Good point. I would suggest that (with permission like you mentioned) we include only such patented software in the main repos like drivers. And everything else like mp3 in the tainted. Especially network-drivers should be included, nothing is worse than looking for the drivers if you have no network (as I always have to do in Debian). Generally drivers have permission to distribute, but not to modify or reverse engineer, and source code is rarely available. Mandriva does include network drivers. But a lot of other commonly used drivers aren't on the free ISOs. I think they should be in all the ISOs. Whatever their licence, with the core packages. So that is one area where Mageia can improve on Mandriva. -- Mit freundlichen Grüßen Greetings Daniel Kreuter Please note that both Ubuntu and Debian carry patented-constrained software. (Debian officially in their non-free repositories.) Both have many mirrors in the U.S. To say that carrying software that may present patent infringement is illegal is grossly simplefying the issue. Only if a court decides that a patent is legitimate, and that a particular software really infringes on that patent, without permission (direct or indirect or implicitly) of the patent holder, does that software contravene the civil rights of the patent holder. Most patents, even if pursued, never reach that stage. Note that the patent holder is always free to not pursue apparent patent violators, thus giving implicit permission. In case of open source projects, they could decide that it is more in their interests to not pursue those who would not be in a position to pay royalties, so as to not discourage the use of their technology, and thus encourage the development of viable alternatives. Which could lead to those currently (or potentially in the future) paying royalties deciding to switch to these patent (and royalty) free alternatives. Copyright infringement is generally much easier to determine, making it both easier to avoid, as well as easier to prove. So a policy of insisting on permission to redistribute for copyrightable material seems appropriate. Such an approach for potentially patent-infringing material is virtually impossible. (Just think of the bogus Linux kernel case a few years back.) (Or Microsoft's patent on certain essential elements of a spreadsheet.) So in my mind we should wait until until approached by the patent holder about a particular package before considering designating the package as patent-constrained. Initially, I don't see us needing a set of repositories for contrained (or tainted) packages. But I do see PLF as a reasonable place for packages we choose not to carry. They have a open invitation to host constrained packages for any distribution, as long as packagers volonteer.) Mageia doesn't necessarily have to be (but could be) involved. I'm sure there will be volonteers, whatever we decide. my 2 cents :) - André
Re: [Mageia-dev] Mirror layout
On Mon, Dec 13, 2010 at 2:44 AM, Ernest N. Wilcox Jr. ewil...@bex.net wrote: People who break laws are criminals - no ifs, ands, or buts, about it. People who break _criminal_ laws like murder and assault are criminals. People who break _civil_ laws like traffic or zoning are not usually considered criminals by the general public. So, not all laws are alike and not all people who break laws can be reasonably labeled as criminals. When there is dispute in the larger world community as to whether or not some behavior rises to a criminal nature, one cannot assign it some moral value and enforce it world-wide with any significance. If the Mageia community chooses to opeate as a criminal organization, I will have nothing to do with it. Based on the popular (in the US, at least) maxim of Ignorance of the law is no excuse, you as end user are responsible for knowing the license of the software and acting accordingly. Just because illegal software is available does not mean you are compelled to use it. If you install software which is permitted in one country but not in yours, you would be the criminal. Legally and morally, you cannot pass on the responsibility of obeying any law to someone else. You alone have the responsibility for obeying your laws. In other words, if the taint is available to you, and you believe to touch the taint is bad, don't do it. But don't force others to follow your rules. The PLF approach has been a good one because it allows the specific option of touching the taint or not while accepting the official distro defaults. -- Hoyt
Re: [Mageia-dev] Mirror layout
2010/12/13 Hoyt Duff hoytd...@gmail.com: In other words, if the taint is available to you, and you believe to touch the taint is bad, don't do it. But don't force others to follow your rules. Yes, this applies to users and mirror maintainers in these environment. This discussion is about exactyl this decision and how Mageia can make it possible or impossible, hard or easy, for the mirror maintainers and the users in question. I don't think this discussion is about how good or bad legal restraints on software are, or about how some countries enforce or not enforce the laws they have. The PLF approach has been a good one because it allows the specific option of touching the taint or not while accepting the official distro defaults. Exactly. It offers an easy way for the mirror maintainers and the users to decide, whatever related circumstances you are living in and whatever your position is on this issue. Why not use it? -- wobo
Re: [Mageia-dev] Mirror layout
On Sun, Dec 12, 2010 at 12:36:05AM -0500, andre999 wrote: Michael scherer a écrit : On Sat, Dec 11, 2010 at 08:16:33AM -0500, andre999 wrote: Not to mention that a ratio of 2 mirrors in the USA out of a total of 25 seems rather odd, for something that admins do not care. 2 of 25 PLF mirrors in the U.S. Technically, 1, since the other is down ( and should be removed from the list ). So a ratio of 4%. Unless you are going to analyse what is down for the other distros, you should say 2 ± 1, that is 4 to 12% Ok, when I say down, I should say the domain no longer exist. It is just not registered. Not down and it will be up later, but down someone didn't bother to pay the domain. Obviously, I should not assume that people check facts before telling me my numbers are wrong. And since other distributions have various systems to detect this ( mandriva have one, fedora have one, opensuse too ), there is no need to touch to the number. PLF do not have any checking tasks, so the mirror was not seen as wrong. There is 1 working mirror and the svn changelog show that this number is quite stable enough. And I would have removed the incorrect one, if I didn't consider this as a abuse of my root privilege on zarb.org. Or 9%. Depending on how you want to fudge the figures. There is no estimate or fudging involved, we have exact number of mirrors, I gave the url for each distributions. But maybe it is because they (in policy at least) exclude non-free software ? So does debian. And just how rigorously do they apply a no patent-constrained software policy ? A quick research could have answered to this question : http://fedoraproject.org/wiki/Software_Patents They used to remove mp3 support from source code : http://www.csparks.com/redhatUnhoarked/index.xhtml But that was 5 years ago. Nowadays, I do not think they still do it as icecast for example is not modified ( despites supporting mp3 format but maybe because there is no trace of codecs, it is ok ). Haven't I heard somewhere that Fedora (and RedHat) are based in the U.S. ? So wouldn't it be natural to expect that it would have a higher proportion of sites there ? Debian too is based in the US ( managed since 1996 by SPI, based in NYC ). So does Novell ( created in Utah, headquarters in Massachusetts ). And I didn't count other country such as Japan, where patents on software are permitted ( http://en.swpat.org/wiki/Japan ), and where the count of PLF mirrors vs Fedora mirrors is 0 to 8. 0 ± 1 gives 0 to 12%. Same ballpark. Also, recruiting Fedora mirrors could be driven by the commercial interests of RedHat. could is a supposition, and I think you should give facts, not suppositions. For the mirror, there is 2 private RD labs ( KDDI, RIKEN ), 2 university ( Yamagata, JAIST ), and the rest are network related ( iij.ad.jp, wide.ad.jp, dti.ad.jp, ftp.ne.jp see http://en.wikipedia.org/wiki/.jp for the meaning of the various second level domain ). So I doubt that commercial interest of the main sponsor have something to do, since the profile is quite similar to the usual one of most mirrors ( ie, people with lots of bandwidth, servers, and interest into helping free software ). More ever, the fact that this is hosted by some private and rather anonymous company is also a important point. Ie, no .edu or big telco ever contacted PLF to host a mirror, while in France and another country, PLF have both. Considering that PLF is based on Mandriva, and Mandriva is based in France, wouldn't it be natural to expect PLF to be better represented there ? I think you missed the point. Let me explain : There is no USA university, nor USA telecom company that contacted PLF. On the other hand, in other part of the world, PLF is mainly hosted by telecom company ( like Zoomnet and Bentel, for example ) and by universities ( Porto, Taiwan, Bahcesehir among others ). Also, there are only about 400 packages for i586 in PLF mirrors. Since most are duplicated, I wonder how many distinct packages there are ? Somehow doubt that an unlicenced copy of quotes from the Simpsons (one of the 2 plf packages that I didn't find also in Mandriva main) is going to be a big attraction. You should look a little bit more closely. For example, libdvdcss2 is plf only. So does various emulator, lame ( and related like darkice ), gstreamer-bad, etc. There is amule, and similar software. More than 2. Of the twenty or so PLF packages that I found looking through available packages with Mandriva and PLF repositories enabled, only 2 did not also have the same version in Mandriva. (All Mandriva main, in this sample.) That is about 10% not in Mandriva. So for arguments sake let's say 20% are not in Mandriva. That makes only about 80 packages only in PLF. Impressive, isn't it ? You said on https://mageia.org/pipermail/mageia-dev/20101201/001576.html that you have decades of programming experience. So I assume
Re: [Mageia-dev] Mirror layout
Michael scherer a écrit : On Sun, Dec 12, 2010 at 12:36:05AM -0500, andre999 wrote: Michael scherer a écrit : On Sat, Dec 11, 2010 at 08:16:33AM -0500, andre999 wrote: Not to mention that a ratio of 2 mirrors in the USA out of a total of 25 seems rather odd, for something that admins do not care. 2 of 25 PLF mirrors in the U.S. Technically, 1, since the other is down ( and should be removed from the list ). So a ratio of 4%. Unless you are going to analyse what is down for the other distros, you should say 2 ± 1, that is 4 to 12% Ok, when I say down, I should say the domain no longer exist. It is just not registered. Not down and it will be up later, but down someone didn't bother to pay the domain. Obviously, I should not assume that people check facts before telling me my numbers are wrong. Right, we should have both said discontinued. Did you understand my point about verifying others distro's mirrors ? My point about comparing the numbers still stands. Unless you've seen anyone with 2,5 mirrors, for example. And my comparisons of numbers don't take into account other factors, which would obviously have at least some effect. What I'm saying, essentially, is that your numbers in no way support your hypothesis that carrying patented software significantly reduces the availability of mirrors. In some cases, your numbers even suggest the contrary. (If you don't consider other factors.) And since other distributions have various systems to detect this ( mandriva have one, fedora have one, opensuse too ), there is no need to touch to the number. PLF do not have any checking tasks, so the mirror was not seen as wrong. ... And I would have removed the incorrect one, if I didn't consider this as a abuse of my root privilege on zarb.org. BTW, you could have added a comment to the page. I'm sure it would have been appreciated. Or 9%. Depending on how you want to fudge the figures. There is no estimate or fudging involved, we have exact number of mirrors, I gave the url for each distributions. It's your methods of comparison that I'm questioning, not the raw figures. Have you ever seen statistics that say something like on the average, each family has 2,2 children ? And have you ever seen a real 0,2 child ? Or realize that some families will have 1 or 4 or more children, and not just 2 or 3 ? Hopefully you understand this point. But maybe it is because they (in policy at least) exclude non-free software ? So does debian. Current Debian documentation says that they have repositories called main, contrib, and non-free. (Verified on a current Debian mirror.) Just what do they put in non-free ? Their documentation says software without a recognized open source licence or subject to patent claims. And just how rigorously do they apply a no patent-constrained software policy ? A quick research could have answered to this question : http://fedoraproject.org/wiki/Software_Patents They used to remove mp3 support from source code : http://www.csparks.com/redhatUnhoarked/index.xhtml But that was 5 years ago. Nowadays, I do not think they still do it as icecast for example is not modified ( despites supporting mp3 format but maybe because there is no trace of codecs, it is ok ). So apparently not that rigorously, after all. Haven't I heard somewhere that Fedora (and RedHat) are based in the U.S. ? So wouldn't it be natural to expect that it would have a higher proportion of sites there ? Debian too is based in the US ( managed since 1996 by SPI, based in NYC ). Interesting. A distro which accepts patent-constrained software (in their non-free repositories) is now based in the USA. And you said that 13% of their mirrors were in the USA ? ... And I didn't count other country such as Japan, where patents on software are permitted ( http://en.swpat.org/wiki/Japan ), and where the count of PLF mirrors vs Fedora mirrors is 0 to 8. 0 ± 1 gives 0 to 12%. Same ballpark. Also, recruiting Fedora mirrors could be driven by the commercial interests of RedHat. could is a supposition, and I think you should give facts, not suppositions. Just as your side of the argument is a supposition. Which is exactly my point. Your facts don't give convincing support of your supposition. As far as this supposition goes, if Fedora and/or RedHat (a well-known entity in free software) were to approach potential mirrors in Japan, but PLF (almost unknown) did not, just who do you think is more likely to attract mirror hosts ? BTW, you might also have mentioned that there are only 2 Mandriva mirrors in Japan. (The first 2 you mention below.) For the mirror, there is 2 private RD labs ( KDDI, RIKEN ), 2 university ( Yamagata, JAIST ), and the rest are network related ( iij.ad.jp, wide.ad.jp, dti.ad.jp, ftp.ne.jp see http://en.wikipedia.org/wiki/.jp for the meaning of the various second level domain ). So I doubt that commercial interest of the main
Re: [Mageia-dev] Mirror layout
On Fri, Dec 10, 2010 at 03:15:40PM -0500, andre999 wrote: And how does that translate for free software ? In the U.S., software patent holders have avoided attacking targets without a lot of financial resources. Well, what if we end having enough ressources in the futur ? The only Linux-associated target I recall is Novell. And TomTom ( http://yro.slashdot.org/story/09/02/25/232212/Has-Microsofts-Patent-War-Against-Linux-Begun ) And a patent deal was done with Amazon ( http://news.slashdot.org/story/10/02/23/1231255/Microsoft-Amazon-Ink-Kindle-and-Linux-Patent-Deal ). And I am sure that with more than 3 minutes research, I can find plenty of example. Mpeg patents are pursued, but the several PLF mirrors in the U.S., with openly indicated patented packages, are ignored. Many PLF mirrors ? I see only 2 of them, and one of them is out ( non existant domain, bigsearcher.com ) http://plf.zarb.org/mirrors.php So basically many PLF mirrors = 1 ? Not to mention that a ratio of 2 mirrors in the USA out of a total of 25 seems rather odd, for something that admins do not care. -- Michael Scherer
Re: [Mageia-dev] Mirror layout
On Fri, Dec 10, 2010 at 02:26:32PM -0500, andre999 wrote: Romain d'Alverny a écrit : - for packaging/shipping the distribution Evidently easier to package. (One less consideration.) As well, the problem doesn't exist in France, so Mageia itself won't be a target. This is a over simplification. PLF is not only for patented softwares, but also for softwares that have others issues ( DMCA, copyright claim, etc ). So from a packaging point of view, we would still have a separate repository, so the consideration would likely still exist. - for using it. It doesn't seem that any individual user has been pursued for using unauthorised patent-affected software. So using patent-affected software is a non-issue for users. (Unless they choose to avoid such software, of course.) We should not only take care of individual users, companies can also use a linux distribution. See how debian is used in many embedded product, or Fedora for that matter. So no, this is not a non-issue for users, because there is more than individual users in the users group. -- Michael Scherer
Re: [Mageia-dev] Mirror layout
Michael scherer a écrit : On Fri, Dec 10, 2010 at 02:26:32PM -0500, andre999 wrote: Romain d'Alverny a écrit : - for packaging/shipping the distribution Evidently easier to package. (One less consideration.) As well, the problem doesn't exist in France, so Mageia itself won't be a target. This is a over simplification. PLF is not only for patented softwares, but also for softwares that have others issues ( DMCA, copyright claim, etc ). So from a packaging point of view, we would still have a separate repository, so the consideration would likely still exist. As for copyrighted material, I think we should only distribute material that has a licence permitting redistribution, or for which we have special permission to redistribute. As for other legally constrained packages, PLF is a reasonable solution. But I don't see the utility of being worried about patent-constrained software at this point, since it hasn't, to the best of my knowledge, impacted mirrors or end-users. BTW, industry publications here in Canada have a lot of articles about legal issues affecting software, and often discuss the situation in the U.S. On which I base much of my opinions. - for using it. It doesn't seem that any individual user has been pursued for using unauthorised patent-affected software. So using patent-affected software is a non-issue for users. (Unless they choose to avoid such software, of course.) We should not only take care of individual users, companies can also use a linux distribution. See how debian is used in many embedded product, or Fedora for that matter. So no, this is not a non-issue for users, because there is more than individual users in the users group. Good. Remove individual, and my statement still stands. Note that there is a difference between - using or distributing software which may use patented technology, and - developing or selling such software for a profit. The former is little affected by patent claims in the U.S., but the latter has resulted in some spectacular cases. Like the recent case where a Texas court awarded a smalll canadian company over 200 million dollars for patent infringement claimed in Microsoft word, which Microsoft is appealing. Note that Ms-word is not exactly free. (It is a U.S. patent : Canada doesn't issue software patents.) Also note that end users, be they individuals or companies, have a choice of what software they install and use. In addition to what they integrate into their products to sell. So they will have the opportunity to react appropriately should problems arise. As will Mageia. - André
Re: [Mageia-dev] Mirror layout
On Sat, Dec 11, 2010 at 08:16:33AM -0500, andre999 wrote: Not to mention that a ratio of 2 mirrors in the USA out of a total of 25 seems rather odd, for something that admins do not care. 2 of 25 PLF mirrors in the U.S. Technically, 1, since the other is down ( and should be removed from the list ). So a ratio of 4%. 16 of 133 Mandriva mirrors in the U.S. A ratio of 12%. Same as debian, based 49 mirrors in the US out of 358. ( ie 13% ), based on http://www.debian.org/mirror/list Ubuntu has 12 out of 62 for isos, ie 16%. http://www.ubuntu.com/getubuntu/downloadmirrors And for packages, that 51 out of 367, ie 13% https://launchpad.net/ubuntu/+archivemirrors Opensuse has 22 out of 155, aka 14%. ( http://mirrors.opensuse.org/ ). Fedora has 59 us mirrors out of 259, ie 22%. ( http://mirrors.fedoraproject.org/publiclist/ ). So basically, between Fedora, with a strict policy, and PLF, the difference is 18%. And I didn't count other country such as Japan, where patents on software are permitted ( http://en.swpat.org/wiki/Japan ), and where the count of PLF mirrors vs Fedora mirrors is 0 to 8. More ever, the fact that this is hosted by some private and rather anonymous company is also a important point. Ie, no .edu or big telco ever contacted PLF to host a mirror, while in France and another country, PLF have both. Also, there are only about 400 packages for i586 in PLF mirrors. Since most are duplicated, I wonder how many distinct packages there are ? Somehow doubt that an unlicenced copy of quotes from the Simpsons (one of the 2 plf packages that I didn't find also in Mandriva main) is going to be a big attraction. You should look a little bit more closely. For example, libdvdcss2 is plf only. So does various emulator, lame ( and related like darkice ), gstreamer-bad, etc. There is amule, and similar software. More than 2. I am sure that using a small shell script, the exact number could be found, if someone want to invest the time. -- Michael Scherer
Re: [Mageia-dev] Mirror layout, round two
Luca Berra a écrit : On Sun, Dec 05, 2010 at 09:46:21PM +0100, Wolfgang Bornath wrote: Thinking of PLF, MLF comes to mind but that abbreviation has another well-known meaning. :) pisc (patented in some countries) is another what i particulary like about the plf name is the liberation word, which has a clear positive meaning. every other suggestions in this thread has a negative connotation 'tainted', 'swamp', etc. Wording should not convey the meaning that it is illegal, thus _wrong_ to use this kind of software. Wording should convey the meaning that using this kind of software is a way to express personal freedom without really committing any _wrong_. I would really hate if a free software distribution fell in the trap of supporting the idea that software patents are _right_. L. I agree. Although (as explained in another post), I think that we should avoid considering separating any particular patent-constrained package until we are approached by the patent holder. Simply because since we are non-profit, all attempting to collect royalties from us will do is cause us to not use their patent technology - and push us to use some alternative - which could tend to lead to others using the same alternative - and thus lead to less usage by those who do pay royalties. For packages we do classify as constrained, we should probably use PLF. It is part of their policy to host packages for any distro, as long as contributors are willing to package them. And as you say, their name doesn't have negative connotations. (If we do end up with a constrained set of repos on Mageia, what about the name Liberation ? ) - André
Re: [Mageia-dev] Mirror layout
2010/12/11 Michael scherer m...@zarb.org: You should look a little bit more closely. For example, libdvdcss2 is plf only. So does various emulator, lame ( and related like darkice ), gstreamer-bad, etc. There is amule, and similar software. More than 2. I am sure that using a small shell script, the exact number could be found, if someone want to invest the time. And there are packages which are in the normal repos as well but PLF offers them with a wider functionality. As already mentioned Mplayer and VLC. Anyway, whatever you decide, it will be a non-ideal decision because the circumstances are very different in many countries, As this is the case it all comes down to - either have everything together and let the mirror maintainers and users sort it out (if needed) - or have one (1) separate repo with everything not clearly without dubious contents, making it easy for the mirrors to exclude and for the users to set or not to set. I am not sure I understand what was the problem with the Mandriva solution. This model is/was easy for users and mirrors likewise (according to my experiences with users and mirrors over the last years). Certainly I can't tell for the developper side. -- wobo
Re: [Mageia-dev] Mirror layout
Michael scherer a écrit : On Sat, Dec 11, 2010 at 08:16:33AM -0500, andre999 wrote: Not to mention that a ratio of 2 mirrors in the USA out of a total of 25 seems rather odd, for something that admins do not care. 2 of 25 PLF mirrors in the U.S. Technically, 1, since the other is down ( and should be removed from the list ). So a ratio of 4%. Unless you are going to analyse what is down for the other distros, you should say 2 ± 1, that is 4 to 12% 16 of 133 Mandriva mirrors in the U.S. A ratio of 12%. Again, 16 ± 1, or 11 to 13% Or essentially the same. Same as debian, based 49 mirrors in the US out of 358. ( ie 13% ), based on http://www.debian.org/mirror/list Ditto. Ubuntu has 12 out of 62 for isos, ie 16%. http://www.ubuntu.com/getubuntu/downloadmirrors So a distro that includes patent-constrained software has a greater proportion in the patent-menaced U.S. ? Interesting. And for packages, that 51 out of 367, ie 13% https://launchpad.net/ubuntu/+archivemirrors Same ballpark as PLF. Opensuse has 22 out of 155, aka 14%. ( http://mirrors.opensuse.org/ ). Ditto Fedora has 59 us mirrors out of 259, ie 22%. ( http://mirrors.fedoraproject.org/publiclist/ ). So basically, between Fedora, with a strict policy, and PLF, the difference is 18%. Or 9%. Depending on how you want to fudge the figures. But maybe it is because they (in policy at least) exclude non-free software ? And just how rigorously do they apply a no patent-constrained software policy ? Haven't I heard somewhere that Fedora (and RedHat) are based in the U.S. ? So wouldn't it be natural to expect that it would have a higher proportion of sites there ? And I didn't count other country such as Japan, where patents on software are permitted ( http://en.swpat.org/wiki/Japan ), and where the count of PLF mirrors vs Fedora mirrors is 0 to 8. 0 ± 1 gives 0 to 12%. Same ballpark. Also, recruiting Fedora mirrors could be driven by the commercial interests of RedHat. More ever, the fact that this is hosted by some private and rather anonymous company is also a important point. Ie, no .edu or big telco ever contacted PLF to host a mirror, while in France and another country, PLF have both. Considering that PLF is based on Mandriva, and Mandriva is based in France, wouldn't it be natural to expect PLF to be better represented there ? Also, there are only about 400 packages for i586 in PLF mirrors. Since most are duplicated, I wonder how many distinct packages there are ? Somehow doubt that an unlicenced copy of quotes from the Simpsons (one of the 2 plf packages that I didn't find also in Mandriva main) is going to be a big attraction. You should look a little bit more closely. For example, libdvdcss2 is plf only. So does various emulator, lame ( and related like darkice ), gstreamer-bad, etc. There is amule, and similar software. More than 2. Of the twenty or so PLF packages that I found looking through available packages with Mandriva and PLF repositories enabled, only 2 did not also have the same version in Mandriva. (All Mandriva main, in this sample.) That is about 10% not in Mandriva. So for arguments sake let's say 20% are not in Mandriva. That makes only about 80 packages only in PLF. Impressive, isn't it ? BTW, gstreamer*plugins-bad is in Mandriva contrib. I'm not trying to say that PLF does not serve a useful role, particularly for applications which would be better to avoid putting in a distro, for legal or other contraints. Offhand, libdvdcss* seems to be a good example. Just that I don't think that patent considerations should be - except in rare circonstances - a serious enough contraint to consider excluding a package from regular repositories. I am sure that using a small shell script, the exact number could be found, if someone want to invest the time. Actually I was only talking numbers to indicate that the numbers don't prove your point, even if we were to accept that they were a valid means of determining the effect of the patent issue on potential mirror sites. There are too many other factors for these numbers to be meaningful. For example, large multi-mirror sites may not be very interested in mirroring small sites, with a relatively small demand. And sites at universities could be driven by the interests of a few students, who could reasonably be less aware of smaller, more obscure sites. (Mandriva was dropped from a local canadian university site last year, probably because the supporting students moved on.) And don't forget, we don't need many sites worldwide to serve the small number of applications on PLF. Another 2 cents :) - André
Re: [Mageia-dev] Mirror layout
Ernest N. Wilcox Jr. a écrit : Perhaps we should follow the approach other distributions seem to use. Official Mageia repos: Core: The core Mageia distribution (IMHO, should contain only a very minimal instalation (No GUI or Productivity software). Desktop: GUI and Productivity software. Server: The various server software that would not normally be used on a Desktop system. Community: Community suppoted GPL software Non-Official Mageis repos (optional): Non-GPL: Software that is not GPL Licensed Assume that this means software without ANY free licence. (Such as bsd, mpl, etc.) If drivers are included in these repos, and they are optional, many systems will not function properly with the required repos. Only Fedora (of the distros mentioned below) has a policy to exclude non-free software. The others have a separate set of repos for non-free. Extra: Software that can not be included in the above categories Is this for software that is legally constrained in some countries ? Where would development software (CLI and GUI) go ? This approach would be advantageous if mirrors were to carry only some of the repo groups suggested. If official mirrors must carry all the official repos, it's not clear the advantage of separating core/desktop/server repos, unless they are to have different levels of support. For non-official mirrors, a server-only mirror would be a lot smaller. Using your definitions : Mandriva main = Core + Desktop + Server + many development packages Mandriva contrib = community Mandriva non-free = most Non-GPL (some of which is in main) Some legally contrained packages are excluded. Supposedly in PLF. Debian uses the same names main, contrib, non-free, with explicit policy close to Mandriva practices. In the same policy page, they say that patent-contrained software goes into non-free, then further down they say that it can be excluded. http://www.debian.org/doc/debian-policy/ch-archive.html OpenSuse has supported oss (free) and non-oss (non-free); as well as unsupported contrib. Corresponding to the repos of Mandriva. Ubuntu has 4 repo groups, essentially free and non-free, each divided into supported and unsupported. They seem to permit contrained packages. Fedora package acceptance policy is explicitly dictated by RedHat. Includes only free packages (thus excluding redistributable drivers), plus excludes legally constrained packages. Fedora is the only distro reviewed here which does not accept non-free packages. However, given that RedHat sells their versions of Linux (with support), one could question the motivation of the Fedora policy. Since I am not knowlegable about running an FTP mirror, I do not know whether it is best to put these listings under a single tree, or to split them into two trees, but if we split them, perhaps we could approach PLF to host the Non-officvial repos? Note that FTP would only be used for end-users downloading FROM mirrors. Mageia will require official mirrors to synchronize at regular intervals using rsync + certain options. For mirrors which want to include everything, it is obviously simpler to have a single tree, requiring a single simple rsync line. However a second simple rsync line isn't that complicated. For mirrors which wish to exclude the optional parts, the choice is between one simple rsync line (if 2 trees), or a more complex line adding an option to exclude each unwanted part of the of the source tree. (With the complication that an error in specifying this option could cause problems with the mirroring. Using PLF for mirroring constrained packages sounds like a very good idea. Their site says that they are open to hosting such packages for all distros, as long as there are volonteers to support the packages. And since Mageia is (at least initially) compatible with Mandriva, their page easyurpmi could be easily modified to set up mirror sources for Mageia users. (Call our version easymageia ?) Using PLF for contrained packages offers a plus for mirror sites willing to host such packages. They need only mirror one PLF tree for all distros - be it Mandriva, Unity, or Mageia. Interestingly, in a search for all packages containing codec or mp (for mpeg) in the name, I found only 2 packages in PLF that weren't already in Mandriva : one being quotations from the Simpsons, which the package said was there for copyright reasons. All the other PLF packages I found in the above searches were in Mandriva main. Many if not all of which were in PLF for patent reasons, according to the package description. Which brings up a difference of PLF packages : the PLF description usually ends with a line specifying why they are there. (At least packages destined for Mandriva users.) So if a user wants to avoid patent constrained packages, they are identified as such in PLF - but not in Mandriva. This is only a suggestion (and we may have already moved past this point), but perhaps this
Re: [Mageia-dev] Mirror layout
Just some smallish notes regarding other distros.. On 10.12.2010 12:22, andre999 wrote: Debian uses the same names main, contrib, non-free, with explicit policy close to Mandriva practices. In the same policy page, they say that patent-contrained software goes into non-free, then further down they say that it can be excluded. http://www.debian.org/doc/debian-policy/ch-archive.html Interesting.. this doesn't seem to correspond to reality (they have e.g. ffmpeg with patent-constrained codecs enabled). [...] Fedora package acceptance policy is explicitly dictated by RedHat. Includes only free packages (thus excluding redistributable drivers), plus excludes legally constrained packages. Fedora is the only distro reviewed here which does not accept non-free packages. They allow non-free firmware: http://fedoraproject.org/wiki/Packaging/LicensingGuidelines#Binary_Firmware However, given that RedHat sells their versions of Linux (with support), one could question the motivation of the Fedora policy. -- Anssi Hannula
Re: [Mageia-dev] Mirror layout
On Fri, Dec 10, 2010 at 17:04, Wolfgang Bornath molc...@googlemail.com wrote: 2010/12/10 Romain d'Alverny rdalve...@gmail.com: Let's try this: what if we consider, at first, that software patents were a non-issue? (that is, we just consider they are all invalid as such). From a mirror maintainer's view: If I am in a country like France (not acknowledging SP) I can ignore safely the issue If I am in a country which does acknowledge SP I will have to decide for myself if I want to take that risk. THis may be an easy decision in some countries but in others (like the USA) it may be a hard decision, also depending on who I am (a private person or a large institution/organisation). From the users's view: Living in a country without SP (or not caring about the issue) it is the easiest way. I can use automagical setup of media and need not worry about an extra repo to set before I can watch my DVDs :) Again in a country like USA I have to decide for myself - this would be a nightmare if the whatever-dubious software is included in the normal repos. I would have to find out by myself which is ok to use and which is not. Ok, but you still take into account SP in your answer. :-p (we would have come to that, but the idea was to think about it from a naïve, software-patent-free perspective). So... let's take the European Union case, namely, no SP (see next §). We just don't have to split the media. Easier for everyone in this territory. Well, thing is, even though there is a European policy about that... it's been unbalanced and challenged for years. In the end, it's just a mess and law is lagging behind; if not just broken. So it's going to be, anyway, a battle of positions before something clear and definitive comes out. Still. What if? Where is it an issue to distribute/mirror then? Only where: - SP do exist by law; - and specific SP are registered on pieces of software distributed/mirrored; - and these SP are not invalidated (de facto or obviously) by some prior art; - and those SP are likely to be enforced (that is, practically, there is a minimum incentive for a patent holder to raise his hand; or, that it is worth it to enforce it). Coming back to my previous post, maybe we should just try something simple and go from that. Shall we take a stance despite SP (for they are just not relevant), worldwide or more reasonably have a simple, risk-management based attitude to alter our media/mirror policy only if something happens? That would relate somehow to Debian policy in this regard, as misc mentionned in the Why validate software patents ? thread on mageia-dev, Dec. 8th, ~12:58. And that sounds a decent attitude; see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=365390#20 or http://lists.debian.org/debian-project/2005/01/msg00316.html . So why not take it the same way, not have a distinct media and see what happens on notices? Yes, this would raise mirroring issues (that would occur anyway), that we can minify with a policy to manage that globaly; that when an issue is raised: - try to fix it for the whole project, not just for some area, so the weight of the whole community (not only Mageia for that matter) is behind the case, and not only a local chapter; - remove only software that gets a full score through this list (to be updated): * has an identifiable patent registered on it (exact code/method, exact patent description); * has been notified about by the holder (or representative); * whose holder is identifiable; * whose holder does not provide a free use license; * which patent: - has not expired; - is not already invalidated; - has no obvious prior art; - is being actively enforced; * other? - such software or components would be made separately available only (so we still manage that it depends on the territory). So we start with an empty tainted/whatever media. And again, see what happens. That's an option. Romain
Re: [Mageia-dev] Mirror layout
2010/12/10 Romain d'Alverny rdalve...@gmail.com: Ok, but you still take into account SP in your answer. :-p (we would have come to that, but the idea was to think about it from a naïve, software-patent-free perspective). If there were no software patents anywhere what would be the issue of this discussion? IMHO it makes no sense to discuss something which does not exist If Mageia were a project fro French users only we would no have this discussion. But as it is a worldwide project the probelm exists and pretending it does not makes no sense, not even from a theoretical POV. because the theoretical POV is No SP, no discussion. Ok, anyway. I see the strategy in your proposition but: 1. We know from the start that there ARE packages with software which is patented in some countries. So, the let's start empty and see what comes up is already done with. 2. In some countries mirror maintainers can not wait until somebody raises his hand, there are lawyers who write nice cease and desist letters, attached is a bill you have to pay. In Germany this is called Kostenpflichtige Abmahnung and has grown to a habit of some lawyers. Meaning: you can't wait and see what happens, you have to make sure that it does not happen from the start. I mean, opinions about software patents set aside for a minute, software patents are protected by official law in those countries. You can not break the law on the basis of let's see what happens. -- wobo
Re: [Mageia-dev] Mirror layout
On Fri, Dec 10, 2010 at 19:14, Wolfgang Bornath molc...@googlemail.com wrote: 2010/12/10 Romain d'Alverny rdalve...@gmail.com: Ok, but you still take into account SP in your answer. :-p (we would have come to that, but the idea was to think about it from a naïve, software-patent-free perspective). If there were no software patents anywhere what would be the issue of this discussion? IMHO it makes no sense to discuss something which does not exist It does. Because it helps looking at a problem from a totally different perspective, build from that, and see the missing/conflicting pieces when you look back at the full problem (or as you used to look at it before). Which conflicting/missing pieces may not be the ones one thought they were. I see the strategy in your proposition but: 1. We know from the start that there ARE packages with software which is patented in some countries. So, the let's start empty and see what comes up is already done with. Are there issues with it? (looking at my previous check-list, maybe to improve). If so, yes, let's fill this up. If not, let's leave it alone in the core. I mean, what difference does it make with PLF repositories that are already mirrored? what differences does it make with Debian stuff that is already mirrored? do they get cease desist? do we hear about this? 2. In some countries mirror maintainers can not wait until somebody raises his hand, there are lawyers who write nice cease and desist letters, attached is a bill you have to pay. In Germany this is called Kostenpflichtige Abmahnung and has grown to a habit of some lawyers. Then in these cases, two options: - just do not mirror; and people use mirrors on the borders; - Mageia (or some related entity) provides legal services about this (taking responsibility for the hosting or other). Why just do not mirror? Because, taking the strict statu-quo point of view regarding the software patent thing, that is just follow the most restrictive set of rules, we won't be able to cope with just medias to separate patented software from non-patented sw. It will be a matter of tags, because the situation is different from territory to territory. And there are more than two for that matter. Meaning: you can't wait and see what happens, you have to make sure that it does not happen from the start. We can't be sure at all of anything. That's why that's to take a risk-management attitude, provided what we want to achieve, what stance we want to take. I mean, opinions about software patents set aside for a minute, software patents are protected by official law in those countries. You can not break the law on the basis of let's see what happens. Many do. Not only for software, but for everything. For many reasons, among which can be: the law is broken, the law is becoming obsolete, people do not enforce it, the law should be changed, etc. Well, actually, there are two options: break the law/try it as it is. Or follow it strictly to demonstrate its absurdity. What I propose here is a middle-ground some other projects already take. With the reasonable attitude to manage cases that _are precisely identified_ (so we avoid reports such as this piece of software is likely to be patented; point needed is: is it? or not? how, why, by who, is it valid, is it free, is it enforced, are we noticeable/a target, does it matter given our size? As said before, regarding law on software patents, the situation today is, that's a battlefield anyway. Although the situation in EU should be clear (no SP), it's not (as many other things at the moment too, sadly). That's a proposal. It has shortcomings too of course; what I find interesting in this is that: - it makes Mageia put a few steps into the software patents debate (instead of only trying to cope with an inconsistent, unpracticable set of rules that we mostly even don't find legitimate at the very start); - it may reveal to be less of a burden than we currently think; it may be worse; either case, we can adapt from a situation we will have _experienced_. Now, that's nothing more than a proposal. :-p Romain
Re: [Mageia-dev] Mirror layout
On Fri, 10 Dec 2010, Wolfgang Bornath wrote: 2010/12/10 Romain d'Alverny rdalve...@gmail.com: Ok, but you still take into account SP in your answer. :-p (we would have come to that, but the idea was to think about it from a naïve, software-patent-free perspective). If there were no software patents anywhere what would be the issue of this discussion? IMHO it makes no sense to discuss something which does not exist If Mageia were a project fro French users only we would no have this discussion. But as it is a worldwide project the probelm exists and pretending it does not makes no sense, not even from a theoretical POV. because the theoretical POV is No SP, no discussion. Ok, anyway. I see the strategy in your proposition but: 1. We know from the start that there ARE packages with software which is patented in some countries. So, the let's start empty and see what comes up is already done with. Being patented does not mean that patent is valid and enforceable. 2. In some countries mirror maintainers can not wait until somebody raises his hand, there are lawyers who write nice cease and desist letters, attached is a bill you have to pay. In Germany this is called Kostenpflichtige Abmahnung and has grown to a habit of some lawyers. Meaning: you can't wait and see what happens, you have to make sure that it does not happen from the start. I mean, opinions about software patents set aside for a minute, software patents are protected by official law in those countries. You can not break the law on the basis of let's see what happens. The problem is that we don't know for sure if we violate the law. We should not be too paranoid about this. Microsoft claims that the Linux kernel violates 235 of their patents : http://money.cnn.com/magazines/fortune/fortune_archive/2007/05/28/100033867/index.htm Should we trust them and remove the kernel from the core repository ? I'm wondering how much mirror admins are concerned about patent issues. If we split the packages between core and tainted repositories, how many will filter it ? If only a few will do it, maybe it's not really worth it and we can still have enough mirrors. It seems that Debian has mirrors in many countries, while hosting patented software in its main repository.
Re: [Mageia-dev] Mirror layout
Romain d'Alverny a écrit : On Fri, Dec 10, 2010 at 16:35, Wolfgang Bornathmolc...@googlemail.com wrote: Isn't this what this whole discussion is about? There ARE legal issues with some software users regard as must have. Now, how do you avoid these issues? To summarize, strategies: 1. ignore the issues and see what happens; 2. ignore the less significant ones; 3. get to know each of these and manage case by case 4. other? and factor whenever possible and see what happens, update, repeat. 1. and 2. are more radical, but are some sort of trial-and-error, risk management strategies. Ok... looking at it this way won't lead us further I guess. Let's try this: what if we consider, at first, that software patents were a non-issue? (that is, we just consider they are all invalid as such). How would this change/simplify the problem? Good approach. - for packaging/shipping the distribution Evidently easier to package. (One less consideration.) As well, the problem doesn't exist in France, so Mageia itself won't be a target. As I understand, basically only the editors of software have been pursued in patent-affected countries like the U.S. (And basically only those with lots of money.) - for mirroring it Easier if mirrors don't have to consider OPTIONAL repositories. (But the NUMBER of repositories doesn't matter.) Theoretically it would affect mirrors in countries with patents. Except that in the U.S., one of the most patent-affected countries, there is no shortage of mirrors, many of which carry patented software that is being actively pursued against other parties - but the mirrors themselves are left untouched. Note that having identifiable patent-affected repositories would presumably increase the probability of patent pursuits against a mirror. But the PLF, with openly identified patent-affected packages, has several mirrors in the U.S., none of which has been pursued, to my knowledge. As well, there are countries free of software patents on every continent, in the event that problems arise. So hosting patent-affected software seems to be a non-issue for mirrors. - for using it. It doesn't seem that any individual user has been pursued for using unauthorised patent-affected software. So using patent-affected software is a non-issue for users. (Unless they choose to avoid such software, of course.) (please don't go but there _are_ software patents for now) (But such arguments are so much fun ;) ) Romain - André
Re: [Mageia-dev] Mirror layout
nicolas vigier a écrit : On Fri, 10 Dec 2010, Wolfgang Bornath wrote: 2010/12/10 Romain d'Alvernyrdalve...@gmail.com: Ok, but you still take into account SP in your answer. :-p (we would have come to that, but the idea was to think about it from a naïve, software-patent-free perspective). If there were no software patents anywhere what would be the issue of this discussion? IMHO it makes no sense to discuss something which does not exist If Mageia were a project fro French users only we would no have this discussion. But as it is a worldwide project the probelm exists and pretending it does not makes no sense, not even from a theoretical POV. because the theoretical POV is No SP, no discussion. Ok, anyway. I see the strategy in your proposition but: 1. We know from the start that there ARE packages with software which is patented in some countries. So, the let's start empty and see what comes up is already done with. Being patented does not mean that patent is valid and enforceable. We should remember that patents are a civil right accorded by rules differing from country to country. Many countries don't offer patents on software. Patent holders have to use the courts to enforce these rights, who often deny or limit patent holder's claims. So in addition to any theoretical rights of software patent holders, there is the consideration is it worth the money and effort for the potential gain in royalties ? In that, free software (in both senses) has a considerable advantage compared to other parties who could be considered in infringement of software patents. 2. In some countries mirror maintainers can not wait until somebody raises his hand, there are lawyers who write nice cease and desist letters, attached is a bill you have to pay. In Germany this is called Kostenpflichtige Abmahnung and has grown to a habit of some lawyers. Meaning: you can't wait and see what happens, you have to make sure that it does not happen from the start. cease and desist letters are just warnings. Any attached bill would only have effect if validatated by a court. As I understand, lawyers have the same habit in the U.S. Wouldn't the amounts accorded be based on the supposed benefit that the supposed violator has received ? (At least that is part of the equation in the U.S.) And how does that translate for free software ? In the U.S., software patent holders have avoided attacking targets without a lot of financial resources. The only Linux-associated target I recall is Novell. Mpeg patents are pursued, but the several PLF mirrors in the U.S., with openly indicated patented packages, are ignored. I mean, opinions about software patents set aside for a minute, software patents are protected by official law in those countries. You can not break the law on the basis of let's see what happens. Again, this is not breaking the law, but potentially infringing on a civil right. Which must be validated by the courts. The problem is that we don't know for sure if we violate the law. We should not be too paranoid about this. Microsoft claims that the Linux kernel violates 235 of their patents : http://money.cnn.com/magazines/fortune/fortune_archive/2007/05/28/100033867/index.htm Should we trust them and remove the kernel from the core repository ? Yes indeed. Off to tainted we go :) :) :) I'm wondering how much mirror admins are concerned about patent issues. In the U.S., not much, and with reason. Not even the PLF mirror sites there are pursued. Which is convenient for us in Canada : often the closest mirror is across the border. If we split the packages between core and tainted repositories, how many will filter it ? We all know that packagers don't have enough work. Don't we ? ;) If only a few will do it, maybe it's not really worth it and we can still have enough mirrors. It seems that Debian has mirrors in many countries, while hosting patented software in its main repository. Including the U.S. Interesting that Debian discussions about patent issues seem to focus on what will be accepted in U.S. mirrors. Who have yet to be impacted on patent issues. It seems that the few spectactular cases against rich players in the U.S. has distorted the perception of the legal reality there. - André
Re: [Mageia-dev] Mirror layout : Why validate software patents ?
2010/12/8 andre999 and...@laposte.net: By presenting a special set of repositories for patent-affected software, we could be seen as justifying these patent sharks. In their minds, why else would be accommodate them ? Patented software is a reality in some countries. You can't discuss it away with logical reason or morale arguments. Ok, I think, how many other distros have such repositories. According to comments on the list : none. Oh, really? Some (like Mandriva) do not have such a repository because they do not distribute such software at all, PLF does that for Mandriva. What about Ubuntu? What about Fedora? And what happens if there is a patent pursuit against Mageia or it's mirrors ? Even if we have a separate repository, the package in question might end up being withdrawn. But it seems doubtful that one would want to withdraw all potentially threatened packages. (That would be a big victory for patent sharks.) A patent pursuit will not be aimed against Mageia because Mageia is a french organisation where there are no software patents. But lawsuits could be aimed at those mirror maintainers who are runnning their mirrors in such countries which allow software patents. There are mirrors which are maintained by single private persons (example: me) where the maintainer can not take such a risk. That there haven't been any pusuits yet does not mean they are not possible. As a private person you don't play around with such things (aka breaking existing laws). No report of anyone wanting to have an official mirror, that wanted such repositories. 2 reasons: It is obvious that Mageia has to find a way to supply this sort of software. It is obvious that in countries with software patents such software can not be distributed on the mirrors. The logical consequence of having tainted software within the usual repos would be that there could not be Mageia mirrors in those countries at all. I agree, this could be a possible solution because geographical distances do not mean anything in the internet. To draw a real picture: who would care if there was no Mageia mirror in the USA while there are mirrors all around outside USA (Canada, Mexico, etc.)? This way we would also make a statement against the patent laws of such countries. We do not validate anything by acknowledging the facts. -- wobo
Re: [Mageia-dev] Mirror layout : Why validate software patents ?
2010/12/8 Ahmad Samir ahmadsamir3...@gmail.com: For Fedora, being the most legally-challenged distro around, they don't include any patented software in their official repos at all, not even mp3 playback is possible in a default install. They even don't include any non-free stuff, so no nVidia and ATI proprietary drivers. Fedora users use some 3rd party repos, e.g. RPM Fusion http://rpmfusion.org/ Thx, so it's the same as with Mandriva wrt patented software. What I wanted to say: distributing no patented software at all is not the same as having no extra repository for patented software, so are Mandriva and Fedora seen as justifying patent sharks as andre999 descibed it? -- wobo
Re: [Mageia-dev] Mirror layout : Why validate software patents ?
On Wed, Dec 8, 2010 at 9:51 AM, Wolfgang Bornath molc...@googlemail.comwrote: Oh, really? Some (like Mandriva) do not have such a repository because they do not distribute such software at all, PLF does that for Mandriva. What about Ubuntu? What about Fedora? In Ubuntu you have some patented software in the repos. For example if you try to install Ubuntu 10.10 you get asked if you want to install some 3rd party codecs such as the codec for MP3 during the install process!!! 3rd party drivers like the ones from AMD or NVIDIA are included as well as some firmware drivers (i never got any problems using my hardware, Debian is more restricted at this point). -- Mit freundlichen Grüßen Greetings Daniel Kreuter
Re: [Mageia-dev] Mirror layout : Why validate software patents ?
Ahmad Samir ahmadsamir3...@gmail.com schrieb am 2010-12-08 On 8 December 2010 10:51, Wolfgang Bornath molc...@googlemail.com wrote: For Fedora, being the most legally-challenged distro around, they don't include any patented software in their official repos at all, not even mp3 playback is possible in a default install. They even don't include any non-free stuff, so no nVidia and ATI proprietary drivers. Fedora users use some 3rd party repos, e.g. RPM Fusion http://rpmfusion.org/ OpenSuSE does include some non-free software (like drivers) in their official repos but for those patent-related packages they have packman which is quite similar to Mandriva's plf. In the OpenSuSE-BuildService you can build Mandriva packages but only if they have no dependencies outside main, because not even contrib is there... And didn't Debian have non-US repositories? Oliver
Re: [Mageia-dev] Mirror layout : Why validate software patents ?
On Wed, Dec 8, 2010 at 10:54 AM, Wolfgang Bornath molc...@googlemail.comwrote: Yes, I know. The question was: do they have those patented software within the same repo as all the other software or do they have an extra repo for that. -- wobo - *Main* - Officially supported software. - *Restricted* - Supported software that is not available under a completely free license. - *Universe* - Community maintained software, i.e. not officially supported software. - *Multiverse* - Software that is not free. This should answer this question. This is the default layout of Ubuntu. -- Mit freundlichen Grüßen Greetings Daniel Kreuter
Re: [Mageia-dev] Mirror layout : Why validate software patents ?
Le mercredi 08 décembre 2010 à 09:51 +0100, Wolfgang Bornath a écrit : 2010/12/8 andre999 and...@laposte.net: By presenting a special set of repositories for patent-affected software, we could be seen as justifying these patent sharks. In their minds, why else would be accommodate them ? Patented software is a reality in some countries. You can't discuss it away with logical reason or morale arguments. Ok, I think, how many other distros have such repositories. According to comments on the list : none. Oh, really? Some (like Mandriva) do not have such a repository because they do not distribute such software at all, PLF does that for Mandriva. What about Ubuntu? What about Fedora? Fedora has rpmfusion ( http://rpmfusion.org/ ) and livna ( http://rpm.livna.org/ ) for libdvdcss. There is stringent requirements : http://fedoraproject.org/wiki/ForbiddenItems Ubuntu has a multiverse repository, and there is also various ppa, and medibuntu ( http://medibuntu.org/ ). Medibuntu is a fork of the PLF project ( even if they never credited us for the content of their start page ... ). Ubuntu is not as rigorous than Fedora or Debian. Debian either do not care of the patent problem, or use some individual repository ( the one of Marillat for example ). AFAIK, the main problem they had with mplayer were around the licensing and the technical issue more than patents. The ftp-masters group check packages, there is a FAQ of the various issues : http://ftp-master.debian.org/REJECT-FAQ.html , but I never noticed any specific discussions around patents. Even the latest discussion about lame on debian legal was around the license used. Gentoo do not care at all, as does most source based distribution ( or the BSD, for the ports ). There is no use flag to filter for patents or anything, according to http://www.gentoo.org/dyn/use-index.xml Mandriva has PLF ( http://plf.zarb.org/ ), even if the patent issue is lightly treated ( given the lack of written policy on this regard ). Opensuse do not ship mp3 or various restricted codecs, according to http://opensuse-community.org/Restricted_formats/11.3 . AFAIK, this is handled by http://packman.links2linux.de/ . Arch seems to offers the software too. And what happens if there is a patent pursuit against Mageia or it's mirrors ? Even if we have a separate repository, the package in question might end up being withdrawn. But it seems doubtful that one would want to withdraw all potentially threatened packages. (That would be a big victory for patent sharks.) A patent pursuit will not be aimed against Mageia because Mageia is a french organisation where there are no software patents. But lawsuits could be aimed at those mirror maintainers who are runnning their mirrors in such countries which allow software patents. There is also the case of private society who could provides services around the distribution. -- Michael Scherer
Re: [Mageia-dev] Mirror layout : Why validate software patents ?
On 8 December 2010 11:39, Wolfgang Bornath molc...@googlemail.com wrote: 2010/12/8 Ahmad Samir ahmadsamir3...@gmail.com: For Fedora, being the most legally-challenged distro around, they don't include any patented software in their official repos at all, not even mp3 playback is possible in a default install. They even don't include any non-free stuff, so no nVidia and ATI proprietary drivers. Fedora users use some 3rd party repos, e.g. RPM Fusion http://rpmfusion.org/ Thx, so it's the same as with Mandriva wrt patented software. What I wanted to say: distributing no patented software at all is not the same as having no extra repository for patented software, so are Mandriva and Fedora seen as justifying patent sharks as andre999 descibed it? -- wobo Reality has proven that some users do use patented software, coming from a semi-official repo or a 3rd party one doesn't seem to matter; i.e. some Mandriva users use PLF (and/or others), some Fedora they use RPM Fusion (and/or others), some OpenSuse users use PackMan; and Debian has a non-US repo... etc The whole point is, it's a CYA (cover your a**) situation; just because a law suit isn't filed doesn't mean it won't/can't be filed. -- Ahmad Samir
Re: [Mageia-dev] Mirror layout : Why validate software patents ?
Wolfgang Bornath kirjoitti: 2010/12/8 andre999 and...@laposte.net: Ok, I think, how many other distros have such repositories. Â According to comments on the list : none. Oh, really? Some (like Mandriva) do not have such a repository because they do not distribute such software at all, In theory only. In practice, Mandriva ships many kind of patented MPEG-4 encoders/decoders, MP3 decoders, VC-1 decoders, etc. Some discussion about this should probably be raised there as well.. If I simply had the time :/ PLF does that for Mandriva. What about Ubuntu? They ship such stuff (like ffmpeg with all decoders/encoders) in their main repository, like Debian does. Also, their universe repository (similar to Mandriva's contrib) does not contain such limitations either, containing stuff like x264 and mp3lame. What about Fedora? Fedora does not have such software. -- Anssi Hannula
Re: [Mageia-dev] Mirror layout : Why validate software patents ?
Wolfgang Bornath kirjoitti: 2010/12/8 Daniel Kreuter daniel.kreute...@googlemail.com: On Wed, Dec 8, 2010 at 9:51 AM, Wolfgang Bornath molc...@googlemail.com wrote: Oh, really? Some (like Mandriva) do not have such a repository because they do not distribute such software at all, PLF does that for Mandriva. What about Ubuntu? What about Fedora? In Ubuntu you have some patented software in the repos. Yes, I know. The question was: do they have those patented software within the same repo as all the other software or do they have an extra repo for that. In reply to andre999 I wanted to point out that there are other distributions who make a difference between patented software and everything else. Some do not distribute them at all (Mandriva, Fedora), some have them in an extra repository (Ubuntu). Ubuntu doesn't have an extra repository for them. They are in universe, which contains all the non-core packages (like mdv contrib). (Some patent-covered stuff, like ffmpeg, are in ubuntu main) -- Anssi Hannula
Re: [Mageia-dev] Mirror layout : Why validate software patents ?
Ahmad Samir kirjoitti: Debian has a non-US repo... etc There hasn't been a non-US repo in Debian releases in years. It existed due to cryptographic regulations in the US, IIRC. -- Anssi Hannula
Re: [Mageia-dev] Mirror layout : Why validate software patents ?
On 12/8/2010 5:47 AM, Anssi Hannula wrote: Wolfgang Bornath kirjoitti: 2010/12/8 andre999and...@laposte.net: Ok, I think, how many other distros have such repositories. Â According to comments on the list : none. Oh, really? Some (like Mandriva) do not have such a repository because they do not distribute such software at all, In theory only. In practice, Mandriva ships many kind of patented MPEG-4 encoders/decoders, MP3 decoders, VC-1 decoders, etc. Some discussion about this should probably be raised there as well.. If I simply had the time :/ PLF does that for Mandriva. What about Ubuntu? They ship such stuff (like ffmpeg with all decoders/encoders) in their main repository, like Debian does. Also, their universe repository (similar to Mandriva's contrib) does not contain such limitations either, containing stuff like x264 and mp3lame. What about Fedora? Fedora does not have such software. I personally would follow the fedora model.
Re: [Mageia-dev] Mirror layout : Why validate software patents ?
On Wed, 2010-12-08 at 09:35 -0700, Nex6 wrote: Fedora does not have such software. I personally would follow the fedora model. Fedora is same as Mandriva and Suse. See Livna and Packman respectively.
Re: [Mageia-dev] Mirror layout : Why validate software patents ?
herman her...@aeronetworks.ca schrieb am 2010-12-08 On Wed, 2010-12-08 at 09:35 -0700, Nex6 wrote: I personally would follow the fedora model. Fedora is same as Mandriva and Suse. See Livna and Packman respectively. We are no company that has to be concerned with selling its product in some strange country with some strange laws. So why should one community have another community to build the packages that may not be sold in the before named strange country? Let's devide the repos in those packages, that can be distibuted everywhere and those that can't and let the mirror maintainers chose if or if not they are willing to mirror the second one. And if you are suggesting not to provide all those packages (which are mostly multimedia I think), I'm not with you. I do want a distribution, that can play my music and videos and so on without having to build the software for myself... Oliver
Re: [Mageia-dev] Mirror layout : Why validate software patents ?
On Wed, 2010-12-08 at 10:28 -0700, Wolfgang Bornath wrote: So, we either abandon the mirrorlist approach or we have 2 mirrorlists (one with and one without tainted software) and let the user decide which one he sets up on his system. +1 for two mirror lists. This is probably the simplest solution.
Re: [Mageia-dev] Mirror layout : Why validate software patents ?
2010/12/8 herman her...@aeronetworks.ca: On Wed, 2010-12-08 at 10:28 -0700, Wolfgang Bornath wrote: So, we either abandon the mirrorlist approach or we have 2 mirrorlists (one with and one without tainted software) and let the user decide which one he sets up on his system. +1 for two mirror lists. This is probably the simplest solution. That's the point where we were already some weeks ago. :) -- wobo
Re: [Mageia-dev] Mirror layout : Why validate software patents ?
On Wed, 8 Dec 2010, Ahmad Samir wrote: On 8 December 2010 11:39, Wolfgang Bornath molc...@googlemail.com wrote: 2010/12/8 Ahmad Samir ahmadsamir3...@gmail.com: For Fedora, being the most legally-challenged distro around, they don't include any patented software in their official repos at all, not even mp3 playback is possible in a default install. They even don't include any non-free stuff, so no nVidia and ATI proprietary drivers. Fedora users use some 3rd party repos, e.g. RPM Fusion http://rpmfusion.org/ Thx, so it's the same as with Mandriva wrt patented software. What I wanted to say: distributing no patented software at all is not the same as having no extra repository for patented software, so are Mandriva and Fedora seen as justifying patent sharks as andre999 descibed it? -- wobo Reality has proven that some users do use patented software, coming from a semi-official repo or a 3rd party one doesn't seem to matter; i.e. some Mandriva users use PLF (and/or others), some Fedora they use RPM Fusion (and/or others), some OpenSuse users use PackMan; and Debian has a non-US repo... etc The whole point is, it's a CYA (cover your a**) situation; just because a law suit isn't filed doesn't mean it won't/can't be filed. Perhaps we should call it cya, then. :) Dale Huckeby
Re: [Mageia-dev] Mirror layout, round two
'Grayzone' ? Mr. Dorian Gray's zone? Or a foggy grey zone? (SCNR!) Hmm, foggy sounds nice :) Or Foggy Bottom :) Better than tainted :D I like from tainted as that term is already somehow known, Another alternative that came to my mind would be challenge as patents could be challenged... Or maybe soap or slippery to explain the uncertainty of possible patents included packages. Mika
Re: [Mageia-dev] Mirror layout, round two
2010/12/8 Mika Laitio lam...@pilppa.org 'Grayzone' ? Mr. Dorian Gray's zone? Or a foggy grey zone? (SCNR!) Hmm, foggy sounds nice :) Or Foggy Bottom :) Better than tainted :D I like from tainted as that term is already somehow known, Another alternative that came to my mind would be challenge as patents could be challenged... Or maybe soap or slippery to explain the uncertainty of possible patents included packages. Mika If we have cauldron associated with sorcerers and like why not swamp as somehow treacherous feature of landscape where you can never be quite sure?
Re: [Mageia-dev] Mirror layout, round two
On 6 December 2010 09:29, Ernest N. Wilcox Jr. ewil...@bex.net wrote: With regard to the naming of the repository dediocated to software tainted with a patent, etc., How about non-GPL? I think that such a name should be well understood by users of nearly any language, particularly if they are familiar with the GPL. My2cents -- Ernest N. Wilcox Jr. Registered Linux User 247790 ICQ 41060744 Read the afro-mentioned thread again; most of those stuff are released under a GPL/GPL-like license (faad and faac packages for example, for playing back and encoding using the AAC audio codec, respectively), they're free open source software, but they infringe some patents. -- Ahmad Samir
Re: [Mageia-dev] Mirror layout, round two
On Mon, Dec 6, 2010 at 1:04 PM, Ahmad Samir ahmadsamir3...@gmail.comwrote: Because Ubuntu already has a repo called universal? that's a similar reason to why it wasn't called restricted, because restricted is used by distros that offer a commercial repo as in pay to use some more stuff. -- Ahmad Samir Do they have a patent on the name? -- Mit freundlichen Grüßen Greetings Daniel Kreuter
Re: [Mageia-dev] Mirror layout, round two
On 06.12.2010 14:10, Daniel Kreuter wrote: On Mon, Dec 6, 2010 at 1:04 PM, Ahmad Samir ahmadsamir3...@gmail.com mailto:ahmadsamir3...@gmail.com wrote: Because Ubuntu already has a repo called universal? that's a similar reason to why it wasn't called restricted, because restricted is used by distros that offer a commercial repo as in pay to use some more stuff. -- Ahmad Samir Do they have a patent on the name? No, but it will cause confusion among users if we use the same name for a different thing than they do. -- Anssi Hannula
Re: [Mageia-dev] Mirror layout, round two
Le lundi 06 décembre 2010 à 13:10 +0100, Daniel Kreuter a écrit : On Mon, Dec 6, 2010 at 1:04 PM, Ahmad Samir ahmadsamir3...@gmail.comwrote: Because Ubuntu already has a repo called universal? that's a similar reason to why it wasn't called restricted, because restricted is used by distros that offer a commercial repo as in pay to use some more stuff. -- Ahmad Samir Do they have a patent on the name? Patents apply to technical invention. What could be used is trademark. And that's not the question, this is a basic usability issue, if a rather important portion of the users associate a word with something, this sound sane to no reuse the same word to hold a different meaning in a very similar context, or it will cause confusion. -- Michael Scherer
Re: [Mageia-dev] Mirror layout, round two
On Mon, Dec 6, 2010 at 7:43 AM, Michael Scherer m...@zarb.org wrote: And that's not the question, this is a basic usability issue, if a rather important portion of the users associate a word with something, this sound sane to no reuse the same word to hold a different meaning in a very similar context, or it will cause confusion. Again, a good argument for a name with no conflicts and no negative meanings: paris. -- Hoyt
Re: [Mageia-dev] Mirror layout, round two
Op maandag 06 december 2010 16:30:00 schreef Hoyt Duff: On Mon, Dec 6, 2010 at 7:43 AM, Michael Scherer m...@zarb.org wrote: And that's not the question, this is a basic usability issue, if a rather important portion of the users associate a word with something, this sound sane to no reuse the same word to hold a different meaning in a very similar context, or it will cause confusion. Again, a good argument for a name with no conflicts and no negative meanings: paris. no negative meaning??? Paris Hilton anyone??? afaik any word has negative meaning...
Re: [Mageia-dev] Mirror layout, round two
Maarten Vanraes wrote: Op maandag 06 december 2010 16:30:00 schreef Hoyt Duff: Again, a good argument for a name with no conflicts and no negative meanings: paris. no negative meaning??? Paris Hilton anyone??? Hoyt is obviously not a subscriber to The Reg :-)
Re: [Mageia-dev] Mirror layout, round two
On Mon, Dec 6, 2010 at 4:33 PM, Maarten Vanraes maarten.vanr...@gmail.com wrote: no negative meaning??? Paris Hilton anyone??? afaik any word has negative meaning... Snooki makes her look like a nun. http://en.wikipedia.org/wiki/Nicole_Polizzi -- Hoyt
Re: [Mageia-dev] Mirror layout, round two
Op maandag 06 december 2010 22:57:23 schreef Hoyt Duff: On Mon, Dec 6, 2010 at 4:33 PM, Maarten Vanraes maarten.vanr...@gmail.com wrote: no negative meaning??? Paris Hilton anyone??? afaik any word has negative meaning... Snooki makes her look like a nun. http://en.wikipedia.org/wiki/Nicole_Polizzi seriously? with PH flashing not wearing underwear, flashing her privates publicly, doing porn?
Re: [Mageia-dev] Mirror layout, round two
On 12/6/2010 2:13 PM, Maarten Vanraes wrote: Op maandag 06 december 2010 22:57:23 schreef Hoyt Duff: On Mon, Dec 6, 2010 at 4:33 PM, Maarten Vanraes maarten.vanr...@gmail.com wrote: no negative meaning??? Paris Hilton anyone??? afaik any word has negative meaning... Snooki makes her look like a nun. http://en.wikipedia.org/wiki/Nicole_Polizzi seriously? with PH flashing not wearing underwear, flashing her privates publicly, doing porn? I personally would not be against using a naming convention from Debian, ubuntu or fedora. in that, people coming from those distros would 'know' what things mean. -Nex6
Re: [Mageia-dev] Mirror layout, round two
Op dinsdag 07 december 2010 00:06:06 schreef Anssi Hannula: On 07.12.2010 00:30, Nex6 wrote: On 12/6/2010 2:13 PM, Maarten Vanraes wrote: Op maandag 06 december 2010 22:57:23 schreef Hoyt Duff: On Mon, Dec 6, 2010 at 4:33 PM, Maarten Vanraes maarten.vanr...@gmail.com wrote: no negative meaning??? Paris Hilton anyone??? afaik any word has negative meaning... Snooki makes her look like a nun. http://en.wikipedia.org/wiki/Nicole_Polizzi seriously? with PH flashing not wearing underwear, flashing her privates publicly, doing porn? I personally would not be against using a naming convention from Debian, ubuntu or fedora. in that, people coming from those distros would 'know' what things mean. They do not have any repository of this kind. I find it strange that the most heavy threads here are naming issues...
Re: [Mageia-dev] Mirror layout, round two
On Mon, Dec 6, 2010 at 7:04 PM, Michael Scherer m...@zarb.org wrote: Le mardi 07 décembre 2010 à 00:10 +0100, Maarten Vanraes a écrit : I find it strange that the most heavy threads here are naming issues... http://bikeshed.com/ ? -- Michael Scherer ... a metaphor indicating that you need not argue about every little feature just because you know enough to do so. ... a metaphor indicating that you argue about every little feature just because you don't know enough not to do so. FIXED 8) -- Hoyt
Re: [Mageia-dev] Mirror layout, round two
On Sat, Dec 4, 2010 at 9:32 PM, andre999 and...@laposte.net wrote: Dale Huckeby a écrit : On Sat, 4 Dec 2010, andre999 wrote: John a écrit : On Fri, 3 Dec 2010 11:28:26 +0100 Maarten Vanraes wrote: Op vrijdag 03 december 2010 10:45:05 schreef Ahmad Samir: [...] The kernel uses the word tainted when it detects the nvidia proprietary module for example, (which admittedly gave me a bit of shock the first time I saw it :)). Heh, i had the same reaction. From all the proposed names, I think tainted is the best one, as the packages in there are in a grey zone, i.e. not totally illegal everywhere, but illegal only in some places in the world. And in reality the existence of a patent doesn't necessarily mean it's enforceable in a court of law (the only way we'd know for sure is if someone actually does try to sue)... my 0.02€ worth :) Generally only potentially illegal in some countries. Tainted means contaminated, polluted. A lot stronger than potentially illegal. (Really only actionable in a civil sense, not criminally illegal, as well.) A package could end up there due to an apparently credible rumour, later discredited. (Anyone remember SCO ?) I agree. Problematic comes closer to potentially illegal, so I looked up some synonyms: ambiguous, debatable, dubious, iffy, suspect, speculative, precarious, suspicious, uncertain, unsettled, in addition to problematic itself. Personally I like iffy, which is both short and to the point, but I think several of these would do. WDYT? Dale Huckeby A much better set of choices. (Thanks for looking these up. Good idea.) Let's remember that the question for these packages is not the quality of their functioning - but rather the advisability to use them, for other reasons, in some countries. So I think that it is better to avoid words that could question the QUALITY of the packages. Words in the list like ambiguous, debatable, problematic, and speculative avoid questioning the quality ... but could be too long or too formal. Or just not catchy enough ;) (Iffy might be ok - certainly catchy enough.) Additional words I found in Roget's thesaurus, along the same lines : Associated more with debatable : arguable, contestable, controvertible, disputable, questionable, Associated more with controversial : confutable, deniable, mistakable, moot Of these additional words, I think that contestable, disputable, and controversial are probably closest to the SENSE of the repositories. But maybe too formal ? Many of these words could be good choices. And maybe someone will come up with some more ? my 2 cents :) - André What about: main, free, non-free? In main is everything what belongs to the core, free contains only packages which are under a free license and in non-free are those which aren't clear if free or not (what you mentioned earlier in this discussion). All three names are as clear as possible what's meant. -- Mit freundlichen Grüßen Greetings Daniel Kreuter
Re: [Mageia-dev] Mirror layout, round two
Op zaterdag 04 december 2010 21:32:51 schreef andre999: Dale Huckeby a écrit : On Sat, 4 Dec 2010, andre999 wrote: John a écrit : On Fri, 3 Dec 2010 11:28:26 +0100 Maarten Vanraes wrote: Op vrijdag 03 december 2010 10:45:05 schreef Ahmad Samir: [...] The kernel uses the word tainted when it detects the nvidia proprietary module for example, (which admittedly gave me a bit of shock the first time I saw it :)). Heh, i had the same reaction. From all the proposed names, I think tainted is the best one, as the packages in there are in a grey zone, i.e. not totally illegal everywhere, but illegal only in some places in the world. And in reality the existence of a patent doesn't necessarily mean it's enforceable in a court of law (the only way we'd know for sure is if someone actually does try to sue)... my 0.02€ worth :) Generally only potentially illegal in some countries. Tainted means contaminated, polluted. A lot stronger than potentially illegal. (Really only actionable in a civil sense, not criminally illegal, as well.) A package could end up there due to an apparently credible rumour, later discredited. (Anyone remember SCO ?) I agree. Problematic comes closer to potentially illegal, so I looked up some synonyms: ambiguous, debatable, dubious, iffy, suspect, speculative, precarious, suspicious, uncertain, unsettled, in addition to problematic itself. Personally I like iffy, which is both short and to the point, but I think several of these would do. WDYT? Dale Huckeby A much better set of choices. (Thanks for looking these up. Good idea.) Let's remember that the question for these packages is not the quality of their functioning - but rather the advisability to use them, for other reasons, in some countries. So I think that it is better to avoid words that could question the QUALITY of the packages. Words in the list like ambiguous, debatable, problematic, and speculative avoid questioning the quality ... but could be too long or too formal. Or just not catchy enough ;) (Iffy might be ok - certainly catchy enough.) Additional words I found in Roget's thesaurus, along the same lines : Associated more with debatable : arguable, contestable, controvertible, disputable, questionable, Associated more with controversial : confutable, deniable, mistakable, moot Of these additional words, I think that contestable, disputable, and controversial are probably closest to the SENSE of the repositories. But maybe too formal ? Many of these words could be good choices. And maybe someone will come up with some more ? my 2 cents :) - André i like speculative
Re: [Mageia-dev] Mirror layout, round two
Op zaterdag 04 december 2010 20:58:12 schreef Erin Wilkins: On December 4, 2010 10:06:37 Anssi Hannula wrote: On 03.12.2010 11:45, Ahmad Samir wrote: On 2 December 2010 18:43, Michael Scherer m...@zarb.org wrote: Le jeudi 02 décembre 2010 à 16:26 +0100, Wolfgang Bornath a écrit : 2010/12/2 Anssi Hannula anssi.hann...@iki.fi: For the record, I'm not a big fan of tainted name (too negative), but I can't think of anything better either, so... :) I agree, as restricted may be misleading former Mandriva users, why not special or extra? I know there is the name extra for some other branch but it may be easier to find another name for that one. That would be misleading to the content of the directory. What about limited ? restrained ? ( restrain, to deprive of liberty , seems like the perfect match ) -- Michael Scherer limited and restrained don't sound right as they don't fully convey the purpose/filtering-rule for packages in that repo Indeed. Wolfgang's foggy sounds nice, but I think I prefer tainted anyway. Since the packages in that repository are there because they're (potentially) encumbered by patents, why not call it for what it is, encumbered? -- Erin too difficult
Re: [Mageia-dev] Mirror layout, round two
On 05.12.2010 19:36, Daniel Kreuter wrote: On Sat, Dec 4, 2010 at 9:32 PM, andre999 and...@laposte.net mailto:and...@laposte.net wrote: Dale Huckeby a écrit : On Sat, 4 Dec 2010, andre999 wrote: John a écrit : On Fri, 3 Dec 2010 11:28:26 +0100 Maarten Vanraes wrote: Op vrijdag 03 december 2010 10:45:05 schreef Ahmad Samir: [...] The kernel uses the word tainted when it detects the nvidia proprietary module for example, (which admittedly gave me a bit of shock the first time I saw it :)). Heh, i had the same reaction. From all the proposed names, I think tainted is the best one, as the packages in there are in a grey zone, i.e. not totally illegal everywhere, but illegal only in some places in the world. And in reality the existence of a patent doesn't necessarily mean it's enforceable in a court of law (the only way we'd know for sure is if someone actually does try to sue)... my 0.02€ worth :) Generally only potentially illegal in some countries. Tainted means contaminated, polluted. A lot stronger than potentially illegal. (Really only actionable in a civil sense, not criminally illegal, as well.) A package could end up there due to an apparently credible rumour, later discredited. (Anyone remember SCO ?) I agree. Problematic comes closer to potentially illegal, so I looked up some synonyms: ambiguous, debatable, dubious, iffy, suspect, speculative, precarious, suspicious, uncertain, unsettled, in addition to problematic itself. Personally I like iffy, which is both short and to the point, but I think several of these would do. WDYT? Dale Huckeby A much better set of choices. (Thanks for looking these up. Good idea.) Let's remember that the question for these packages is not the quality of their functioning - but rather the advisability to use them, for other reasons, in some countries. So I think that it is better to avoid words that could question the QUALITY of the packages. Words in the list like ambiguous, debatable, problematic, and speculative avoid questioning the quality ... but could be too long or too formal. Or just not catchy enough ;) (Iffy might be ok - certainly catchy enough.) Additional words I found in Roget's thesaurus, along the same lines : Associated more with debatable : arguable, contestable, controvertible, disputable, questionable, Associated more with controversial : confutable, deniable, mistakable, moot Of these additional words, I think that contestable, disputable, and controversial are probably closest to the SENSE of the repositories. But maybe too formal ? Many of these words could be good choices. And maybe someone will come up with some more ? my 2 cents :) - André What about: main, free, non-free? In main is everything what belongs to the core, free contains only packages which are under a free license and in non-free are those which aren't clear if free or not (what you mentioned earlier in this discussion). All three names are as clear as possible what's meant. The license of the packages is not in question (they are free), the patent (etc) situation is. -- Anssi Hannula
Re: [Mageia-dev] Mirror layout, round two
On Sun, Dec 5, 2010 at 8:39 PM, Anssi Hannula anssi.hann...@iki.fi wrote: On 05.12.2010 19:36, Daniel Kreuter wrote: On Sat, Dec 4, 2010 at 9:32 PM, andre999 and...@laposte.net mailto:and...@laposte.net wrote: Dale Huckeby a écrit : On Sat, 4 Dec 2010, andre999 wrote: John a écrit : On Fri, 3 Dec 2010 11:28:26 +0100 Maarten Vanraes wrote: Op vrijdag 03 december 2010 10:45:05 schreef Ahmad Samir: [...] The kernel uses the word tainted when it detects the nvidia proprietary module for example, (which admittedly gave me a bit of shock the first time I saw it :)). Heh, i had the same reaction. From all the proposed names, I think tainted is the best one, as the packages in there are in a grey zone, i.e. not totally illegal everywhere, but illegal only in some places in the world. And in reality the existence of a patent doesn't necessarily mean it's enforceable in a court of law (the only way we'd know for sure is if someone actually does try to sue)... my 0.02€ worth :) Generally only potentially illegal in some countries. Tainted means contaminated, polluted. A lot stronger than potentially illegal. (Really only actionable in a civil sense, not criminally illegal, as well.) A package could end up there due to an apparently credible rumour, later discredited. (Anyone remember SCO ?) I agree. Problematic comes closer to potentially illegal, so I looked up some synonyms: ambiguous, debatable, dubious, iffy, suspect, speculative, precarious, suspicious, uncertain, unsettled, in addition to problematic itself. Personally I like iffy, which is both short and to the point, but I think several of these would do. WDYT? Dale Huckeby A much better set of choices. (Thanks for looking these up. Good idea.) Let's remember that the question for these packages is not the quality of their functioning - but rather the advisability to use them, for other reasons, in some countries. So I think that it is better to avoid words that could question the QUALITY of the packages. Words in the list like ambiguous, debatable, problematic, and speculative avoid questioning the quality ... but could be too long or too formal. Or just not catchy enough ;) (Iffy might be ok - certainly catchy enough.) Additional words I found in Roget's thesaurus, along the same lines : Associated more with debatable : arguable, contestable, controvertible, disputable, questionable, Associated more with controversial : confutable, deniable, mistakable, moot Of these additional words, I think that contestable, disputable, and controversial are probably closest to the SENSE of the repositories. But maybe too formal ? Many of these words could be good choices. And maybe someone will come up with some more ? my 2 cents :) - André What about: main, free, non-free? In main is everything what belongs to the core, free contains only packages which are under a free license and in non-free are those which aren't clear if free or not (what you mentioned earlier in this discussion). All three names are as clear as possible what's meant. The license of the packages is not in question (they are free), the patent (etc) situation is. -- Anssi Hannula That's what i ment. -- Mit freundlichen Grüßen Greetings Daniel Kreuter
Re: [Mageia-dev] Mirror layout, round two
On Sun, Dec 5, 2010 at 1:59 PM, Maarten Vanraes maarten.vanr...@gmail.com wrote: Since the packages in that repository are there because they're (potentially) encumbered by patents, why not call it for what it is, encumbered? -- Erin too difficult I suppose that's why nobody liked supernumerary. 8) How about segregated? Oh, wait ... The problem is that in all languages, words that mean not part of the group, not one of us or not like us all have negative connotations for cultural reasons. Perhaps we need an unrelated word that has meaning to Mageia, but infers uniqueness without being pejorative. I suggest calling it the paris repository, a place for unique and useful applications that cannot be placed in any other repository for whatever reason. Then perhaps any local repository of one-off packages could always be labeled paris-local by default. -- Hoyt
Re: [Mageia-dev] Mirror layout, round two
On 05.12.2010 21:47, Daniel Kreuter wrote: On Sun, Dec 5, 2010 at 8:39 PM, Anssi Hannula anssi.hann...@iki.fi mailto:anssi.hann...@iki.fi wrote: On 05.12.2010 19:36, Daniel Kreuter wrote: On Sat, Dec 4, 2010 at 9:32 PM, andre999 and...@laposte.net mailto:and...@laposte.net mailto:and...@laposte.net mailto:and...@laposte.net wrote: Dale Huckeby a écrit : On Sat, 4 Dec 2010, andre999 wrote: John a écrit : On Fri, 3 Dec 2010 11:28:26 +0100 Maarten Vanraes wrote: Op vrijdag 03 december 2010 10:45:05 schreef Ahmad Samir: [...] The kernel uses the word tainted when it detects the nvidia proprietary module for example, (which admittedly gave me a bit of shock the first time I saw it :)). Heh, i had the same reaction. From all the proposed names, I think tainted is the best one, as the packages in there are in a grey zone, i.e. not totally illegal everywhere, but illegal only in some places in the world. And in reality the existence of a patent doesn't necessarily mean it's enforceable in a court of law (the only way we'd know for sure is if someone actually does try to sue)... my 0.02€ worth :) Generally only potentially illegal in some countries. Tainted means contaminated, polluted. A lot stronger than potentially illegal. (Really only actionable in a civil sense, not criminally illegal, as well.) A package could end up there due to an apparently credible rumour, later discredited. (Anyone remember SCO ?) I agree. Problematic comes closer to potentially illegal, so I looked up some synonyms: ambiguous, debatable, dubious, iffy, suspect, speculative, precarious, suspicious, uncertain, unsettled, in addition to problematic itself. Personally I like iffy, which is both short and to the point, but I think several of these would do. WDYT? Dale Huckeby A much better set of choices. (Thanks for looking these up. Good idea.) Let's remember that the question for these packages is not the quality of their functioning - but rather the advisability to use them, for other reasons, in some countries. So I think that it is better to avoid words that could question the QUALITY of the packages. Words in the list like ambiguous, debatable, problematic, and speculative avoid questioning the quality ... but could be too long or too formal. Or just not catchy enough ;) (Iffy might be ok - certainly catchy enough.) Additional words I found in Roget's thesaurus, along the same lines : Associated more with debatable : arguable, contestable, controvertible, disputable, questionable, Associated more with controversial : confutable, deniable, mistakable, moot Of these additional words, I think that contestable, disputable, and controversial are probably closest to the SENSE of the repositories. But maybe too formal ? Many of these words could be good choices. And maybe someone will come up with some more ? my 2 cents :) - André What about: main, free, non-free? In main is everything what belongs to the core, free contains only packages which are under a free license and in non-free are those which aren't clear if free or not (what you mentioned earlier in this discussion). All three names are as clear as possible what's meant. The license of the packages is not in question (they are free), the patent (etc) situation is. -- Anssi Hannula That's what i ment. I don't understand. So, where would you put e.g. patent-encumbered packages of free software, then? If to free, that runs counter to the desire to having them
Re: [Mageia-dev] Mirror layout, round two
Giving names we have to keep the structure in mind which was developped during this thread. Now we are talking about a name for that repo which never existed in Mandriva, so Mandriva never had to worry about the correct naming. How about abbreviations? Thinking of PLF, MLF comes to mind but that abbreviation has another well-known meaning. :) pisc (patented in some countries) is another no-go because of various resons in different languages. But here's one which could work: tbp (tainted by patents). -- wobo
Re: [Mageia-dev] Mirror layout, round two
On December 5, 2010 10:59:45 Maarten Vanraes wrote: Op zaterdag 04 december 2010 20:58:12 schreef Erin Wilkins: Since the packages in that repository are there because they're (potentially) encumbered by patents, why not call it for what it is, encumbered? -- Erin too difficult To understand? If that's the case, I think you're going to be stuck with tainted. And while I don't have an issue with it, this whole discussion started because some people find it too negative. The purpose of the repository name is to convey what sort of packages are contained in it. While many of the names that have been mentioned (foggy, speculative, etc) are relatively easy to remember, they don't have any existing meanings with regard to software. If I, or pretty much any other user, were not following this thread, I would not understand what sort of packages would be in a repository with those names. And like any other name that I wouldn't understand, I'd have to look up the documentation. I don't know about you, but I'd rather go with a name that conveys an existing meaning, but some people will need to look at the documentation to understand. -- Erin
Re: [Mageia-dev] Mirror layout, round two
Op zondag 05 december 2010 21:50:00 schreef Erin Wilkins: On December 5, 2010 10:59:45 Maarten Vanraes wrote: Op zaterdag 04 december 2010 20:58:12 schreef Erin Wilkins: Since the packages in that repository are there because they're (potentially) encumbered by patents, why not call it for what it is, encumbered? -- Erin too difficult To understand? If that's the case, I think you're going to be stuck with tainted. And while I don't have an issue with it, this whole discussion started because some people find it too negative. The purpose of the repository name is to convey what sort of packages are contained in it. While many of the names that have been mentioned (foggy, speculative, etc) are relatively easy to remember, they don't have any existing meanings with regard to software. If I, or pretty much any other user, were not following this thread, I would not understand what sort of packages would be in a repository with those names. And like any other name that I wouldn't understand, I'd have to look up the documentation. I don't know about you, but I'd rather go with a name that conveys an existing meaning, but some people will need to look at the documentation to understand. I understand your point. however, Mageia is international and i think a high group of international no-native-english-speakers will have a hard time finding out what this is about... the english language is pretty rich; and i suspect there are quite a few words that could convey the correct meaning without the word being too difficult. otoh, there is also the fact that free or core don't really convey the correct meaning at all either and could be quite dubious. patented would be more correct, but i don't wanna call it that, because then mageia would be sued by patent-lawyers all over the world. don't get me wrong, it wouldn't be illegal, but it would just be too timeconsuming... imho, we should have a simple not too difficult word that somehow shows a bit about the nature of the contents in it, while still being vague enough.
Re: [Mageia-dev] Mirror layout, round two
On Sun, 5 Dec 2010 17:39:08 -0600 (CST), Dale Huckeby sp...@evansville.net wrote: On Sun, 5 Dec 2010, Maarten Vanraes wrote: the english language is pretty rich; and i suspect there are quite a few words that could convey the correct meaning without the word being too difficult. otoh, there is also the fact that free or core don't really convey the correct meaning at all either and could be quite dubious. patented would be more correct, but i don't wanna call it that, because then mageia would be sued by patent-lawyers all over the world. don't get me wrong, it wouldn't be illegal, but it would just be too timeconsuming... imho, we should have a simple not too difficult word that somehow shows a bit about the nature of the contents in it, while still being vague enough. Okay, short words: iffy, chancy, dicey, knotty, clouded, foggy, hazy, unclear, contro (for controversial), prob (for problematic), equiv (for equivocal), irreg (for irregular). I like iffy best. It's short, it's informal, its meaning is clear, yet it's not too narrow. Dale Huckeby Considering the other repo names to be used, we could always call this one other. -- Sam Bailey Cyprix Enterprises Web: cyprix.com.au Em: cyp...@cyprix.com.au Mb: 0425 796 308
Re: [Mageia-dev] Mirror layout, round two
On Sun, Dec 5, 2010 at 4:12 PM, Maarten Vanraes maarten.vanr...@gmail.com wrote: Perhaps we need an unrelated word that has meaning to Mageia, but infers uniqueness without being pejorative. I suggest calling it the paris repository, a place for unique and useful applications that cannot be placed in any other repository for whatever reason. Then perhaps any local repository of one-off packages could always be labeled paris-local by default. after Paris Hilton? a place for unique and useful applications that cannot be placed in any other repository for whatever reason sounds like a good comparison... I was associating the richness and diversity of the City of Lights, but I like the way you think. -- Hoyt
Re: [Mageia-dev] Mirror layout, round two
Dale Huckeby a écrit : On Sun, 5 Dec 2010, Maarten Vanraes wrote: the english language is pretty rich; and i suspect there are quite a few words that could convey the correct meaning without the word being too difficult. otoh, there is also the fact that free or core don't really convey the correct meaning at all either and could be quite dubious. patented would be more correct, but i don't wanna call it that, because then mageia would be sued by patent-lawyers all over the world. don't get me wrong, it wouldn't be illegal, but it would just be too timeconsuming... imho, we should have a simple not too difficult word that somehow shows a bit about the nature of the contents in it, while still being vague enough. Okay, short words: iffy, chancy, dicey, knotty, clouded, foggy, hazy, unclear, contro (for controversial), prob (for problematic), equiv (for equivocal), irreg (for irregular). I like iffy best. It's short, it's informal, its meaning is clear, yet it's not too narrow. Dale Huckeby great idea, abreviations ! contro, irreg, and equiv are abreviations for words that don't question the quality. I like contro and irreg best. We can always give the full word in our documentation which explains the purpose of each repository. That would work. (BTW, when I think about it, iffy could be considered to refer to quality - but it's still way better than tainted.) Of course, there should be lots of other abreviations to choose from, if collectively we don't like one of these. - André
Re: [Mageia-dev] Mirror layout, round two
On Mon, 06 Dec 2010 00:02:21 -0500, andre999 and...@laposte.net wrote: Maarten Vanraes a écrit : i like speculative That's not bad I would prefer a very clear term, even if long, such as possibly-patented. Regards, Dave Hodgins
Re: [Mageia-dev] Mirror layout, round two
Wolfgang Bornath a écrit : 2010/12/3 Johnj...@neodoc.biz: 'Grayzone' ? Mr. Dorian Gray's zone? Or a foggy grey zone? (SCNR!) Hmm, foggy sounds nice :) Or Foggy Bottom :) Better than tainted :D
Re: [Mageia-dev] Mirror layout, round two
On Sat, Dec 4, 2010 at 4:33 AM, andre999 and...@laposte.net wrote: Better than tainted :D Tainted makes me chuckle -- crude anatomical reference. -- Hoyt
Re: [Mageia-dev] Mirror layout, round two
On Sat, 4 Dec 2010, andre999 wrote: John a écrit : On Fri, 3 Dec 2010 11:28:26 +0100 Maarten Vanraes wrote: Op vrijdag 03 december 2010 10:45:05 schreef Ahmad Samir: [...] The kernel uses the word tainted when it detects the nvidia proprietary module for example, (which admittedly gave me a bit of shock the first time I saw it :)). Heh, i had the same reaction. From all the proposed names, I think tainted is the best one, as the packages in there are in a grey zone, i.e. not totally illegal everywhere, but illegal only in some places in the world. And in reality the existence of a patent doesn't necessarily mean it's enforceable in a court of law (the only way we'd know for sure is if someone actually does try to sue)... my 0.02€ worth :) Generally only potentially illegal in some countries. Tainted means contaminated, polluted. A lot stronger than potentially illegal. (Really only actionable in a civil sense, not criminally illegal, as well.) A package could end up there due to an apparently credible rumour, later discredited. (Anyone remember SCO ?) I agree. Problematic comes closer to potentially illegal, so I looked up some synonyms: ambiguous, debatable, dubious, iffy, suspect, speculative, precarious, suspicious, uncertain, unsettled, in addition to problematic itself. Personally I like iffy, which is both short and to the point, but I think several of these would do. WDYT? Dale Huckeby
Re: [Mageia-dev] Mirror layout, round two
On 03.12.2010 11:45, Ahmad Samir wrote: On 2 December 2010 18:43, Michael Scherer m...@zarb.org wrote: Le jeudi 02 décembre 2010 à 16:26 +0100, Wolfgang Bornath a écrit : 2010/12/2 Anssi Hannula anssi.hann...@iki.fi: For the record, I'm not a big fan of tainted name (too negative), but I can't think of anything better either, so... :) I agree, as restricted may be misleading former Mandriva users, why not special or extra? I know there is the name extra for some other branch but it may be easier to find another name for that one. That would be misleading to the content of the directory. What about limited ? restrained ? ( restrain, to deprive of liberty , seems like the perfect match ) -- Michael Scherer limited and restrained don't sound right as they don't fully convey the purpose/filtering-rule for packages in that repo Indeed. Wolfgang's foggy sounds nice, but I think I prefer tainted anyway. -- Anssi Hannula
Re: [Mageia-dev] Mirror layout, round two
On Fri, 2010-12-03 at 03:28 -0700, Maarten Vanraes wrote: how about gray or grey ? No, the Speling Nazi's will drive us nuts...
Re: [Mageia-dev] Mirror layout, round two
On Fri, 3 Dec 2010 11:28:26 +0100 Maarten Vanraes wrote: Op vrijdag 03 december 2010 10:45:05 schreef Ahmad Samir: [...] The kernel uses the word tainted when it detects the nvidia proprietary module for example, (which admittedly gave me a bit of shock the first time I saw it :)). Heh, i had the same reaction. From all the proposed names, I think tainted is the best one, as the packages in there are in a grey zone, i.e. not totally illegal everywhere, but illegal only in some places in the world. And in reality the existence of a patent doesn't necessarily mean it's enforceable in a court of law (the only way we'd know for sure is if someone actually does try to sue)... my 0.02€ worth :) how about gray or grey ? 'Grayzone' ? John
Re: [Mageia-dev] Mirror layout, round two
Op vrijdag 03 december 2010 18:58:15 schreef herman: On Fri, 2010-12-03 at 03:28 -0700, Maarten Vanraes wrote: how about gray or grey ? No, the Speling Nazi's will drive us nuts... For this, it is no problem, because they are both correct! :-P
Re: [Mageia-dev] Mirror layout, round two
On 01.12.2010 22:29, Anssi Hannula wrote: On 30.11.2010 12:37, Thomas Backlund wrote: [...] Can we reach an agreement that this is the way to start the distro? Yes. and for refernece: The suggested layout for is: * core * nonfree * tainted For the record, I'm not a big fan of tainted name (too negative), but I can't think of anything better either, so... :) * debug_core * debug_nonfree * debug_tainted Every media contains the same layout: * backports * backports_testing * release * updates * updates_testing I wonder which 32bit ones we should add on 64bit, and which ones of those should be enabled and which ones disabled. On MDV, main+main_updates were added and enabled. But for example wine backports are commonly wanted by 64bit users, and those are in main/backports (core/backports for us). Or is there an alternative approach that I can't think of? -- Anssi Hannula
Re: [Mageia-dev] Mirror layout, round two
2010/12/2 Anssi Hannula anssi.hann...@iki.fi: For the record, I'm not a big fan of tainted name (too negative), but I can't think of anything better either, so... :) I agree, as restricted may be misleading former Mandriva users, why not special or extra? I know there is the name extra for some other branch but it may be easier to find another name for that one. -- wobo
Re: [Mageia-dev] Mirror layout, round two
Le jeudi 02 décembre 2010 à 16:26 +0100, Wolfgang Bornath a écrit : 2010/12/2 Anssi Hannula anssi.hann...@iki.fi: For the record, I'm not a big fan of tainted name (too negative), but I can't think of anything better either, so... :) I agree, as restricted may be misleading former Mandriva users, why not special or extra? I know there is the name extra for some other branch but it may be easier to find another name for that one. That would be misleading to the content of the directory. What about limited ? restrained ? ( restrain, to deprive of liberty , seems like the perfect match ) -- Michael Scherer
Re: [Mageia-dev] Mirror layout, round two
On Thu, Dec 2, 2010 at 10:26 AM, Wolfgang Bornath molc...@googlemail.com wrote: 2010/12/2 Anssi Hannula anssi.hann...@iki.fi: For the record, I'm not a big fan of tainted name (too negative), but I can't think of anything better either, so... :) I agree, as restricted may be misleading former Mandriva users, why not special or extra? I know there is the name extra for some other branch but it may be easier to find another name for that one. -- wobo supernumerary a thing that exceeds the required, an extra -- Hoyt
Re: [Mageia-dev] Mirror layout, round two
Op donderdag 02 december 2010 08:20:15 schreef andre999: Maarten Vanraes a écrit : Op woensdag 01 december 2010 21:54:48 schreef andre999: [...] allthough interesting, this thread is about mirror layout; and is not about removing the distinction between supported packages and not. (this wasn't all that clear to me at first.) I'll discuss further down why I think that this is a critical part of the question. i do understand that you think other methods of having the distinction might not work; i have reservations myself that way. (i do feel the disctinction is important.) Glad to see that you understand my concerns. i also see that mirror layout should be as easy as possible for mirror admins. Agreed. However keeping an extra set of repositories for core packages would just add a few extra directories (without changing the number/size of their total content), thus have little impact on mirror administration. One would think so; however, a few people who replied where mirror administrators; and it seems, IIUC that they said it does have impact. I'm just gonna trust their judgement on this, since they know more about this than myself. [... snipping tainted stuff...] In any case, rsync is a pretty straight-forward application. however, looking at the big picture, i think that logically it's sounds to have one purpose to one thing; and thus for the mirror layout; only the mirror admins should be looked at; the viewpoint of a user _should_ not really matter. I agree that the user viewpoint is not of major importance : I see that as just a positive side effect. I am trying to look at the big picture. And perhaps I haven't been very effective at expressing my concerns. In my mind, we should always consider important side effects of major changes. And removing separate core/extra (or main/contrib repositories does have an important side effect. Realigning core so it is really core should very much help packagers, as well as maintaining an important distinction. Note that if, down the road, we find another effective method for distinquishing core / non-core, it is relatively simple to transfer packages in extra to core. But if we eliminate the parallel set of repositories, and find later that we have a problem giving priority to core packages, moving in the other direction would be a much more difficult process. IIRC someone with experience said in this thread that we could always go to that sort of scenario if like this it wouldn't work well. Again, i'm gonna trust their judgement on this. The suggestion that we only transfer to Mageia packages that we see as important to keep, sounds like a very good approach. This would also facilitate maintaining the core / non-core distinction. I suppose, however, I think that developers are their own users; they write for theirselves; hence people will pull what they think is important for them. but at the very least, since it's something they will use, it'll at least be tested some. (even if QA doesn't test it) I'm not trying to say that defining core / non-core in detail is a trivial process. But it is in the interest of Mageia to define it. I realise, at least at first, that things will be more difficult for packagers. But firmly believe that this will be largely alleviated by a careful triage of existing main and contrib packages. Thus I am more than willing to put in a lot of effort, since it will have an important impact on the future of Mageia. I also realise that many of those proposing eliminating a set of repos have a lot of valuable experience. And I'm sure that if/when we can agree on this concern, that we will be able to work very well together. And I look forward to becoming a Mageia packager. another 2 cents :) - André
Re: [Mageia-dev] Mirror layout, round two
Op donderdag 02 december 2010 18:23:35 schreef Leandro Dorileo: On Thu, Dec 2, 2010 at 12:26 PM, Wolfgang Bornath molc...@googlemail.com wrote: 2010/12/2 Anssi Hannula anssi.hann...@iki.fi: For the record, I'm not a big fan of tainted name (too negative), but I can't think of anything better either, so... :) I agree, as restricted may be misleading former Mandriva users, why not special or extra? I know there is the name extra for some other branch but it may be easier to find another name for that one. What about leftover? or maybe optional? regards /me likes leftovers
Re: [Mageia-dev] Mirror layout, round two
On 30.11.2010 12:37, Thomas Backlund wrote: [...] Can we reach an agreement that this is the way to start the distro? Yes. and for refernece: The suggested layout for is: * core * nonfree * tainted * debug_core * debug_nonfree * debug_tainted Every media contains the same layout: * backports * backports_testing * release * updates * updates_testing I wonder which 32bit ones we should add on 64bit, and which ones of those should be enabled and which ones disabled. On MDV, main+main_updates were added and enabled. But for example wine backports are commonly wanted by 64bit users, and those are in main/backports (core/backports for us). Or is there an alternative approach that I can't think of? -- Anssi Hannula
Re: [Mageia-dev] Mirror layout, round two
Ahmad Samir a écrit : On 30 November 2010 07:29, andre999and...@laposte.net wrote: Michael Scherer a écrit : Le lundi 29 novembre 2010 à 20:54 -0500, andre999 a écrit : Yann Ciret a écrit : I dislike the main/contrib separation in some case. The first example is with Mozilla Thunderbird packages. Some extension packages are in contrib. So each time thunderbird received security update, the update cannot be installed because of non automatically rebuild of his contrib package. And each time I see a bug report of user asking a manual rebuilt. With only one core media, this situation will disapear (I hope). Unlikely. This problem is not at all related to separate repositories. It is. It is exactly related to the fact that thunderbird is supported, and that extension are not despites depending on it. In this case it is evident that you don't understand how extensions work with mozilla products. Thunderbird will function correctly with no extensions installed. So why should any extension block the update of Thunderbird ? So the user can simply uninstall that extension and update to new thunderbird? the user can do this only if he doesn't need that extension, only if it doesn't offer features he wants to use. That's an invalid argument, if he doesn't need that extension why does he have it on his system?? You're missing some points here : 1) There is no need to remove an extension. It will continue to work, as long as there hasn't been some error in packaging. In other words, on a generic Mozilla installation, it would continue to work. The only exceptions in the past are when Mozilla changed the version of XML used to code extensions. (Which has happened twice since the beginning of Mozilla, if I recall correctly.) But that would not happen on an update. 2) If by chance the extension does not work properly, it can always be updated directly by the update function inside Thunderbird. Unless the distro packaging has somehow disabled this function. Which would be an error in packaging. 3) There is no reason to package Mozilla extensions in the distro, except for base localisation modules, which are already in main. 4) If an optional module of any application stops working, that can only affect the application in question. And should not stop the application from working. That does not in itself justify such an extension being considered (logically) core. The rationale is/was that mozilla code breaks/broke ABI, so it was agreed that extensions are rebuilt for both firefox and thunderbird respective new versions. See above. We will look into that with upstream, so that if a rebuild isn't needed, then all the better for us (packagers). But until that happens, they will be rebuilt. A 1-2 day delay isn't too much for users. Good. Check with upstream. It can be done quickly, and will help clean the system. By the way, if you install Thunderbird, you can confirm the critical elements yourself. (Installation/update of Extensions and other optional modules fully managable from inside Thunderbird. As well, by default there are automatic alerts when updates become available.) The more pressing issue is, what does this have to do with the topic at hand Mirrors layout, round two ?? this discussion is deviating too much, to the extent it's becoming bloated... Everything. Removing the distinction between core and non-core packages removes an important control, useful to give greater assurance that (logically) core packages are not broken, thus breaking users' systems. In my mind, alternative controls are likely to be more complex to maintain, and probably less reliable. It is interesting that the names core and extra were chosen to replace main and contrib. Especially since main was originally meant to be core packages. But not enforced, as some packagers themselves have pointed out. (One would prefer that I don't mention his name.) Additionally, modules installed will continue to work as long as the major version doesn't change. (Actually slightly more complicated.) In some cases one won't be able to newly install a module because a config file inside the module - equivalent to the spec file in rpm packages - hasn't been updated for compatible versions. (In fact, the versions were probably improperly specified.) But installed modules will continue to function. It is possible that the packager did not realise this - or for whatever reason did not properly set up a spec file - but this issue has nothing at all to do with separate sets of repositories. Speaking abstractly without examples in this case is just that, speaking. Give us an example of such a case (if any) in a spec file so that it can be fixed. More precise details added above. That precisely because we tell security and bugfixes occurs only on main that contribs got broken, since the security team do not care to not break contribs packages The crux of this problem is that core
Re: [Mageia-dev] Mirror layout, round two
Op woensdag 01 december 2010 21:54:48 schreef andre999: [...] allthough interesting, this thread is about mirror layout; and is not about removing the distinction between supported packages and not. (this wasn't all that clear to me at first.) i do understand that you think other methods of having the distinction might not work; i have reservations myself that way. (i do feel the disctinction is important.) i also see that mirror layout should be as easy as possible for mirror admins. however, looking at the big picture, i think that logically it's sounds to have one purpose to one thing; and thus for the mirror layout; only the mirror admins should be looked at; the viewpoint of a user _should_ not really matter.
Re: [Mageia-dev] Mirror layout, round two
Maarten Vanraes a écrit : Op woensdag 01 december 2010 21:54:48 schreef andre999: [...] allthough interesting, this thread is about mirror layout; and is not about removing the distinction between supported packages and not. (this wasn't all that clear to me at first.) I'll discuss further down why I think that this is a critical part of the question. i do understand that you think other methods of having the distinction might not work; i have reservations myself that way. (i do feel the disctinction is important.) Glad to see that you understand my concerns. i also see that mirror layout should be as easy as possible for mirror admins. Agreed. However keeping an extra set of repositories for core packages would just add a few extra directories (without changing the number/size of their total content), thus have little impact on mirror administration. However tainted repositories, being optional, would be more problematic. Especially, as others pointed out, for the larger multi-project mirror sites, where admins are already distracted by many other demands. On the other hand, I see the point of adding tainted. Since it is for packages that are likely to be problematic in *some* countries, I imagine that relatively few of these larger mirror admins would feel the need to exclude tainted. (And for the same reason my quibble about choosing a more neutral name, such as restricted. Or maybe even problematic. For countries where these packages would be acceptable.) In any case, rsync is a pretty straight-forward application. however, looking at the big picture, i think that logically it's sounds to have one purpose to one thing; and thus for the mirror layout; only the mirror admins should be looked at; the viewpoint of a user _should_ not really matter. I agree that the user viewpoint is not of major importance : I see that as just a positive side effect. I am trying to look at the big picture. And perhaps I haven't been very effective at expressing my concerns. In my mind, we should always consider important side effects of major changes. And removing separate core/extra (or main/contrib repositories does have an important side effect. Realigning core so it is really core should very much help packagers, as well as maintaining an important distinction. Note that if, down the road, we find another effective method for distinquishing core / non-core, it is relatively simple to transfer packages in extra to core. But if we eliminate the parallel set of repositories, and find later that we have a problem giving priority to core packages, moving in the other direction would be a much more difficult process. The suggestion that we only transfer to Mageia packages that we see as important to keep, sounds like a very good approach. This would also facilitate maintaining the core / non-core distinction. I'm not trying to say that defining core / non-core in detail is a trivial process. But it is in the interest of Mageia to define it. I realise, at least at first, that things will be more difficult for packagers. But firmly believe that this will be largely alleviated by a careful triage of existing main and contrib packages. Thus I am more than willing to put in a lot of effort, since it will have an important impact on the future of Mageia. I also realise that many of those proposing eliminating a set of repos have a lot of valuable experience. And I'm sure that if/when we can agree on this concern, that we will be able to work very well together. And I look forward to becoming a Mageia packager. another 2 cents :) - André
Re: [Mageia-dev] Mirror layout, round two
I think this whole question is not done with an easy answer. It can also not be ssen in a black/white mode. I see the clear insight of Michael's suggestion which is a black/white point of view. Not maintained? Kick it out (well, not out but into the ante-room). But I also see the reality from the user's POV. As for technical skilled or experienced users (including server admins) the main question is that those packages which are available should work and be maintained. Period. But there is also the vast group of the unwashed masses including those we want to attract to Mageia. Many of those do look at the sheer number of packages (like, I'd rather switch to Foo Linux which offers 2 million packages while Mageia only offers 5,000). Yes, I know, it's rather dumb and those users are the first to complain about some missing icon. But they are a large part of the users out there. So we have to find a middle way between the pure and the ugly. How to find that, I don't know, this is far beyond my knowledge. I only wanted to comment on the philosophical side of the problem. For me as a mostly non-technical guy the best solution would be the flag solution. Forget the main/contrib split and just flag unmaintained rpms so that the user sees it in the GUI. How to accomplish that on the CLI with urpmi I don't know. Then people who are security- aware like server admins can easily avoid unmaintained packages or open a request in Bugzilla which **may** inspire somebody to pick up the poor unmaintained package. One comment on the mirror maintainer part of the story: I was mentioned by Michael several times as an example of a certain kind of mirror maintainers. Yes, ressources are tight but not that tight. As I understood the official mirror as suggested by Olivier was about to fill up to 700 GB during the next 3 years - given that we will have 2 releases per year. Most of the official mirrors of Mandriva do not provide 6 releases, moreso when the life cycle of a release is less than 2 years. So, a realistic size woul be more like 450-500 GB at the most which is easily done with today's hardware. This is not a problem. Time is not a problem either for such people like me. The only problem I still see from the mirror maintainer's side is the way to deal with tainted packages wrt the mirrorlist (as already mentioned). -- wobo
Re: [Mageia-dev] Mirror layout, round two
On 30 November 2010 07:29, andre999 and...@laposte.net wrote: Michael Scherer a écrit : Le lundi 29 novembre 2010 à 20:54 -0500, andre999 a écrit : Yann Ciret a écrit : I dislike the main/contrib separation in some case. The first example is with Mozilla Thunderbird packages. Some extension packages are in contrib. So each time thunderbird received security update, the update cannot be installed because of non automatically rebuild of his contrib package. And each time I see a bug report of user asking a manual rebuilt. With only one core media, this situation will disapear (I hope). Unlikely. This problem is not at all related to separate repositories. It is. It is exactly related to the fact that thunderbird is supported, and that extension are not despites depending on it. In this case it is evident that you don't understand how extensions work with mozilla products. Thunderbird will function correctly with no extensions installed. So why should any extension block the update of Thunderbird ? So the user can simply uninstall that extension and update to new thunderbird? the user can do this only if he doesn't need that extension, only if it doesn't offer features he wants to use. That's an invalid argument, if he doesn't need that extension why does he have it on his system?? The rationale is/was that mozilla code breaks/broke ABI, so it was agreed that extensions are rebuilt for both firefox and thunderbird respective new versions. We will look into that with upstream, so that if a rebuild isn't needed, then all the better for us (packagers). But until that happens, they will be rebuilt. A 1-2 day delay isn't too much for users. The more pressing issue is, what does this have to do with the topic at hand Mirrors layout, round two ?? this discussion is deviating too much, to the extent it's becoming bloated... Additionally, modules installed will continue to work as long as the major version doesn't change. (Actually slightly more complicated.) In some cases one won't be able to newly install a module because a config file inside the module - equivalent to the spec file in rpm packages - hasn't been updated for compatible versions. (In fact, the versions were probably improperly specified.) But installed modules will continue to function. It is possible that the packager did not realise this - or for whatever reason did not properly set up a spec file - but this issue has nothing at all to do with separate sets of repositories. Speaking abstractly without examples in this case is just that, speaking. Give us an example of such a case (if any) in a spec file so that it can be fixed. That precisely because we tell security and bugfixes occurs only on main that contribs got broken, since the security team do not care to not break contribs packages. The crux of this problem is that core (in the general sense) packages are dependant on packages that are not recognized as core. That again has nothing to do with repositories as such. I agree with Michael here, doing sec fixes isn't hard (once one gets used to it), just time consuming, and it should be done for all packages in the official repos; it's true that GPL gives no guarantees what so ever, just it's a moral obligation for people involved in the FOSS world to support users as best they can. Users do not differentiate between main/contrib, there's a package they install it, I don't think they look from which repo it comes from. Rather that one package was updated, and an optional installed module was not. The fact that the module is optional is the key point. The installer should be flexible enough to give a warning in this case, and ask if you wish to continue the installation. So basically, you want a --nodeps ? If there is a requires, there is usually a good reason. Engineering is not randomly adding line to a file until it work. How about better configured spec files ? A better definition (in general) of core packages ? A focus on ensuring that core packages are maintained ? Basically my idea behind a core sandbox. But if you have a better idea ... Again, give us an example of a spec file that needs better configuration, otherwise you're theorising. Just remember, eliminating a supported core breaks the sandbox. So removing repositories does have secondary effects. And they should be seriously considered and discussed by those proposing to remove the repositories. As well, in the case of Thunderbird, it is almost certain that the installed module was in fact compatible with newer version of Thunderbird. (A security problem may directly impact Thunderbird or the module, but highly unlikely both packages.) Rpm tags should have been set so that Thunderbird would recognize that the module was appropriate in the newer version. No. If there is stricter dependency, it is precisely because there is no guarantee of any kind of ABI between thunderbird
Re: [Mageia-dev] Mirror layout, round two
So, after reading all different opinions here and discussing with founders, here is the idea: We start of with 3 medias: core, nonfree, tainted and 3 debug medias: debug_core, debug_nonfree, debug_tainted. In order to avoid confusion, we wont use the name restricted as it was used in MDV commercial products. Now all of theese medias will have their 5 submedias: release, updates, updates_testing, backports, backports_testing. That brings us to 30 medias in total :) The details of the media layout suggestion is also at the end of this mail, and at: http://mageia.org/wiki/doku.php?id=mirrors_policy Now... We wont blindly import every package from cooker, instead we'll start off the import with basesystem (as in bootable system with shell access), compiler and rpm tools (and of course their buildtime depencies). When all of that is imported and rebuilt, we have a working buildsystem / base to build from. Then we to go on with and start importing X, the different DE's and every other package needed to build a full distro. By doing it this way, we get a clean start, every package rebuilt, and no old/unmaintained stuff in the beginning. Then as more maintainers join, I guess more packages will be imported from cooker and other sources. And packages can always be requested. As for those that want the core/extra split: We already tried it with main/contrib split. And I know mdv is now trying to refine what belongs in main or not, but thats for mdv to work through the problem as it wont be an easy task. For us I think the best way for now is to start with this suggested layout, and see if it works well for us. Remember, as Michael pointed out, this is a community supported distro, and only time will tell how well the community actually will support their distro. Point is, if we later decide this is not working well, we can always review the decisions and if decided do the split. Can we reach an agreement that this is the way to start the distro? and for refernece: The suggested layout for is: * core - enabled by default - mirrors must mirror this media to be listed as a mirror - only free/libre stuff as described by FSF / OSI - must be selfcontained * nonfree - disabled by default, installer will ask to enable it if it detects hw that need driver/fw from here - mirrors must mirror this media to be listed as a mirror - contains apps/drivers/firmware that are free to redistribute but we dont have redistributable source for - for example: ati/nvidia drivers/firmware, Oracle Java, Adobe stuff we might get redistribution permission for * tainted - disabled by default - mirrors are free to not mirror this media ( ? ) - stuff we think we can redistribute, but that may have some patent issues or other legal restrictions - what belongs / is allowed here must still be discussed * debug_core - disabled by default - debug rpms for core * debug_nonfree - disabled by default - debug rpms for nonfree * debug_tainted - disabled by default - debug rpms for tainted Every media contains the same layout: * backports - disabled by default * backports_testing - disabled by default * release - disabled by default on nonfree, installer will ask to enable it if it detects hw that need driver/fw from here - disabled by default on tainted, debug_core, debug_nonfree, debug_tainted * updates - disabled by default on nonfree, installer will ask to enable it if it detects hw that need driver/fw from here - disabled by default on tainted, debug_core, debug_nonfree, debug_tainted * updates_testing - disabled by default -- Thomas
Re: [Mageia-dev] Mirror layout, round two
On 10/11/30 12:37 +0200, Thomas Backlund wrote: We wont blindly import every package from cooker, instead we'll start off the import with basesystem (as in bootable system with shell access), compiler and rpm tools (and of course their buildtime depencies). When all of that is imported and rebuilt, we have a working buildsystem / base to build from. Then we to go on with and start importing X, the different DE's and every other package needed to build a full distro. By doing it this way, we get a clean start, every package rebuilt, and no old/unmaintained stuff in the beginning. Then as more maintainers join, I guess more packages will be imported from cooker and other sources. And packages can always be requested. sounds sensible to me. questions: - how will the import be done? - is it up for the maintainer to request it? or only for non-base system packages? - or does the maintainer has a magic command to do? - will submitting a package for rebuild bork the list of maintainer (mdv uses the maintainer = 1st to submit scheme) - do we have an estimated planning with the different steps? jérôme -- jque...@gmail.com
Re: [Mageia-dev] Mirror layout, round two
Le mardi 30 novembre 2010 07:37:42, Thomas Backlund a écrit : So, after reading all different opinions here and discussing with founders, here is the idea: We start of with 3 medias: core, nonfree, tainted and 3 debug medias: debug_core, debug_nonfree, debug_tainted. In order to avoid confusion, we wont use the name restricted as it was used in MDV commercial products. [...] We wont blindly import every package from cooker, instead we'll start off the import with basesystem (as in bootable system with shell access), compiler and rpm tools (and of course their buildtime depencies). When all of that is imported and rebuilt, we have a working buildsystem / base to build from. Are you (not specifically you thomas :p) going to check again the basesystem dependencies/requirements, if i remember correctly the basesystem in mandriva is not anymore a « real » basesystem ? Then we to go on with and start importing X, the different DE's and every other package needed to build a full distro. Should not each package imported directly by the maintener here (for the DE), so he's going to import (hopefully ?) only the real requirements so we'll be able to drop « more » unused packages maybe? [...] Can we reach an agreement that this is the way to start the distro? Sure (even if i'm not followed for the 2 points before :p ) Regards, -- Balcaen John IRC: mikala on freenode.org XMPP: mik...@jabber.littleboboy.net
Re: [Mageia-dev] Mirror layout, round two
On Tue, 30 Nov 2010, Thomas Backlund wrote: So, after reading all different opinions here and discussing with founders, here is the idea: We start of with 3 medias: core, nonfree, tainted and 3 debug medias: debug_core, debug_nonfree, debug_tainted. In order to avoid confusion, we wont use the name restricted as it was used in MDV commercial products. Now all of theese medias will have their 5 submedias: release, updates, updates_testing, backports, backports_testing. That brings us to 30 medias in total :) The details of the media layout suggestion is also at the end of this mail, and at: http://mageia.org/wiki/doku.php?id=mirrors_policy [...] Can we reach an agreement that this is the way to start the distro? I agree with this proposal.
Re: [Mageia-dev] Mirror layout, round two
Le mardi 30 novembre 2010 11:37:42, Thomas Backlund a écrit : So, after reading all different opinions here and discussing with founders, here is the idea: We start of with 3 medias: core, nonfree, tainted and 3 debug medias: debug_core, debug_nonfree, debug_tainted. In order to avoid confusion, we wont use the name restricted as it was used in MDV commercial products. Now all of theese medias will have their 5 submedias: release, updates, updates_testing, backports, backports_testing. That brings us to 30 medias in total :) The details of the media layout suggestion is also at the end of this mail, and at: http://mageia.org/wiki/doku.php?id=mirrors_policy Now... We wont blindly import every package from cooker, instead we'll start off the import with basesystem (as in bootable system with shell access), compiler and rpm tools (and of course their buildtime depencies). When all of that is imported and rebuilt, we have a working buildsystem / base to build from. Then we to go on with and start importing X, the different DE's and every other package needed to build a full distro. By doing it this way, we get a clean start, every package rebuilt, and no old/unmaintained stuff in the beginning. Then as more maintainers join, I guess more packages will be imported from cooker and other sources. And packages can always be requested. As for those that want the core/extra split: We already tried it with main/contrib split. And I know mdv is now trying to refine what belongs in main or not, but thats for mdv to work through the problem as it wont be an easy task. For us I think the best way for now is to start with this suggested layout, and see if it works well for us. Remember, as Michael pointed out, this is a community supported distro, and only time will tell how well the community actually will support their distro. Point is, if we later decide this is not working well, we can always review the decisions and if decided do the split. Can we reach an agreement that this is the way to start the distro? OK for me provided support policy matters are not discarded forever but only delayed to allow things to start. It would be great to start QA Team's organization as soon as possible. I don't think we need to wait for the BS and the packages to begin thinking about those matters. Regards Samuel
Re: [Mageia-dev] Mirror layout, round two
2010/11/30 Thomas Backlund t...@iki.fi: So, after reading all different opinions here and discussing with founders, here is the idea: For us I think the best way for now is to start with this suggested layout, and see if it works well for us. Remember, as Michael pointed out, this is a community supported distro, and only time will tell how well the community actually will support their distro. Point is, if we later decide this is not working well, we can always review the decisions and if decided do the split. Can we reach an agreement that this is the way to start the distro? Looks ok for me and the easiest layout we may achieve. Still we will need to finalize policies about repositories content. -- Anne http://www.mageia.org
Re: [Mageia-dev] Mirror layout, round two
In Mandriva, you can find many examples of packages in main which are not supported in reality, or even maybe simply don't work. You can find also many packages in contrib which are perfectly supported, in cooker as in stable releases. You gave me examples. However I see very rarely security or bugfix updates for packages in contrib for stable releases (or sometimes they go to backports), whereas there are many security fixes and bugfixes for packages in main thanks to Mandriva's security team. There really is a difference between supported packages and other, although it's far from perfect. The difference is mainly that Mandriva has a team of 2 people full time doing the bugfixes and security updates. We do not have them. So that's not because there is contribs that main got more bugfixes and updates. That's because people are paid to do the work. And so there is no correlation between there is updates in main and there is a split. Yes there is a correlation : there is a team of people working to provide quick support for a set of packages. Without a list of supported packages, they couldn't focus their work. However please remember that I agreed that the split mirror-side is not the only way to achieve such focus. Our main disagreement here is you prefer that we have the same level of support for any package in the distribution (which probably means very few packages in the distribution then) while I'd like many packages in the distribution, a subset of which is officially supported. At least, it worked well enough so that we could send more than 450 servers with Mandriva in French hospitals and use Mandriva at work on workstation. Why do I prefer a large package list to a list restricted to platinum-supported packages : I can build a system where the critical parts are supported, and if I need to add some less supported stuff, I still can. We should compare the ratio between packages in main and packages in contrib which are actually installed on people's systems. On our servers, that would be around 98% coming from main, and less than 2% coming from contrib. On my workstation, it would be probably 75% vs 25%. Main provides stability and security (regardless of some badly supported packages). Contrib provides choice.. Seeing that everything is equally supported is a sign of a lack of quality ? It depends on the amount of available packages and available resources. 1 packages *equally supported* with 30 packages, yep, that would be a sign of a lack of quality. If there are only 1000 packages, of course, this is different. I still prefer the 1000 supported packages + 9000 use-at-your-own-risk packages. Now if there were a list of supported packages, either it would not be officially supported and the user would know he could use it but maybe won't have security and bugfix updates, or it is officially supported. Now take the example above : - Someone checks if postgresql is supported because if not he'll use another distribution where it is - It is ! - However the maintainer went away doing his own fork, so he dropped maintainership. - Someone in QA Team rings a bell : this supported package isn't supported anymore, but we promised we would support it for Mageia 2011 for 2 years from now ! We have to do something ! - The package team leader, or someone else, relays the warning and finds someone else to maintain the package, at least for Mageia 2011, for security and bugfix updates. Please, I would appreciate that you do not arrange facts just to support your point, or I will seriously have to reconsider answering in the futur. In the first case : package is not supported, no one step to maintain, we drop - that's bad. second case : package is not supported, someone step, we don't drop - that's good Why do you make the assumption that someone will step to maintain in 2nd case and not in the first one ? Just saying it should be supported because it is on some official list is not really something that worked that well at Mandriva for the community. The way you make a caricature of my arguments is rude here. What I'm saying is totally different : In the first case : - no one steps in to maintain it. We drop it. In the second case : - no one steps in to maintain it. Because we promised to support it, and because there are people who care about that (the QA Team Leader for example), we would *try very hard* to find a solution. this is a problem, we identify the problem, we try to solve it. Maybe we fail, but at least we try hard, because the package is on the supported list. In my example I supposed we find a solution, because I suppose that we find it. If I were that kind of person who cares, I'm sure I would find someone. Of course, if we flag too much packages as supported, then it may become actually impossible to support them all,
Re: [Mageia-dev] Mirror layout, round two
Jerome Quelin skrev 30.11.2010 12:48: On 10/11/30 12:37 +0200, Thomas Backlund wrote: We wont blindly import every package from cooker, instead we'll start off the import with basesystem (as in bootable system with shell access), compiler and rpm tools (and of course their buildtime depencies). When all of that is imported and rebuilt, we have a working buildsystem / base to build from. Then we to go on with and start importing X, the different DE's and every other package needed to build a full distro. By doing it this way, we get a clean start, every package rebuilt, and no old/unmaintained stuff in the beginning. Then as more maintainers join, I guess more packages will be imported from cooker and other sources. And packages can always be requested. sounds sensible to me. questions: - how will the import be done? It will be done by reviewing every srpm, drop anything mdv owned/trademarked, and then committed to svn. This is to get a clean svn to start from. - is it up for the maintainer to request it? or only for non-base system packages? - or does the maintainer has a magic command to do? maintainers will be able to import stuff into svn themselves. More to follow soon regarding packagers / cleanup work. We will notify users when we open up the svn so people can start reviewing/cleaning packages and commit it to svn Then a new notification will be sent when we consider BS fully open. - will submitting a package for rebuild bork the list of maintainer (mdv uses the maintainer = 1st to submit scheme) I guess that will be so atleast for now. This will be refined for packaging teams/maintainer groups... - do we have an estimated planning with the different steps? Not yet, there are still some fixes needed to be done on youri to get it fully working. -- Thomas
Re: [Mageia-dev] Mirror layout, round two
Balcaen John skrev 30.11.2010 12:50: Le mardi 30 novembre 2010 07:37:42, Thomas Backlund a écrit : So, after reading all different opinions here and discussing with founders, here is the idea: We start of with 3 medias: core, nonfree, tainted and 3 debug medias: debug_core, debug_nonfree, debug_tainted. In order to avoid confusion, we wont use the name restricted as it was used in MDV commercial products. [...] We wont blindly import every package from cooker, instead we'll start off the import with basesystem (as in bootable system with shell access), compiler and rpm tools (and of course their buildtime depencies). When all of that is imported and rebuilt, we have a working buildsystem / base to build from. Are you (not specifically you thomas :p) going to check again the basesystem dependencies/requirements, if i remember correctly the basesystem in mandriva is not anymore a « real » basesystem ? Well, technically it's basesystem-minimal that should be just that: minimal. but it will be reviewed as everythng else. Then we to go on with and start importing X, the different DE's and every other package needed to build a full distro. Should not each package imported directly by the maintener here (for the DE), so he's going to import (hopefully ?) only the real requirements so we'll be able to drop « more » unused packages maybe? [...] Can we reach an agreement that this is the way to start the distro? Sure (even if i'm not followed for the 2 points before :p ) -- Thomas
Re: [Mageia-dev] Mirror layout, round two
Samuel Verschelde skrev 30.11.2010 13:04: Le mardi 30 novembre 2010 11:37:42, Thomas Backlund a écrit : So, after reading all different opinions here and discussing with founders, here is the idea: We start of with 3 medias: core, nonfree, tainted and 3 debug medias: debug_core, debug_nonfree, debug_tainted. In order to avoid confusion, we wont use the name restricted as it was used in MDV commercial products. Now all of theese medias will have their 5 submedias: release, updates, updates_testing, backports, backports_testing. That brings us to 30 medias in total :) The details of the media layout suggestion is also at the end of this mail, and at: http://mageia.org/wiki/doku.php?id=mirrors_policy Now... We wont blindly import every package from cooker, instead we'll start off the import with basesystem (as in bootable system with shell access), compiler and rpm tools (and of course their buildtime depencies). When all of that is imported and rebuilt, we have a working buildsystem / base to build from. Then we to go on with and start importing X, the different DE's and every other package needed to build a full distro. By doing it this way, we get a clean start, every package rebuilt, and no old/unmaintained stuff in the beginning. Then as more maintainers join, I guess more packages will be imported from cooker and other sources. And packages can always be requested. As for those that want the core/extra split: We already tried it with main/contrib split. And I know mdv is now trying to refine what belongs in main or not, but thats for mdv to work through the problem as it wont be an easy task. For us I think the best way for now is to start with this suggested layout, and see if it works well for us. Remember, as Michael pointed out, this is a community supported distro, and only time will tell how well the community actually will support their distro. Point is, if we later decide this is not working well, we can always review the decisions and if decided do the split. Can we reach an agreement that this is the way to start the distro? OK for me provided support policy matters are not discarded forever but only delayed to allow things to start. It wont be discarded. We need to list package priority, wich ones must go through QA, and wich ones that are subject to maintainer qa testing It would be great to start QA Team's organization as soon as possible. I don't think we need to wait for the BS and the packages to begin thinking about those matters. Yes, its time to start defining policies around all this and team creation. -- Thomas
Re: [Mageia-dev] Mirror layout, round two
Anne nicolas skrev 30.11.2010 13:15: 2010/11/30 Thomas Backlundt...@iki.fi: So, after reading all different opinions here and discussing with founders, here is the idea: For us I think the best way for now is to start with this suggested layout, and see if it works well for us. Remember, as Michael pointed out, this is a community supported distro, and only time will tell how well the community actually will support their distro. Point is, if we later decide this is not working well, we can always review the decisions and if decided do the split. Can we reach an agreement that this is the way to start the distro? Looks ok for me and the easiest layout we may achieve. Still we will need to finalize policies about repositories content. True. A post on that will follow later today/tomorrow. -- Thomas
Re: [Mageia-dev] Mirror layout, round two
Michael Scherer skrev 30.11.2010 14:23: Le mardi 30 novembre 2010 à 07:50 -0300, Balcaen John a écrit : Le mardi 30 novembre 2010 07:37:42, Thomas Backlund a écrit : So, after reading all different opinions here and discussing with founders, here is the idea: We start of with 3 medias: core, nonfree, tainted and 3 debug medias: debug_core, debug_nonfree, debug_tainted. In order to avoid confusion, we wont use the name restricted as it was used in MDV commercial products. [...] We wont blindly import every package from cooker, instead we'll start off the import with basesystem (as in bootable system with shell access), compiler and rpm tools (and of course their buildtime depencies). When all of that is imported and rebuilt, we have a working buildsystem / base to build from. Are you (not specifically you thomas :p) going to check again the basesystem dependencies/requirements, if i remember correctly the basesystem in mandriva is not anymore a « real » basesystem ? The explicit goal is to be able to boot, and start bash. Not bash and be able to do anything useful with it :) ( ok, maybe a script with /dev/tcp to say hello on irc ). So if basesystem as a rpm is not enough, we will import what is needed to complete it. or basesystem-minimal :) -- Thomas
Re: [Mageia-dev] Mirror layout, round two
On Tue, Nov 30, 2010 at 13:29, Samuel Verschelde sto...@laposte.net wrote: What I'm saying is totally different : In the first case : - no one steps in to maintain it. We drop it. In the second case : - no one steps in to maintain it. Because we promised to support it, and because there are people who care about that (the QA Team Leader for example), we would *try very hard* to find a solution. this is a problem, we identify the problem, we try to solve it. Maybe we fail, but at least we try hard, because the package is on the supported list. Ok, it's a degree of support management: - first case, dropping is automatic, - second case, we turn the red light on and try to organise around this to find a best effort solution. But, in the second case, relying exclusively on the community, for the support promise to work, you have to show that you have either some separate incentive, either a large enough community to grow the chances for this to happen. another solution : we do no promises of supporting anything. This is a solution. Not mine however. Not promising of something to happen is not a promise of this thing not to happen. Such a promise of support is much more sustainable if you have a clear, identifiable incentive or reason or experience (for the people you promise to) to keep it. There are differences between: * guaranteed, * trying very hard, * best effort, * good will, * nothing pretended support promises. Let me present the idea differently. There are 2 levels of support : - top guaranteed support (a subset of packages) : those are packages your can rely on blindly, they'll be updated in a timely manner. Those are the packages the QA Team puts its limited resources on (doesn't mean the QA Team provides support, but they check that good support is provided). The maintainer is responsible for the package, but the QA Team is vigilant about them. - supported packages (every other package) : those are maintained packages, however the QA Team doesn't have to check them. It's up to the maintainer. - unsupported packages are dropped. So everything is supported, but there a special level of support for some critical components. Just saying, but as packages support is to be distributed, we may as well have commercial companies step around and manage this kind of support: * within/through Mageia through their employees (so, it matches our policies, that's the idea), * because it matches their activity/interest (they build the software, they consult/sell/build around it). To help thinking about that (in the future, because now we have nothing to track/compare) we need to collect and report relevant data about packages management experience (supported, not supported, number of updates, maintainers, time to push an update, etc.) against a first policy. So we can measure what happens and what can be reasonably changed/expected in the future. Romain
