Arch Linux Turkish Community Announcement

Hey All,
We, as the Turkish users of Arch Linux, have created our own community to support, to translate, to develop our very beloved Linux distro on all platforms. As our first gift to the community, we have translated pacman completely to Turkish. It's also being tested by our community right now.
We set http://www.archlinuxtr.org as our web site (it's currently under development) and have SVN, Trac projects (still being configured). We also have #archlinux.tr on irc.freenode.net
We look forward to see anyone commenting, helping, cheering, donating and of course contributing our work.
Cheers..!

Yeah, that's mine! (which runs Leopard for now but has several virtual Arch's on it..) I'm working on installing Arch on it.. (is a 3-4 years Arch user by now btw..)

Similar Messages

Arch Linux Turkish Community @ 8th Free Software and Linux Festival

Hey There Guys,
We'd love to tell you about the latest news. We were at our stand all
day long on the very first day of 8th Free Software and Linux Festival.
What we've done?
* We've burnt 20 i686 and 10 x86_64 CD images and created paper CD cases
and gave everyone for free. (unfortunetly we were only capable of doing
40 of them and 30 cases since especially the cases were so expensive as
they were the best quality available)
* Made some installations for people who needs help
* Printed nearly 30 Turkish installation manual and gave them with the
CD's..
* Created a "Arch Linux on Tap" concept and made it available over the
network! They is very cool though since anyone can put the plug in
and install Arch with our very new and fresh Arch mirror (that have i686
and x86_64 packages for core, testing, community, extra).
We'll continue to do introduce Arch Linux to visitors of the festival
and help them to discover the beauty!
We also have some pictures for you! Comments are welcome!
http://www.flickr.com/photos/tunix/sets … 848517025/

Yeah, that's mine! (which runs Leopard for now but has several virtual Arch's on it..) I'm working on installing Arch on it.. (is a 3-4 years Arch user by now btw..)

Arch Linux (and general Linux) graphics and artists community

TheBodziO has started a discussion about the (Arch) linux graphics community. That gives me an idea. It would be nice to create an online (sub)community dedicated to graphics, DTP, and photography centered around Arch Linux. For now, I can only offer some ideas, my experience in graphics and DTP, and lots of hosting space on a non-dedicated server.
The ideas for the (sub)community:
* an open forum for discussion, not just Arch-related but 'graphics on Linux' in general
* a wiki for Linux artists
* a gallery (d'oh!)
* an Arch LiveCD for graphics artists
* a dedicated graphics repository
If you have suggestions and/or are interested to participate, please post below.

For start I want to say that I'm content that the new thread have been started to discuss the matters of cooperation of designers and developers communities. It's a good sign.
As foxbunny said the whole idea is *much* more than another art repository. I thought about creating a common ground - a meeting point - for both developers and designers. Developers have the skills to code. Designers have needs and ideas how to speed up/ease their work. Developers create tools that designers use and designers provide feedback and ideas. What I think free software world lacks is an organized way to provide the pan-project and pan-distro connection between these groups.
To illustrate the whole thing on a simple example: let's assume that I'd love to have a possibility to lock some operations on elements of my project with password. It's because my work will be given to someone else who will be responsible for placing a text in proper places on the design. I don't want to see him to move or delete something accidentally. It's possible that also some other designers will find that feature useful too. Then maybe some developer will be willing to implement that. The trouble is, that if I propose that feature and encourage its implementation in gimp, I would have to repeat the same process for scribus for example. But the idea is common. I want to state it once and see who will catch the bait . To some extent it will promote deeper integration between different projects.
Today graphic designers have the tools for editing vector graphics, raster graphics some page design tools. These tools often use the same methodologies! There are bezier curves in gimp, inkscape, scribus... whatever yet they are implemented redundantly. Perhaps thanks to one thoughts sharing panel it will be possible to come with some common solutions. Maybe some common libraries or platforms will emerge in time? I think that mentioned meeting point will keep us close to unix philosophy: do it for a single purpose and do it well. In other words I think that it will allow us to have powerful building blocks on which something even better than today state of the art apps could be build.
I want to at least start some discussion about the issue. Hopefully this will be only a beginning.
First I want to ask: do you believe that a subcommunity of archers that would be responsible for communication between the developers and designers would be useful? If so then we could more precisely state our goals and code of conduct.
Designers experience is of the essence if we want to make free software usable for demanding "art" community.
Last edited by TheBodziO (2007-10-28 20:35:15)

About the future of Arch Linux Newsletter.

Hi,
As you may have noticed, I have taken the job to make the Arch Linux weekly newsletter a possibility again. I the time I've been doing them, we speak of about 3 weeks, I have enjoyed writing them and have received very positive comments from the community that reads them. I would like to thank all of you personally for the support, you are the community and yours are the newsletter. But, as you all may have noticed the newsletter has been in an unchanged format for quite a long time. I mean, I just added the Humor section thats all, I know there is an email address to which you can all write your suggestions to, but I find people communicate and express themselves better on the forums.
So what I will ask of you, dear readers, suggestions of sections I should add/remove/edit, I will appreciate your constructive criticism in general. Express your thoughts in this thread to help me make a better more quality newsletter.
In other news, the newsletter won't be weekly no more, as Jason Chu and I have talked about, is easier to maintain a 2 time a month newsletter than 4 times a month, also the Arch Linux Developers/Community doesn't make that much noise as the other major distributions, we tend to be a bit quieter. The bright side is, the newsletter will be written with more time at hand, more stuff to write about, and will contribute to a better quality overall.
What has been suggested so far and I will work out on the next issue of the newsletter?
* Change the Bugs stats to not reflect the overall percentage but the actual bugs opened and closed that week.
As Roman Kyrylych points out: "They show a summary of status field "Progress" in open reports, but in 99% this field goes straight from 0% to 100%, so the overall number is always very low and doesn't really show anything".
So I wait for your suggestions as well.;)

