Welcome to Kirsle.net!

For once, this is actually not going to be a rant about Gnome Shell. It actually runs decently on a touchscreen!

I recently got a Samsung Series 5 Ultrabook which has a touchscreen on it. After having trouble getting Windows 8 how I want it on this laptop, I installed Fedora w/ XFCE across the entire disk. I got motivated to try again with Windows 8, though, because it's a shame having a touchscreen and no software that knows how to use it properly.

XFCE doesn't work well with a touchscreen. I can't move windows around on it by touching and dragging their title bars. I can't highlight text.. when I touch and drag over text, it selects it, but it immediately de-selects as soon as I let go. About the only thing I can do on XFCE is click on things, and scroll a window by touching and dragging the scroll bar.

Before dealing with repartitioning and getting Windows 8 back on there, I decided I'd yum groupinstall "GNOME Desktop" and see how well Gnome Shell works with this touchscreen.

The first thing I tested was dragging windows around. It works. I opened Firefox and dragged inside a web page, which highlighted text (don't remember if the text stayed highlighted though). Dragging the scrollbar worked.

I opened Nautilus and navigated to /usr/share by touching the icons. This folder had a scrollbar. I could drag the scrollbar just like in Firefox, but I could also scroll the window by touching anywhere else in the window and swiping, just like you'd expect on Android or iOS. It supported acceleration too, where you could swipe quickly and let go and the window would continue scrolling and eventually slow down.

Dragging windows around in the Activities view worked exactly how you'd expect, too.

Gnome Shell doesn't support multi-touch, though. But I think this is the fault of X11 in general not supporting it, so you can't blame them for that. If you try a multi-touch gesture, it just gets confused and tries to treat all your fingers as one and you get erratic mouse movements or something.

I still don't like Gnome, but I am impressed that this actually works, for all the propaganda you hear from the Gnome devs about making it a tablet interface. I was expecting it to be as painful to use as XFCE on a touch screen.

Now, to install Windows 8 and then put Fedora XFCE back on. ;)

Having used both brands of video card in Linux over the years, the tl;dr. is that Nvidia has much better support with their closed source drivers on Linux than AMD does. Here's my anecdotal evidence for why I think so.

I've used three computers that came with various kinds of AMD graphics cards, and all of them have given me nothing but problems in Linux. The first one was an ATI Radeon Xpress 200M, built into an old laptop I bought in 2007. This video card appears to have already been obsoleted by AMD at the time I bought the laptop, but that's another story.

