I think that's to be expected. The developer-written official documentation covers the essential Gentoo topics (e.g., installation), Wikipedia covers the general Linux topics (e.g., filesystems), and the Arch wiki covers much of the day-to-day operation of Linux systems.

I think where the Gentoo wiki fits in is covering more technically difficult topics in which Gentoo users would be especially interested. You and I already covered how to make bootable USB sticks for loading firmware, another person wrote an article on LTSP, and I look forward to someone else writing replete articles on hardened systems and filesystem encryption.

All right, no basic stuff...
Anyway, I would like to know what the developers think at the moment

docs.gentoo.org redirects to gentoo.org/doc/en _________________"Dear Enemy: may the Lord hate you and all your kind, may you be turned orange in hue, and may your head fall off at an awkward moment."
"Linux is like a wigwam - no windows, no gates, apache inside..."

Again, the developers in their ivory towers obstruct any "community" help by means of another unfriendly username: prompt. What do they consider us? Feeble, beta male wallflowers, only but able to run emerge commands but unable to contribute anything to their work of art? Again, they maintain their secrecy; like children exchanging password: and key of some playground club and neighborhood hangout with walls of cardboard.

I think where the Gentoo wiki fits in is covering more technically difficult topics in which Gentoo users would be especially interested. You and I already covered how to make bootable USB sticks for loading firmware, another person wrote an article on LTSP, and I look forward to someone else writing replete articles on hardened systems and filesystem encryption.

DM-Crypt with LUKS article is already pretty rich as a wiki article... I've added a few things here and there for an alternate script and planned to detail more stuff, at least for the squash part of the article that I introduced with the alternate script, but meh, too much hassle as everything is clear with the README file, putted before the actual init script. Well, the article could improved alot but hey it requires too much time and hassle for somebody who is not familiar with the wiki syntax/grammar!

I think where the Gentoo wiki fits in is covering more technically difficult topics in which Gentoo users would be especially interested. You and I already covered how to make bootable USB sticks for loading firmware, another person wrote an article on LTSP, and I look forward to someone else writing replete articles on hardened systems and filesystem encryption.

DM-Crypt with LUKS article is already pretty rich as a wiki article... I've added a few things here and there for an alternate script and planned to detail more stuff, at least for the squash part of the article that I introduced with the alternate script, but meh, too much hassle as everything is clear with the README file, putted before the actual init script. Well, the article could improved alot but hey it requires too much time and hassle for somebody who is not familiar with the wiki syntax/grammar!

It would be nice if you input few directions for users that don't want to use lvm but simple partitions instead... please!
Thank you!_________________"Dear Enemy: may the Lord hate you and all your kind, may you be turned orange in hue, and may your head fall off at an awkward moment."
"Linux is like a wigwam - no windows, no gates, apache inside..."

It would be nice if you input few directions for users that don't want to use lvm but simple partitions instead... please!

Well, the reason I did not insist on that is, simply, a great deal of the article is about disk encryption! Moreover, the init script is all about that as well. I couldn't insist even more about that. So the alternate one introduced LVM2, some precisions on GnuPG encrypted key files, loop back (LUKS) crypted key files, aufs+squashfs and use exlusively TuxOnIce as THE hibernate implementation. I guess I could consider modifying the hibernate side to be able to use the in kernel solution, or leave the user to suspend to no LVM2/LUKS (PV) volumes, there's no use for swap as one can pretty much use dmcrypt init service for that. But hey I won't help to hibernate to a plain unencrypted partion! how could I leave the possibility to leave an unencrypted RAM image with everything easily readable by anyone?! And yes, one can even use unencrypted partion for root `/' already with the alternate script and no LVM for both scripts.

I think where the Gentoo wiki fits in is covering more technically difficult topics in which Gentoo users would be especially interested. You and I already covered how to make bootable USB sticks for loading firmware, another person wrote an article on LTSP, and I look forward to someone else writing replete articles on hardened systems and filesystem encryption.