Hi again,
I ask for your opinion again on the subject of the stats section in the newsletter, Do you find this an important part that should stay there?
I mean, this is going to be the most tedious, time-taking and in my opinion useless section I will have to write for the newsletter. I do want to bring a high quality newsletter but I feel this part doesn't contribute to the quality of the newsletter at all, Why?
* Newsletters that include this section are mostly from distributions that has point releases and not rolling releases.
* The number will always increase with minimum decrease because as a rolling release system Arch Linux is every package keep being updated everyday to newer versions, opening and closing more bugs by itself.
* People might not be interested in how many bugs are and how many are closed every week, since this numbers aren't even provided on the bug system itself.
Please give this a consideration and tell me your opinions.

Announcing some new Arch Linux Schwag offerings

Hey All,
I wanted to introduce you to some new Arch Linux Schwag offerings I've been cooking up over the past little while.
I'm currently sold out of case badges, and Simo has faithfully shipped his last order. I'm trying to think of a way to compensate him, he's done so much work for me on the shipping front and all I ever offered him was dinner, (granted, he's a starving student, and dinner was hopefully much appreciated). When I reorder stickers, probably in the new year, I will be shipping them myself, from Canada, so domestic prices will be a touch higher.
Now, onwards to Schwag:
It's no secret that I'm the odd man out on the tacos vs poutine debate. I know you all will come around to my way of thinking eventually, but in the meantime, check out the new schwag where you can proudly pick your piece. I've also added a few other new t-shirt design, mostly as your suggestions. Check out the new products line at zazzle to place your order:
http://www.zazzle.com/archlinux/gifts?c … 1284817680
I think most of you know about the laptop bags, jewellery, and case badges (currently out of stock) selling at: http://schwag.archlinux.ca/
I've added a few handmade items of my own invention to the mix, including wooden and soapstone sculptures, keychains, and coasters, all featuring our favourite distro's logo:
http://schwag.archlinux.ca/product/coaster/
http://schwag.archlinux.ca/product/soapstone_sculpture/
http://schwag.archlinux.ca/product/sculpture/
http://schwag.archlinux.ca/product/keychain/
I'm particularly proud of the soapstone sculptures, they look incredible. I'm not sure I can give them up. The keychains will also make great stocking stuffers this Christmas season, so remind your friends to shop Arch Schwag!
In addition, I would like to announce a preview of the Arch Linux Handbook. This should be retailing in a couple weeks, and will be available from both CreateSpace and Amazon.com. The handbook is basically a quick restyling of the epic beginner's guide in the wiki. You can preview it here:
https://www.createspace.com/3398103
That's all for now!
Dusty

Runiq wrote:Cool stuff. Like the coasters, and the allanbrokeit shirt is stylish.
That's Acecero's contribution, as he implies. :-)
Also, there's a typo in the handbook's headline: "A simple lightweight Linuk handbook."
Yeah, I know... sadly, I didn't notice it until it was too late to change (the book was set up for publication). Now I have to wait for a new edition, or pay $40 to put one out now.
Acecero wrote:Just curious, are you going to release different editions of the Arch Linux Handbook from time to time? I'm assuming the information would need to be updated and the more marketability you will gain anyway.
I'm hoping to sell between 10 and 50 copies of this edition to pay for the upfront costs before making a new edition. The more popular it is, the more likely I will be to keep it up to date.
BTW, if anyone is interested in doing cover art for the second edition, get in touch with me. I've been told that this cover looks like ass (it was gently, with links to tutorials on design :-D)
Dusty

