See this post for some background on how easy it is to be "peer-pressured" in the OSR. So here's part two, again inspired by Alex Schroeder's answers, again to questions that Random Wizard originated as part of an evil scheme to take over the Trolls of the world.
Should energy drain take away one level of experience points from the character? Yes or No? If no, what should level drain do? I've actually never run into this. I guess I don't play enough D&D? I've had characters turn into werewolves and eat the rest of the party, I've had characters die while riding into town to start their adventuring career, I've had all kinds of bad stuff happen to characters in my games. But not this. So I'll put on my "player hat" for a second and say that I hate energy drain. Not because of the loss of level and XP mind you, but because of the book-keeping horror it entails. I'd rather just fail a save and have the character die instead! Wanted to try playing a halfling bard anyway...
Should the oil used in lanterns do significant damage (more than 1
hp in damage) if thrown on an opponent and set on fire? Yes or No? If
yes, how much damage should it do? I realize that for all kinds of somewhat scientific reasons, lamp oil should not be the cause of an inferno that sets entire dungeons on fire. But it's sometimes fun to set shit on fire (in game mind you!) and I've had my share of laughs with players fumbling attack rolls and dropping the darn things on their own party instead. Good times! The B/X standard of d8 damage may be a bit excessive, but I'd probably stick with it just for the heck of it. Also holy water does d8 to undead, so at least it's consistent with that. BTW, many monsters can toss those things right back at you if you fail to hit...
Should poison give a save or die roll, with a fail rolled
indicating instant death? Yes or No? If no, how should game mechanics
relating to poison work? I think that should depend entirely on the poison, don't you? There are different kinds after all, at least in my worlds. The real question trolly-troll hid here is "Should there be save-or-die rolls at all?" so I'll go with that instead. Sure, there should be "save-or-die" rolls, at least every now and then, at least for certain very powerful monsters, at least for (some) climactic encounters. Those saving throws on your character sheet get better for a reason: They measure how much work you've put into your character so far and how sad it would be to lose that character. It's a perfectly fair setup and you sat down to play the game. Now roll up another character! That said, I am not opposed at all to converting "save-or-die" things written into a module to something completely different if it suits me better. There's little point in tricking noobs with yellow mold spores for example. They just don't know, so they'll have their first character die on entering that room without really having a say in the matter. Not fun at all. So I'd replace that with a huge coughing fit that attracts monsters, maybe some minuses for 6 turns, etc. Oh, also important: If you use "save-or-die" stuff on player characters, be fair and allow them to use it on your favorite villain as well.
Do characters die when they reach 0 hit points? Yes or No? If no, then at what point is a character dead? The house rule from my "Expedition to the Borderlands" open-table game is pretty representative of what I usually do: "Characters are unconscious at 0 hit points and dead at their negative constitution score. Serious injury (negative hit points) can have permanent effects such as scarring, broken bones, missing limbs, etc." I don't specify a particular table, and usually I don't do evil things like letting the player roll for their character's new disability. Maybe I should? After all there's an entire blog dedicated to this stuff! (As a side-note, I am not too fond of critical hits. Most players aren't either once their character has been on the receiving end of a Stone Giant who crits his thrown rock.)
Does the primary spell mechanic for a magic user consist of a
"memorize and forget system" (aka Vancian)? Yes or No? If no, what
alternative do you use? Yes. In my "home game" however, I am giving wizards a permanent "detect magic" and priests a permanent "detect evil" as it were. I'd roll it, like finding secret doors or something, but those things wouldn't be spells. They are silly as spells. (Also here's a cursed sword for the fighter-types who keep complaining about that "one-shot" wizard in the party.)
Should all weapons do 1d6 damage or should different weapons have varying dice (1d4, 1d8, etc...) for damage? I know I'll get at least one "but you're double-dipping" comment for this, but anyway. Let me quote another house rule from my open-table game (which I just noticed I had never posted to our G+ group, something I'll have to remedy): "Damage is primarily class-based: Fighters do d8, Clerics do d6, Thieves and Wizards do d4. Light weapons (dagger, sling, etc.) get -1, heavy weapons (two-handed sword, pole arm, crossbow, etc.) get +1 to damage." The "home game" would differ on a few details (I give Thieves d6 hit-dice so they'd do d6 damage), but overall the system would be the same.
Should a character that has a high ability score in their prime requisite receive an experience point bonus? Yes or No? Depends. If I run B/X straight then there's an XP bonus. In my "home game" there wouldn't be.
Should a character with an constitution of 18 get a +3 bonus to hit
points, or a +2 bonus to hit points, or a +1 bonus to hit points or no
bonus to hit points? And should other ability scores grant similar
bonuses to other game mechanics? Depends again. I am so fickle! "Moldvay knows best." is what Alex says and for B/X RAW I agree. The "home game" is again a special snowflake because I use standard deviations (strictly speaking 2.9581 but I round up to 3) from the "average 9-12 range" as the measure for bonuses: 13-15 is +1, 16-18 is +2, and the same on the other end.
Should a character have 1 unified saving throw number, or 3 saving
throw types based on ability scores (reflex, fortitude, will), or 5
types based on potential game effects (magic wand, poison attacks)? or
something else? Finally one of these questions really gets to me. Of course the B/X answer is easy, just roll with the five classic saves and we're good. I've looked at saving throws in different editions and various clones before, trying to figure out what I really like. But those posts didn't help in the end because I'd still really like a simpler approach (or better rationales for the existing numbers). As per usual, Daniel Collins has a good answer. But I am still hopelessly undecided.
Should a cleric get (A) 1 spell at 1st level (B) no spells at 1st level (C) more than 1 spell at 1st level? Straight B/X for the open-table game, although all characters start at level 2 in that one so it's not something that bothers people. Priests in the "home game" would use the same progression as wizards, the one I first suggested here and later compared across various systems. (Back when I still had clerics, they would have used a slower progression to compensate for their "martial" aspects. Alas that's now taken care off by my strange approach to multi-classing.)
And done?
Thursday, April 23, 2015
Wednesday, April 22, 2015
B/X Troll-ol-lol
I posted a link to Jeffro's blog on G+ the other day. Now Alex Schroeder insists that I shouldn't be allowed to just post stuff, I have to work for it and answer the Trollish Questions myself. Much like he did here and here. Well alright then!
Race (Elf, Dwarf, Halfling) as a class? Yes or no? Depends on the kind of game I run. For my current "Expedition to the Borderlands" open-table game I use B/X as written. I might tweak it if there was a reason for it, i.e. if the players went to the Dwarven Clan in the West and begged to recruit a cleric of Moradin or something. For a "real" campaign, the ominous "home game" I keep dreaming about, I'd go with my own version that splits race and class although the "chassis" of the rules would still be B/X.
Do demi-humans have souls? Does anybody? Under the weirdo D&D-esque assumption that the dead "transcend" to a plane according to their alignment, sure. Whatever it is that "does the transcending" could be called a soul. Doesn't really matter though, I don't run planar games. (Wait, maybe I would. If the only way to get to the planes was if the characters killed themselves, that would be kinda cool.) What matters is that you can resurrect everybody just fine, doesn't matter if they are human, demi-human, humanoid, or intelligent mushroom. And nobody even gets a saving throw against it. :-)
Ascending or descending armor class? I really don't care, plays more or less the same. But Target20 works great with descending AC and I grew up with descending AC and I use resources that have descending AC listed so that's what I use. (I only get annoyed by the silly little difference between D&D and AD&D.)
Demi-human level limits? Sure. It's only fair. Again, it depends on the kind of game I run. In the "home game" I'd use my own version with my own crazy "rationale" behind it all. You should try inventing your own rationale as well!
Should thief be a class? Sure. If you don't like them, don't play one! But anybody can attempt to do what a thief is able to do, they just never get much better at it. Wizards can fight with swords too in my game, they just suck at it so it's a really bad idea for them. And if a halfling decided to cast a spell from scroll? I'd probably give them a chance! A very, very low chance. With hilarious consequences if they mess up.
Do characters get non-weapon skills? Sure. But it's not really formalized. If you want your character to be good at something that's not in the rules, ask me: Maybe I'll let you write something down. I won't let you write things down again and again, not even if you're playing an elf who could have learned 27 different trades by the time they turn 314. (And of course it's easier to convince me that your halfling can cook and that your dwarf is a decent smith than to convince me that your elf is a deadly assassin and that your fighter can fly.)
Are magic-users more powerful than fighters (and, if yes, what level do they take the lead)? Sure. Wait what? Troll-trolly-troll left out thieves and clerics and all the other fun things like Balrogs and Gargantuan Purple Worms. Useless question. Next!
Do you use alignment languages? Not as they are usually defined in D&D. So let's just say "No!" and be done with it.
XP for gold, or XP for objectives (thieves disarming traps, etc…)? I use B/X RAW for the open-table, so XP for gold and some for monsters overcome. I'd probably switch to "XP for money spent" for the "home game" I keep talking about. Sometimes I like "objectives" but they are so anti-sandbox. (I hate AD&D2 in this regard, so that's a total no-no. But I suffer through it for the game I play in.)
Which is the best edition; ODD, Holmes, Moldvay, Mentzer, Rules Cyclopedia, 1E ADD, 2E ADD, 3E ADD, 4E ADD, Next? I grew up on BECMI and really liked RC for a good long while. But that was because I never knew about B/X, it wasn't available in Germany when I got started. There's no question in my mind that B/X is the best overall package, period. I do like AD&D as well, but only Gary's and only in mild doses. So I guess what I am saying is I tend to like some of the AD&D classes (hence probably my fascination with this thing). AD&D2 is horrible, just horrible. I'd probably play AD&D3 if it's just the core three books, but I wouldn't touch 3.5 or 4. I have no real opinion on 5 yet. I like some mechanics and I appreciate that they rolled some nice options into character generation. But really it's B/X for me. OD&D and Holmes win special prices for being, well, special. But I don't play them.
Unified XP level tables or individual XP level tables for each class? This was Jeffro's bonus question. Again, depends on the game. In my "home game" I would use a unified XP table, the 2000/4000/8000/... Fighter table. Edit: Should have linked to this post.
And done?
Race (Elf, Dwarf, Halfling) as a class? Yes or no? Depends on the kind of game I run. For my current "Expedition to the Borderlands" open-table game I use B/X as written. I might tweak it if there was a reason for it, i.e. if the players went to the Dwarven Clan in the West and begged to recruit a cleric of Moradin or something. For a "real" campaign, the ominous "home game" I keep dreaming about, I'd go with my own version that splits race and class although the "chassis" of the rules would still be B/X.
Do demi-humans have souls? Does anybody? Under the weirdo D&D-esque assumption that the dead "transcend" to a plane according to their alignment, sure. Whatever it is that "does the transcending" could be called a soul. Doesn't really matter though, I don't run planar games. (Wait, maybe I would. If the only way to get to the planes was if the characters killed themselves, that would be kinda cool.) What matters is that you can resurrect everybody just fine, doesn't matter if they are human, demi-human, humanoid, or intelligent mushroom. And nobody even gets a saving throw against it. :-)
Ascending or descending armor class? I really don't care, plays more or less the same. But Target20 works great with descending AC and I grew up with descending AC and I use resources that have descending AC listed so that's what I use. (I only get annoyed by the silly little difference between D&D and AD&D.)
Demi-human level limits? Sure. It's only fair. Again, it depends on the kind of game I run. In the "home game" I'd use my own version with my own crazy "rationale" behind it all. You should try inventing your own rationale as well!
Should thief be a class? Sure. If you don't like them, don't play one! But anybody can attempt to do what a thief is able to do, they just never get much better at it. Wizards can fight with swords too in my game, they just suck at it so it's a really bad idea for them. And if a halfling decided to cast a spell from scroll? I'd probably give them a chance! A very, very low chance. With hilarious consequences if they mess up.
Do characters get non-weapon skills? Sure. But it's not really formalized. If you want your character to be good at something that's not in the rules, ask me: Maybe I'll let you write something down. I won't let you write things down again and again, not even if you're playing an elf who could have learned 27 different trades by the time they turn 314. (And of course it's easier to convince me that your halfling can cook and that your dwarf is a decent smith than to convince me that your elf is a deadly assassin and that your fighter can fly.)
Are magic-users more powerful than fighters (and, if yes, what level do they take the lead)? Sure. Wait what? Troll-trolly-troll left out thieves and clerics and all the other fun things like Balrogs and Gargantuan Purple Worms. Useless question. Next!
Do you use alignment languages? Not as they are usually defined in D&D. So let's just say "No!" and be done with it.
XP for gold, or XP for objectives (thieves disarming traps, etc…)? I use B/X RAW for the open-table, so XP for gold and some for monsters overcome. I'd probably switch to "XP for money spent" for the "home game" I keep talking about. Sometimes I like "objectives" but they are so anti-sandbox. (I hate AD&D2 in this regard, so that's a total no-no. But I suffer through it for the game I play in.)
Which is the best edition; ODD, Holmes, Moldvay, Mentzer, Rules Cyclopedia, 1E ADD, 2E ADD, 3E ADD, 4E ADD, Next? I grew up on BECMI and really liked RC for a good long while. But that was because I never knew about B/X, it wasn't available in Germany when I got started. There's no question in my mind that B/X is the best overall package, period. I do like AD&D as well, but only Gary's and only in mild doses. So I guess what I am saying is I tend to like some of the AD&D classes (hence probably my fascination with this thing). AD&D2 is horrible, just horrible. I'd probably play AD&D3 if it's just the core three books, but I wouldn't touch 3.5 or 4. I have no real opinion on 5 yet. I like some mechanics and I appreciate that they rolled some nice options into character generation. But really it's B/X for me. OD&D and Holmes win special prices for being, well, special. But I don't play them.
Unified XP level tables or individual XP level tables for each class? This was Jeffro's bonus question. Again, depends on the game. In my "home game" I would use a unified XP table, the 2000/4000/8000/... Fighter table. Edit: Should have linked to this post.
And done?
Monday, April 6, 2015
Better be at least this paranoid!
So you've prepared the disk in a way suitable for your level of paranoia, now it's time to actually create the encrypted file system on it. Luckily that's an increasingly simple task, at least if you are using a moderately well-equipped kernel. If you didn't build your own, then it probably has everything you need already; if you did build your own, you should know how to fix things if something is missing. So we're good to continue.
I start by partitioning the disk. Note that if you want to be more mysterious you can encrypt the entire thing without partitioning it, but I like to at least get some kind of message that's not "disk not formatted" out of most systems I am likely to connect the drive to. So I partition. Since this is a pure "data disk" there's really no need for more than one partition, therefore no need for GPT. I simply make an old-school MBR partition table. But then I create two partitions. The first one (/dev/sdX1 say) is tiny, just 1 MB in size for example, and it'll get formatted with ext2. I like to put a small disclaimer and a few related files (such as the Bill of Rights) on that one.
The rest of the disk gets allocated to the second partition (/dev/sdX2 say). Here's how I then set up the encryption layer:
Alright, that's quite a long command, so let's see. First I explicitly pick a cipher that is reasonably secure as of this writing. It's actually the same cipher that cryptsetup would default to anyway as of 1.6.0 or so. But I turn up the key size to something higher than the default and I also replace the hash function used for key generation to something more likely to survive a few more years. Finally I tell it to iterate for 5 seconds instead of just 1 second when computing the key. It's hard to say what kind of improvement that is, but in general the assumption is that if you spend more time generating the key, it'll be "better" in some way. Oh, I also use /dev/random instead of /dev/urandom, something you may not want to do if your system doesn't have enough entropy built up. Overall I think those are fairly conservative options that should result in decent security for the next few years. Or so one would hope...
But we're paranoid, right? So let's make sure that we actually got what we requested from the command. Here's how to see that:
This will spit out some interesting information I don't want to get into, but it'll also show you that the cipher, key size, and hash function are as requested. Good to know, right? Now it's time to actually attach the encrypted device to the system. Here's how we do that:
The name "encrypted" will be used to create /dev/mapper/encrypted which is the name we use to refer to the encrypted version of the partition. (Remember that /dev/sdX2 is the raw, unencrypted partition and that we're "simulating" an encrypted layer above that.) Now I go ahead and create an ext4 filesystem as follows:
And after mounting that sucker, we're set: We can now write data to the ext4 filesystem on top of the encrypted disk on top of the actual raw partition. Win! After your backup, unmount the whole thing, issue an
and finally store the disk in a safe place. You have succeeded. More or less anyway. Good luck in that military tribunal!
I start by partitioning the disk. Note that if you want to be more mysterious you can encrypt the entire thing without partitioning it, but I like to at least get some kind of message that's not "disk not formatted" out of most systems I am likely to connect the drive to. So I partition. Since this is a pure "data disk" there's really no need for more than one partition, therefore no need for GPT. I simply make an old-school MBR partition table. But then I create two partitions. The first one (/dev/sdX1 say) is tiny, just 1 MB in size for example, and it'll get formatted with ext2. I like to put a small disclaimer and a few related files (such as the Bill of Rights) on that one.
The rest of the disk gets allocated to the second partition (/dev/sdX2 say). Here's how I then set up the encryption layer:
cryptsetup --verbose --cipher aes-xts-plain64 --key-size 512 --hash sha512 --iter-time 5000 --use-random luksFormat /dev/sdX2
Alright, that's quite a long command, so let's see. First I explicitly pick a cipher that is reasonably secure as of this writing. It's actually the same cipher that cryptsetup would default to anyway as of 1.6.0 or so. But I turn up the key size to something higher than the default and I also replace the hash function used for key generation to something more likely to survive a few more years. Finally I tell it to iterate for 5 seconds instead of just 1 second when computing the key. It's hard to say what kind of improvement that is, but in general the assumption is that if you spend more time generating the key, it'll be "better" in some way. Oh, I also use /dev/random instead of /dev/urandom, something you may not want to do if your system doesn't have enough entropy built up. Overall I think those are fairly conservative options that should result in decent security for the next few years. Or so one would hope...
Pick a good, long, cryptic, etc. pass phrase!
But we're paranoid, right? So let's make sure that we actually got what we requested from the command. Here's how to see that:
cryptsetup luksDump /dev/sdX2
This will spit out some interesting information I don't want to get into, but it'll also show you that the cipher, key size, and hash function are as requested. Good to know, right? Now it's time to actually attach the encrypted device to the system. Here's how we do that:
cryptsetup luksOpen /dev/sdX2 encrypted
The name "encrypted" will be used to create /dev/mapper/encrypted which is the name we use to refer to the encrypted version of the partition. (Remember that /dev/sdX2 is the raw, unencrypted partition and that we're "simulating" an encrypted layer above that.) Now I go ahead and create an ext4 filesystem as follows:
mkfs.ext4 /dev/mapper/encrypted
And after mounting that sucker, we're set: We can now write data to the ext4 filesystem on top of the encrypted disk on top of the actual raw partition. Win! After your backup, unmount the whole thing, issue an
cryptsetup luksClose encrypted
and finally store the disk in a safe place. You have succeeded. More or less anyway. Good luck in that military tribunal!
Sunday, April 5, 2015
How paranoid would you like to be today?
I've been working on new backup practices for myself. I can't say that I am finished, but I've at least thought about the encryption aspect a bit.
Encrypt my backups? Why would I want to do that? For starters I can hand an encrypted backup to someone else to store for me: A friend in Baltimore, my parents in Europe, the bank's vault, a lawyer's safe, etc. As soon as the disk is encrypted, I don't have to worry about them finding things I don't want them to find. Like my draft autobiography that may talk about them in a way they don't approve of. Or whatever.
So how should I do it? That brings me to the topic of this post. The process really depends on how paranoid I want to be, doesn't it? For starters it would be good if the disk I am using actually worked. Luckily there's a neat tool for that: badblocks. Study the man page for a bit and you come up with something like this:
Note that this performs a destructive test (-w) so you'll lose all the data on the drive! It also fills the disk with random garbage (-t random), probably a plus since that'll make it a little harder to reverse-engineer things from the encrypted disk. (Note that this took about 15 hours for a 1 GB disk attached via USB2. Sheesh.)
Wait, that's a good point. A decent rule of thumb when it comes to cryptography is that you want the encrypted data to look random. But now the question becomes whether the "random" that badblocks uses is "random enough" to blend in with my encrypted data. How paranoid should I be about that? Turns out that badblocks just uses the C library, probably not cryptographically sound...
Of course help is on the way in the form of shred, a program often used to securely delete files. Now I can choose my source of randomness, /dev/urandom say. So we could use something like this:
Great! Or is it? Don't get me wrong, the randomness is fine now, probably good enough even after just one pass, but I've at least doubled (more likely "increased by an order of magnitude" I'd guess) the time I have to spend on prepping the disk. After all, badblocks already did part of this job, right? I am probably not that paranoid. (Some of my friends might disagree?)
Even if I were that paranoid however, we have completely ignored another problem so far: We've assumed that disk drives are dumb and contain no data except for what we write on them. And that's decidedly untrue! Modern disk drives are moderately sophisticated computers in their own right and they store all kinds of data in places that a "normal write" can't ever get to. But luckily most disk manufacturers have added a S.M.A.R.T. feature called "Secure Erase" that should (in theory!) allow you to completely erase a disk back to its factory defaults. You can check out the details here but it turns out that using this feature through USB has a good chance of bricking your disk permanently.
So if I was that paranoid, I'd have to first move the drive onto an internal SATA port, then perform the "Secure Erase" process using hdparm, then perform the badblocks test, then shred the drive, and finally move it back onto the USB port.
That's what I decided anyway. I guess I am really not paranoid enough for this modern world? I am sure some people need to be this paranoid. They shouldn't have to be in a free society, but sadly that's not what we live in.
But before I get too political I'll just go back to my little backup project. I'll try to write another post tomorrow that describes the rest of it, i.e. what's needed after the disk is finally prepped according to your paranoia level.
Update 2015/04/06: I had forgotten the most basic trick to achieve a random fill that "blends in" nicely with the encrypted stuff you'll eventually store. Just create an encrypted disk, fill it up with whatever you want through the encryption layer, /dev/zero or /dev/urandom or whatnot, then start from scratch with the "real thing" as it were. Should "blend" very well. Of course it'll still take way too long for my level of patience...
Encrypt my backups? Why would I want to do that? For starters I can hand an encrypted backup to someone else to store for me: A friend in Baltimore, my parents in Europe, the bank's vault, a lawyer's safe, etc. As soon as the disk is encrypted, I don't have to worry about them finding things I don't want them to find. Like my draft autobiography that may talk about them in a way they don't approve of. Or whatever.
So how should I do it? That brings me to the topic of this post. The process really depends on how paranoid I want to be, doesn't it? For starters it would be good if the disk I am using actually worked. Luckily there's a neat tool for that: badblocks. Study the man page for a bit and you come up with something like this:
badblocks -s -v -w -c 16384 -t random /dev/sdX
Note that this performs a destructive test (-w) so you'll lose all the data on the drive! It also fills the disk with random garbage (-t random), probably a plus since that'll make it a little harder to reverse-engineer things from the encrypted disk. (Note that this took about 15 hours for a 1 GB disk attached via USB2. Sheesh.)
Wait, that's a good point. A decent rule of thumb when it comes to cryptography is that you want the encrypted data to look random. But now the question becomes whether the "random" that badblocks uses is "random enough" to blend in with my encrypted data. How paranoid should I be about that? Turns out that badblocks just uses the C library, probably not cryptographically sound...
Of course help is on the way in the form of shred, a program often used to securely delete files. Now I can choose my source of randomness, /dev/urandom say. So we could use something like this:
shred --iterations 1 --random-source=/dev/urandom --verbose /dev/sdX
Great! Or is it? Don't get me wrong, the randomness is fine now, probably good enough even after just one pass, but I've at least doubled (more likely "increased by an order of magnitude" I'd guess) the time I have to spend on prepping the disk. After all, badblocks already did part of this job, right? I am probably not that paranoid. (Some of my friends might disagree?)
Even if I were that paranoid however, we have completely ignored another problem so far: We've assumed that disk drives are dumb and contain no data except for what we write on them. And that's decidedly untrue! Modern disk drives are moderately sophisticated computers in their own right and they store all kinds of data in places that a "normal write" can't ever get to. But luckily most disk manufacturers have added a S.M.A.R.T. feature called "Secure Erase" that should (in theory!) allow you to completely erase a disk back to its factory defaults. You can check out the details here but it turns out that using this feature through USB has a good chance of bricking your disk permanently.
So if I was that paranoid, I'd have to first move the drive onto an internal SATA port, then perform the "Secure Erase" process using hdparm, then perform the badblocks test, then shred the drive, and finally move it back onto the USB port.
Too. Much. Trouble.
That's what I decided anyway. I guess I am really not paranoid enough for this modern world? I am sure some people need to be this paranoid. They shouldn't have to be in a free society, but sadly that's not what we live in.
But before I get too political I'll just go back to my little backup project. I'll try to write another post tomorrow that describes the rest of it, i.e. what's needed after the disk is finally prepped according to your paranoia level.
Update 2015/04/06: I had forgotten the most basic trick to achieve a random fill that "blends in" nicely with the encrypted stuff you'll eventually store. Just create an encrypted disk, fill it up with whatever you want through the encryption layer, /dev/zero or /dev/urandom or whatnot, then start from scratch with the "real thing" as it were. Should "blend" very well. Of course it'll still take way too long for my level of patience...
Wednesday, February 25, 2015
Lining up Octagons in Reassembly
Alright, I feel really, really dense now. I finally started playing Reassembly yesterday. Not sure why I waited this long, after all I had a beta key from the Kickstarter campaign. But that's not why I feel dense. (Well, a little maybe...)
For the first 10 hours or so, I could not for the life of me figure out how to design a ship that holds together well as soon as larger octagonal prefabs are involved. I just couldn't figure out how to line them up properly with the more square geometry of the other prefabs.
Oh how many things I tried. I actually thought I had tried everything in the game! As I was about to send the developer a bug report (well, since I know him, I was just going to whine at him on Facebook) I finally realized why there's one prefab that can be rescaled to odd dimensions like "square root of 2" and such:
Yep, you guessed it! Those are exactly the sizes you need to fit those darn octagons into a rectangular geometry. Oh how badly I beat up myself after I finally figured it out! I have a degree in Math and Computer Science mind you, and it's painful when you realize that instead of thinking about those dimensions in connection to my problem, I spent 10 hours just shrugging them off as "weird choices" by the developer. They're not weird, they're essential! Alright, but now back to playing the darn game!
For the first 10 hours or so, I could not for the life of me figure out how to design a ship that holds together well as soon as larger octagonal prefabs are involved. I just couldn't figure out how to line them up properly with the more square geometry of the other prefabs.
Oh how many things I tried. I actually thought I had tried everything in the game! As I was about to send the developer a bug report (well, since I know him, I was just going to whine at him on Facebook) I finally realized why there's one prefab that can be rescaled to odd dimensions like "square root of 2" and such:
 |
| Squares and Octagons: Check out the Little Rectangles! |
Yep, you guessed it! Those are exactly the sizes you need to fit those darn octagons into a rectangular geometry. Oh how badly I beat up myself after I finally figured it out! I have a degree in Math and Computer Science mind you, and it's painful when you realize that instead of thinking about those dimensions in connection to my problem, I spent 10 hours just shrugging them off as "weird choices" by the developer. They're not weird, they're essential! Alright, but now back to playing the darn game!
Saturday, February 7, 2015
Installing LFS with QEMU
I traditionally start my Operating Systems course with an assignment that requires students to install Linux From Scratch. They need to hand in a disk image of a 32-bit x86 LFS that can be booted with QEMU, but how they go about making that image is up to them.
A common side-effect of this first assignment is that 20% of students drop the course in frustration. The complaint I hear most often is that they "learn nothing" because "it's just a long series of boring instructions and a tiny mistake in an early step can ruin the entire install 4 hours later". And they are correct (with the latter part anyway): That's exactly what this assignment is.
However, I vehemently disagree with the notion that there's no learning taking place here. Patience is a virtue. Persistence is as well. Working carefully should be one. And so on.
A few years ago I pretty much took the stance that if you're not able to do this, you're not going to be a good computer scientist: It's not just about coming up with new and shiny ideas and hacks, it's also about being able to do semi-boring detail-oriented work with lots and lots of care.
Nowadays I can appreciate that some students simply get too frustrated with this kind of work, especially if they also have to deal with unfamiliar tools and are not really sure how to start. So in an effort to help out a little bit, I've put together the following to show students how to get started (and finished!) with their LFS install using nothing but QEMU.
Note that the last time I actually tested these instructions was in February 2015 with QEMU 2.1.2 and LFS 7.6!
First install the current version of QEMU for your operating system, preferably through your package manager.
Then download and decompress the following disk image. It provides a basic install of Arch Linux that can be used to build LFS.
Note that this is a raw image that expands into a 4 GB file. You can check that everything is alright by starting QEMU and booting the image:
If your host machine doesn't support KVM, things are going to be a lot slower for you; it's in your best interest to use on a host machine that supports KVM. The last option above instructs QEMU to forward port 2222 of the host machine to port 22 of the virtual machine. This is useful because it allows you to use SSH to do your work:
That way you won't have to worry about QEMU's strange behavior when it comes to copying and pasting things, you can just use your regular terminal application.
Login as user root with password lfs and take a look around if you wish. The home directory of root will contain a bunch of LFS-related files from LFS 7.6. If you're working on a later version of LFS, you'll need to get updated copies of those files (as explained in the LFS book itself).
Finally you may want to run pacman -Syu to bring the system up-to-date before you continue. However, performing such an update is not without risks, especially if gcc gets updated to a version that can no longer compile some of the packages your LFS version depends on. So update with care!
Next run the scripts that check if all the required tools are installed and what versions you have compared to what's needed for LFS:
Again, if you are using an LFS version greater than 7.6 you need to get yourself the updated versions of those files. Read through the output of the scripts and carefully compare against the versions listed in the LFS book. If a package is missing, you can (in most cases) install it as follows:
Once you are sure that you have all the correct tools, use the following command to shut down the virtual machine:
You have now confirmed that you have a VM that can be used to install LFS. The next step is to make a separate disk image file for LFS:
This will create another 4 GB file that QEMU will use to simulate a second disk attached to the virtual machine. Restart QEMU as follows:
Once again QEMU will boot into the Arch Linux installation we'll use to create the LFS system. Login again and then run the command
to display the disks attached to QEMU. You should see /dev/sda with two partitions /dev/sda1 and /dev/sda2 as well as a new disk /dev/sdb. The former refers to the Arch Linux image, the latter to the LFS target image we just created. You now need to follow the instructions from the LFS book for creating partitions and filesystems on the LFS disk. I'd suggest that you create two partitions: First create a 3.5 GB partition for the root filesystem, then use the remaining space on /dev/sdb as a swap partition. Incidentily, that's exactly the partition layout I used for the Arch Linux image:
Don't forget to mark /dev/sdb1 as bootable! Then create an EXT4 filesystem in /dev/sdb1 and a swap partition on /dev/sdb2 following the instructions from the LFS book.
Now you're set to perform the actual LFS install, so we'll skip ahead to the very end (hours later!) when you need to install the GRUB bootloader on /dev/sdb and create /etc/fstab in the LFS root filesystem.
The important thing to realize here is that when you boot your LFS disk image by itself, it will be considered /dev/sda by QEMU! Think about it, that's exactly what's been happening so far with the Arch Linux image. We handed it to QEMU using the -hda command line option, which told QEMU to consider it the first hard disk and boot from it. That's exactly what your LFS disk will be when it boots by itself.
Therefore, while you will install GRUB into the MBR of /dev/sdb as long as the Arch Linux image is /dev/sda, the configuration in /boot/grub.cfg as well as in /etc/fstab must be written with /dev/sda in mind. Proceed accordingly!
When you're done with all of that, follow the LFS book and leave the chroot, unmount all the LFS filesystems, and finally shut down the VM as before. Now you're ready to boot LFS:
And there you go! Hopefully the boot process goes smoothly and you're looking at your brand-new LFS login prompt.
Credits: Thanks to Ruben Fiszel for taking Operating Systems as a graduate independent study course this semester, forcing me to double-check how all this LFS stuff really worked.
A common side-effect of this first assignment is that 20% of students drop the course in frustration. The complaint I hear most often is that they "learn nothing" because "it's just a long series of boring instructions and a tiny mistake in an early step can ruin the entire install 4 hours later". And they are correct (with the latter part anyway): That's exactly what this assignment is.
However, I vehemently disagree with the notion that there's no learning taking place here. Patience is a virtue. Persistence is as well. Working carefully should be one. And so on.
A few years ago I pretty much took the stance that if you're not able to do this, you're not going to be a good computer scientist: It's not just about coming up with new and shiny ideas and hacks, it's also about being able to do semi-boring detail-oriented work with lots and lots of care.
Nowadays I can appreciate that some students simply get too frustrated with this kind of work, especially if they also have to deal with unfamiliar tools and are not really sure how to start. So in an effort to help out a little bit, I've put together the following to show students how to get started (and finished!) with their LFS install using nothing but QEMU.
Note that the last time I actually tested these instructions was in February 2015 with QEMU 2.1.2 and LFS 7.6!
First install the current version of QEMU for your operating system, preferably through your package manager.
Then download and decompress the following disk image. It provides a basic install of Arch Linux that can be used to build LFS.
arch-based-lfs-install-i686.img.xz (483 MB)
(md5sum is 7ae93112f07d8662944a0d4ab0b1fa4d)
Note that this is a raw image that expands into a 4 GB file. You can check that everything is alright by starting QEMU and booting the image:
qemu-system-i386 -enable-kvm -m 256 -hda arch-based-lfs-install-i686.img -redir tcp:2222::22
If your host machine doesn't support KVM, things are going to be a lot slower for you; it's in your best interest to use on a host machine that supports KVM. The last option above instructs QEMU to forward port 2222 of the host machine to port 22 of the virtual machine. This is useful because it allows you to use SSH to do your work:
ssh -p 2222 root@localhost
That way you won't have to worry about QEMU's strange behavior when it comes to copying and pasting things, you can just use your regular terminal application.
Login as user root with password lfs and take a look around if you wish. The home directory of root will contain a bunch of LFS-related files from LFS 7.6. If you're working on a later version of LFS, you'll need to get updated copies of those files (as explained in the LFS book itself).
Finally you may want to run pacman -Syu to bring the system up-to-date before you continue. However, performing such an update is not without risks, especially if gcc gets updated to a version that can no longer compile some of the packages your LFS version depends on. So update with care!
Next run the scripts that check if all the required tools are installed and what versions you have compared to what's needed for LFS:
sh version-check.sh
sh library-check.sh
Again, if you are using an LFS version greater than 7.6 you need to get yourself the updated versions of those files. Read through the output of the scripts and carefully compare against the versions listed in the LFS book. If a package is missing, you can (in most cases) install it as follows:
pacman -S whateverpackagename
Once you are sure that you have all the correct tools, use the following command to shut down the virtual machine:
shutdown -h now
You have now confirmed that you have a VM that can be used to install LFS. The next step is to make a separate disk image file for LFS:
qemu-img create lfs-target-disk.img 4G
This will create another 4 GB file that QEMU will use to simulate a second disk attached to the virtual machine. Restart QEMU as follows:
qemu-system-i386 -enable-kvm -m 256 -hda arch-based-lfs-install-i686.img -hdb lfs-target-disk.img -redir tcp:2222::22
Once again QEMU will boot into the Arch Linux installation we'll use to create the LFS system. Login again and then run the command
lsblk
to display the disks attached to QEMU. You should see /dev/sda with two partitions /dev/sda1 and /dev/sda2 as well as a new disk /dev/sdb. The former refers to the Arch Linux image, the latter to the LFS target image we just created. You now need to follow the instructions from the LFS book for creating partitions and filesystems on the LFS disk. I'd suggest that you create two partitions: First create a 3.5 GB partition for the root filesystem, then use the remaining space on /dev/sdb as a swap partition. Incidentily, that's exactly the partition layout I used for the Arch Linux image:
[root@arch4lfs ~]# fdisk -l /dev/sda
Disk /dev/sda: 4 GiB, 4294967296 bytes, 8388608 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x08659cdb
Device Boot Start End Sectors Size Id Type
/dev/sda1 * 2048 7317503 7315456 3.5G 83 Linux
/dev/sda2 7317504 8388607 1071104 523M 82 Linux swap / Solaris
Don't forget to mark /dev/sdb1 as bootable! Then create an EXT4 filesystem in /dev/sdb1 and a swap partition on /dev/sdb2 following the instructions from the LFS book.
Now you're set to perform the actual LFS install, so we'll skip ahead to the very end (hours later!) when you need to install the GRUB bootloader on /dev/sdb and create /etc/fstab in the LFS root filesystem.
The important thing to realize here is that when you boot your LFS disk image by itself, it will be considered /dev/sda by QEMU! Think about it, that's exactly what's been happening so far with the Arch Linux image. We handed it to QEMU using the -hda command line option, which told QEMU to consider it the first hard disk and boot from it. That's exactly what your LFS disk will be when it boots by itself.
Therefore, while you will install GRUB into the MBR of /dev/sdb as long as the Arch Linux image is /dev/sda, the configuration in /boot/grub.cfg as well as in /etc/fstab must be written with /dev/sda in mind. Proceed accordingly!
When you're done with all of that, follow the LFS book and leave the chroot, unmount all the LFS filesystems, and finally shut down the VM as before. Now you're ready to boot LFS:
qemu-system-i386 -enable-kvm -m 256 -hda lfs-target-disk.img
And there you go! Hopefully the boot process goes smoothly and you're looking at your brand-new LFS login prompt.
Credits: Thanks to Ruben Fiszel for taking Operating Systems as a graduate independent study course this semester, forcing me to double-check how all this LFS stuff really worked.
Sunday, December 21, 2014
Mixing and Matching Classes
I am a B/X D&D kind of guy: I like having four core classes and not much else. So officially that's Cleric, Fighter, Magic-User, and Thief — but actually I tend to call them Cleric, Fighter, Rogue, and Wizard instead. Never mind the details here, let's just say that I like those names better. Of course there are also demi-humans in B/X, but I treat them more like AD&D does: I separate race from class. I actually wrote a thing about that if you're interested. (Before you complain, I do understand why some people like race-as-class but for me it's just not the right fit, at least not for a campaign game.)
Now obviously there are many players with experience in other systems such as AD&D, and some of those players would really like to run a Paladin or a Druid or an Illusionist or whatnot. There are plenty of resources that provide those classes (and many more) as additions for B/X D&D or compatible systems such as Labyrinth Lord. But I still prefer the purity of just four core classes and so I usually negotiate with players like that, granting their characters a "small edge" that goes in the right direction but doesn't mess with the game too much. Dyson's random sub-classes are an excellent example of the kind of thing I tend to do.
Then along comes Zach H of Zenopus Archives fame with a G+ post that gets me thinking. Here's that post:
One can obviously debate whether the suggested "breakdown" for each of these is the best possible one, but the idea of "mixing and matching" the core classes to re-create approximations of other popular classes is genius! And although Zach's "idle thought" is not explicitly targetting B/X it can certainly work there as well, once we add some kind of multi-classing mechanic anyway.
As luck would have it, I already added such a mechanic in support of my take on demi-humans: I am using a variant of archetypal multi-classing! And one of the cool things about that approach is that Fighter/Thief and Thief/Fighter are not the same thing: The secondary class is always at half the level of the primary class, so those combinations feel very different in play.
Applied to Zach's idea this gives us a number of additional possibilities for "mixing" classes together. For example we can interpret Fighter/Thief as "Ranger" or maybe "Scout" whereas Thief/Fighter might be "Thug" or "Assassin" if we squint a little.
But I got my real Christmas present when I tried to figure out the difference between a Fighter/Cleric and a Cleric/Fighter. I agreed with Zach that a Fighter/Cleric should be a "Paladin", but what the heck is a Cleric/Fighter if not also a "Paladin", albeit of a slightly different bent? (Yes, I could make up another name for that combination, but it still seems too redundant.)
What hit me at that point was that the Cleric is already a multi-classed character: Clerics combine "divine spell-casting" with "decent combat-ability" after all! So if there was a class that only focused on the divine stuff, a Priest class say, then I would get a much more sensible result: The Fighter/Priest would be the "Paladin" but the Priest/Fighter would now be the "Cleric," reconstituted from salvaged parts.
This little insight fixes so much for me. I've always looked at Paladins with a critical eye, mostly because I felt like the Cleric was already some kind of Paladin to begin with. The "heavily armored guy bashing orcs with a mace while waving a cross" just never really worked for me as something a "run of the mill" religious person should be. So I found it necessary to cast the Cleric as a "militant fanatic" of sorts to make sense of it all and I assumed some "less militant" religious folks in the background as non-player characters: tending to the sick, writing history and philosophy tracts, celebrating "mass" of one sort or another, herding the undead pets of their EHP, etc.
Now I can finally remedy this situation in a framework that makes sense to me. I'll throw out the existing Cleric class and replace it with a Priest class that gets "divine spell-casting" and "turn undead" but nothing else. Priests are of a scholarly bent, sort of like Wizards (or Magic-Users or whatever). Priests get the Wizard's hit die, combat progression, weapon selection, and armor restrictions, but (just for kicks) they keep the old Cleric's saving throws. And of course Priests have to memorize spells from their "prayer books" just like Clerics had to already in my campaign. (This allows me to cut down on Dan's old complaint that Clerics have access to too many spells.) Now if players want to have a priestly character, one that's not also a slaughter-house, they finally can! And if they want to be something with more "oomph" in battle, well, just multi-class the right way and become either a Paladin or a Cleric.
Having said all that, the one thing I am not sure about is whether this added complexity is worth it in the end. Don't get me wrong, I really like this approach. But the old "just give them a special thing" worked as well and in the end it's more flexible since the referee is involved and can "grant" something that's very special and not in the "official" rules.
In any case, I still need to "interpret" all the possible class combinations in a useful way, and I am still having trouble with some of them. Maybe you can help by suggesting something I have not thought of? Here's what I have now:
Fighter / Priest = Paladin
Fighter / Rogue = Scout or Ranger
Fighter / Wizard = Warlock?
Priest / Fighter = Cleric
Priest / Rogue = Monk? Inquisitor?
Priest / Wizard = Druid? Shaman?
Rogue / Fighter = Thug or Assassin
Rogue / Priest = Charlatan? Agitator?
Rogue / Wizard = Bard?
Wizard / Fighter = ?
Wizard / Priest = Thaumaturgist? Theurge?
Wizard / Rogue = Illusionist? Mountebank? Trickster?
And with that I am putting my behind on a plane to Germany. Merry Christmas (or whatever it is you celebrate) and a Happy New Year!
Now obviously there are many players with experience in other systems such as AD&D, and some of those players would really like to run a Paladin or a Druid or an Illusionist or whatnot. There are plenty of resources that provide those classes (and many more) as additions for B/X D&D or compatible systems such as Labyrinth Lord. But I still prefer the purity of just four core classes and so I usually negotiate with players like that, granting their characters a "small edge" that goes in the right direction but doesn't mess with the game too much. Dyson's random sub-classes are an excellent example of the kind of thing I tend to do.
Then along comes Zach H of Zenopus Archives fame with a G+ post that gets me thinking. Here's that post:
Idle thought on adding subclasses to whitebox OD&D or Holmes, but without adding any new rules.
Paladin = Fighter/Cleric
Ranger = Fighter/Thief
Monk = Cleric/Thief
Druid = Cleric/MU
Bard = Thief/MU
Subclasses are for humans only (Fighter/MU is still just elves). Use whatever multi-class rules you use for elves.
One can obviously debate whether the suggested "breakdown" for each of these is the best possible one, but the idea of "mixing and matching" the core classes to re-create approximations of other popular classes is genius! And although Zach's "idle thought" is not explicitly targetting B/X it can certainly work there as well, once we add some kind of multi-classing mechanic anyway.
As luck would have it, I already added such a mechanic in support of my take on demi-humans: I am using a variant of archetypal multi-classing! And one of the cool things about that approach is that Fighter/Thief and Thief/Fighter are not the same thing: The secondary class is always at half the level of the primary class, so those combinations feel very different in play.
Applied to Zach's idea this gives us a number of additional possibilities for "mixing" classes together. For example we can interpret Fighter/Thief as "Ranger" or maybe "Scout" whereas Thief/Fighter might be "Thug" or "Assassin" if we squint a little.
But I got my real Christmas present when I tried to figure out the difference between a Fighter/Cleric and a Cleric/Fighter. I agreed with Zach that a Fighter/Cleric should be a "Paladin", but what the heck is a Cleric/Fighter if not also a "Paladin", albeit of a slightly different bent? (Yes, I could make up another name for that combination, but it still seems too redundant.)
What hit me at that point was that the Cleric is already a multi-classed character: Clerics combine "divine spell-casting" with "decent combat-ability" after all! So if there was a class that only focused on the divine stuff, a Priest class say, then I would get a much more sensible result: The Fighter/Priest would be the "Paladin" but the Priest/Fighter would now be the "Cleric," reconstituted from salvaged parts.
Praise be to that glorious redemption from the interwebz!
This little insight fixes so much for me. I've always looked at Paladins with a critical eye, mostly because I felt like the Cleric was already some kind of Paladin to begin with. The "heavily armored guy bashing orcs with a mace while waving a cross" just never really worked for me as something a "run of the mill" religious person should be. So I found it necessary to cast the Cleric as a "militant fanatic" of sorts to make sense of it all and I assumed some "less militant" religious folks in the background as non-player characters: tending to the sick, writing history and philosophy tracts, celebrating "mass" of one sort or another, herding the undead pets of their EHP, etc.
Now I can finally remedy this situation in a framework that makes sense to me. I'll throw out the existing Cleric class and replace it with a Priest class that gets "divine spell-casting" and "turn undead" but nothing else. Priests are of a scholarly bent, sort of like Wizards (or Magic-Users or whatever). Priests get the Wizard's hit die, combat progression, weapon selection, and armor restrictions, but (just for kicks) they keep the old Cleric's saving throws. And of course Priests have to memorize spells from their "prayer books" just like Clerics had to already in my campaign. (This allows me to cut down on Dan's old complaint that Clerics have access to too many spells.) Now if players want to have a priestly character, one that's not also a slaughter-house, they finally can! And if they want to be something with more "oomph" in battle, well, just multi-class the right way and become either a Paladin or a Cleric.
Having said all that, the one thing I am not sure about is whether this added complexity is worth it in the end. Don't get me wrong, I really like this approach. But the old "just give them a special thing" worked as well and in the end it's more flexible since the referee is involved and can "grant" something that's very special and not in the "official" rules.
In any case, I still need to "interpret" all the possible class combinations in a useful way, and I am still having trouble with some of them. Maybe you can help by suggesting something I have not thought of? Here's what I have now:
Fighter / Priest = Paladin
Fighter / Rogue = Scout or Ranger
Fighter / Wizard = Warlock?
Priest / Fighter = Cleric
Priest / Rogue = Monk? Inquisitor?
Priest / Wizard = Druid? Shaman?
Rogue / Fighter = Thug or Assassin
Rogue / Priest = Charlatan? Agitator?
Rogue / Wizard = Bard?
Wizard / Fighter = ?
Wizard / Priest = Thaumaturgist? Theurge?
Wizard / Rogue = Illusionist? Mountebank? Trickster?
And with that I am putting my behind on a plane to Germany. Merry Christmas (or whatever it is you celebrate) and a Happy New Year!
Subscribe to:
Posts (Atom)