Documentation July 2013

documentation@lists.ipfire.org

13 participants
15 discussions

VLAN Konfig
by Thomas Berthel 08 Aug '13

08 Aug '13

Hi zusammen, ich habe hier: http://wiki.ipfire.org/de/optimization/vlan/start die Doku für das VLAN fertig gestellt, könnte das jemand von euch in ein brauchbares Format für die englisch sprechenden Uer vorbereiten. Korregturen dürfen natürlich ebenso vorgenommen werden ;-) Ein schönes Wochenende! Thomas

4 17

GPG wiki
by Erik K. 06 Aug '13

06 Aug '13

Hi all, i want to introduce the first translation of the GPG wiki to english --> http://wiki.ipfire.org/en/optimization/scripts/gpg/start . This wiki is in the beginning of state (B) of the wiki workflow --> http://wiki.ipfire.org/projects/docs/workflow . Please go for some checks on that. Greetings Erik

5 13

Re: IPFire Wiki Workflow
by Erik K. 02 Aug '13

02 Aug '13

Allright, > * How do we attract authors? (People who write content) > * How do we attract translators? (People who translate the content from > English into their respective languages) > * How do we decide what to work on? When? For how long? for myself this questions are difficult to replay, haven´t found until now a clear tendency why people do author or translator work. The willing to help is for sure a concern, but the multitude of informations and themes which are to care for can also slain this willing, my first purpose at this time was to learn more about IPFire but also to support a good project, so i started to translate wiki sections from german to english and tested also a various amount of addons and functions on the basic system of IPFire. I think also what Rod says is important, new users or mostly people from the forum feels a high obstacle to change things in the wiki cause they think they make something wrong or swipe somebodies work. May some more hints in the wiki that everybody is invited to extend own know how can may change those attitudes, but we have tried also those rudiments with sides like this --> http://wiki.ipfire.org/projects/docs/start and references to this side in the wiki, but also by motivating the people directly in the forum. The result is the reason of this mailinglist theme, so i have not really an answer how we can attract people to work more in this topic. A possibility to reach more people or to transfer a kind of "wiki politic" were everybody is invited to help out in this working area can be to write a round mail, like with the core updates, everybody who have signed into the forum can be informed in that way. But i don´t know how much attraction comes out of that. The decision what to work on should be set by a similar priority like in development. If there is a bug in the basic system it is more important than a bug in a addon, surely both will be fixed fast ;-) but i want to point out that the wiki for the basic system is more important to have it complete and well structured i think. Also a good indicator for improvements can be to look at the questions in the forum. Before the "new" Squid wiki there was really a lot of repeating questions, after every single part (function of the WUI) was explained, the questions concerning to the proxy in the forum was reduced dramatically. Also the possibility to give short help informations only by linking to the specific section was a work simplification for supporter in the forum. The decision "When" to work on topics should be as soon and straight-lined as possible, but to make those decisions, a organized team should be available, this takes me back to the question "How do we attract people". "For How long?": Depends on the theme and also on the amount of helpers i think. > On your note about that development has to be involved in this as well: > Agreed and I already talked to Arne and Stevee how we can do that in the > least time consuming way, because we also don't have much time and loads > of things to work on. > Writing articles in more than one language is an absolute no-go. We will > leave it at English and write down the most important things one needs > to know about a certain add-on or what ever. Adding screenshots, doing > the translations and getting the article into a round shape should be > the task of the translation team. Could you guys agree on that? > I also think that developers are not the best people to write end-user > documentation. It is getting to complex and not suitable for beginners > any way. Not only You Arne and Stevee should follow those rules, also addon developers, or development in general. Sorry for the worse link to Wikipedia --> https://en.wikipedia.org/wiki/Software_documentation#Role_of_documentation_… but i think in there are some good statements why documentation in software development are very important and also a inherent part of development. If it is in german or in english is for now secondary i think. All developed functions needs to be explained in there, otherwise how should a possible documentation team knows what they have to write for. Screenshoots, the layout stuff, the literarily consolidation and translation should be the very own of an documentation team i think, so far i can agree with you. But a good documentation hand out of new development is the basic of a better documentation i think. Time is always a problem for all, since this project is a non commercial one, nobody can live by working in full time in this project, but it shouldn´t be a whitewash for incompleteness. So an idea can be to have an closer contact from the developer team to a possible documentation team, to ensure this knowledge transfer. This can also be attractive for new helpers to stay a little closer to the matter. Erik Am 12.07.2013 um 00:01 schrieb Michael Tremer: > Great thoughts, but let's bring down the pace a little bit before we > start talking about the actual content that needs to be reviewed and > possibly (re-written). > > I am still aiming for defining a workflow in this discussion that should > be followed under all circumstance, because I think this is what is most > important on a team, that we are all on the "same page" (almost > literally in this context). > > Central questions are: > > * How do we attract authors? (People who write content) > * How do we attract translators? (People who translate the content from > English into their respective languages) > * How do we decide what to work on? When? For how long? > > The has to be a "team", otherwise we don't need to think about the > content. > > On your note about that development has to be involved in this as well: > Agreed and I already talked to Arne and Stevee how we can do that in the > least time consuming way, because we also don't have much time and loads > of things to work on. > Writing articles in more than one language is an absolute no-go. We will > leave it at English and write down the most important things one needs > to know about a certain add-on or what ever. Adding screenshots, doing > the translations and getting the article into a round shape should be > the task of the translation team. Could you guys agree on that? > > I also think that developers are not the best people to write end-user > documentation. It is getting to complex and not suitable for beginners > any way. > > -Michael > > On Thu, 2013-07-11 at 19:30 +0200, Erik K. wrote: >> Hi all, >> regarding to the ideas causing a better overview of the wiki content, i have tried a more compressed layout of the configuration wiki. The actual (official) look of this section can be found in here --> http://wiki.ipfire.org/en/configuration/start . >> The new one is very unready and only a first try, but it should show an idea how it could be better overviewed. >> In here --> http://wiki.ipfire.org/en/configuration/start you belong to the new structure. >> Until now there is no content behind the structure but this should be done fast by a copy and paste of the old content. <-- Better to check out some sections before. Another possibility in this kind of structure can be to work more precised in themes with e.g. 5-10 different sections not as before with 40-50 (example in here --> http://wiki.ipfire.org/en/configuration/start ). >> >> A statement to the wiki workflow: >> In the last months, mostly work was done in particular articles of the wiki, also to clean up the code cause a lot of plugins was replaced, so the general structure wasn´t touched but becomes more and more informations. I think most important is for the first >> * Find out a new structure which can be better overviewed (configuration and installation, ???). >> * Go for a checkout of the basic system articles (without addons) and find out the worse sections to make them better and clearer. >> * If old articles will be revised, the explained functions should also be tested. >> * Documentation should be a part of the development of software (and if it is only a short developer hand out) so a possible documentation "team" have it easier. >> >> Also to overview the actual changes in the wiki needs to be checked. In here --> http://wiki.ipfire.org/start?do=recent a done list can be overviewed. If there was a change in german, it might be great to find it also in the english wiki. As more people looks in there as better it is. >> >> The native speakers: It is very important to have some people especial in english (american/english). The best might be that some people are native in two languages german/english otherwise we have the same condition than before. I tried always my best as an native german speaker to translate the wikis into english, but thats not enough for a good feeling by reading. So i tried always to send some messages over the docu mailinglist with the please that someone can go for corrections (also in german). Sometimes this kind of workflow did it very good (thanks again Rod by the way ;-), but sometimes (especially in the last past months) there was no response. As time goes by the wiki articles leaves the memory that there was something to do and they where forgotten. So it is maybe an idea to mark those articles as "uncheck, everybody is invited to go for a revise" or something. >> >> So for the first some ideas from me. >> >> >> Greetings >> >> >> Erik >> _______________________________________________ >> Documentation mailing list >> Documentation(a)lists.ipfire.org >> http://lists.ipfire.org/mailman/listinfo/documentation > >