Arch Linux RetroShare Thread

This thread provides a place for Arch Linux forum users to connect with each other by using the RetroShare darknet.
If you would like the opportunity to connect to other Arch Linux forum users, you may reply to this thread announcing that you are available on RetroShare. Other forum users may then send you a private message with their connection information, which you may then choose to respond to.
By "following" this thread, you can be notified when new people announce that they are available on RetroShare. You only need to post to this thread once. If you would like people to stop sending you requests, please edit your original post to say so.
As with all things Arch Linux, you are responsible for learning and understanding the use of RetroShare and any possible consequences.
Please remember to only connect with people you trust.
What this thread is not:
This is not a place to discuss what you will be using RetroShare for. As always, please remember to follow the Arch Linux forum etiquette.
Other:
I am not affiliated with the RetroShare software or website in any way. I have cleared the creation of this thread with the forum moderator ewaller.
Lastly, I don't use RetroShare, but I may in the future.
Thank you.
Last edited by drcouzelis (2012-04-12 19:01:07)

drcouzelis wrote:
No problem, this is a "forever" thread.
You're looking at the Arch Linux user Retroshare community (this thread). No, it's not active.
I suppose the distinctive features (FoF) of retroshare really don't have that much appeal for the common user.

Arch Linux Reviewed in Argentinian Magazine

Im happy to announce that after some work and evangelization, Arch Linux was reviewed in a local and quite popular Linux magazine here in Argentina. The magazine is called USERS Linux and its in Spanish. The review was followed by some questions they made me as admin of ww.archlinux.com.ar, if there is enough interest i will translate the article.
I collaborated on the article, so i cant say its "objective", its quite centred in the distribution and community, touching point by point the pluses and differences with others, we mention Arch64 and Archie as they had some good reasons to be on the article, the first being for those with 64bit procesors and want the best out of them, and the second for those who didnt want to risk to install Arch without trying it out first.
Congrats to Judd and all the developers, and i hope this gets us some more Spanish Talking users!
You can find a scan of each page here:
http://www.archlinux.com.ar/blog/2006/0 … ers-linux/
edit:
Changed the URL as the site changed hosting and I moved the whole system.

Hi,
im going to start translating the articles, but i will go slow unless there is a bit more interest, either way, sooner or later it will be translated.
brain0:
Yes, your are right, i missed that. I will write them so they can print an "errata" on the next issue, there is also a typo, they printed CRUZ instead of CRUX.
On the other hand, although it has been talked to death, no-one actually tried Arch on a K6-2, so we dont know for sure if it works or not. According to several posts here and some sites found via google, AMDs K6-2 are missing a couple of functions necesary to be fully i686 compliant. They are pretty common in this latitudes, so maybe someone gives it a shot and we will know for sure once and for all!

Arch Linux Logo Competition

Hello everyone!
As you may have heard, the Arch logo as we know it is going the way of the dodo! We are refreshing our graphical identity, and in that spirit we're having a logo competition, open to the entire Arch community!
We want to know what you think of when you think Arch Linux - what logo do you think would best suit the distribution we've all come to love?
Submission guidelines are as follows:
. Anyone can submit as many logo concepts as they wish
. Entry is freeform, with no need to base it on current logo. Be creative!
. For the sake of moving the competition along, artists will maintain the rights to their works until the completion of the competition, when we've decided what to do with license issues.
Per submission, you will need:
. SVG sources for logo preferred. If you don't know how to make SVG logos, but have a great idea, visit this thread; foxbunny has graciously stepped up to help with logo concepts.
. Fill out the following on this submission sheet (courtesy of foxbunny)
.. Name (or alias)
.. Main logo areas (white/black/neutral BG)
.. 2-colour or Black version
.. 128x128px and 16x16px icon version
.. Colour palette used
All other fields are optional - you do not need them to create a submission, and omission of those options will not count negatively against you.
Submit completed submission sheet attached in an email to travis AT archlinux.org. They will be posted in this thread; two weeks after the date of this post, we will collect all submissions in that thread and judge.
Judging will be the job of the Developers, and will proceed as follows:
All submissions will be posted to the [arch-dev] private mailing list, and developers will give their +1 to those logos they like. They may add a +1 to more than one submission - once all developers are accounted for, the logo with the most +1 votes will win.
Should multiple logo submissions tie for first place, those entries will be announced to the community, and we will have a community vote on the forums. The logo voted highest in this case will be the winner.
Additionally, we'll want to use the logo for additional media - CD labels or wallpapers, for example. If the winning author hasn't provided any, they will be given a chance after the competition is over to create this artwork, if they want. Basically, no need to get it done before the judging, if you want to do it, so don't worry!
Please note: there are also threads for logo concept discussion and for showing off possible concepts, without entering them into the competition. Feel free to make use of them.
Good luck to all participants, and have fun!
NOTE: There has been some recent concern about entries by developers, since it is the developers themselves voting. This was never forbidden at the beginning of the contest, and so the rules will not be modified for this halfway through; developer entries are allowed, and will be treated on exactly equal merit as any other entry. Rest-assured, there is no reason for favouritism in this contest - if we wanted an explicitly developer-made logo, we would have simply done so, so there's no reason to choose a dev's submission simply because they are a dev.
Last edited by Cerebral (2007-10-30 17:54:16)

