Older blog entries for elanthis (starting at number 104)

Orkut

So, nobody has invited me to Orkut. This doesn't surprise, since I don't actually know anybody in the FOSS world, and nobody really knows me, except the people I've managed to irritate greatly (hi GNOME devs ^,^ ) and they probably don't want me anywhere near them. ;-)

On the upside, however, this means I haven't wasted any time what-so-ever on this supposedly addictive site. And, to be honest, given that I don't know anybody in FOSS, I don't think I'd have anything interesting to do in Orkut even if I was a member.

On a side note, the fact that there is a market for invitations rather strongly indicates how incredibly lame some people are. ~,^

Dragon Slave!

Bought two Slayers movies, "Slayers Next" and "Slayers Great." I'm not sure whether I like the movie character or series characters better. The movies lack Zelgadis, who simply rules, but the series lacks Naga, who also rules. (Altho I honestly believe the artists went a little over-board.)

Anyways, both films were money well spent. Only, it rather drives home the fact that I hate watching anime alone, and the only three people I really enjoy watching it with are either very far away or no longer want much to do with me.

AweMUD Affects

Ya, so I'm going to write about the affect system for AweMUD, yet again.

This has been the hardest AweMUD feature to get started on. The problem is it is just very hard to get right. Especially given how dynamic it has to be. In some of the older game engines I've written, namely the old roguelike War of the Runes, the affect system was quite simple. There were no dynamic scripts or plugins, so everything could be kept internal and very simple and clean.

That was back in my youth (no, I mean, really back in my youth - not like last year which was also in my youth...) when my C++ coding was basically just C with methods on structs, so affects were pretty much an array of affect IDs and arguments. Things like, AFFECT_DAMAGE with arguments of the DAM_FIRE constant and some number for amount. Arguments where just ints, up to 5 of them. Bloody simply.

But no, not in AweMUD, because I have this silly wish to make everything scriptable (which is good, of course). No simple enumerations of affect IDs and simple parameters. Nope. Instead, I need a class interface, and each affect must be a sub-class, and affect instances need arguments more varied and descriptive than ints, so we need to attach a vector of Affect derived objects.

Of course, because of the C++ nature, we can't cleanly just have the Entity class (which is the base of all classes of things that exist in the MUD world) keep the affect list (centralizing everything), because the Affect then wouldn't be type-safe in regards to affects that only work on, say, Characters, or Objects, or whatever.

