Opinions on Diablo III

Blizzard's latest hit game Diablo III is quite interesting. The first act gives many nods to the original Diablo, from the events of the Fall of Tristram, to the characters involved - King Leoric and the Archbishop Lazarus - even to some of the monsters, such as the Butcher, which could be found in the original Diablo on labyrinth level 2. One of the earliest quests in the game has you saving Deckard Cain, yet again, from demons, in the catacombs underneath the Tristram Cathedral. No, he doesn't reprise his role as your item identifier, as the only items requiring identification are those of rare quality or higher, and you can identify items yourself for free, so long as you perform identification someplace where you won't be disturbed for five seconds. Town portals are the same. 

There's a new lineup of classes, of course, with the only one held over from Diablo II being the Barbarian. There's also the Monk from the original; all classes can be played as either male or female. Your stash, as opposed to being per-character, is now global (transferring items between characters is as simple as putting it in the stash, and then switching over.) So far, I've a Barbarian and a Demon Hunter (roughly equivalent to the Amazon in Diablo II.) Only one class (the Witch Doctor) has Mana; the other classes have class-specific energy reserves which are replenished or charged up in similar ways. At that, there's also no longer Mana Potions. 

Health potions have a cooldown rate - after using one, you're locked from using another for some 30 seconds or so. That's not always a problem, as many monsters drop health orbs, which instantly give you and your mercenary health as they are picked up. Also, health orbs and gold need not be clicked - simply run over either, and your character picks it up. (Imagine how useful that would have been in Diablo II, say, in the Forgotten Tower?) 

There's a few things to be disliked. One, you must register your CD-Key with you Battle.net account, making it pretty much impossible to give the game away afterwards. Two, there is NO offline mode. You must be constantly connected to the Internet to play at all. Adding friends is a two-way process, like on Facebook, and friends can hop into your games at any time - if you want to go solo, they can interrupt and there's not anything you can do about it, aside from leaving the game. The lack of an offline mode is real simple: It's meant to protect the Real Money Auction House, where in-game items can be bought and sold with *gasp*, you guessed it, real money!

The chat system is carried over from World of Warcraft, which isn't all that bad, aside from the help command for chat showing you some chat commands that only work in World of Warcraft. StarCraft II also uses the same chat system, but not as much of it (Diablo III literally has the same floating chatbox, scroll buttons, behaviours, and font as World of Warcraft. Brand identity, I guess.) You can add friends who play StarCraft II or World of Warcraft, and chat with them in-game from Diablo III.

That pretty much summarizes my thoughts. So here's some screenshots of the game, some of which were intended to be used to report bugs to Blizzard. Enjoy!

Note: Click on a screenshot to see it in larger detail.

Bypassing Gmail's Executable Attachment Restriction

A few hours ago I tried to download a build of a program that was uploaded to uploaded.to, except that with the recent shutdown of MegaUpload, uploaded.to has ceased all dealings with anyone whose IP address originates in the United States of America.

So I had a friend overseas download the program and tried to send it to me, except for the fact that Gmail doesn't allow executable attachments, among others.

So, me and my buddy overseas cooked up an idea to bypass this. What if we just dropped the .exe extension and also used a simple XOR cipher to encrypt the data? Using a key of 0xFF, I came up with this program (after a few bug-fixing revisions, click for larger view):

The source is freely available on the text-snipplet site, Pastebin.com. View the source (updated 2012-01-27 01:32)

Computings

First off, Happy New Year 2012!

Secondly, Portmaster for FreeBSD is funny. Let me just demonstrate:

===>>> Proceed? y/n [y] yes

        ===>>> yes is not a valid response

===>>> Proceed? y/n [y]

I'm not sure if it's a bug or not, but it still makes me laugh. :)

Why comments on Android Market apps are mostly useless.

I've noticed that the rating and comment system on Android Market is mostly useless; it is full of pointless posts. An example of a pointless post would be something like "great app". Just "great app". Shit, people, they give you the ability to rate between 1 and 5 stars; the overall rating should be a reflection on whether or not an app is great. Saying it is great, on top of that, is outright redundant, and helps no one. Worse, is that you'll find dozens of such comments on an app listing. I honestly don't want to scroll through a page of "great app!" "five stars!" comments to find a comment that is actually useful.