The Xpress 200M card was problematic for both Linux and Windows. It only worked reasonably well with Windows XP; and it's entirely not supported by any means in Windows 7 or 8. In Linux, I can only use the open source radeon driver with it, but that doesn't give me any kind of hardware acceleration. If I install the fglrx driver (AMD's closed source proprietary one), it makes the system completely unstable, and random kernel panics and freezes become very common.

My second computer with an AMD video card was a Dell Studio XPS desktop. I don't remember the exact model number of this AMD card, but it was somewhere in the mid-range area. I installed the fglrx driver in Linux, and it worked reasonably well, except every once in a while my screen would completely go black, and then I could bring back parts of my display by "refreshing" them (i.e. moving my mouse around, dragging a window... any time a part of the screen needed to be redrawn by Linux, it would be redrawn and the solid black would go away). My XFCE panels were particularly difficult to get to redraw themselves, though, because they don't refresh very often. I'd have to kill/restart the panels instead.

The reason I replaced this card with a mid-range Nvidia wasn't because of the random blacking-out issue, it was actually the card's pitiful performance in Windows 7. I ordered the desktop with suitably powerful specs (6 GB RAM, 6 core 64-bit AMD CPU), so that I could run emulators for the likes of Sega Saturn and GameCube. For the latter, the frame rate would be pretty slow in parts and I suspected the video card was the bottleneck, so I tried replacing it with an Nvidia card I had from my old desktop. This did indeed speed up the frame rate in the emulators by quite a lot (most games run at full speed most of the time), and of course fixed my blacking-out issues in Linux.

The third time I had to deal with an AMD card was on a work PC. This one has an AMD Radeon HD 7400 Series video card, and it really caused nothing but problems.

First, the open source radeon drivers in this case were entirely useless. About half of the time when I booted this computer, it was unusable. I'd end up seeing a completely white screen, with maybe 3 pixels worth of stuff happening at the top of the screen (I think it was the bottom of an XFCE panel, with a workspace switcher applet). It's like the screen resolution was completely wrong and/or scaled up to a ridiculous level. Switching to text mode didn't work either... the screen would go black, but there'd be no prompt (presumably, the prompt was WAY outside the screen borders).

The other half of the time, the display would simply be off-centered. The left edge of the display would be about 1/3 of the way across the monitor, and then it would wrap-around on the right so that the right part of the display was on the left 1/3 of the monitor. Attempting to change the screen resolution within XFCE (using both XFCE's built-in tool, or xrandr directly), would put the monitor into "seizure mode" where it would flicker black and white rapidly.

Installing the fglrx drivers fixed most of my problems, except that AMD feels the need to let me know that my video card isn't officially supported. They placed a watermark in the bottom right corner of my screen, that's rendered on top of everything else the display puts out, that has their logo on it and says "Unsupported hardware". And there's no configurable option where you can say "that's fine, just let me try my own luck using this driver anyway". Nope, to get rid of the watermark, you have to hotpatch the driver binary to basically delete the image out of it, and then reboot. There's a shell script on the Internet that does this - just google "fglrx watermark"

In contrast, I have never seen an Nvidia card that gave me any problems in Linux. The binary drivers for Nvidia have always been absolutely perfect. The only issues I'd ever run into were the times when Fedora would get a new kernel update, and the third party group who package the Nvidia driver lagged behind a day or two in getting their update out. This is largely fixed by using akmod-nvidia instead of kmod-nvidia, though. akmod's automatically rebuild themselves when you update your kernel.

So, I thought I liked Windows 8 a bit. The OS itself isn't absolutely horrible once you get used to it. I even bought the $40 upgrade to Windows 8 for my main PC, where I promptly spent 100% of my time on the desktop and not in the Metro apps. ;)

But, I just bought my first computer that actually had Windows 8 preinstalled on it: a Samsung Series 5 Ultrabook. It has a touchscreen and some nice features, and I wanted to dual-boot Windows 8 and Fedora Linux on it (giving Windows the smaller half of the hard drive, of course). Microsoft apparently went to great lengths to make this darn near impossible.

I came to find out, when you have Windows 8 pre-installed on your computer, it's probably the Windows 8 "Core" Edition. The only Win8 install DVD I had laying around was the Professional edition that I bought for $40. It was logical to me that I should be able to hopefully reinstall Windows 8 on the ultrabook from this DVD, maybe even using the same OEM product key that the laptop came with and not having to worry about any activation issues.

Apparently, Windows 8 PCs have their product keys "baked in" to the BIOS ROM. If you boot a Windows 8 installer of any edition, the installer looks for this product key in the ROM, and if the key is for a different edition than what the installer is intended for, it gives you some ugly error message about, "The product key you entered doesn't correspond to any of the install images. Enter a different product key." -- except it doesn't let you enter a product key anywhere, and just restarts the setup process from the beginning.

There also apparently is no Windows 8 Core ISO floating around the Internet -- not one that I would trust downloading, anyway. With the baked-in product key, the only Win8 installer that would work would be a Core edition installer, which doesn't exist. You can't install Windows 8 Pro on your computer, because the installer simply won't allow it.

Long story short, Microsoft has basically forced me to forego dual-booting completely and just install Linux on the entire hard disk. The built-in Windows 8 OS came bundled with a bunch of Samsung's crapware, and there's no way to "start fresh" with Windows 8 -- your only option of "reinstalling" is to use the Control Panel feature, which restores "to factory settings", which means your Samsung crapware is still gonna be there after the reinstall is done. And you can't install from scratch from a DVD for the aforementioned reasons.

You can even completely remove Windows 8 from your computer, maybe install Windows 7 or Linux across the whole drive, and you still won't be allowed to put Windows 8 back on there from an install DVD or USB again.

There is a workaround, though: if you make a bootable USB for Windows 8, you can add a text file to it where you specify the product key to use. For me to do this, however, I'd need to buy an additional Windows 8 Pro license, and that's not worth it to me. So, good riddance Windows 8, I don't care to have you on my ultrabook anymore, anyway.

It's high time for my first Minecraft mini tutorial!

I tend to prefer playing vanilla Minecraft and try to get away with it as much as I can, and as such I've been electing not to run Bukkit or any other custom servers ever since about Minecraft 1.4 came out.

Minecraft has Command Blocks nowadays, and you can do a lot of creative things with them to replicate the behavior you could get by using Bukkit plugins. I recently started a new "Swampcore" server... the name is borrowed from a popular server on Reddit when they set up a swamp superflat temporarily while they waited for Bukkit plugins to get updated for the latest version of Minecraft.

Their version of Swampcore had you spawn in a small enclosed room, lined with pressure plates by the walls which would teleport you to an unpredictable location within a large radius on the overworld. The idea was to evenly distribute the players, so that people wouldn't build too close to the spawn point and therefore be open to griefing by newly joining players. Also, Swampcore had a 24/7 thunderstorm, which prevents mobs from burning up during the day and even allowed them to spawn in the middle of the day. I've managed to more or less copy all of this behavior using nothing more than the vanilla server, and here's how I did it:

First, the superflat preset I'm using is this:

2;0,49,1,2x7,3,2;6;biome_1,decoration,lake,lava_lake

Put simply, from the bottom up you have: 1 layer of air, 1 layer of obsidian, 1 layer of stone, 2 layers of bedrock, 1 layer of dirt, and 1 layer of grass. It's set in a swamp biome, with lakes and lava lakes, and sometimes the stone blocks (around lava lakes for example, or in the stone layer) might spawn ores.

So, go into creative mode and find the world's spawn point (give yourself a compass and go to where the needle points to, until you get to the point where the needle flips the opposite direction when you cross onto the next block). This is the center of the spawn point.

The server's spawn protection radius should be reasonably large (16 blocks should do). The protection radius basically prevents any users who aren't the operator from being able to change any blocks (destroy or place any). It also prevents them from activating any redstone devices except for pressure plates. They couldn't even open wooden doors in the protection zone.

Build a bunker out of bedrock. Here's what mine looked like:

(Click this and other screenshots for full size versions)

I put an iron door on my bunker and have a stone button that opens it. The button couldn't be activated by a non-operator, and as you'll see shortly, it should be unreasonably difficult for a non-operator to grief your bunker by having a creeper explode next to it.

Inside the bunker, build a redstone circuit designed to run on an infinite loop. I put a bunch of repeaters around, all set to the longest delay (right click 3 times), to keep the loop from bunching up on itself. When you're ready (not yet!), you'll place a redstone torch on the raised bedrock block and then immediately destroy it, so that it's only there long enough to give a quick pulse to the circuit and get it started.

Pro Tip: the 5x5 chunk radius surrounding the spawn point is always loaded in memory. Any redstone circuit that runs there will never be unloaded from memory even if all the players wander far away, so it's a good place to put your infinitely looping circuits that enforce "rules" on your server. The spawn protection radius is icing on the cake as well, as it automatically protects your circuit from being interfered with by other players (note that creepers and TNT launched from outside the protected zone can still damage the protected blocks).

In part of the circuit, make sure the redstone runs over the top of a command block. Use /give <your name> 137 to give yourself a command block to place. You'll definitely need to be an operator and in creative mode to set the command on the block. Hint: you can place redstone on top of the block by holding down the Shift key while you place the redstone.

The command I have here is this:

/tp @a[m=0,r=36] -336 202 179

This command will teleport all Survival Mode players (m=0), within a radius of 36 blocks from this command block, up to the coordinates -336, 202, 179. These coordinates in my case are, the spawn point, 202 blocks up into the sky.

The radius is set to 36 to make sure it fully encompasses the entire spawn region of the server. So anybody who joins the server or dies without a bed, they'll spawn on the surface (probably) within this radius and be immediately sniped up to the teleport spot. Players in Creative Mode are not affected, so that the operator can still get into the bedrock bunker to restart the redstone circuit in case it fails for any reason, or whatever.

Up in the sky above the spawn point, I built this floating room:

The floor of this room is at Y=200... I set the command block on the surface to teleport players to Y=202 just to have them off the floor a little bit. YMMV.

This room is a lot like their Swampcore server. It's a radially symmetrical room (looks the same on all 4 sides) with command blocks surrounding the perimeter. This is so that when you die and respawn and come back to this room, it won't be easy to know which pressure plate you used the last time. Even if you remember you "used the one in the middle", you still only have a 25% chance of guessing the same exact one as last time. The pressure plates are all rigged to command blocks to teleport players to a spot within a large radius, to evenly distribute them across the overworld.

Here is a view of this floating room from above. I put a roof area and a hole to drop down into the room just in case a user happens to spawn on top of the roof, instead of somewhere on the surface near the bedrock bunker. Hey, it happens. Note that since this room is still within the spawn protection zone, the blocks can't be destroyed or altered by the players unless they're operators. And since the room is so high in the air, the odds of getting a creeper up here, or launching TNT into the spawn region from outside to damage the room are extremely low.

Just like with the bedrock bunker, I have an iron door with a stone button for maintenance work (if needed) for the server operator. Even if a survival mode player spawns on the roof and drops down to this door, they can't get inside because of the protection radius.

This is a view from inside the maintenance room, directly below the main spawn room. These are all the command blocks that are positioned underneath the pressure plates above. I placed wooden signs under each command block that tells me the coordinates that the block will teleport you to. I also placed stone buttons on the side of the block (hint: hold down Shift to place the buttons), for testing purposes. Both the button and the pressure plate above will activate the command block.

The commands I used on these blocks are along these lines:

/tp @p 500 7 -1000

This teleports them to Y=7 (the level of the surface in my world), at the X/Y coordinates that are mentioned on the wooden signs below the command block. The @p targets the nearest player, which will usually be the one standing on the pressure plate above.

And that's all there is to it. If players find their way back to the spawn region, they can't get anywhere near the bunker without being teleported back up to the welcome room. The only way they could attack the bunker would be to somehow fling TNT over 36 blocks towards the bunker (an amazing feat in itself), but it being made of bedrock they wouldn't be able to do a whole lot of damage to it. The only way they could attack the welcome room would be to build up a super large tower to the top of the world, build a bridge as close as they're allowed to (within what the spawn protection radius will allow), and then fling TNT from all the way over there. If you set your radius high enough, even this will be highly impractical.

As for the 24-hour thunder storm... you could use another command block down in the bedrock bunker that does /weather thunder to make sure the weather stays tempestuous. Personally, I have a cron job that runs my make-it-rain script every 2 minutes. This is my cron entry for anyone interested:

*/2 * * * * /home/minecraft/bin/make-it-rain swampcore thunder 9000

I've discovered how to get the full range of Emoji icons to render on Linux systems.

tl;dr. - Just install the Symbola font (the link on the right half of this page: Unicode Fonts for Ancient Scripts) into your /usr/share/fonts or ~/.fonts folders. Ubuntu users can sudo apt-get install ttf-ancient-fonts. For Fedora users, you can yum install gdouros-symbola-fonts (thanks James in the comments for correcting the spelling. I typed this command for the blog instead of copying/pasting from my terminal. ;)).

---

I ranted about the poor Emoji support in non-Apple systems before, then updated the post with screenshots showing exactly how various users will see (or not) your Emoji icons, but I got curious again to figure out what can be done to make Linux support them.

I heard (inaccurately) that Ubuntu should support them (in actuality, the person I heard this from had installed the Symbola font, so he could see Emojicons, but the default Ubuntu user can't). I also heard that it was up to the individual typefaces to include all the Emoji symbols, and if your chosen font doesn't include them, they don't render.

Testing the latter theory, I yanked the Segoe UI font from Windows 8, which is the default font, and I know that Windows 8 fully supports Emoji. This font in Linux though didn't render Emoji icons any better than all my other fonts did.

I heard about Symbola from a Google search, but the blog post I saw that mentioned it was talking specifically about how to use Emoji on your web pages... and it sounded like, "you embed Symbola.ttf using HTML5's new feature, and use that font family for each Emoji icon you want to include on your page... i.e. <span style="font-family: Symbola">emoji symbol here</span>.

Then a coworker mentioned that the typefaces don't need to include the Emoji icons, as long as font substitution is supported... so I was curious if Linux could do such a thing, so I simply dropped Symbola.ttf in my ~/.fonts folder, and within 2 seconds, all the unrenderable Emoji symbols I saw in my Pidgin chat logs suddenly transformed into the correct symbols like some kind of magic.

So, that's how you do it.

But now I'm curious about what kind of black magic Linux did to suddenly render these symbols. Maybe, when it finds an unrenderable symbol, it scans through the installed fonts until it finds one that provides that symbol...

I recently had need to install PAR::Packer on Windows (for those that don't know, pp is the best fully-open-source way to build a stand-alone .exe file from a Perl script, which doesn't require a Perl installation to run). I had installed pp on Windows a long time ago, but the process seems to have changed a bit so here's my experience doing it now, what problems I ran into, and how I fixed them.

Versions:

• Windows: Windows XP Professional, 32-bit
• Perl: ActivePerl 5.16.2 for Windows 32-bit
• PAR::Packer: 1.014
• Module::ScanDeps: 1.10

The Makefile.PL from PAR::Packer lists what other dependencies it has. These were all available in ActivePerl's PPM repository so they were easy to install, for example, ppm install Win32-Exe.

nmake 1.5?

A long time ago, you used to be able to download this stand-alone nmake binary from Microsoft, which replaced the usual make command from Unix. But, it seems Microsoft has pulled this download offline and they want you to install some kind of Visual Studio Express app that provides a newer version of nmake. I ended up finding a copy of nmake somewhere else on the Internet, which I've hosted here: nmake15.zip (NOTE: You might not need nmake, I later found out ActivePerl comes with dmake which worked for installing other modules, YMMV).

The only modules I needed to manually install (perl Makefile.PL; nmake; nmake install) were Module::ScanDeps and PAR::Packer, but running nmake gave this rather cryptic error message:

to undefined at C:/Perl/lib/ExtUtils/Install.pm line 1208

I found this relevant Perlmonks article. What I needed to do was open the Makefile (not Makefile.PL; the one with no extension) in Wordpad, and do a Find/Replace of {{@ARGV}} to {@ARGV}, and then nmake ran just fine.

For my project I needed to manually install Template::Toolkit, and the Makefile.PL told me to run dmake. Running this worked just fine without requiring me to manually modify the Makefile. If this is available, I imagine it would probably work better for you then nmake.

Anyway, after installing PAR::Packer's dependencies, PAR::Packer installed and ran just fine.

Update: Spot has a Steam yum repository set up. Download steam.repo to your /etc/yum.repos.d directory, and then yum install steam. When I originally wrote this post, Spot's steam repo was gone (that link gave a 404).

---

Just a quick post about how to install the Steam for Linux client on 64-bit Fedora Linux.

This works for Fedora 17 x64. I'm not sure it will work in Fedora 18 or later versions when they come out, but I'll probably test that at some point too and update this post.

NOTE: It should go without saying, but the terminal commands I list below begin with a $ sign -- you don't type this symbol. That represents your prompt. So when it says "$ yum install ..." you just type "yum install ..."

1. Download the steam.deb Ubuntu package (currently, Steam only officially supports Ubuntu 12.04) - link that works as of the time of this writing.
2. Open the .deb in an archive manager, such as Gnome's file-roller. Extract data.tar.gz from the .deb file.
3. Extract data.tar.gz somewhere like ~/steam - put it in an empty folder, so after extracting, this folder will only contain the directories "etc" and "usr"
4. In a terminal, switch to the directory you extracted data.tar.gz to, and run:
   $ sudo cp -r * /
   Alternatively, open a file manager like Nautilus as the root user if you'd prefer to do a copy/paste visually.
5. You'll also have to install the 32-bit versions of some libraries that Steam depends on. Run this command in a terminal:
   $ sudo yum -y install libpng.i686 libpng-compat.i686 gtk2.i686
6. Run Steam either by the steam command in your terminal, or via your application menu.

And it should work. You will probably also need to install 32-bit support libraries for your video card, for example xorg-x11-drv-nvidia-libs.i686 for recent NVIDIA video cards (assuming of course you're using kmod-nvidia and not the default nouveau drivers!). You're on your own here though, but this Crossover Wiki page may help.

Problems?

If you get an error that says "Failed to load steamui.so", this will be caused by missing dependency errors. Steam will need the 32-bit versions of some libraries it depends on, which don't get installed by default in a 64-bit Fedora OS. Re-read the steps above and make sure you installed the 32-bit versions of libpng, libpng-compat, and gtk2. If they're all installed, it may be another library (I personally only had to install the three listed). The general procedure to track down missing libraries in Linux is as follows:

1. In a terminal, navigate to Steam's library folder, which (as of right now) should be in $HOME/.local/share/Steam/ubuntu12_32
2. Run this command to list the missing library dependencies for steamui.so:
   env LD_LIBRARY_PATH="$PWD:$LD_LIBRARY_PATH" ldd steamui.so | grep "not found"
3. If this command shows no results, this means there are no missing libraries and everything should be working. If it does list results, continue reading.
4. For example, if it says "libgtk-x11-2.0.so.0 => not found", run this command to identify the package in Fedora that provides that file:
   yum provides '*/libgtk-x11-2.0.so.0'
5. This will list packages like gtk2-2.24.10-1.fc17.i686 : The GIMP Toolkit (GTK+), a library for creating GUIs for X (there will also be a ".x86_64" version, but we don't care about those because we need the 32-bit libraries).
6. Ignore the version number part of the package and just sudo yum install gtk2.i686 -- make sure to include the .i686 part, otherwise Fedora will just assume you want 64-bit because it matches your current architecture.

Good luck!

Let's look at some very, very old* desktop environments, which lack in some features we've had for at least a good decade now.

Gnome Shell

What sorts of things does this clunky old desktop environment not allow us to do, which every other desktop does (and has for a decade)?

• We don't have a customizable panel. There's a panel on the top, and it stays there; can't be moved, hidden, changed in any way...
• We can't change the widget (GTK) themes on the fly. The desktop environment itself provides no way of changing the theme at all, and changing it via a third-party tool requires you to log out of your desktop and back in for the change to take effect. How old school is that!
• The same goes for the window manager theme. Every other window manager in the history of ever lets you re-theme it "live" without logging out. Not good old Metacity, though!

That's enough ragging on this one, let's look at another one!

Cinnamon

This one is based on Gnome Shell. Some people didn't like Gnome Shell and they wanted to make it look and feel like a more functional desktop environment known as Gnome 2. So let's compare it to that!

• Oh no. The panels aren't hardly configurable. You have 3 options: one panel on top, one on bottom, or both. And changing that setting requires you to log out and back in. How ancient.
• Panel applets? I hope you only want one of each applet, and that you're fine sticking them into pre-designated slots on your panel. You can't customize them beyond that. The applets don't even have their own settings--your app menu will say "Menu", and you can't change that.
• Metacity strikes again! You can't change the window manager theme without logging out and back in.

Wait, what ever happened to Gnome 2, anyway? I used to like that guy!

Actually...

*These desktop environments aren't very old at all. They're current. Gnome Shell is the default desktop environment of Fedora, and Cinnamon is one of the defaults of Linux Mint. And who's really at fault for these two desktop environments being so 1995, anyway? The GNOME dev team of course!

Gnome Shell is just so, so awful that Cinnamon was spawned as a way to get a more traditional (read: Gnome 2-like) desktop environment out of the utter mess that is Gnome Shell, except that Shell's bad design decisions are rotten to the very core and Cinnamon has to suffer for it as well.

Just to pick on one specific problem, Metacity no longer supports re-theming the window manager without logging out and back in. How many window managers in the world follow this behavior? Let's count them:

1. Metacity 3.x

Oh? And which window managers do allow being re-themed live?

• Metacity from Gnome 2 and back
• XFWM4 (the window manager for XFCE)
• KWin (window manager for KDE)
• OpenBox, Blackbox, Fluxbox, FVWM, . . .

That's right, damn well every single one of them.

I was very impressed with the MATE desktop environment when I tested it on Linux Mint... it is the exact same Gnome 2 that I used to love. The panels behaved the same way (read: fully effing configurable and requiring no log-outs to see your changes take effect), it had all the same applets and didn't come with the high-and-mighty "we know better than you and you may have ONE of each applet at most" attitude that Cinnamon has... and it doesn't use Metacity 3 so that all kinds of theming takes effect immediately.

So there's MATE, XFCE, KDE, LXDE and a good handful of window managers that exist here in the 21st century, and then there's Gnome Shell, and by extension Cinnamon, stuck back in 1995 which is the only place that their lack of features can possibly fit in.

</rant>

Last weekend I finally got into Minecraft and have been quite addicted to it ever since. I'm hosting my own server (minecraft.kirsle.net) so feel free to stop by and say hello! Just don't be a jerk and blow up other peoples' creations. :)

A long time ago I wrote about my plans to rewrite my Archive::Tyd project. Well, I've finally gotten around to doing that recently, and I feel like talking a little about it here.

I decided to keep things simple, and went with a plain text, ASCII based file format for the Tyd archives. Originally I was planning to make it a binary file format, but I didn't wanna have to deal with C-style data types (which would probably end up imposing limits on me, for example a 32-bit number has a maximum value of about 4 billion, which caused problems with the FAT32 file system by limiting maximum file sizes to 4 GB). So, plain text keeps things much simpler.

First, I'll show you what an example Tyd2 archive looks like:

TYD2:SHA1:46698a6530d53ca7004719bcad5095efaa09420a

[header]
name=Untitled Archive
packager=Archive::Tyd/2.00

[file:/file1.txt]
asize=68
atime=1345597264
checksum=97503ea37402b56b429c5210e9cfcd843c38b486
chmod=33204
ctime=1345597264
index=0
mtime=1345597264
size=51

[file:/file3.txt]
asize=32
atime=1345597264
checksum=37c9daa7930605795dbc00753e7d93c0da50b9e5
chmod=33204
ctime=1345597264
index=1
mtime=1345597264
size=24

[content]
VGhpcyBpcyBmaWxlIG51bWJlciBvbmUuCgpJdCBpcyBhIHZlcnkgc21hbGwgZmlsZS4K
VGhpcwppcwp0aGUKdGhpcmQKZmlsZS4K

The archive resembles an INI file in some ways. The very first line begins with "TYD2" as a sort of magic number for the file format, and then the checksum algorithm that's being used throughout the entire archive (SHA1 in this case), and then the SHA1 checksum of the entire archive itself (this is, the checksum of the entire file after the first line). This way the archive can easily self-validate.

Then we have the [header] section, with archive headers. Tyd 2.0 supports pluggable "file mangling algorithms" which will let you compress or encrypt the file contents in any way that you want. If an algorithm is being used, one of the headers will be "algorithm" and will name the algorithm being used; for example, "algorithm=CipherSaber". In this example, no algorithm is used.

Then there are [file:*] sections. There's one for each file in the archive. Each file contains a handful of attributes, like their creation and modification times, chmod permissions, file size and "archive size" (the size of the Base64-encoded data in the archive itself), and most importantly, an index number. This is how Archive::Tyd is able to "pluck" the file's data out of the [content] section.

In the [content] section lies the Base64-encoded data that belongs to each file mentioned in the file table, with one on each line. So, for the file whose index is "0", the very first line after the [content] section belongs to that file. The file with index "1" has the second line, and so on.

When an algorithm is used to mangle the file data, the data gets mangled before being encoded in Base64. So, for example, if you use CipherSaber to password-encrypt your file data, their data is encrypted and then encoded to Base64 (so you can't simply Base64-decode the data; you'd still have to decrypt the result with the CipherSaber password that was used).

You could just as well create a compression algorithm to use for this, for example something that uses Compress::Deflate7, but I'm not sure how useful compression will be considering the Tyd file format itself is kind of bloated (since it's ASCII based and not binary). But to each their own.

Anyway, this project is still in development. I plan to at least work out a way to get RSA encryption and signing to work before I release this module to CPAN. One idea I have for RSA signatures would be:

There would be support for custom blocks in the file, so you could create a [signature] block to hold the RSA signature, and a method to get the entire file table as a string. So, you could create your archive, get the file table out of it, cryptographically sign the table using your RSA private key, and then include the resulting signature directly inside the Tyd archive itself.

Also, I have yet to think up a way to support encrypting the file table itself, in cases where the file names and attributes are to be considered sensitive information as well.

Stay tuned.

You can check out the progress so far on GitHub: https://github.com/kirsle/Archive-Tyd.