Re: Question about repositories
Le 23/10/2020 à 15:22, negin jafari a écrit : > Dear sir or madam, > > I am a university Student trying to learn a lot of things about Debian. > I searched all the website about list of repositories but I could only > find the link below : > http://ftp.acc.umu.se/debian/ > Is there only one repository for Debian or are there more ? What are > their links? Hi, See https://www.debian.org/mirror/list (both sources and binaries) > Is there any security repository or source repositories ? What are their > links? http://security.debian.org/debian-security/ (both sources and binaries) > I really need to know this and I’d be really thankful for your answer. > Best regards > > Negin jafari Cheers, Xavier
Re: Salsa as authentication provider for Debian
Le 07/04/2020 à 18:50, Sam Hartman a écrit : >>>>>> "Xavier" == Xavier writes: > > Xavier> Le 07/04/2020 à 17:20, Paul Wise a écrit : > >> On Mon, Apr 6, 2020 at 3:58 PM Bastian Blank wrote: > >> > >>> ## Highlevel plan > >> > >> I'd like to learn a bit about what the effects for Debian account > >> holders and service admins will be. > >> > >>> - Salsa becomes primary source of user info and authentication > >>> for secondary services via OpenID Connect (OAuth2), for both DDs > >>> and non-DDs, replacing sso.debian.org. > >> > >> It sounds like the answer is no, but does Salsa, Keycloak or > >> LemonLDAP::NG support TLS client certs? > > Xavier> LLNG and KeyCloack support TLS authentication, 2FA,... See > Xavier> > https://lemonldap-ng.org/documentation/latest/start#authentication_users_and_password_databases > Xavier> for a complete list of LLNG supported authentication > Xavier> mechanisms > > I authenticate using TLS to the SSO server. > But then I use http redirects or JSON tokens to authenticate to the > protected app, right? Hi, Yes or secured-cookie. OIDC or SAML share authentication level with applications. With LLNG ≥ 2.0, you can restrict OIDC/SAML using a rule (which can read auth level). Handlers applies the rule given by LLNG so they can require a strong level or not > llng does not end up being a short-lived CA like the current > sso.debian.org SSL handshake is done by portal web server, so you have the same features than with any webserver
Re: Salsa as authentication provider for Debian
Le 08/04/2020 à 17:28, Luca Filipozzi a écrit : > reminder: I'm replying linearly and from what I know (keycloak, SAML and > OIDC). > > > On Tue, Apr 07, 2020 at 12:20:40PM +0200, Xavier wrote: >> Le 05/04/2020 à 20:46, Bastian Blank a écrit : >> I can help if you want to use lemondap-ng (LLNG: >> https://lemonldap-ng.org https://tracker.debian.org/pkg/lemonldap-ng) > > Cool. > >> This requires to change all services. Using a SSO is easier here: >> gatekeeper (KeyCloack) or handler (LLNG) permits to protect a web app >> without having to change to many things. LLNG handlers are directly >> included in Apache/Nginx configuration and provides HTTP-headers to the >> web app. > > Or Apache modules like mod-auth-openidc (OIDC) or mod-auth-mellon > (SAML). Hi, LLNG handlers are apache modules. The difference is that they don't only manage authentication but also authorizations >> Other way, LLNG is able to be a proxy between OAuth (OpenID-Connect) and >> any other SSO-language (CAS, SAML, OpenID-2) or handlers. The portal >> then becomes transparent > > Keycloak, as a broker, is similar. Service provider can be using one > protocol and the identity provider another. > >> It's easy to integrate GitLab in SSO using SAML (or OIDC). It is perhaps >> more safe to manage users elsewhere (custom app) and make GitLab a slave >> of SSO system. LLNG provides a plugin engine for that. > > Gitlab can use OIDC for OmniAuth, so it can authenticate against any > OIDC-compliant IdP, LLNG and Keycloak included. > >> NB: KeyCloak is free but this needs to stay in last version, else you >> need a RedHat-SSO support. LLNG is totally free, written in Perl and JS; >> and Debian has a lot of Perl-Gurus ;-). > > Redhat has the distinction (thankfully) of not following a 'freemium' > model (at least for Directory389 and Keycloak). The features available > in RedHat SSO and Keycloak are identical. Redhat SSO lags behind > Keycloak but may include fixes not yet ported to Keycloak. Keycloak is > also totally free and, yes, is written in Java. > >> I can give some accounts to demo platform: https://auth.openid.club/ >> [dev platform, so sometime broken...] or install an instance in a Debian >> machine if you want to try it. > > > Please work with Michael Lustfield (IRC MTecknology) as he is also > interested in setting upa Debian-specific instance of LLNG. With pleasure ! >> Resume of proposition: >> * all users managed by SSO; > > Agree! > >> * self-registration authorized with "-guest" >>in a distinct LDAP branch > > More thought required but don't disagree. > >> * GitLab becomes a slave of SSO using SAML (or OIDC) > > Agree! > >> * other applications are protected by handlers/GateKeepers. If LLNG is >>chosen, just to add few lines in Nginx configuration > > Agree and/or mod-auth-openidc/mod-auth-lemon, etc. > >> * new applications can be protected using handlers, SAML, CAS, OIDC,... > > Agree but with order of preference being OIDC, SAML and... way over > there, almost too distant to see... CAS. Of course, old protocol. Choosing between handlers and federation protocols depends on how we want to manage authorizations: * centralized authorization: handlers (authorization managed by manager application, websites are filtered globally or using regxp on URLs * managed in application: both way This is the choice to do (both ways are possible simultaneously) >> > > Very helpful response! Thanks ;-) --- /me has worked for 15 years on Identity and Access Management (IAM) topics
Re: Salsa as authentication provider for Debian
Le 07/04/2020 à 17:20, Paul Wise a écrit : > On Mon, Apr 6, 2020 at 3:58 PM Bastian Blank wrote: > >> ## Highlevel plan > > I'd like to learn a bit about what the effects for Debian account > holders and service admins will be. > >> - Salsa becomes primary source of user info and authentication for secondary >> services via OpenID Connect (OAuth2), for both DDs and non-DDs, replacing >> sso.debian.org. > > It sounds like the answer is no, but does Salsa, Keycloak or > LemonLDAP::NG support TLS client certs? LLNG and KeyCloack support TLS authentication, 2FA,... See https://lemonldap-ng.org/documentation/latest/start#authentication_users_and_password_databases for a complete list of LLNG supported authentication mechanisms > So it sounds like Debian would be switching our SSO authentication > protocol from TLS client certs directly supported by TLS clients to > something based on HTTP redirects, referrers and cookies and that > requires a browser in order to login? Authentication gives an "authenticationLevel". You can restrict some applications to TLS, some other to "password+2FA or TLS" and authorize some other to use simple authentication > It seems like one side effect of the protocol change is that login > events are centralised on the SSO service rather than at each > individual service. > > Is there anything else that account holders need to be aware of? > >> - nm.debian.org uses Salsa usernames by default to populate LDAP usernames >> when >> creating accounts, and stores OIDC subject to strongly correlate between >> Salsa and Debian LDAP users. Application profiles can be managed by SSO (give profile to app and/or restrict some URL to a particular group [handler/GateKeeper only]) > Is it intended that service maintainers each implement OpenID Connect > etc within their service code using existing libraries, or should we > use something like the mod_auth_openidc Apache module to pass > authentication details to service code. Both are possible but handler/GateKeeper can do the job > https://github.com/zmartzone/mod_auth_openidc > > Can services using non-HTTP protocols be authenticated with OpenID Connect > etc? > > Is it intended that there be moderation at account creation time? In > our experience with the Debian wiki, a large amount of spammers > attempt to sign up. I hear that Salsa gets a lot of spammers signing > up too and those are manually cleaned up if they do something spammy. Yes, possible > For the wiki we found the best way to prevent spammers from signing up > is human moderation. Even that doesn't always help as I've let > spammers sign up before based on the content of their signup emails, > but it is a good start. One very nice aspect of the wiki signup > moderation is that the team can respond to aspects of the signup > email, welcoming the applicant with pointers to documentation, > suggestions of ideas on how to help, mailing lists to join and so on. > > Is there anything else that service admins need to be aware of?
Re: Salsa as authentication provider for Debian
Le 07/04/2020 à 16:02, Enrico Zini a écrit : > On Tue, Apr 07, 2020 at 03:28:07PM +0200, Xavier wrote: > >> With a SSO, I don't think it's a good thing to have a protected app as >> user database (even if it's possible). Then migration consists to >> extract gitlab accounts and push them in LDAP (2 branches, one for DD, >> one for guests) > > Ok, please help me to see where that would be an issue. It's not an issue. With a SSO we shall probably change this: salsa accounts will be created on-the-fly using federation mechanism, then there is only one user database (LDAP with 2 branches) > The current status of accounts, is that: > > - There is only one LDAP server, DSA-managed, on db.debian.org, which >has accounts that do not end in "-guest". They may be DD or ex-DD >accounts, or "guest accounts" created for non-DDs who need to have >temporary access to porterboxes > > - There are accounts ending in "-guest" (that are not "guest >accounts"), that are not managed by DSA, and used to be on Alioth's >separate LDAP when alioth existed. > > - "-guest" accounts for purposes on sso.debian.org authentication are >now stored on a hand-maintained text file that is exported somehow to >serve as an apache authentication source for sso.debian.org > > - "-guest" accounts on Salsa are stored on Salsa's user database > > We currently have all sorts of overlaps and corner cases: > > - "guest accounts" in LDAP that do not end in "-guest" and are for >non-DDs > - "-guest" accounts in Salsa for DDs and ex-DDs, with the part before >"-guest" not matching the LDAP account name. > > I wonder if we have the same "-guest" accounts in Salsa and in the > sso.debian.org text file, that are controlled by different people? > > With the Salsa proposal: > > - the text file disappears, reducing the count of user databases from 3 >to 2 > - LDAP remains as it is, and Salsa remains as it is > - DD accounts remain on LDAP > - We gain an explicit mapping between LDAP accounts and Salsa accounts, >via nm.debian.org, that we currently do not have > - People who gain or lose DD status can keep using their Salsa account >without needing to migrate from "something-guest" to "something", or >from "something" to "something-guest" > > With the Salsa proposal the only change from here that I can see is that > we would start to have non-DD accounts on Salsa that do not end with > "-guest", like we already have non-DD accounts on LDAP now that do not > end with "-guest". > > I still don't see how the Salsa proposal makes adoption of a new system > harder than what we have now: removing one user database and introducing > a mapping between the remaining two, seem to me to make further > adoptions actually easier. No not harder, just different ;-)
Re: Salsa as authentication provider for Debian
Le 07/04/2020 à 14:38, Enrico Zini a écrit : > On Tue, Apr 07, 2020 at 02:31:31PM +0200, Xavier wrote: > >>> I'll ask you the same question I asked Luca: is there something in the >>> Salsa proposal that would prevent further experimentation with LLNG and >>> eventually possibly integrating it into the ecosystem, or migrating to >>> it? >> >> No, just to migrate accounts > > Could you give some more detail of what you mean? With a SSO, I don't think it's a good thing to have a protected app as user database (even if it's possible). Then migration consists to extract gitlab accounts and push them in LDAP (2 branches, one for DD, one for guests)
Re: Salsa as authentication provider for Debian
Le 07/04/2020 à 13:50, Enrico Zini a écrit : > On Tue, Apr 07, 2020 at 12:20:40PM +0200, Xavier wrote: > >> Resume of proposition: >> * all users managed by SSO; self-registration authorized with "-guest" >>in a distinct LDAP branch >> * GitLab becomes a slave of SSO using SAML (or OIDC) >> * other applications are protected by handlers/GateKeepers. If LLNG is >>chosen, just to add few lines in Nginx configuration >> * new applications can be protected using handlers, SAML, CAS, OIDC,... >> >> > > I greatly appreciate yours and Luca's and Michael's proposals, and > offers of help. Thanks ! > I would like to avoid stalling progress on sso on things like analysis > paralysis, or like sorting out deployment details, as happened in the > last years. > > I'll ask you the same question I asked Luca: is there something in the > Salsa proposal that would prevent further experimentation with LLNG and > eventually possibly integrating it into the ecosystem, or migrating to > it? No, just to migrate accounts > If not, then we could start with that, which requires no deployment of > new software, and on which we can make progress immediately, and buy > time for everyone to work out the perfect solution, meanwhile moving on > from an unsustainable status quo. > > As a side effect of an interim on Salsa, services can begin to migrate > from client certificates to OIDC, switching to a mode widely used, > usable, and flexible standard, which I wouldn't be surprised if it would > make things easier when moving to something else later on. > > Enrico Little addon: LLNG has a GPG auth plugin, this can be useful to self-reinitialize lost passwords or unlock accounts if password policy blocks it and/or register new DDs
Re: Salsa as authentication provider for Debian
nc. > - Check for username conflicts. > > ### sso.debian.org > > - Authenticate via OIDC to provide certificate management for a transition > period, until all sso-using services have migrated to OIDC > > ## Exit plan > > Should GitLab and/or Salsa become unmaintainable, what do we need to migrate > away? It's easy to integrate GitLab in SSO using SAML (or OIDC). It is perhaps more safe to manage users elsewhere (custom app) and make GitLab a slave of SSO system. LLNG provides a plugin engine for that. > We can export username, e-mail addresses, group membership and OIDC subject > into a new system. Passwords may not be portable. > > Most OIDC using services allow multiple authentication providers out of the > box, so adding a new authentication system can be straightforward. If > replacing > Salsa, the issue would be to map user-related information from Salsa's OIDC > subject to whatever the new system uses, and data can be exported from Salsa > to > help creating such mapping lists services can use to transition. NB: KeyCloak is free but this needs to stay in last version, else you need a RedHat-SSO support. LLNG is totally free, written in Perl and JS; and Debian has a lot of Perl-Gurus ;-). I can give some accounts to demo platform: https://auth.openid.club/ [dev platform, so sometime broken...] or install an instance in a Debian machine if you want to try it. Resume of proposition: * all users managed by SSO; self-registration authorized with "-guest" in a distinct LDAP branch * GitLab becomes a slave of SSO using SAML (or OIDC) * other applications are protected by handlers/GateKeepers. If LLNG is chosen, just to add few lines in Nginx configuration * new applications can be protected using handlers, SAML, CAS, OIDC,... My 2 cents... Cheers, Xavier (yadd)
Re: are Debian mentors nuts? the DebConf scandal
Le 29/12/2019 à 13:25, Ondřej Surý a écrit : > My guess this is the same individual that is harassing our lists. Maybe we > should finally involve lawyers+police and start protecting our community, the > Debian community. > > I am pretty sure that the targeted harassment and release of debian-private > archives is punishable by law at least in some jurisdictions. GDPR also comes > to a mind. > > So, I think an official legal action is required now. Sure, the best shall be an official action from Mary-Anne: she is the victim Cheers, Xavier
Re: Do we still value contributions?
Le 25/12/2019 à 21:18, Charles Plessy a écrit : > Le Tue, Dec 24, 2019 at 11:11:43AM -0500, Scott Kitterman a écrit : >> >> More generally, New is being processed as fast as it can given available >> volunteer time. Any delays are not reflective of a lack of value placed on >> people's contributions. > > Hi Scott, John, everybody, > > In the past I proposed a system of peer review to pre-screen the > packages that are in the NEW queue. > > https://wiki.debian.org/CopyrightReview > > It never took off but maybe some process along these lines could help > reducing the time needed by the FTP Masters to process the packages ? > > Have a nice day, > > Charles Hi, I think it's a good way. We could perhaps replace peer review by Team review when this (language) team exists. Ftpmaster could trust one or two people in each team and use their review to simplify. Of course, nobody can trust their own work. Cheers, Xavier
Re: Debian and Non-Free Services
Le Mardi, Octobre 08, 2019 09:49 CEST, Michael Lustfield a écrit: > On Sat, 5 Oct 2019 23:42:50 +0200 > Thomas Goirand wrote: > > > So, if someone is not using Github's "advanced" features, like pull > > requests and so on, why that person would care about using Github more > > than using Salsa? > > > > > You may guess that people using github accept pull requests, but you > > > even can't see whether they actually like them -- there are many reasons > > > why people use github, and PRs may not necessarily the specific reason > > > for the repository. > > > > I'm just trying to understand here... > > Apart from the "close to upstream" bit, what would be the reasons? > > I prefer GitHub over Debian's GitLab instance because: > > - It's significantly more stable > + I've seen "GitLab is not responding" more times than I can keep track of > + I've also seen a large number of 500 and 504 errors (at least 1x/wk) > + This reliably fails: https://salsa.debian.org/api/v4/groups/debian > - GitHub often addresses problems quickly; this is rare with salsa > - GitHub takes efforts to provide root cause analysis & lessons learned > - Decisions are discussed, instead of drunken thoughts over chips and salsa > - I've witnessed more changes accepted by GitHub > + Salsa concerns have been met with, "fix it in upstream or go away" > + GitHub concerns have been met with, "this is now an internal incident" > & often fixed within a month or two > - It's a well-known standard solution where many people already have accounts > - GitHub admins are *much* more responsive (for obvious reasons) > > I prefer GitHub over GitLab, in general, because: > > - GitHub doesn't require javascript just to browse repos > - GitHub is often *much* faster to respond to feature requests > - GitHub stages upgrades; improving general stability > - GitLab has a *lot* of weird ACL bugs > + I can create projects in groups that I have no access to maintain > + I can create branches that won't let me force push (git push -f) > + I can create projects that let me push to anything except master > + I can be given maintainer access to a team owning those projects, but > still > run into all the same problems > > I can provide a much longer list, but it shouldn't be necessary. There are > plenty of reasons why someone would prefer GitHub over other alternatives. > Attempting to force one option only going to further divide our community. I heard the same thing when we were migrating from Office to LibreOffice (x ~100.000 users). Freedom has a price. Thank you very much to the salsa teams for the great work they do Cheers, Xavier
Re: Upstream metadata to help our users contribute back to projects we redistribute.
Hi, pkg-js-tools embeds a tool that generates debian/upstream/metadata for Github repositories (github-missing-upstream). dpt from pkg-perl-tools uses this file to link locally upstream repo in "git remote" Le 25 juillet 2019 16:17:13 GMT+02:00, Felipe Sateler a écrit : >On Thu, 25 Jul 2019 17:27:51 +0900, Charles Plessy wrote: > >> Hello everybody, > >Hello Charles, > >> >> (posted on -project because of the context, but answers probably >belong >> to -devel, where I am not subscribed...) >> >> there is an intersting discussion going on about Git and the >preferred >> form for modification of the programs we redistribute. >> >> Indeed, as of today would be hard to say « just run “apt-get source >> ” and voilà, you can hack and contribute back upstream >». >> >> There has been now and in the past (for instance when discussing the >> proposed format “3.0 (Git)” for dpkg) some important points raised >> explaining the challenge of redistributing the upstream VCS instead >of a >> flat file archive. >> >> This is why some packges are shipping metadata indicating where to >find >> the upstream sources, send upstream bugs, or even where to dontate >> money, in order to help our users contribute back to the developement >of >> the software that Debian is made of. > >Are there tools that are actively using this information? >Unfortunately, >the links you quote below do not provide much information about where >this information is used (other than bibref table in UDD). > >On the other side of the coin, are there any tools that help generate >this metadata? For example, github-hosted projects can have their Bug- >Database, Bug-Submit, Changelog, Repository, Repository-Browse >automatically derived. > >-- >Saludos, >Felipe Sateler -- Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma brièveté.
Re: Information request
Le 28/12/2018 à 11:58, User Web a écrit : > > Dear Debian team, > Hi! > First of all, thank you for all the work you do to make debian such a > powerful, reliable and secure distribution. > Thanks also for all your support, documentation and availability to > those who do not have your expert knowledge. > Secondly, I contact you to ask an information: > > I know the safest version is old stable (jessie), but I know it can only > have older software. Hello, no the safest is "stable" > But I also know that there is the possibility of replacing the > repository of the oldstable version with backports, but I do not know if > this repository makes available for debian oldstable also the latest > version of LAMP and wordpress. > therefore, I would like to know which is the safest version to do the > following: > 1 put a server in production > 2 install the latest version of the LAMP stack > 3 install the latest version of wordpress I think stable+backports could be a good solution > I thank you for your attention. > And, waiting for your answer, I wish you a fantastic continuation of the day > But, if we do not have to feel, I wish you the best life possible > > Cordial greetings Cheers, Xavier
Re: A team to grant rights on collab-maint?
On 12:45 Mon 14 Jun , Raphael Hertzog wrote: > Hello, Hi, > This project started for two reasons: > - encourage usage of public VCS with broad write permissions (all DD) > even for single packages > - be able to refuse single-package project request on Alioth that would > only clutter the project list when they only need some space to dump > their VCS files (see http://wiki.debian.org/Alioth/PackagingProject) > > Now I would like to stop dealing with those requests and thus I would like > a team of people to replace me. Understandable. > Is there an existing team that could take this responsibility? [2] > Are there volunteers for the task? Why a team ? People volunteers registered as Admin could do the needed job right ? Im volunteer to help maintaining this project active. I think if we could be 3 or 4 DDs, it could be nice, well handled and will not take that much time for each DD. > [2] Currently the Alioth admins have it somewhat. Request that are asked > on #alioth are processed (using super powers of Alioth admins) but out of > the Alioth admins, I'm the only one receiving the email requests because > I'm the only one registered as project admin on collab-maint. Greetings, -- ,''`. Xavier Oswald (xosw...@debian.org) : :' : GNU/LINUX Debian Developer <http://www.debian.org> `. `' GPG Key: 1024D/88BBB51E `- 938D D715 6915 8860 9679 4A0C A430 C6AA 88BB B51E -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100614132527.ga22...@gmail.com
Re: Debian new user (french language)
On 10:14 Mon 27 Apr , El Haouari ZOUAGHI wrote: >Bonjour, >Hi, Hi, Please use the french debian user mailing list for this kind of questions.. 'debian-user-fre...@lists.debian.org' >Je suis sur Ubuntu et je songe `a songer car la nouvelle version d'Ubuntu >galere avec ma carte video (ATI mobility radeon X1300). >I want to change from Ubuntu cos' the new Ubuntu has problem with ATI >mobility radeon X1300. >J'hesite `a passer sur Debian ou Mandriva. >Maybe I'm gonna use Debian or Mandriva. > >Tout d'abord, pouvez-vous m'envoyer par la Poste un live CD gratuitement ? >First of all, could you send me for free one live CD ? >Ensuite, comment cela se passe-t-il avec les mises `a jour quand on >utilise votre OS ? >How your system is with update ? > >Toutes le ressources en ligne (doc, forum, irc, ...) sont-elles en >franc,ais ? >Documents, forum, IRC, ... are they all in french on your websites ? > >Votre OS est-il entierement gratuit (y compris les autres softs) ? >Is your system absolutely in french ? > >Merci d'avance pour vos reponses. >Cordialement. >Best regards. Greetings, -- ,''`. Xavier Oswald : :' : GNU/LINUX Debian Developer `. `' GnuPG Key ID 0x88BBB51E `-938D D715 6915 8860 9679 4A0C A430 C6AA 88BB B51E -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Two GR concepts for dicussion
On 18:37 Thu 31 May , Anthony Towns wrote: Hi Anthony, > - minimal requirements: gpg keyring signed by either one or two > developers, recommendation by a developer, use of existing > fields such as "Maintainer:" and "Uploaders:" to control access, > no provision for uploaders to do NMUs or upload NEW packages etc I think the use of an existing fields "Maintainer" should do the job but Im not in favour of "Uploaders". Im throught the NM process and member of the parted team so Im in the uploaders field. If I will have this kind of right, I could be able to upload a new version of parted and maybe then broke the d-i for exemple. So for the "Maintainer" field, ok, but for "uploader" we should maybe need to take care about what are the packages co-maintained and if they are 'critical'. We could maybe check the "Section" field and only allow some of them for a DM. friendly, -- ,''`. Xavier Oswald <[EMAIL PROTECTED]> : :' : GNU/LINUX Debian & Debian-Edu `. `' GnuPG Key ID 0x88BBB51E `-938D D715 6915 8860 9679 4A0C A430 C6AA 88BB B51E -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Honesty in Debian (was Re: Amendment to GR on GFDL, and the changes to the Social Contract
On Mon, 13 Feb 2006, Sven Luther wrote: > > Fonts or documentations are not softwares, for god's sake! > everything that is not hardware is software So a cat is a software, or a hardware ? Do I have to provide the sources (the DNA full sequence) if I want to give a kitten to someone, following the "free" spirit ? :p > all the rest is excuses and play with words. My opinion is that my holiday pictures aren't neither hardware nor software. > Indeed, but they should know (and we should tell them), that the hardware they > are buying is not free-software friendly Err, I think the problem is that most users *do not care*. They just want their card to *work*. I think this more productive to make their card work, AND then tell them "this card is working with a non-free piece of thing, meaning that you may have problems in the future in case of bugs or after upgrading your system. please ask the manufacturer to do something about it" > so that they have a chance to vote > with their wallet and chose those companies who are friendly to free software You mean Mandriva ? > when buying hardware, so hiddenly putting non-free software in main, is I was talking about firmwares, that is, opaque piece of bits aimed to be run on an external, exmbedded system, part of the hartdware. > counterproductive, while putting it in non-free, and making its use easy if > the user wants to, is the right way out of this, and the more (if not only) > honest way of dealing with this issue. In this case, yes, the solution might be to create a "non-free-data" *distributed* and available in standard. > So, you believe that documentation is hardware, well, this is a sensible No more software or hardware than a cat. The world is not binary. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Honesty in Debian (was Re: Amendment to GR on GFDL, and the changes to the Social Contract
On Mon, 13 Feb 2006, Sven Luther wrote: > Nope, but i think those who try to hide the issue of non-free material in > main, by insisting that it is not software Fonts or documentations are not softwares, for god's sake! > I want to remind you all, that previous to the two GRs which clarified the > meaning of what we must consider free .. what we must consider free *software* > For the rest of the stuff, just put it in non-free, and maybe modify how we > handle non-free, classifying it in non-free-but-distributable and > non-free-with-distributions-constraints, and making its use easy, especially > at the installer level for kernel firmware Good idea. I wish all users could install Debian on their exotic-firmware-enabled-network card and wifi-aware laptop (which is not the case currently) instead of saying "shit, this crap is just not working well. let's switch to gentoo or mandriva" But I still consider documentation different than softwares, and don't see any major problem regarding the FDL. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Downloading matters!!
Hello, I have tried to download this CD image iso:debian-31r0a-i386-binary-1.iso.torrent But when I burn my CD what I find inside is the image of the CD number 3. Please, where can I find thethe image of CD number 1? Thanks in advannce, Xavier Appel audio GRATUIT partout dans le monde avec le nouveau Yahoo! Messenger Téléchargez le ici !
