Arch Linux cheat sheet [PDF and ODG]

Hi, as far as I know, I already turn two Windows users to Arch, so I was thinking that would be nice to have a simple cheat sheet to help new users quickly.
Somethings maybe wrong and thats why I'm asking for help and contributions. Many new things I wasn't aware (like the new "No xorg.conf" philosophy, the departure of hwd and many other new things), I've been using Arch for almost two and a half years, so I even haven't tried the new Installation Framework (hopefully tomorrow a friend will install Arch, so I will have a chance). Many other errors must be in the grammar, I'm pretty lousy at English as you can see. And finally, maybe I just forgot something you may think that should be in the cheat sheet or something I put, but in the wrong way.
Anyway, hope somebody find it useful or like to help, the link is: http://elzoona.com.ar/archcheatsheet
P.S.: The PDF was made using OpenOffice Draw, but, after many years, I still can't use offimatic software, so If anybody knows a better option please tell me (if you download the ODG will see that indentation was done with four spaces...).

Typos fixed.
Xyne wrote:I like the overall idea but I worry that the pacman command section might encourage laziness. I think you should emphasize the importance of the pacman man page along with some others to make it clear that most information is readily available from the command line.
Yeah, could it be. My attempt was to give a quick reference for common commands, to avoid reading all the man page when you only can't remeber wich one was the, i.e., --foreign switch. But encourage to read a lot more by giving the "pacman -[Q|R...] --help" section. The whole idea of the cheat sheet it's to remind a simple command you know that exists but can't remember the name or a specific switch. Anyhow, to include the "look for man pages, they still exists" could be an excellent idea (you know, this times when everything is a wiki or a search button away) because reading trough man pages provide a lot of knowledge.
Xyne wrote:Perhaps an "important man pages" section would convey this. You could include pacman, pacman.conf and makepkg to start with.
Damn, I knew it! I forgot to include a single reference to makepkg command.
EDIT: Included a "useful man pages" at the end of some sections and 100% more advices for free! :-).
Last edited by el_zoona (2009-06-13 13:08:25)

Similar Messages

Linux Cheat Sheets (awk, ed, sed, bash, screen, perl, and more)

Hey! While learning various linux tools in the past, I made several cheat sheets to speed up the learning process. Recently I decided to put them on my blog.
Here is a link to all the cheat sheets on my blog:
cheat sheets at catonmat (my blog)
They include (some of the links include tutorials, as well):
* awk (awk, nawk and gawk) programming language cheat sheet,
* sed, unix stream editor, cheat sheet,
* ed, interactive unix text editor, cheat sheet,
* perl's special variable cheat sheet,
* perl's pack/unpack and printf/sprintf function cheat sheet,
* screen vt100 terminal emulator cheat sheet,
* bash vi editing mode (readline) cheat sheet, and
* bash emacs editing mode cheat sheet.
Tell me what you think and I hope you find them useful!
ps. I have 5-10 more to publish, if you are interested, check back and possibly subscribe to my posts via rss feed
Last edited by pkrumins (2008-02-19 15:41:00)

Hi all! I just wrote a another article with a cheat sheet. It's called "The Definitive Guide to Bash Command Line History". This tutorial teaches you how to quickly retrieve and modify commands you executed previously.
It starts by reviewing the keyboard shortcuts for history retrieval in emacs and vi editing modes, then it covers the commands for listing and erasing the history, then it goes into discussing history expansion mechanism - event designators, word designators and their modifiers. Finally the guide lists variables and options to modify the default history behavior.
The cheat sheet comes in PDF, Plain Text ASCII and LaTeX:
* PDF format (.pdf): bash history cheat sheet (.pdf)
* ASCII .txt format: bash history cheat sheet (.txt)
* LaTeX format (.tex): bash history cheat sheet (latex .tex)
Last edited by pkrumins (2008-02-19 15:40:31)

Linux cheat sheet?

On this URL: http://www.oracle.com/technology/products/ias/hi_av/index.html
I tried accessing the Linux cheat sheet to no avail. The document is not available on Metalink.
Where is it?
--AndrÃ©.

Hi there,
The link is correct but somehow the page was not made public. This should be fixed during this week.
Thanks

Arch Linux won't boot (and Linux in general)