PJ wrote:
I think this speaks for itself:
Cerebral wrote:Heh, sorry to say, but it's going to be a little bit longer before we announce anything, I think. We still have to do a decent trademark search on the top couple of logos to ensure we won't be stepping on anyone else's toes before anything else.
http://bbs.archlinux.org/viewtopic.php? … 02#p302102
Yeah, 'cause we can just use any old arch that we want to. These three, for instance, are already taken:
I think this one (below) is still available, though:
Last edited by dhave (2007-12-03 04:39:25)

Arch Linux Documentation

Is anyone in charge of developing Arch Linux documentation? From an interview that I came across on the net, I gather that there is. If so, could I ask what the programme is to improve documentation and what the target dates are?
If there isn't anyone in charge, are there people who would be interested in working on documentation, maybe within the Arch community, but maybe outside on an independent site?

redge wrote:
I get the sense that there are a lot of people involved in this distribution who like to pretend that deficiencies are strengths. I also think that the distribution is undermanned. Normally, if a project is undermanned, the idea is to bring people on-board. Trashing people who explore the possibility of getting on-board, and who in the process ask some hard questions, given that getting on-board involves a commitment of time and effort, is not necessarily a clever strategy.
Anyway, having read through this thread, the question in my case is now academic. There is no way that I am going to dedicate 8-10 hours a week to documentation is if people think that spare documentation is a badge of honour. Besides, it is so much easier to write the occasional post.
This is all fair enough; if you don't feel that your efforts would be useful, then by all means don't "waste" time on it (I say this from the point of view that I think you should feel fulfilled by your contributions to this kind of community, not "I didn't like what you said, so I don't want your help" kind of way ) . I think a lot of the feelings expressed in this thread are summed up by the last line of your post, but in a more positive way. That is to say, the Arch Forums are fantastic, and people are willing to answer questions that come up here. As a result, they are maybe unwilling to spend time adding stuff to the wiki that may be too general to cover specific questions anyway. I do think there are a lot of projects and common questions that can be summed up in informative wiki pages (and a lot of things *are* covered there). Perhaps naturally, the wikipages that *do* get written are ones that involve projects people are personally involved or interested in (I put in a wmii wiki page at one point when I got into ruby-wmii, but even that has fallen behind wmii releases at this point).
There have obviously been documentation efforts, and plenty of people that stop by to say "Hey, I'd like to help". However, I think the stopping point for a lot of people is either a) What needs documenting and b) Gee, I don't know anything about the stuff that needs documenting! I actually think the best wikipages are born of arch forum threads; when a discussion has a lot of great tidbits, somebody usually chimes in and says "Hey, somebody make a wikipage", or better yet, "Hey, I already made a wikipage, check it out and add stuff if you want". This works, because obviously a lot of people reading the threads that end up creating the wikipages *know* about the subject. Also, people are immediately alerted in the thread that there's a new page, and may say "Hey, I can add to that", as opposed to a system where people are just going through adding pages and hoping other people notice and add stuff too.
So, in summary, I guess I'd say that documentation is great, but due to the nature of Arch, our efforts work the best when the ball is already rolling in the forums. Which really is the best way for a "smaller" distro like Arch, IMO. Maybe to you this still seems like a "deficiency" that Arch users think is a strength; it seems to me to be more of a natural product of a really active user community (where instead of there being a group of people dictating what documentation is needed and such, those things that come up in community end up being codified in the wiki).
Personally, for me, I think a good documentation effort would be to keep your eye on long or very active threads; if they look like they have juicy info in them, condense it into a wikipage and announce it in the thread. Of course, that's just one Archer's opinion, and not necessarily of one that knows what he's talking about . I do agree that there are steps that could be taken to make tackling documentation easier (and I am aware that Dusty has the "Wiki volunteers wanted" thread for this) for people that "want to lend a hand", and I'm certainly not saying the efforts that have gone on so far have been wasted. I just like the idea of the really active community in the forums being leveraged to help the "static" documentation in the wiki. See a thread that indicates the install guide is lacking info is confusing? Make the wiki edit! See a thread with great new info? Start a new wiki page! See a thread born of BAD INFORMATION in the wiki? DEFINITELY update the wikipage! Embrace the wikiness of the documentation; worry less about "who maintains this page", and more about "what are the actual issues users are having, and can I change something right now to help?". Coming from this angle really reduces the feeling of being overwhelmed when loading up the wiki to edit it with no particular agenda in mind... rather, you have particular pages in mind, and you know they will be immediately useful.
Cripes, this was a long post. Sorry! Hopefully it will encourage people to contribute, even if it's just a small edit on a single page, without them worrying about becoming documentation maintainers. You don't have to be an expert at everything or anything, but being a part of a community is contributing what you can when you can. Oh, and yeah, this post probably looks funny coming out of the mouth of an "Occasional poster"; I'm actually on the forums daily, looking for spots where I can answer a question, and do so when I can.. my lack of posts is simply an indication of my not knowing enough .
Oh, and as to the response to Dusty's response... I feel like we see these kind of responses a lot on the forums, and I kind of wish people wouldn't take such umbrage at these comments. These comments are a result of people *knowing* the community. It doesn't mean that they think your idea is stupid, it just means that they're telling you what has been true in the past, and why certain things maybe don't work out. It doesn't mean you shouldn't feel like you can contribute how you want; it's open, go for it. Get the ball rolling; the community may embrace it gladly. If it didn't, well, you contributed out of love of the community, and that will certainly still be appreciated.