3 8

New DNS-forwarding wiki
by Erik K. 29 Jul '13

29 Jul '13

Dear documentation team, i want to introduce the DNS-forwarding wiki http://wiki.ipfire.org/en/configuration/network/dnsforward which was extended and is currently on stage (B) of the new wiki workflow --> http://wiki.ipfire.org/projects/docs/workflow . If you think the point "(B) Authoring the article in English" lacks, please go for enhancements. Otherwise point (C) can be worked out. Greetings Erik

2 2

IPFire Wiki Workflow
by Michael Tremer 27 Jul '13

27 Jul '13

Hello *, as mentioned before I want to discuss the situation of the documentation in the IPFire project. This is a hard topic and I am sure we won't find a solution that will fix all the problems we are experiencing now in a swift, but at least I would like to find out what we are doing wrong and what we can do about it. Disclaimer: The documentation on the IPFire wiki is not all in a bad quality. There are some parts which are well written but there are other parts which are not. I will be mostly talking about the bad parts, here. In the last couple of weeks, some people came to me and complained about the wiki. That's what made me think again about the problem. We all know that this has been a problem for years, but as the project is growing bigger and bigger, there are more people trying to find information on the wiki, but they can't. So here is what I personally think the problems are: 1) There is an answer to almost every question on the wiki, but nobody can find it. The presentation of the information and the structure is not very good on some pages. Some are too long, some things are too short. Some pages are not even linked and only accessible via the search - we all know how much people like the search :) People who are joining the project and are installing IPFire for the first time are basically on their own, because reading the installation guide takes hours and states a lot of obvious things. What to do after that (like configuring your DSL connection) can not be found anywhere. 2) The different translations are in very poor quality. Some parts of English and German sounds as if they have been translated by Babelfish. We are lacking native speakers for everything else than German, and even there, we need to fix a lot of grammar, wording, orthography and more. 3) Problems 1) and 2) essentially boil down to: We don't have enough man power. The list of people which are in the documentation team is long, but if you kick out all the people who are inactive, you are left over with only a few. Erik is the current wiki coordinator who manages the documentation team, but there is really nothing to manage at the moment. He is doing a lot of work, but maintaining the entire wiki by only one person is not working. Nobody can do that. I don't have THE solution to fix all the problems, but I have a few suggestions to make and I would like to hear your opinions about that: a) We need to encourage more people to join the documentation team. People who actually do work on the team. b) We need to find native speakers for the main languages which are English and German, to raise the quality of the language. c) We need a better structure for beginners, because that's the group of people the documentation is meant for. We need to cover things like the installation and initial setup much better, shorter and sweeter, because setting up IPFire is not a big deal, but there should documentation that tells the user what to do next. I would like to see some things sorted that are essential for this to work: * There must be guide that tells people how to contribute to the documentation. There need to be styling and language guidelines, which have to be written. Those will help people to get started writing documentation and tells them how to contribute in the right way. Lots don't know how to edit the wiki. Others don't have the confidence to change anything and are afraid that they will mess things up. We need to tell them that they are not alone in this and that even small improvements are very important - and easy to make as well. * After that I would like to start rewriting sections one after an other. Maybe we can create a workflow that is roughly like this: i) Grab some topic and discuss what the problems are and what needs to be improved. ii) A one week(?) phase were a team of authors is (re-)writing. iii) A one week(?) phase for QA, reviewing what has been done. iv) After that team of authors starts at i) with a new section. The translation teams translate the work into their respective languages. The coordinator's task will be (despite writing and translating) to check that process is followed and he will also check if the result complies to the guidelines. A workflow like this has a lot of advantages, because it is highly modular. If there is more time needed for writing it can easily be extended. Lot's of people can work on it at the same time and they will check each others work for mistakes which results in a higher quality. You don't have too much on your plate and won't lose focus. Everybody knows what the team is working on and can join. Working on other sections during phase ii) should not be strictly forbidden but discouraged so that there is not too much to do at the same time, but it should be allowed to make trivial changes and so on. So that's my idea about how this could/should work. Please post your opinions and your ideas at well. Share what you think the major problems are, so that we can work them out. -Michael