Hello everyone,
I've been having this problem for about 3 days now. I finally made an account and post the problem since I can't find a solution (I solved most of my past problems by searching forums and googling so I had never posted before).
So, I was installing Arch linux and Windows 7 on my machine (eee pc 1201t) but had problems booting into linux. First I installed Windows and it worked fine, then I installed Arch linux (this isn't my first time) and rebooted after finishing the installation. But my laptop just won't boot. It just displayed a blinking cursor on the top left of the screen. No error messages whatsoever. It was my first time encountering the problem so I thought reinstalling would do the trick. But it didn't. So I started researching on the same problems on google and discovered that it could be either a HD problem or corrupted MBR or some other problem. My drive works fine, since I can copy data onto it using a live cd (Ubuntu) and Windows works fine with it.
I'm thinking of using "dd" command on my drive and repair the MBR. I would like to know if you guys have encountered the same problem before and what kind of solution you applied.
Note: I also tried installing Ubuntu on my machine but the result was the same.

ngoonee wrote:Live CD, setup grub again, and profit?
I tried this first, had no luck or maybe I wasn't doing it right.
nixpunk wrote:So are you booting into windows using grub or just ntldr?
My laptop boots using ntldr only. Grub does not seem to work. I tried installing Arch and Ubuntu but I had the same result (blinking cursor on the top left of the screen).
schuay wrote:As always with boot problems, you will need to provide some more data about your setup. Output of 'df -h', contents of /boot/grub/menu.lst, install location of grub, etc. Without that, other people can only make guesses about the possible solution
I'll keep that in mind. Sorry for the lack of details regarding my problem. I will try to add as much information as I can the next time I post.
Anyway, I think I solved the problem. I zeroed the MBR on my HD by issuing the command "dd if=/dev/zero of=/dev/sda bs=512 count=1 and grub installed just fine. Thanks for the reply everyone.

New Arch Linux Schwag offerings: Speakers and Notepaper

It's been a while since anything exciting has happened in the Arch Linux Schwag shops. Laptop stickers seem to be the most popular offering. I'm having trouble getting rid of Arch Linux Pens so they've been discounted to below cost.
New today are a couple offerings in the Arch Linux Zazzle Schwag store:
Arch Linux Speakers
Arch Linux note paper
Hope you enjoy the new schwag!
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

Securing Arch Linux by Scrubbing SUIDs and SGIDs

Hello.
Scrubbing SUIDs and SGIDs has been a perennial security recommendation for Linux. Recently I ran:
find / ( -perm -4000 -o -perm -2000 ) -exec ls -ldb {} ;
on one of Arch Linux machines which resulted in finding 43 SUIDs and SGIDs:
-r-sr-xr-x 1 root root 19848 Jul 1 13:19 /bin/su
-rwsr-xr-x 1 root root 31024 Jun 10 09:32 /bin/ping
-rwsr-xr-x 1 root root 64816 May 13 19:15 /bin/mount
-rwsr-xr-x 1 root root 26832 Jun 10 09:32 /bin/ping6
-rwsr-xr-x 1 root root 31908 May 13 19:15 /bin/umount
-rwsr-xr-x 1 root root 544452 Jun 7 06:27 /opt/kde/bin/kppp
-rwsr-xr-x 1 root root 10341 Jan 17 2004 /opt/kde/bin/fileshareset
-rwsr-xr-x 1 root root 5188 Jun 6 19:54 /opt/kde/bin/kgrantpty
-rwxr-sr-x 1 root 1003 52152 Jun 6 21:07 /opt/kde/bin/kdesud
-rwsr-xr-x 1 root root 10368 Jun 6 21:07 /opt/kde/bin/kcheckpass
-rwsr-xr-x 1 root root 5356 Jun 6 19:54 /opt/kde/bin/kpac_dhcp_helper
-rwsr-xr-x 1 root root 28444 Jul 1 12:58 /usr/bin/chfn
-rwsr-xr-x 1 root root 24368 Jul 1 12:58 /usr/bin/chsh
-rwxr-sr-x 1 root mail 78200 Sep 4 2002 /usr/bin/mail
---s--x--x 1 root root 85800 Jun 21 2003 /usr/bin/sudo
-rwsr-xr-x 1 daemon daemon 8480 Jul 21 14:16 /usr/bin/lppasswd
-rwsr-xr-x 1 root root 10032 May 5 18:15 /usr/bin/crontab
-rwsr-xr-x 1 root root 34988 Jul 1 12:58 /usr/bin/chage
-rwxr-sr-x 1 root tty 8012 May 13 19:15 /usr/bin/write
-rwxr-sr-x 1 root slocate 26432 Dec 4 2003 /usr/bin/slocate
-rwsr-xr-x 1 root root 201216 Jul 27 11:56 /usr/bin/xscreensaver
-rws--x--- 1 root cdrom 552820 Jul 20 19:06 /usr/bin/cdrdao
-rwsr-xr-x 1 root root 15532 Jul 1 12:58 /usr/bin/expiry
-rwsr-xr-x 1 root root 11768 Jan 6 2003 /usr/bin/netselect
-rwsr-xr-x 1 root root 19756 Jul 1 12:58 /usr/bin/newgrp
-rwsr-xr-x 1 root root 25004 Jul 1 12:58 /usr/bin/passwd
-rwsr-xr-x 1 root root 32952 Jul 1 12:58 /usr/bin/gpasswd
-rwsr-xr-x 1 root root 10564 Jul 27 11:52 /usr/bin/suexec
-rwsr-xr-x 1 root root 68056 Oct 22 2002 /usr/bin/procmail
-rwsr-xr-x 1 root root 306444 Dec 6 2003 /usr/bin/screen-4.0.2
-rwsr-xr-x 1 root root 5772 Aug 3 14:48 /usr/bin/pt_chown
-rws--x--- 1 root cdrom 290364 May 30 2003 /usr/bin/cdrecord
-rws--x--x 1 root root 132396 Apr 19 12:41 /usr/lib/ssh/ssh-keysign
-r-sr-x--- 1 root root 24676 Jan 30 2004 /usr/lib/pppd/2.4.2/rp-pppoe.so
-rws--x--x 1 root bin 88156 May 30 2003 /usr/sbin/rscsi
-rwsr-xr-x 1 root root 564048 Jul 23 16:48 /usr/sbin/exim-4.41-1
-r-sr-xr-x 1 root bin 18328 Sep 4 2002 /usr/sbin/traceroute
-rws--x--x 1 root root 1943573 Jul 10 10:22 /usr/X11R6/bin/Xorg
-rws--x--x 1 root root 292896 Jul 10 10:22 /usr/X11R6/bin/xterm
-rwsr-xr-x 1 root root 21790 Jul 1 14:22 /usr/X11R6/bin/xcardinfo
-rwsr-xr-x 1 root root 9670 Jul 16 12:44 /usr/libexec/rssh_chroot_helper
-r-sr-xr-x 1 root root 14424 Mar 16 14:52 /sbin/unix_chkpwd
-rwsr-xr-x 1 root root 14148 Jul 1 14:22 /sbin/cardctl
First Question: How many of these should NOT be SUID or SGID "out of the box" (i.e., on installation of Arch Linux)?
Second Question: What are some good approaches to reducing the use of SUIDs and SGIDs?
My approaches are: (a) deleting executables/packages that I actually don't use (for example, I will remove executables/packages I don't ever use or plan to use such as /opt/kde/bin/kppp); (b) removing the SUID or SGID bit on some of the executables.
My concern is less with approach (a) than with (b). Which of these executables MUST be SUID or SGID to work properly?
Regards,
Win