DM-Crypt with LUKS article is already pretty rich as a wiki article...

Do you mean on gentoo-wiki.com ? I guess that's another issue, how wiki.gentoo.org and gentoo-wiki.com would complement each other, if at all ..._________________Personal overlay | Simple backup scheme

It would be nice if you input few directions for users that don't want to use lvm but simple partitions instead... please!

Well, the reason I did not insist on that is, simply, a great deal of the article is about disk encryption! Moreover, the init script is all about that as well. I couldn't insist even more about that. So the alternate one introduced LVM2, some precisions on GnuPG encrypted key files, loop back (LUKS) crypted key files, aufs+squashfs and use exlusively TuxOnIce as THE hibernate implementation. I guess I could consider modifying the hibernate side to be able to use the in kernel solution, or leave the user to suspend to no LVM2/LUKS (PV) volumes, there's no use for swap as one can pretty much use dmcrypt init service for that. But hey I won't help to hibernate to a plain unencrypted partion! how could I leave the possibility to leave an unencrypted RAM image with everything easily readable by anyone?! And yes, one can even use unencrypted partion for root `/' already with the alternate script and no LVM for both scripts.

Isn't it possible to encrypt partitions without lvm2 ?
If that is not possible, then lvm2 is absolutely necessary for the correct setup._________________"Dear Enemy: may the Lord hate you and all your kind, may you be turned orange in hue, and may your head fall off at an awkward moment."
"Linux is like a wigwam - no windows, no gates, apache inside..."

Isn't it possible to encrypt partitions without lvm2 ?
If that is not possible, then lvm2 is absolutely necessary for the correct setup.

It's absolutely not necessary with the alternate init script (and there's no LVM2 support with the "main" one)--as with GnuPG, loop back (LUKS) key file or even a key file at all, as for TuxOnIce or swap. You can pretty much use the init script without LVM2 support and can build an initramfs without as well (with the provided script). You can even use it with unencrypted PVs--this is true only for root! There's only an extra kernel (cmdline) argument when using LVM2 and there's a little change for tree others as well. Well, I did not post the building scripts in the unofficial wiki, but there are links to github repository if one need more stuff related to the alternate script.

Isn't it possible to encrypt partitions without lvm2 ?
If that is not possible, then lvm2 is absolutely necessary for the correct setup.

It's absolutely not necessary with the alternate init script (and there's no LVM2 support with the "main" one)--as with GnuPG, loop back (LUKS) key file or even a key file at all, as for TuxOnIce or swap. You can pretty much use the init script without LVM2 support and can build an initramfs without as well (with the provided script). You can even use it with unencrypted PVs--this is true only for root! There's only an extra kernel (cmdline) argument when using LVM2 and there's a little change for tree others as well. Well, I did not post the building scripts in the unofficial wiki, but there are links to github repository if one need more stuff related to the alternate script.

Thank you! _________________"Dear Enemy: may the Lord hate you and all your kind, may you be turned orange in hue, and may your head fall off at an awkward moment."
"Linux is like a wigwam - no windows, no gates, apache inside..."

If someone wants to incorporate pieces of that into official doc, have at it.

My gripes with the existing doc were mainly that it tried to throw absolutely everything at you all at once, instead of building up from the basics, THEN showing deviations, THEN showing how to make it a bit more fancy, THEN showing an "all in one" sort of deal.

As it is now, you go through the articles verbatim, and if something doesn't work, since you don't know *how* things are pieced together, and *why* the doc tells you to do one thing or another, you're completely lost.

Whereas if you build from the basics, and explain the *why* of things along the way, you aren't in a situation with a "one size fits all" document, where if one part doesn't work the whole thing is rendered irrelevant/invalid.

Documentation should teach, rather than just giving readers things to repeat - even if writing such doc takes a fair bit more keystrokes. I want to understand what I'm doing, and why I'm doing what I'm doing, not just be told "hey, do this" and not know why_________________Lost configuring your system?
dump lspci -n here | see Pappy's guide | Link Stash