Polish Arch Linux Conference - 2011

Hi there!
We'd love to inform You about our conference! Tomorrow (23'rd of July) we'll meet for the first time as Polish Archlinux community[1] at Archcon 2011 in Warsaw. This year Archcon will also be KDE Release Party and a great start for next meetings about FLOSS in business world.
Thanks to Polish FLOSS Foundation[2] and BRAMA Mobile Technologies Laboratory[3] we'll meet at Warsaw University of Technology spending whole day watching interesting presentations and networking during brakes and after party.
We hope to start Archcon as a series of conferences about FLOSS in business (2-3 presentations of successful cases + pizza & networking) in Warsaw and annual road show which will be a great opportunity to meet other members of Archlinux community in Poland.
Thanks to our sponsors and partners we have a chance to do everything as planned, have fun meeting other members of our community and starting new exciting projects using FLOSS!
You'll find more informations about Archcon and future meetings at our site[4] (soon also in English) and on twitter (look for #archcon2011 and #archcon).
[1] http://archlinux.pl
[2] http://fwioo.pl/section/o-nas/
[3] http://brama.elka.pw.edu.pl/site/home#goto:about
[4] http://archcon.pl
Last edited by Partition (2011-07-22 14:12:58)

This appears to be completely unrelated to the official ArchCon conferences, only one of which has been held.
If that is the case then I think naming this "ArchCon" is both confusing and potentially illegal. "ArchCon" is and should be the official name of the official Arch Linux Conference organized by the Arch Linux developers, and only by them or those they delegate. Misappropriating the title can be viewed as trademark infringement. Given that you have sponsors for this, you may be directly profiting from trademark infringement which is even more serious.
If this actually is the official ArchCon (which I doubt), then I think it's deplorable that it has only been announced 1 day in advance. There is no way that most people would be able to attend on such short notice. Also, ArchCon is about Arch Linux itself, not general FLOSS in business. Such an ArchCon would misrepresent Arch Linux and its purpose, which is not to become a business distro nor to promote FLOSS in business.
I would appreciate some clarification on these points, both from you and from the developers.
Thanks.

[SOLVED]System Hang in Arch Linux