5 18

DMZ server with multiple names.
by Ralph Crongeyer 16 Jul '13

16 Jul '13

Hello list, I have a web server with multiple eg (servername.mydomain.com, www.mydoman.com, mail.mydomain.com, webmail.mydomain.com, vpn.mydomain.cometc...) and I would like to be able to access these by name from my Blue network. I have DMZ pinholes and I can get to the server by IP just fine but IPFire dosn't know about the other names. Can I add multiple names to an IP from IPFire? If so where do I do this in the GUI? I would like to do this so I don't have to run bind on my web server and use it for DNS lookups. Thanks, Ralph

1 1

Re: IPFire Wiki Workflow
by embp 12 Jul '13

12 Jul '13

Am 12.07.2013 um 14:03 schrieb Erik K.: > Allright, >> * How do we attract authors? (People who write content) >> * How do we attract translators? (People who translate the content from >> English into their respective languages) >> * How do we decide what to work on? When? For how long? > > for myself this questions are difficult to replay, haven´t found until now a clear tendency why people do author or translator work. The willing to help is for sure a concern, but the multitude of informations and themes which are to care for can also slain this willing, my first purpose at this time was to learn more about IPFire but also to support a good project, so i started to translate wiki sections from german to english and tested also a various amount of addons and functions on the basic system of IPFire. > I think also what Rod says is important, new users or mostly people from the forum feels a high obstacle to change things in the wiki cause they think they make something wrong or swipe somebodies work. May some more hints in the wiki that everybody is invited to extend own know how can may change those attitudes, but we have tried also those rudiments with sides like this --> http://wiki.ipfire.org/projects/docs/start and references to this side in the wiki, but also by motivating the people directly in the forum. The result is the reason of this mailinglist theme, so i have not really an answer how we can attract people to work more in this topic. > > A possibility to reach more people or to transfer a kind of "wiki politic" were everybody is invited to help out in this working area can be to write a round mail, like with the core updates, everybody who have signed into the forum can be informed in that way. But i don´t know how much attraction comes out of that. > > The decision what to work on should be set by a similar priority like in development. If there is a bug in the basic system it is more important than a bug in a addon, surely both will be fixed fast ;-) but i want to point out that the wiki for the basic system is more important to have it complete and well structured i think. Also a good indicator for improvements can be to look at the questions in the forum. Before the "new" Squid wiki there was really a lot of repeating questions, after every single part (function of the WUI) was explained, the questions concerning to the proxy in the forum was reduced dramatically. Also the possibility to give short help informations only by linking to the specific section was a work simplification for supporter in the forum. > > The decision "When" to work on topics should be as soon and straight-lined as possible, but to make those decisions, a organized team should be available, this takes me back to the question "How do we attract people". > > "For How long?": Depends on the theme and also on the amount of helpers i think. > >> On your note about that development has to be involved in this as well: >> Agreed and I already talked to Arne and Stevee how we can do that in the >> least time consuming way, because we also don't have much time and loads >> of things to work on. >> Writing articles in more than one language is an absolute no-go. We will >> leave it at English and write down the most important things one needs >> to know about a certain add-on or what ever. Adding screenshots, doing >> the translations and getting the article into a round shape should be >> the task of the translation team. Could you guys agree on that? > >> I also think that developers are not the best people to write end-user >> documentation. It is getting to complex and not suitable for beginners >> any way. > > Not only You Arne and Stevee should follow those rules, also addon developers, or development in general. Sorry for the worse link to Wikipedia --> https://en.wikipedia.org/wiki/Software_documentation#Role_of_documentation_… but i think in there are some good statements why documentation in software development are very important and also a inherent part of development. If it is in german or in english is for now secondary i think. All developed functions needs to be explained in there, otherwise how should a possible documentation team knows what they have to write for. Screenshoots, the layout stuff, the literarily consolidation and translation should be the very own of an documentation team i think, so far i can agree with you. But a good documentation hand out of new development is the basic of a better documentation i think. Time is always a problem for all, since this project is a non commercial one, nobody can live by working in full time in this project, but it shouldn´t be a whitewash for incompleteness. > > So an idea can be to have an closer contact from the developer team to a possible documentation team, to ensure this knowledge transfer. This can also be attractive for new helpers to stay a little closer to the matter. > > > Erik > > > > Am 12.07.2013 um 00:01 schrieb Michael Tremer: > >> Great thoughts, but let's bring down the pace a little bit before we >> start talking about the actual content that needs to be reviewed and >> possibly (re-written). >> >> I am still aiming for defining a workflow in this discussion that should >> be followed under all circumstance, because I think this is what is most >> important on a team, that we are all on the "same page" (almost >> literally in this context). >> >> Central questions are: >> >> * How do we attract authors? (People who write content) >> * How do we attract translators? (People who translate the content from >> English into their respective languages) >> * How do we decide what to work on? When? For how long? >> >> The has to be a "team", otherwise we don't need to think about the >> content. >> >> On your note about that development has to be involved in this as well: >> Agreed and I already talked to Arne and Stevee how we can do that in the >> least time consuming way, because we also don't have much time and loads >> of things to work on. >> Writing articles in more than one language is an absolute no-go. We will >> leave it at English and write down the most important things one needs >> to know about a certain add-on or what ever. Adding screenshots, doing >> the translations and getting the article into a round shape should be >> the task of the translation team. Could you guys agree on that? >> >> I also think that developers are not the best people to write end-user >> documentation. It is getting to complex and not suitable for beginners >> any way. >> >> -Michael >> >> On Thu, 2013-07-11 at 19:30 +0200, Erik K. wrote: >>> Hi all, >>> regarding to the ideas causing a better overview of the wiki content, i have tried a more compressed layout of the configuration wiki. The actual (official) look of this section can be found in here --> http://wiki.ipfire.org/en/configuration/start . >>> The new one is very unready and only a first try, but it should show an idea how it could be better overviewed. >>> In here --> http://wiki.ipfire.org/en/configuration/start you belong to the new structure. >>> Until now there is no content behind the structure but this should be done fast by a copy and paste of the old content. <-- Better to check out some sections before. Another possibility in this kind of structure can be to work more precised in themes with e.g. 5-10 different sections not as before with 40-50 (example in here --> http://wiki.ipfire.org/en/configuration/start ). >>> >>> A statement to the wiki workflow: >>> In the last months, mostly work was done in particular articles of the wiki, also to clean up the code cause a lot of plugins was replaced, so the general structure wasn´t touched but becomes more and more informations. I think most important is for the first >>> * Find out a new structure which can be better overviewed (configuration and installation, ???). >>> * Go for a checkout of the basic system articles (without addons) and find out the worse sections to make them better and clearer. >>> * If old articles will be revised, the explained functions should also be tested. >>> * Documentation should be a part of the development of software (and if it is only a short developer hand out) so a possible documentation "team" have it easier. >>> >>> Also to overview the actual changes in the wiki needs to be checked. In here --> http://wiki.ipfire.org/start?do=recent a done list can be overviewed. If there was a change in german, it might be great to find it also in the english wiki. As more people looks in there as better it is. >>> >>> The native speakers: It is very important to have some people especial in english (american/english). The best might be that some people are native in two languages german/english otherwise we have the same condition than before. I tried always my best as an native german speaker to translate the wikis into english, but thats not enough for a good feeling by reading. So i tried always to send some messages over the docu mailinglist with the please that someone can go for corrections (also in german). Sometimes this kind of workflow did it very good (thanks again Rod by the way ;-), but sometimes (especially in the last past months) there was no response. As time goes by the wiki articles leaves the memory that there was something to do and they where forgotten. So it is maybe an idea to mark those articles as "uncheck, everybody is invited to go for a revise" or something. >>> >>> So for the first some ideas from me. >>> >>> >>> Greetings >>> >>> >>> Erik >>> _______________________________________________ >>> Documentation mailing list >>> Documentation(a)lists.ipfire.org >>> http://lists.ipfire.org/mailman/listinfo/documentation >> >> >