More useless commentary comes in the form of "App does not work on [insert device here]". The comments list is not meant as a way to send feedback to the app developer. It is meant to convey your opinion to other (potential) users of the app. When you post a review comment saying "Please fix!", you are NOT saying that to the developer. You are instead saying that to other users like yourself.

Speaking of developers, do any of these users have any idea of the process of developing an application? Or testing one, for that matter? Fixing bugs? Developers are human. They aren't perfect, and on occasion, they make mistakes. And, like humans, they don't know everything. Just because you know how to program, does not necessarily mean you could write a program to identify a person by voice, especially if you know nothing about sound from a scientific perspective.

A lot of apps on the Android Market are developed by one-man shows. When I see comments like "Everyone post a complaint so that it gets fixed faster", I want to reach through my phone and strangle the pinhead that wrote that. First of all, as I have said, the comments system is not meant for communicating with developers, and as such, many developers do not read the comments. Developers usually leave an email address, and maybe a phone number as well, that are at the bottom of the app's Market page.

Users that rate an app down because it doesn't work on their particular phone aren't doing anything to help the developers get the app working on the phone. There are well over a thousand different models of Android devices; while a developer can try their damnest to make their app work on as many as possible, they cannot foresee every issue that will arise on every device, and most of them cannot afford to buy one of every Android device.

Some Diablo II Screenshots

Someone showed me some items on Diablo II that made me shit myself... here's the screenies (click image to enlarge):

Oh, and here's one where Wine buggered up (and you now see that I play Diablo II in Wine, on Linux, Ubuntu 11.04 to be exact):

Microkernels vs. Monolitic kernels - What's The Difference?

I was recently asked to explain the differences between a monolithic kernel and a microkernel. Here I will discuss the pros and cons of both. I neither advocate one or the other, so those of you who are looking for support in your holy war (yes, that means you, Andrew Tanenbaum).

To start things off, let's discuss monolithic kernels.

A monolithic kernel is the traditional kernel of the days of ole. All the drivers and system services exist in one big binary blob, sharing code and data.

Now, the pros and cons of this are:

• Pros: Code runs much faster. Most, if not all, system services run in kernel mode, so there is no need to perform costly context switches between user mode and kernel mode. Only two context switches are needed for most syscalls, one from user to kernel on invocation of the syscall, and another context switch from kernel mode back to user mode on syscall return.
  
• Cons: Bugs in the kernel have a high chance of bringing the entire system down. Also, some kernels must be recompiled to add or remove drivers.

Common systems with a monolithic kernel would be Linux and FreeBSD. Note, however, that more specifically, these systems have a modular kernel, that is, a monolithic kernel that supports having parts of it loaded sometime after kernel boot, and possibly also removed as well. Also note that it is also possible to configure the Linux and FreeBSD kernels to be fully monolithic, without module support.

Microkernels, on the other hand, only have a very small portion of their code that runs in kernel mode, that is, has unfettered access to the full system hardware. For the most part, the portion that runs in kernel mode is a mere message marshalling system. All other system services, such as the filesystem, network stack, tty driver, etc., all run as user mode daemons known as "servers".

The pros and cons of this approach is this:

• Pros: If a bug crops up in a system service, and crashes that service, it is very unlikely that the system will crash with it. Usually, the system will merely restart the service. Depending on the system, there might be slight side effects from the service crash. For example, if the network stack crashes, applications might find all of a sudden that their socket handles are all now invalid. Sometimes, this can be made transparent to the applications, e.g. if the filesystem driver crashes, the libc could transparently detect this and reopen all file handles that were made invalid in the crash. Also, adding new drivers and system services to the system is as simple as starting the respective servers for them.
  
• Cons: Your system runs terribly slower than a monolithic kernel. A write() syscall to a tty, for example, will go to the filesystem driver first (as /dev/tty is filesystem), and then the file system driver would then call upon the teletype driver, and so on and so forth. It may take hundreds, if not thousands of messages to complete one traditional syscall, each message requiring two context switches each, one to kernel mode and one back, and each context switch may take thousands of CPU cycles to complete.

Common examples of microkernel-based operating systems include QNX and Minix. Note that QNX's microkernel architecture is advanced enough to allow network-transparent message passing - allowing you to, for example, directly access hardware in another machine as if the hardware was in your own, much akin to Plan 9.

In short, each type of kernel has it's advantages and drawbacks. I am not trying to say that one is better than the other, or anything like that, but each one has it's merits, and I leave it up to the reader to determine which is better for any given situation.