If someone wants to incorporate pieces of that into official doc, have at it.

My gripes with the existing doc were mainly that it tried to throw absolutely everything at you all at once, instead of building up from the basics, THEN showing deviations, THEN showing how to make it a bit more fancy, THEN showing an "all in one" sort of deal.

As it is now, you go through the articles verbatim, and if something doesn't work, since you don't know *how* things are pieced together, and *why* the doc tells you to do one thing or another, you're completely lost.

Whereas if you build from the basics, and explain the *why* of things along the way, you aren't in a situation with a "one size fits all" document, where if one part doesn't work the whole thing is rendered irrelevant/invalid.

Documentation should teach, rather than just giving readers things to repeat - even if writing such doc takes a fair bit more keystrokes. I want to understand what I'm doing, and why I'm doing what I'm doing, not just be told "hey, do this" and not know why

Very good document, thank you !_________________"Dear Enemy: may the Lord hate you and all your kind, may you be turned orange in hue, and may your head fall off at an awkward moment."
"Linux is like a wigwam - no windows, no gates, apache inside..."

Whereas if you build from the basics, and explain the *why* of things along the way, you aren't in a situation with a "one size fits all" document, where if one part doesn't work the whole thing is rendered irrelevant/invalid.
Documentation should teach, rather than just giving readers things to repeat - even if writing such doc takes a fair bit more keystrokes. I want to understand what I'm doing, and why I'm doing what I'm doing, not just be told "hey, do this" and not know why

Well, I guess the Initramfs article (in the unofficial wiki) plus a HOWTO or two in the forums just do somthing with that in mind. I don't know if it's crystal clear for an initramfs noob. I'd just add that the basic is pretty simple build a static busybox with many "applets" (basic commad like dd, cp, mv, et. all) as one will need if not the whole stack so you don't bother to ask yourself what is needed for what? And then construct the root `/' of the initramfs as one would expect in basic system with bin:sbin:lib:usr:dev:sys:proc with devices nodes in dev if the init script does not take care of creating them, plus extra binaries/libraries that one may need with his/her init script of choice.
And then build the compressed cpio image, and add a line in the boot loader command. That's all, nothing really complicated for a basic initramfs. And you'll find that basic structure in the forum HOWTO or in the Initramfs wiki article.

Well, if we come back to our complicated init script with a few possibilities left to the user to use functionalities included in the init script that become a little complicated--as the DM-Crypt with LUKS article--depending of the functionalities included in the script, so the simple process to build a simple initramfs just vanish somewhere and the user is faced to many details related to the complicated task to do. That's where the building script comes into play and leave the user in the middle of nowhere if he/she doesn't has basic idea of how to build an initramfs. But there's nothing that complicated with what is posted on the wiki or forum, the int script is a bit long (several hundreds of lines of a POSIX sh script), that's all. Did you even try to read Arch initramfs' building script? That one is complicated because it is intended to adress everything without requiring the user anything but a few configurations options.

Ahah aren't violating themself the license then ? It's by many law considered a benefit/un-benefit (dunno the word, bad?) toward a company to have its name stick to something, agreed or not.
As-is, anyone could consider the unofficial wiki a benefits (or maybe if you wish, even an attack) to use any gentoo name, logo...
And if gentoo take audience or anything good from that, gentoo get profits from their NC document
Nobody could publish anything toward a company under NC license, else this would grant benefits (fame, audience...) to the company.
Not all gift, benefits... are made of money. Fame, audience... are also benefits.

Quote:

in any manner that is primarily intended for or directed toward commercial advantage or private monetary compensation.

fame, audience... are direct advantages (some company even base their market on that, like google), and none can say Gentoo isn't well know for its documentation. So the more you speak about gentoo, the more you promote gentoo, the more doc you write about gentoo, the more you add fame to gentoo fame about its documentation...

It appears a bit like a non-sense no?
(i admit it might not be the right place to chat about that, and i don't really wish chat about that, it was just funny to note)