I have tried distributions like ubuntu and fedora in hope for finding a stable system . So I move on to Arch Linux
But this problem also exist on Arch. While using my Arch Linux (including ubuntu and fedora) my system hangs with a black screen with something written on the whole screen which cannot be pasted here as my system hangs and I have to push power button to restart.
So I check my errors.log file and found these errors
Jul 8 22:59:24 localhost kernel: [ 1.680013] ata3: softreset failed (device not ready)
Jul 8 22:59:24 localhost kernel: [ 7.298612] SP5100 TCO timer: mmio address 0xfec000f0 already in use
Jul 8 22:59:31 localhost kdm_greet[792]: Cannot load /usr/share/apps/kdm/faces/.default.face: No such file or directory
I have a HCL K21 pdc notebook
Note: In Ubuntu my notebook start with ata1: softreset failed error at boot time
Most often this error occur while watching videos or listening music with VLC
Last edited by Manuj19 (2011-07-09 10:13:24)

ewaller wrote:It might be better to just post the output of lspci -nn It will tell us a great deal more about the hardware related to the PCI bus, including specific chip set identifiers.
Thanks for suggestion
Here is output of lspci -nn
00:00.0 Host bridge [0600]: ATI Technologies Inc Device [1002:5a31] (rev 01)
00:01.0 PCI bridge [0604]: ATI Technologies Inc RS480 PCI Bridge [1002:5a3f]
00:04.0 PCI bridge [0604]: ATI Technologies Inc RS480 PCI Bridge [1002:5a36]
00:05.0 PCI bridge [0604]: ATI Technologies Inc RS480 PCI Bridge [1002:5a37]
00:06.0 PCI bridge [0604]: ATI Technologies Inc RS480 PCI Bridge [1002:5a38]
00:07.0 PCI bridge [0604]: ATI Technologies Inc RS480 PCI Bridge [1002:5a39]
00:12.0 SATA controller [0106]: ATI Technologies Inc SB600 Non-Raid-5 SATA [1002:4380]
00:13.0 USB Controller [0c03]: ATI Technologies Inc SB600 USB (OHCI0) [1002:4387]
00:13.1 USB Controller [0c03]: ATI Technologies Inc SB600 USB (OHCI1) [1002:4388]
00:13.2 USB Controller [0c03]: ATI Technologies Inc SB600 USB (OHCI2) [1002:4389]
00:13.3 USB Controller [0c03]: ATI Technologies Inc SB600 USB (OHCI3) [1002:438a]
00:13.4 USB Controller [0c03]: ATI Technologies Inc SB600 USB (OHCI4) [1002:438b]
00:13.5 USB Controller [0c03]: ATI Technologies Inc SB600 USB Controller (EHCI) [1002:4386]
00:14.0 SMBus [0c05]: ATI Technologies Inc SBx00 SMBus Controller [1002:4385] (rev 13)
00:14.1 IDE interface [0101]: ATI Technologies Inc SB600 IDE [1002:438c]
00:14.2 Audio device [0403]: ATI Technologies Inc SBx00 Azalia (Intel HDA) [1002:4383]
00:14.3 ISA bridge [0601]: ATI Technologies Inc SB600 PCI to LPC Bridge [1002:438d]
00:14.4 PCI bridge [0604]: ATI Technologies Inc SBx00 PCI to PCI Bridge [1002:4384]
01:05.0 VGA compatible controller [0300]: ATI Technologies Inc RC410 [Radeon Xpress 200M] [1002:5a62]
02:00.0 Ethernet controller [0200]: Atheros Communications Inc. AR5001 Wireless Network Adapter [168c:001c] (rev 01)
08:01.0 CardBus bridge [0607]: Ricoh Co Ltd RL5c476 II [1180:0476] (rev b3)
08:01.1 FireWire (IEEE 1394) [0c00]: Ricoh Co Ltd R5C552 IEEE 1394 Controller [1180:0552] (rev 08)
08:01.2 SD Host controller [0805]: Ricoh Co Ltd R5C822 SD/SDIO/MMC/MS/MSPro Host Adapter [1180:0822] (rev 17)
08:01.3 System peripheral [0880]: Ricoh Co Ltd R5C592 Memory Stick Bus Host Adapter [1180:0592] (rev 08)
08:07.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ [10ec:8139] (rev 10)
Last edited by Manuj19 (2011-07-09 07:20:08)

Arch Linux Beginners Guide

Remembering the days when I installed Arch Linux for the first time I still feel that Arch misses a guide for beginners. I started one at the Wiki. Its intention is to show how you install and configure Arch Linux until you have a fully working desktop system for multimedia and office purpose. I'm still heavily improving it. If you have any suggestions or critics feel free to drop me a note or add the content to the wiki. If you find some spelling or grammar errors do the same or fix them, I'm no native speaker

