You are not logged in.
Pages: 1
Hi.
This may be a bit of a tricky question, but I'll try anyway.
I've been using Arch for about 2 and a half years now. I know how pacman works, and I've composed quite a few packages.
However, I feel I do not know Arch well enough, especially with all of the more recent changes, such as the module autodetection, udev and the likes. I thought it through, and I'm also not sure about Arch's booting sequence either.
To make a long story short, I'm looking for information about what makes Arch tick, in a more in-depth approach. The wiki mostly contains HowTos and guides for very specific actions, involving more of a "do this and do that" approach.
I'd like to learn how Arch is doing what it's doing. So that I can solve some of my own problems and even help others.
How would you advise me to do so?
Thanks.
Some PKGBUILDs: http://members.lycos.co.uk/sweiss3
Offline
How would you advise me to do so?
Well you have been using arch longer than me so I don't think I'm the right to answer this, but if you want to know the arch bootup sequence it sounds sane to look through the initscripts.
Offline
To make a long story short, I'm looking for information about what makes Arch tick, in a more in-depth approach. The wiki mostly contains HowTos and guides for very specific actions, involving more of a "do this and do that" approach.
Whenever i write a wiki page, I try to make it more "here's why" than just "do this".
The top part of this: http://wiki.archlinux.org/index.php/XOr … figuration
and this page: http://wiki.archlinux.org/index.php/ModaliasPrimer
are both examples.
If there's anything specific, feel free to ask.
Mostly, the best way to know what's happening is to read through the system level scripts (/etc/rc.sysinit, /usr/lib/initcpio/init, etc etc).
Offline
If you're not already on the mailing list, subscribe now. Also, the dev blog can be useful reading.
Offline
However, I feel I do not know Arch well enough, especially with all of the more recent changes, such as the module autodetection, udev and the likes. I thought it through, and I'm also not sure about Arch's booting sequence either.
Just read: Start with /etc/udev/rules.d/udev.rules, read them, understand them, try to understand the programs referenced there, read them if they are scripts.
Understand the boot process, read /etc/inittab, read the files that are referenced there, start with /etc/rc.sysinit. Read the mkinitcpio files, starting with /lib/initcpio/init and the mkinitcpio tool itself.
That way you will be able to understand arch very well. Have fun.
Offline
Sweiss!!! I haven't seen you in ages!
Read every file in /etc/* and the manpages or online docs for each that looks confusing and/or interesting.
Dusty
Offline
Just reading probably won't teach you much. Rolling up your sleeves and jumping into a project will both teach you in a way you won't soon forget AND will force you to read whatever's relevant.
Here are some project ideas:
* Encrypt a /home partition
* Encrypt all but the /boot partition
* Automate the process so you can quickly build a new encrypted system (i.e. shell scripts)
* Build your own Arch ISO so as to include your unique packages:
-- Custom kernel
-- "Missing" packages you usually have to install from Community, afterwards
* Alter your ISO so it auto-partitions just the way you like it (e.g. separate encrypted /home partition)
* Alter "quickinst" and any other dependencies so you don't have to go through the menus to do a install -- and things turn out just the way you like, every time
* Make all of the above work on a 512MB (or larger) USB Flash drive
* Get suspend2 to work (not much of a challenge any more, I guess)
* Get two USB devices -- cameras, printers, etc. -- to connect and always appear as the same /dev (e.g. /dev/cannon /dev/kodak)
HTH 8)
Offline
* Get two USB devices -- cameras, printers, etc. -- to connect and always appear as the same /dev (e.g. /dev/cannon /dev/kodak)
That is easy.. hehe
Gruß, Johannes
http://www.hehejo.de
http://gallery.hehejo.de/jo
Offline
If I had the time... Ok, not a good way to start a thought, I know. But my point is, I think it would be a great way to learn if one were to pick some essential wiki pages, go through them step-by-step and see what works, what breaks and what's missing -- and fix the pages, of course. Then deviate from the main instructions some, where applicable, and put those results at the bottom (as sort of an "Tips and Tricks" appendix).
This would have to boost a person's understanding of any subject. Plus it seems it would only enhance the wiki's value. Bonus!
I'll get right on it! Err... When I have some time ![]()
Offline
Sweiss!!! I haven't seen you in ages!
Read every file in /etc/* and the manpages or online docs for each that looks confusing and/or interesting.
Dusty
Hey there Dusty.
I've been quite busy, yeah, but I continue educating myself Python-wise at least. Maybe soon I'll be able to create a wacky test editor myself and start a holy war
Thanks a lot for everyone's suggestions, I'm gonna do a lot of reading on friday I guess.
Keep it coming.
Some PKGBUILDs: http://members.lycos.co.uk/sweiss3
Offline
Pages: 1