1 0

Please could someone review it
by Daniel Weismüller 09 Jul '13

09 Jul '13

http://wiki.ipfire.org/de/updates/openvpn-transfer-net-block http://wiki.ipfire.org/en/updates/openvpn-transfer-net-block All suggestions are welcome. - Daniel

3 3

RE: IPFire authenticated with Domain Controller Window server 2008
by Phai Sophanith 09 Jul '13

09 Jul '13

Dear IPfire Document Team, I really want to use ipfire as proxy for our organization but I cannot configure to authenticate with Window Active Directory 2008. I have tried to do it for a few weeks ago, so I would like to get recommendation and advices from ipfire team. I am hopeful document team can help me on this. Many Thanks, Phai Sophanith From: documentation-bounces(a)lists.ipfire.org [mailto:documentation-bounces@lists.ipfire.org] On Behalf Of Phai Sophanith Sent: Wednesday, July 3, 2013 6:37 PM To: t.berthel(a)gmx.net; documentation(a)lists.ipfire.org Subject: RE: IPFire authenticated with Domain Controller Dear BG. Thomas, Your guide is very useful for us and I followed this step for a few times, but I have not succeed. Could you provide additional guide to make sure windows authentication is working properly? Best regards, Sophanith From: t.berthel(a)gmx.net<mailto:t.berthel@gmx.net> [mailto:t.berthel@gmx.net]<mailto:[mailto:t.berthel@gmx.net]> Sent: Tuesday, July 2, 2013 3:29 PM To: Phai Sophanith Cc: documentation(a)lists.ipfire.org<mailto:documentation@lists.ipfire.org> Subject: [SPAM] - Aw: IPFire authenticated with Domain Controller - Recipient blocklisted Hi, first, your proxy cannot run in transparent mode with LDAP! Fore more informaiton to setup the LDAP-Proxysettings see this Link: http://www.advproxy.net/ldapads.html And the WPAD over the DNS to send the Proxy information on the clients. http://wiki.ipfire.org/en/configuration/network/proxy/extend/add_distri?s[]…<http://wiki.ipfire.org/en/configuration/network/proxy/extend/add_distri?s%5…> For further assistance use the forum: http://forum.ipfire.org BG, Thomas Gesendet: Dienstag, 02. Juli 2013 um 10:04 Uhr Von: "Phai Sophanith" <Sophanith.Phai(a)amkcambodia.com<mailto:Sophanith.Phai@amkcambodia.com>> An: "documentation(a)lists.ipfire.org<mailto:documentation@lists.ipfire.org>" <documentation(a)lists.ipfire.org<mailto:documentation@lists.ipfire.org>> Betreff: IPFire authenticated with Domain Controller Hello IPfire Supporter, Our organization need a proxy which can be authenticated with the existing Active Directory Windows Server 2008; I found ipfire has this features and suitable with our requirement. I have been happy to try ipfire as proxy server for several day but we cannot configure successfully; therefore, could you provide any clue guide to resolve? I am very appreciated for your response. Yours Faithfully, Phai Sophanith Technical Support Engineer AMK (Angkor Mikroheranhvatho Kampuchea Co., Ltd) # 442, St. 193, Toul Svayprey 1, Chamkarmorn, Phnom Penh, Cambodia. P.O. Box 480 Phnom Penh, Cambodia Tel: 855 (0) 17 789 654, Ext: 167 www.amkcambodia.com<http://www.amkcambodia.com>, We are here...<http://maps.google.com/maps/ms?ie=UTF8&msa=0&msid=102927072356456234666.000…>