iphitus wrote:article is too big. provide links to existing wiki pages and documentation. If things change and you dont know, your article will be broken.
Sure...but you will have this problem with all wiki pages. If you don't have a maintainer for bigger articles, the whole idea of the wiki won't work well.
iphitus wrote:For example, change the install documentation to the install guide. Same goes for network, link to existing pages, and if there isnt one, create one.
I disagree with this one. I personally like the idea of having one basic guide which will led in most cases to a fully working system and does not stop right after the installation, which will leave you with a single prompt. I tried to explain the "basic things" and give links for digging deeper (I may have failed at this, but I tried and will try again).
Therefore you are right about linking, but as you may have seen I tried to link to existing pages if they exist and give more than just a basic information. As far as I know no install guide for voodoo exists yet.
What I really don't want to do, is to create just a meta page that only links to other pages, for three reasons:
* It's annoying to read if you have to follow a link, get back and follow the next link...
* Because there is no single maintainer for all the sub pages, you can only link to pages that are known stable, otherwise the beginner will be totally lost fast
* Some of the other pages are way too technically for a beginner, they quickly start with special things for exotic purposes (mainly because experienced people don't like writing about basic things I believe)
iphitus wrote:Some of it seems a bit overkill too, you give a newbie style how to for tiny things, but completely gloss over even a basic description of what the "daemons line" is. Newbies using this beginners guide learn bugger all, as they just copy from the beginner guide. When things go wrong, they come to the forums rather than use initiative. I guess the installation and configuration acts as a form of natural selection.
I think we have a different opinion how a wiki works, I always thought you start with something and improve it over time, when questions or suggestions arrive.
A wiki will get better if more than one people is involved, therefore sharing and discussing at an early point of time is reasonable.
On the other hand you are absolutely right about the daemons line, which should be explained for a beginner (EDIT: I added a paragraph about daemons a few moments ago).
But I think differently about the natural selection. I never felt that Arch Linux aims to be an elitist distribution and that an acceptance test is needed if you want to use it...what I have seen from the community so far, Arch seems in fact to be the opposite. I like Arch for being clean, simple and logical constructed, not for being complicated. I'm too old to get self-confidence just from installing an operating system.
If users use the forum to ask the same questions again and again, our beginners guide is incomplete and we should fix it.
iphitus wrote:Things like:
http://wiki.archlinux.org/index.php/Arc … or_newbies
and a better FAQ, would be more useful than yet another blow by blow install tutorial that falls out of date in 6 months.
James
This may not be representative, but a better FAQ and Jargon for Newbies (damn, I really love this elite attitude ) wouldn't helped him:
Someone at my blog wrote:Thanks for the guide! I tried installing Arch over Christmas and had the worst time trying to figure that out. So I of course went back to my trusty Gentoo. I always liked Gentoo because even though its an "advanced distro" they provide you with plenty of documentation. Arch on the other hand does not and that really bothered me. But now that I have a Gentoo style guide, I think I'll try it again!
Don't get me wrong, I really appreciate your criticism because it makes me think twice about some things and will most probably lead to a better guide.

Arch Linux on Distrowatch

http://www.distrowatch.com/stats.php?section=popularity
Arch Linux Rankings:
Last 12 months: 58
Last 6 months: 56
Last 3 month: 45
Last 1 month: 28

i3839 wrote:Well, theoretically it shouldn't matter if 100 or 1000000 people use a distro for the developers, they still should do the same work. Only thing that really changes is that the community will be much bigger, so there will be more questions and demands, but those should be handled by the community itself imho. A bigger community also means potentially more people willing to write docs and make packages, so the "problem" should be fixed by itself. Only thing that can go wrong is that reality isn't in sync with theory .
yeah the last sentence is more true than the rest. and the first one is definitely the least accurate. some devs do more work than others and everyone should have the same workload. the TURs should be processing incoming, the TURs should be moving stuff to staging more regularily. ALL devs should be working abit on moving packages from incoming and staging to the repos. alll package maintainers should regularily work on their packages and ideally the workload (ie number of packages maintained) should be equal.
but for every 200 packages added you need one more maintainer. some devs have way more than 100 packages which is entirely too much. i did 400+ for three months and it drove me nuts. it isn't good to have some overworked while others disappear for months and maintain only a few packages.
doc developers NEED to be ontop of what is going on inthe community so that anything that is becoming FAQs is incorporated into the docs and does not lie in in three or four different places.
it would be nice too if the workload was in such a way that releases could be more regular or even incremental so that ugly upgrades can be avoided or installing via ftp.
and so forth.
it would be nice if your theory was true but alas i just don't think it is.

(Arch) Linux Myths

I have recently noticed that online forums and Linux user communities in particular are prone to developing what I'd like to call "technology myths".
Most of the problems and solutions given on forums are anecdotal in nature. Problems are rarely sourced to the actual code and suggestions are often casual or incomplete which is of course natural for this kind of communication. However, as certain solutions are being repeated without clear feedback, some notions take deeper roots in the collective consciousness thus becoming myths. Let me illustrate with an example.
How often have you seen people posting glxgears results? How often have you seen people replying "glxgears is not a benchmark"? Could you actually explain why it's not suitable to be one? The explanation is out there.
Another example could be the myth that exporting INTEL_BATCH=1 increases performance on Intel integrated GPUs. I have seen this in circulation for a long time, despite the fact that the actual code that could be triggered by this environment variable has been removed a long time ago.
As Arch Linux is rolling-release and a lot of code is being replaced rather rapidly, old and tried solutions are likely to become obsolete fast. I'd like to ask the Community to share their examples of other widely circulated myths and help keep an updated and sourced list of them (https://wiki.archlinux.org/index.php/Myths) so others will not waste their time trying solutions which are sure to fail.

In my experience, outdated wiki pages tend to propagate this stuff, along with blog entries. The trouble with blog entries is that they're often fire-and-forget, which means that solutions that might have been necessary a while ago are now unsuitable or unnecessary.
Wiki pages have no such excuse, being more fluid than blogs posts. This is particularly prevalent on the Arch Wiki, as Arch is a distribution with a small number but a large variety of (mostly) technically-experienced users who will often go to great lengths to increase performance or to accomodate for Rube Goldberg machine-like hardware or network setups. Thus, there are a lot of hacks on obscure pages (not, say, the Beginner's Guide or the major pages).
What we need is a major overhaul and review of many of the shorter and more obscure wiki pages, such as any of the ones under Request:Correction and Request:Expansion. I've "rescued" a few pages from this purgatory, but many pages have sat there for months or years and I do not have the experience or knowledge to improve them. I think that we could gain a great deal from more community awareness about improving the wiki and trying to encourage people to edit more. Rather than the same editors working on more mainstream pages and ignoring or barely touching the more arcane ones, it might be preferable to have people with little editing experience but more technical experience to take a look at some of the pages, capitalizing on the cumulative knowledge of our userbase a bit more.
Just a thought.

Arch Linux deemed "best" distro of 2014 by Linux Voice

Congrats everyone! http://www.linuxvoice.com/linux-distros/.
We were looking for a distro that performs well in every area, and excellently in many, making it a good all-round distro. However this alone isn’t enough. It needs to have something that pushes it ahead of the competition – and the competition is getting better every year. It needs that certain X factor to make it stand out. It should be a distro people want to install; a distro that people get passionate about; a distro that makes you remember why you love Linux.
Arch Linux does all this and more. The two things that make it stand out aren’t fancy bits of software, or slick user interfaces, but its philosophy and its community.
Last edited by link (2014-10-09 05:31:52)

From the same DistroWatch page karol quoted from:
Before one can answer what is the best distro, they have to answer for what purpose! While Arch is a great linux distribution, it isn't the one I would want to install and support on a 100 workstations in a business or classroom environment, or even my mother's computer. I probably wouldn't use it for a mission critical server role and it's also not one I would use for embed systems work.
There's a saying that learn Ubuntu and you learn Ubuntu, learn Arch and you learn Linux. Well, most users don't want or need to learn Linux (or Ubuntu).
"Best Distro" declarations are worthless. Instead they need to be "Best Distro For..." declarations. Arch is an excellent distribution, but as most people will tell you, it's not for the feint of heart. For general use, particularly in a business setting, openSuse would seem to be a better choice. For general use as a home desktop, one might look at one of the *buntus. For development work, particularly in the US, fedora, RHEL or CENTOS seems a good choice.
The reality is that from the user perspective, one can make any distro look and act like any other. The question as to what is best really comes down to how much work is involved to make it actually do that.
Again, Arch is an excellent distro. But depending on your use case, it might not be the best distro.
Fair points all (except for the "development work" bit), but since the whole article was a comparison of rolling-release operating systems, why single out Arch? Why bother even commenting? Using a rolling-release OS when you want a static setup is foolish, no matter what the distribution is.

Arch Linux Turkish Community Announcement

Similar Messages

Maybe you are looking for