But, adding an Affect list to each Entity sub-class is evil and wasteful. This means I either need the IAffect class to just worry about Entity types, and have the individual affects to dynamic type checking (which isn't too bad, but it means a lot of extra code in the Affect sub-classes) or a templates Affect class that derives from IAffect and just adds type-checking, which then centralizes that.

I don't really like either solution, tho. Both need a lot of "hacks" to get around the problem. Only, no matter what language this would be written in, the problem would persist, because the affects need to be written for the specific features of the Entity subclasses. ::sigh::

Scriptability

I firmly believe that apps should be extensible and scriptable.

However, there may come a time when one has gone too far. Namely, when core parts of your app are tossed out into scripts. Scripts are great for quick addons or anything that needs to be changed often, but they aren't good choices for things you expect to be relatively static, or things which are rather large and integral to the application.

Like, for example, AweMUD's combat system. Or character creation. The former was put into a script more just as proof I could. Which is a pretty damn dumb reason. The later was done to make character systems flexible but, to b honest, there's still a lot of C++ code that needs to be changed to change character internals, so what's the point?

Both would be tons easier in C++ in many ways (albeit, much harder in others - I think the ease will outweigh the pain, tho).

Getting back to Affects, then, just how dynamic do I really need to make them? Instead of just making a big dynamic affect system, what would happen with a tightly coupled simplified affect system with lots of small but specific hard-coded affects, that could then just be "assembled" together to make larger affects? Work better, perhaps?

::sigh:: If I keep trying to find the 100% best solution, this'll never get done. I just hate forging blindly ahead, as it almost never results in anything worth keeping. Maybe I just need to prototype some things out and see how they work?

Ack, I'm rambling. Time to go practice my bass. :)

Ooohh! My iBook shipped. Go me! ^_^

Relief

etrepum: Aaah... OK. I don't think the iBook I ordered is a new product. I will quit worrying now. ;-)

Of course, the Apple Store isn't too far away...

Why am I an Idiot?

Don't answer that.

Seriously, I tend to preach a lot about proper coding discipline and techniques and all that. And never follow my own advice. Example....

AweMUD Accounts

So, just after ripping out the UserDB code in AweMUD and moving all the account information into the individual players, I realized this sucks and am now implementing an account system. Now, had I actually thought out ahead about the design of this stuff, I'd have likely just morphed the UserDB code straight into the account code. Silly me.

Anyways, the new behaviour will mean that upon logging in, users will now be presented with an account menu, versus going straight into playing.

Accounts will have one (or more) characters attached. Players could create new characters, delete characters, or start playing with a character.

The other nifty thing about this will be that we can enforce limits like how how many players an account can have (default 3), how many can be logged in at once (default 1), etc. The main configuration can over-ride the defaults, and the individual accounts can have over-rides as well.

For example, a game might only let free accounts have one characters, but might allow paid members to have two/three characters, and perhaps even more for "gold" members or whatnot.

Code could even be added for IP tracking restrictions based on account type. For example, perhaps free accounts would not be able to play if another player (even from a different account) connected to the same IP is already logged in. This would prevent people from making several free accounts to get around the multi-play restrictions. Paid for accounts wouldn't have such a restriction, at least not beyond the built in limits used to protect against DoS attacks.

Scriptix Security

The current access permission flags in Scriptix are set per-thread. Whenever you start a new thread, you specify the access permissions if different from default. The fork() call and such can just copy the originating thread's permissions, perhaps applying a "non-inheritable" mask. At least, that was the idea.

Now, tho, I've thought of some problems with this approach. First, it requires the C++ code launching the thread to have some knowledge of where the code came from. I.e., in AweMUD, scripts in the scripts/ folder should have full access, as they are administrator/coder scripts, while scripts loaded from AweMUD zone files should have greatly reduced privileges. In this case it's easy for AweMUD to keep track of these things, but in other theoretical cases it may be difficult to track this metadata.

Additionally, there is a potential security hazard. Say that a function was made by a scripter that shouldn't have file I/O capabilities, as the function is found in a zone file. Some Scriptix thread that has full privileges might be tricked into calling the zone file function (perhaps it was added as a callback somewhere), and that function gets full access. Now it could do file I/O. Bad.

The first solution which I've been thinking of would be to tell the compiler which privileges to have, and as a function/method is compiled the privileges are embedded in it. So, the functions in the zone would always have reduced privileges; if a thread has a function with full privileges, and it called the function with reduced privileges, it wouldn't matter because the privileges would be based on the current function, not the whole thread.

The problem with that approach is that a function compiled with full privileges could be easily in most cases called by a function with reduced privileges. This makes coding any function with advanced privileges more difficult, because the scripter would then be required to do their own privilege checking to see if the caller should be allowed to access the function.

Of the course, the logical next step is to do this automatically. The idea there is, each function again has privileges compiled in. But when function A calls function B, function B's privileges will be only the common set of privileges shared by function A and function B. I.e., if function A has fork and net privileges, and function B has file and net privileges, then when function B is called by function A it will only have net privileges. And it a function C is called from B, it will use the running B's privilege list. (i.e., if C also had file and net privileges, it still only get the net privileges as the calling instance of B didn't have the file privileges.)

Hollywood

jdhildeb: I was recently participating in a discussion about "Fedex" style quests in role playing games. The argument is that these style quests (which by definition consist of taking an item from point A to point B, usually embellished by having to find point A first or kill some creature there to get the item) are horrendously boring, and that all quests matching this pattern are, thus, boring.

The problem is, there are almost no quests you could possibly think up that doesn't fall into this pattern. With a little (too much?) thought, you could map any quest to the pattern, no matter how intricate or entertaining.

I would dare say this sounds like your description of Disney movie plots. Pirates of the Carribean has a rather unique plot, and is definitely unlike any other Disney movie I've seen. You however claim that, "stripped down", the plot is unoriginal. Unfortunately, *any* movie, including the indy movies, could also be stripped down to one of a few basic plots. The thing that differentiates movies isn't the underlying basic plot, but the details of that plot. (And perhaps any meaningful underlying message trying to be delivered with that plot; those are just as rare in indy movies as mainstream movies, I'd argue, however.)

I would dare say that you are perhaps biased against mainstream movies, and thus (subconsciously) put in the effort to strip down the mainstream movie plots in ways you don't try to do with indy movies you enjoy. Ya, Hollywood shovels out a lot of crap, but so do indy movie producers. Eschewing mainstream films because of a prejudiced feeling that big budgets are only for bad movies is just as bad as refusing to watch anything but Hollywood movies because you think that only a big budget can make a movie good. ;-)

Also, on a bit of a side note, no good pirate movie *could* have a female as a true main character, as it wouldn't fit in with the culture of the period. If I have anything against Pirates of the Carribean, it's that they did make Elizabeth such a modern-times kind of girl, as chances are that kind of behaviour/spirit would've been schooled out of her long before she grew up. Were we talking about a movie in a different period/culture, then the lack of an indepth female character would've been a real shame.

It also rather bothered me that the skeletons had eyeballs; that didn't make much sense. I suppose the truly terrifying way they *should've* looked, however, would've made the movie classified as horror and not a family adventure film. ~,^

Two Months!?

xf: If it does take that long, I won't be buying from Apple. That's just plain out insane. There is no reason for an order to take that long, especially if they don't provide stock information on their webstore.

If it takes much longer than a week or two, I'll cancel the order and head to CompUSA or an Apple Store and buy there. And if *they* can't get me one, then I just won't buy an Apple product.

Customer service matters, after all, and needing two months to ship a machine I could rather use now does not, in my rules, count as good customer service.

-end rant

Aye Laddie

criswell: hmm, I am also the dwarf. And am also 6'3". Weird. Of course, the "king of the dwarves" on the LARP field I play at is even bigger than me, so I guess size doesn't matter much. ;-)

The actor that played Gimli is frickin huge, I might note.

Fedora Shemora

Hmm, yum finally updates things. Yay me!

Many things are broken. No yay me.

I rebuilt the gstreamer-mp3 plugin, but it has a habit of cutting out in the middle of a song in Rhythmbox. Sound starts up again on the next song. Weird. That's probably what I get for mangling up a spec file for the 0.6.3 gstreamer release and hoping it'll work on 0.7.3. (yes, I did use the 0.7.3 for compilation.)

SMB in Nautilus is working, altho the implementation doesn't seem to bother using the keyring when querying the server, just on accessing a share. Meaning that it doesn't even *show* some of the shares, such as my personal home folder. (submitted bug.)

Various icons seem broken; show desktop, lock screen, etc. (will wait for next update, this is all in flux after all.)

Damn scroll mouse still doesn't work. (bug already filed.)

Many of the Nautilus "special areas" don't work or aren't available. the CD Creator has no "Burn" button or menu option, for example. The "network" location doesn't show anything. There's no documentation about it that I see, so I don't know if that's good or bad... Guess the interface isn't done being hammered out. (will file bug after next release if no improvements are made - don't want to tell the developers what they are already working on.)

Metacity has a habit of crashing. (Can't get a backtrace atm, so no point in filing a bug here - would just be spam in the bug tracker.)

gedit has the new file selector, and I'm very disappointed. I surely hope the UI improves - it is beyond any doubt *worse* than the old one. not to mention buggy. and has silliness like an add/remove button book which *doesn't work*, but tells you by making a popup appear after clicking them, versus just disabling the buttons... (am about to file some notes on this)

iBook

Still hasn't been shipped. Poor me. I'm too impatient. :(

Packaging

I'm starting to *really* get the itch to design up a saner packaging system than what we have. autopackage is quite close to what I'd want tho, so I've rather not put forth the effort to just duplicate already existing work.

Autopackage has a few design issues I rather dislike, however. The first is the whole idea of putting the installer stub in the package. *Nobody* but uber geeks can use this! When you download a .package file, it's not executable, and no sane browser/file manager will try to execute it. And users shouldn't have to be told to make it executable or use a command line.

The only way for it to work sanely is to have the package manager already installed. Which means the stubs are useless.

What I'd like is not only a solid usable application package manager, but a very indepth manual of rules for packaging that is strictly enforced. A package warehouse (or just directory) would be available which rates packaging attempts (in which the only way to score the highest rating is to meet *all* the guidelines/rules), and provide community written specs for packages. A community run QA system, if you will. Both users and vendors would then have an archive of pre-written fully functional specs of best quality available to them.

Of course, as always, I never have the time to follow thru with any of my ideas... ;-)

At least they're here in the public for some other fool^wdeveloper to implement them if they so wish.

Banging Head Like a Bull

Argh! The player account states in AweMUD are driving me nuts!

States include 'valid' (is an actual Player, not just a garbage temporary object from a failed login or something that hasn't been GC'd yet), 'playable' (has gone thru character creation and can start playing any time), 'connected' (has a valid TelnetHandler object, someone is using the player), and 'active' (player is in the game world; usually also connected, but may have been disconnected and hasn't had the anti-cheating timeout expire yet).

Now, you can't save a non-valid player to disk - wouldn't serve a purpose. Alright. If a player that isn't playable logs in, character creation must be started. All good. If a player is valid and playable, but not connected but is alive, you can take over the player on login. Getting hard to follow. If the player is valid and playable and connected and alive, you are asked if you wish to take over the player on login (perhaps a hung connection is making AweMUD thing you're still connected).

When does a player become playable? After character creation, or if loaded from disk and the playable attribute isn't set to false. When do they become valid? After character creation or after they are loaded from disk (as they must have been valid to be saved to disk). When are they active? As soon as they connect, and up until the player quits, which happens some 60 seconds after most disconnections. Um... OK.

It's just getting to be a serious pain in the ass. I need to think up a better way to manage all these...

Dead

Ugh. Not sure why, but I feel completely dead. No energy at all. I'm surprised at got as much of my morning workout done as I did. (Which wasn't very much.)

Even now, it's all I can do to stay upright in front of my desktop...

Scriptix Security

Started finishing off the Scriptix security access stuff. I figure for now a 16 bit flags variable is all we'll need - the system is likely to never need the 8 bits reserved for it, and I can't imagine an embedding app (at least none of Scriptix' target apps) using more than the 8 user bits.

Big Patches

Unfortunately, as part of my bad developer discipline, the Arch patch is going to end up having several completely different updates in it, including a change to using the C99 intptr_t type and a cleanup to tons of public constant and type names.

How do people generally manage splitting a single file's changes into multiple patches? The only way I can think of (hand-hacking the diff) is waaay too much pain for the payback in the case of a mostly single developer project. And, besides, I really don't think you can hack the diffs like that in GNU Arch at all.

File I/O

I guess now that I have the security stuff in place I need to actually write file I/O routines for Scriptix. Joy.

Laptop Goodness (or not?)

Well, the iBook is ordered. Thanks to those who gave me suggestions! Should be here within 5 business days, along with a (much cheaper than Apple would provide) 512MB PC2100 SODIMM stick.

My old laptop is powering on again, which is good, but the Windows Quick Restore CDs don't work, which is bad. So I guess I'll just dump the whole lot off at Best Buy tomorrow and let those bastards fix it. (Of course, all they do is ship the laptop to Compaq itself, who then proceeds to not fix it, and ship it back to Best Buy, for me to pick it up.) ::sigh::

27 Jan 2004 (updated 27 Jan 2004 at 16:46 UTC) »
Powerbook vs iBook

I was looking at iBook reviews last night, and noticed two things that sound rather unappealing: the white plastic gets dirty very easily and is hard to clean, and the 14" model has a max res of 1024x768.

I speced out two PowerBooks (both 15.2", 1ghz or 1.25ghz, the later also have the backlit keyboard), altho the weaker PB is $700 more than the iBook, and the other PB is $900 more than the iBook.

One thing that makes the decision even harder is that even tho the PBs are more expensive, they aren't even necessarily better - the iBooks are smaller, lighter, and should have a longer battery life. I want to avoid wires, so that's a big plus for the iBook. I guess what it comes down to is whether a 1024x768 on 14" display is good enough for my wide-screen DVDs and whether the 933mhz processor is good enough, or if I should go for the 1ghz or 1.25ghz of the PBs.

I'm wondering if anyoen here has any recommendations for which to get? I have no plans to do any gaming, just school work, watching movies, using iTunes, and (of course) programming. The notebook wouldn't be my main development machine, so speed isn't super important, but I don't want something that'll take 7 minutes to compile AweMUD. (Like my current laptop.)

Laptop

My laptop died. Yet again. POS. It's under warranty for a little longer, so I'm going to get it fixed for free and then stick the sucker on EBay.

For a replacement, I'm very likely to get a 14" iBook. With my student discounts, it's quite cheap, and if I go for the loan route, it's only $14/month. That's nothing. I make that much every time I sneeze at work. So all I have to do is sneeze once more per month and the iBook is free. ;-)

(no, actually, that's a little over an hour's worth of work, not including taxes, but oh well.)

GNOME-VFS SMB

Fedora's gnome-vfs packages have been broken for a long time with regards to SMB. Or, perhaps, it's something on my local system. With the new gnome-vfs 2.5 packages in Fedora Devel, it hasn't gotten any better. When opening smb://, nothing shows at first. Hitting refresh makes the link to the HOME workgroup show, but the link doesn't work - Nautilus claims there is no app for opening application/x-desktop files...

Scroll Wheel

Hmm, seems the latest Fedora kernel has borked the scroll wheel on my mouse. I find it rather funny how attached to that thing I've become - my computer felt almost useless until I fixed it (by reinstalling an older devel kernel).

Geeks?

jds: I'm not really sure how to say this nicely, so I won't. Your definition of geek seems to have no relation to what "geek" really means. It looks a lot more like you're trying to justify your own unpopular behaviour and liken yourself to respectful figures. I'm appalled to think others might read your writing and assume the rest of us are anything like what you describe - arrogant, pompous, self-centered and thoughtless. I almost think you're writing something closer to satire than anything you expect to be taken seriously.

21st Birthday Parties

Spent last evening at my good friend's 21st birthday party, which was interesting. I avoid alcohol almost religiously, for several reasons (not the least of which is that I rather prefer keeping my head in working order), but just about everyone else there was plastered after the first hour or two.

It wasn't so bad until later in the evening, where pretty much every game being played turned into a drinking game. ;-) That was about when I left, since I was relegated to watching the others have fun.

On a side note, I am ashamed to admit that I still almost always lose at Super Smash Brothers, even when the other three players are (ahem) smashed.

Linux Evangelism

I've noted that many of my recent attempts at Linux/Free Desktop evangelism have failed since my personal box is so often borked. A few days ago I found audio had stopped working (due to the removal of OSS in the Fedora kernel), and while I got ALSA setup quick enough, the fact that friends watched me do all this intricate wizardry just to play Red vs Blue videos rather left a bad impression on them. Even my 'stable' boxes tend to have numerous problems, since I keep tinkering around with various things and end up breaking it in subtle ways. ;-)

I think when Fedora Core 2 comes out, I'm going to reinstall this box and my laptop, to get things in a clean working order. I need to save up and get a nice big harddisk for my home folders on my workstation first, tho. 40GB is too little when you want to install even a few large games, especially when you have the drive partitioned.

Drive partitioning in general is evil for the user, I believe. Yes, yes, it's great for numerous technical reasons, but that doesn't matter to normal people. What does matter is that it's very, very difficult to predict how much software you'll install system-wide and how much data/software you'll keep per user. You might very well have enough disk space for everything, but find out that due to your guess up front about partition sizes you don't have enough space in the right place.

Dynamic automatic partition resizing might fix this, might I'm not sure it could actually be done. I guess the lazy modern fix is just to buy 200GB hard disks. ;-)

Art of UNIX Programming

The book, as a whole, is quite good, I think. I really wish more so called programmers would read it. I wish even more than non-programmers would read it; managers in particular.

One thing that I must say, however, is that ESR definitely asserts his personality in the book. He, of course, is the author, but I would personally expect a little less of his personal opinion and more of the straight facts. The several new terms he's tried to coin in the book alone are a good example of the problem. In other places, applications (especially his own) are praised for design choices with either no reasoning given, or with reasoning that ignores how the apps break the philosophies he's preaching in the book.

One good example is the fetchmailrc configuration format. It's horrible for a number of reasons. The "English like" syntax is conter-productive. It's much more difficult to parse by scripts (more code, more bugs, etc.) more difficult to learn by humans (the rules aren't obvious and self explanatory) and more complicated than need be (remember KISS?). Fetchmailrc should've been one of the examples of what not to do in the book. The fact that it is (mis)placed in the mini-languages section of the book makes the problem even more obvious.

Again, tho, the books is on a whole quite good. I'm quite glad I bought a paper copy.

95 older entries...

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!