Win wrote: Which of these executables MUST be SUID or SGID to work properly?
Probably almost all of them need to be SUID to work properly from a user account. Such programs have to access root files, usually.
However, if you never use a particular program as user, it need not be SUID (this is usage dependent).
Dusty

Arch Linux 32x64 bits, Developers and Window Managers Support

Greetings!
After having some time issues due to college that prevented me from this, I wish to have again a rolling-release distro in my computer.
I was in the past a big fan of Gentoo, but now it seems too much work to compile everything from scratch. Also they seemed to have some issues with the developers - the original developer if I understood correctly has quit the project, others were forced to quit due to misbehavior, etc. - and maybe due to some other facts their popularity on distrowatch dropped drastically.
Then this year I've tried Debian Testing... My goodness, that was messy. Tons and tons of bugs on XFCE, like thunar hanging on load and displaying error messages, gedit not removing the ~lock files properly on close, so I had the myfile and ~myfile, and many others. Really, I gave up.
I wish to give Arch Linux I try then. Of course that would be quite stupid to ask if arch linux is the best choice in an arch linux forum, but there are some key points that if you could answer would help me a lot to give it a try:
1. 32x64
"Should I use 32-bit or 64-bit?" is NOT the intended question. Many still prefer 32-bit-pae on a 64-bit capable machine, others prefer 64-bit. I wish to use 64-bit. Made my mind. But I would like to know if the support of 64-bit on Arch Linux is as good as 32-bit and if it comes by default with cross-libs which makes me able to run 32-bit applications natively right out of the box,
2. Developers
About how many and what's their relation with the users? When I've googled for Arch Linux, I've had found a review video on youtube where some guy said in the comments that developer's mind changed a lot in the past 2 years and they introduced many buggy packages that required manual workaround. At the end of his comments, he said "Sympathy? Apologies for the ****? Nope. blame the user for trusting 'pacman -Syu'" Surely I don't know which are these options because I haven't read about pacman yet (just know it's the default package manager) but you get the idea.
Another key question: Is Arch Linux hiring new developers over the time? Replacing the ones that leaves for the many reasons?
3. Window Managers Support
With Gnome3's overall rejection (including mine), we have only two options: Switch to KDE or try other Window Managers. I still wish to have faith on gtk, so the first option is still not considered by me. I don't wish to know "which one is the best", because that's another large discussion just as the 32-bit x 64-bit. Just how good is Arch's support (updated constantly? bug-fixes?) on:
- XFCE
- MATE
- Cinnamon
(Of course there are others like LXDE, Enlightenment, etc. but I've decided to narrow down to XFCE even having quite bad experiences on Debian Testing.)
4. Package Manager
Last, being a rolling-release dist, can I add an option for a specific package to install a specific older version and/or not upgrade when you tell the dist. to upgrade everything? I remember that back on Gentoo I could edit a text file and just type the version of the package I wished to keep and the "update everything" option wouldn't touch the package (worked also to try new versions that were still not stable enough).
Any replies will be very appreciated. Sorry for the long post.
Best regards.

I'll start at the end with #4. Of course on the arch forums you will get people who are biased towards liking arch - but I think if you ask in other communities you will regularly hear that arch's package management system is its greatest strength. Pacman is the primary tool for this, but we also have makepkg for things in the Arch User Repository (AUR), and the Arch Build System (ABS) to recompile anything from the main repos with additional/alternate compilation options.
But for your direct question, there is an option to only upgrade to a particular version of a given package. There is an option in pacman's configuration file for just this purpose. However depending on what the package is, this could lead to problems. Users are discouraged from updating most of their system while keeping some older packages - This can lead to issues with shared dependencies. Of course if you build the package from source (AUR or ABS) yourself, such issues would be easy to resolve. Is there a certain package you know you'd want to keep at an older version? If you tell us what it is, we can give more specific information on how easy/hard it would be to accomplish.
#3: Arch is a DIY distro. You choose whatever window manager / DE you want. I can vouche for XFCE working wonderfully in arch. There are also numerous archers who use mate and cinnamon. I have heard of some problems, but (AFAIK) these have nothing to do with compatibility with arch, rather these are due to upstream issues. In other words, cinnamon, mate, xfce, or any other WM should work just as well on arch as on any other distro. I'd bet our wiki for installing and configuring those WMs are better than those of the distros that bundle the WM with the core install. (In addition to package management, you will find the arch wiki is second to none).
#2: I can't answer with any specifics - other than to say they continue to do an excellent job. I am not surprised by the youtube video - not because I'd agree with it, quite the opposite. But as arch is a DIY distro it puts some responsibility on the user to maintain their own system. If one is not prepared for nor willing to do this, they often become frustrated and end up blaming someone else. Often this is the developers, sometimes it is the forum moderators, other times it is the whole arch community. In every case these accusations are absurd. Your questions on replacement of developers is a good question though - there is a history page on the wiki which might give some insight on this, but I suspect others will have better input on this.
#1: I use i686 (32bit) on two of my computers and it works perfectly. It sounds, however, that a majority of the community uses 64bit (which I just updated to on one of my computers). My 64bit system works perfectly as well, but I don't have any 32bit-only apps. Occasionally there are forum threads about some issue or another with "multilib" applications which are 32bit programs run in a 64bit system. Generally these threads seem to be resolved without much hassle. You can search for some of them yourself: Skype seems to be a common topic of such issues.
All in all, I'd reiterate arch's strengths in it's package management and wiki/documentation. Potential weaknesses could be found by users who are unwilling or unable to take responsibility for their own system. I word this is a bit biased manner - there are many people who have no interest in being responsible for maintaining their own system, a majority of all computer users would fall into this category; most of them would be quite unhappy with arch linux. If you were happy with gentoo in the past and only want to avoid constant recompiling then you probably would be one who could be very happy with arch.
Or an even shorter summary: try it out. If you don't like it, switch.

UArch - arch linux for for old and tiny machines

Hello everyone,
I just want to post my the new location for uArch over at google code.
http://code.google.com/p/uarch/
check it out and let me know what you think.
zio

Don't cross-post.
Closed.

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 on SmartQ (V5II) -looking to start project-

Upfront I will note that I am not skilled enough to accomplish this alone at my current level. I will learn what I can in order to achieve this task, so any and all links to tutorials and ideas on how to get this working will be taken and put through heavy consideration. Primary concern will be getting a working "livecd" cloned image (basically, all the most standard core packages to get a working Arch Linux with USB Keyboard and mouse support, then build from there till I get X and all the nice features of the V5(II) working, and branch out from there Will probably look into repartitioning the NAND so I can have a complete and full install (probably preserve Android for being boot from SD, which is fine since it's a complete dual-boot which requires rebooting to switch anyway) As of now, I am referencing the development tutorial for SmartQ, tutorials for building firmware images from plugapps (nice Arch port to ARM devices) and whatever information I can gather from someone on the Arch Linux forums who has recently ported it to the newest ARM processor type (v7, if I'm not mistaken). All links will be provided at the bottom of this post.
My guess is that I will have to approach this with a "Linux From Scratch" mindset of compiling the kernel, busybox and whatever else I need to get a working base install (which, from there, I can compile everything else natively on the actual device)to the point where I reach a working system with gui, basic tools, maybe a game or two, and whatever else would constitute being enough for "firmware" status. I guess, my only question ahead of all that is how do I go about making the "base install" firmware to build up from? Secondary question to that is, once I get a nice setup, how do I take that (all being on the actual V5II) and remaster THAT into a firmware that I can then post online for others to test? I already have my homework cut out for me, so I'll be reading what i can to figure this out while anybody and everybody here throws me tutorial links and ideas on how I can accomplish this each step of the way... We shall see where this train takes us.
SmartQ Linux Development Guild: https://docs.google.com/View?id=ddtx8wk … skpm&pli=1
PlugApps Development Portal: http://www.plugapps.com/index.php5?titl … evelopment
Arch Forum post for developer who ported Arch Linux to the v7 ARM processor: https://bbs.archlinux.org/viewtopic.php?id=59638
can't think of anything else at this point, but I will categorize links the best I can to morph them into somewhat of a workflow process and group the help aids to each relevant step along the way. Anyone interested in helping, feel free to join in on the fun.. Will be looking that the ArchMobile stuff and incorporating what I can into my project... maybe this will help revive the ArchMobile project as well...

If you are a new programmer then Python is a good place to start. Install WingIDE 101 from the AUR for a good beginner's IDE for that.
Think Python is a free book to get started with (PDF or HTML download on that page and you can buy the dead tree if you want)
If you want to do programming that requires fast code above all else then C++ is the standard. Code::Blocks is a good IDE for that. Be sure to install "base-devel" and "gdb" to go along with it.
Programming - Principles and Practice Using C++ is a dead tree book for C++, you have to buy it but that is offset by the fact that its author is also the author of the C++ language.

[SOLVED] Arch Linux on Macbook - Can't fix Screen Resolution

I just installed Arch Linux as a dual-boot on my Macbook. I really like it so far. However, I came across a problem that is really bothering me. It may seem simple, but no matter what I try, I only get "1024x768" and "800x600" resolution options. What I need is "1280x800." Here is my xorg.conf file right now:
Section "ServerLayout"
Identifier "X.org Configured"
Screen 0 "Screen0" 0 0
InputDevice "Mouse0" "CorePointer"
InputDevice "Keyboard0" "CoreKeyboard"
EndSection
Section "Files"
ModulePath "/usr/lib/xorg/modules"
FontPath "/usr/share/fonts/misc"
FontPath "/usr/share/fonts/100dpi:unscaled"
FontPath "/usr/share/fonts/75dpi:unscaled"
FontPath "/usr/share/fonts/TTF"
FontPath "/usr/share/fonts/Type1"
EndSection
Section "Module"
Load "glx"
Load "dri2"
Load "extmod"
Load "dbe"
Load "dri"
Load "record"
EndSection
Section "InputDevice"
Identifier "Keyboard0"
Driver "kbd"
EndSection
Section "InputDevice"
Identifier "Mouse0"
Driver "mouse"
Option "Protocol" "auto"
Option "Device" "/dev/input/mice"
Option "ZAxisMapping" "4 5 6 7"
EndSection
Section "Monitor"
Identifier "Monitor0"
VendorName "Monitor Vendor"
ModelName "Monitor Model"
EndSection
Section "Device"
### Available Driver options are:-
### Values: <i>: integer, <f>: float, <bool>: "True"/"False",
### <string>: "String", <freq>: "<f> Hz/kHz/MHz"
### [arg]: arg optional
#Option "ShadowFB" # [<bool>]
#Option "DefaultRefresh" # [<bool>]
#Option "ModeSetClearScreen" # [<bool>]
Identifier "Card0"
Driver "vesa"
VendorName "Intel Corporation"
BoardName "Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller"
BusID "PCI:0:2:0"
EndSection
Section "Screen"
Identifier "Screen0"
Device "Card0"
Monitor "Monitor0"
SubSection "Display"
Viewport 0 0
Modes "1280x800"
Depth 1
EndSubSection
SubSection "Display"
Viewport 0 0
Modes "1280x800"
Depth 4
EndSubSection
SubSection "Display"
Viewport 0 0
Modes "1280x800"
Depth 8
EndSubSection
SubSection "Display"
Viewport 0 0
Modes "1280x800"
Depth 15
EndSubSection
SubSection "Display"
Viewport 0 0
Modes "1280x800"
Depth 16
EndSubSection
SubSection "Display"
Viewport 0 0
Modes "1280x800"
Depth 24
EndSubSection
EndSection
I just followed the instruction on the Arch Linux - Macbook Wiki page, and everything worked perfectly, except the resolution question. The only thing I added to the file is the 'Modes "1280x800"' lines. This is exactly what I've always done with linux, and it has always worked. So I'm perplexed, and I can't find any solutions that actually work by googling it. Has anyone else come across this problem, and even more important, does anyone know what is wrong?
Thanks.
Last edited by meolson (2009-09-23 04:44:23)

Ok. I figured it out. I found this forum:
http://bbs.archlinux.org/viewtopic.php?id=56899
I found it before, but I had done everything, or so I thought. At the end, he mentions two things that are important to fix the resolution. I've repeated them here, and adapted them to what I had before:
pacman -S xf86-video-intel
edit /etc/X11/xorg.conf, and change video card driver from 'vesa' to 'intel'
I thought I had installed xf86-video-intel already, but apparently I hadn't. So, I followed those two steps, and now, it looks so much better! Thanks to anyone who tried to looked for a solution.

New Arch Linux review

Arch Linux: The Simple, Flexible (and Fast!) Distro http://www.linux-mag.com/cache/7469/1.html.
Good review.

Reading it right now
Arch seems to get a lot of attention lately!
I still find linux-mag.com's articles more often then not boring... It seems like a 15 yo blog, not the high quality publication of before. But then, now its free
Edit: After 2 paragraph, they can't even link to the website: http://www.archlnux.org/ instead of http://www.archlinux.org/ ...
Edit: Still a nice article that talks about Arch general terms. It should give Arch more visibility!
Last edited by big_gie (2009-08-13 13:37:34)

(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.

Recommend Virtualization Software on Arch Linux 64-bit

I have my Arch Linux 64-bit workstation and need to test out some virtual guest machines and was wondering if anyone on Arch Linux has ever had any results between Oracle's 'VirtualBox' or 'VMware' suite. I heard good things about both. VMware has a crazy / confusing amount of options and different versions which appear to be more 'enterprise' geared but this could be the fact that it's just been around longer and more known commonly known.
Thanks for any feedback / suggestions on what I should use.

http://www.virtualbox.org/wiki/VBox_vs_Others
Of course, take it with a grain of salt since it is from Virtualbox website.
http://stackoverflow.com/questions/6301 … virtualbox
Some slightly old benchmarks there. Vbox is in version 3 now, not 2. But probably somewhere out there you could google some benchmarks if that is what you are interested in.
As far as personal experience, I used to use Qemu, then VMware, and now been on Virtualbox for a couple years. I like having a little pet WinXP kept in its cage It works fine with me. I switched off of VMware because I liked the Seamless Mode in Vbox and Vbox has experimental D3D support

Arch Linux cheat sheet [PDF and ODG]

Similar Messages

Maybe you are looking for