1 0

Questions about IPFire installation documentation for the non-specialist
by com＠riseup.net 05 Jul '13

05 Jul '13

To the IPFire Documentation Team: Hello, I have just been communicating with Erik Kapfer, who tells me that I might be useful to your work with some polishing of the English. I am from San Francisco, although I live in Paris at the moment. While I do some work as a web developer, the hardware end is pretty much Greek to me, and in that respect I would like to suggest some additional information might be useful much closer to the front of where newcomers get started reading your documentation, even before the installation guide. I did download the software. "Don't be afraid!" it said, but no information after that came up on the screen. I must say, it reminded me of the politician's "Trust me!" So then I searched in a search engine for an installation guide. I must tell you that yesterday I attempted to install IPFire and gave up before I had begun. The hardware requirements were a complete puzzle. I could not tell whether it was possible to run the firewall on a single computer with only a wireless connection to the Internet. In fact, I wrote in to the forum, asking about the 2 network cards, but no one was able to reply. It would be useful to have information like this right up front for potential users. If there is someone available to answer the technical questions, I might work on your installation guide, http://wiki.ipfire.org/en/hardware/start from the point of view of someone who knows little about the inside of their computer. For instance: Hardware Because of its modular concept, IPFire is very flexible in its hardware demands. On this page, we will present possible setups, without making any claim to be complete: Intel D945GCLF2 - A miniITX-Board with one Intel-Atom-Processor. fit-PC2 - An embedded system with Intel-Atom-Z-Processor. [WHAT DOES THIS MEAN? WHAT ARE THESE TWO ITEMS? DO I HAVE TO BUY THEM? IF THEY POTENTIALLY ARE ALREADY IN MY COMPUTER, HOW DO I FIND OUT?] Demands Processors IPFire needs at least a i586 CPU (from Intel Pentium upwards). [OK, HOW DO I FIND THIS OUT? I LOOKED UP THE CPU IN MY MACHINE, AND THEN SEARCHED ON THE INTERNET FOR SOME SORT OF BENCHMARKING. I FOUND IT LISTED ON A PRIVATE SITE, PASSMARK SOFTWARE. THERE ARE VARIOUS MEASURES OFFERED. I COULD NOT FIND i586 ANYWHERE, THOUGH, AND THERE WERE MANY INTEL PEMTIUMS LISTED. ALREADY, IF I HADN'T ALREADY BEEN IN TOUCH WITH THE PROJECT, I WOULD HAVE BEEN LONG GONE. IN FACT, I NEVER WOULD HAVE TAKEN THE TIME TO TRY TO LOOK IT UP.] ... Network IPFire should have at least 2 network-cards available (see Network topology)... [SO HERE IS WHERE I GAVE UP. DOES THIS MEAN THAT I CANNOT USE IPFire ON ONE COMPUTER ONLY? AND FOR SOMEONE WHO HAS TWO OR MORE COMPUTERS, ARE NETWORK CARDS THE SAME AS CONNECTED COMPUTERS? IF NOT, HOW DOES SOMEONE KNOW HOW TO FIND OUT HOW MANY THERE ARE?] ... [I HAVE NO IDEA WHAT IS BEING REFERRED TO ON THE REST OF THE PAGE.] ------------ So my question for the documentation team is this: is the project interested in having non-specialists use IPFire, or is it really geared for system administrators? If the latter, there's no point in changing what you have, since it seems that there is already a growing number of users. If the former, maybe a different stream of documentation could be added. Cordially, Beryl Magilavy (Ms)

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Documentation July 2013