The move to typo 4.0

Typo is my blogging software. Written in Ruby on Rails, it seemed like an ideal choice for me since I’m a big fan of the RoR movement. But like so many other open source applications, Typo has got some major problems. I’m not going to say another open source blog would have been better (though I suspect this is true from other pages I’ve found on the net), but Typo has been a major pain in the ass to upgrade.

For anybody who has to deal with this issue, I figure I’ll give a nice account here.

First, the upgrade tool is broken. If you have an old version of typo that has migrations numbered 1 through 9 instead of 001 through 009, you get conflicts during the attempt at migrating to the newest DB format. You must first delete the old migrations, then run the installer:

rm /home/user/blog_directory/db/migrations/*
typo install /home/user/blog_directory

Now you will (hopefully) get to the tests. These will probably fail if, like me, your config/database.yml file is old and doesn’t use sqlite. Or hell, if it does use sqlite but your host doesn’t support that. Anyway, so far as I’m concerned the tests should be unnecessary by the time the Typo team releases a version of Typo to the public.

Next, if you have a version of typo that uses the components directory (back before plugins were available in Rails, I’m guessing), the upgrade tool does not remove it. This is a big deal, because some of the components that are auto-loaded conflict with the plugins, causing all sorts of stupid errors. That directory has to be nuked:

rm -rf /home/username/blog_directory/components

This solves a lot of issues. I mean, a lot. If you’re getting errors about the “controller” method not being found for the CategorySidebar object, this is likely due to the components directory.

Another little quirk is that when Typo installs, it replaces the old vendor/rails directory with the newest Rails code. But it does not remove the old code! This is potentially problematic, as I ended up with a few dozen files in my vendor/rails tree that weren’t necessary, and may have caused some of my conflicts (I never was able to fully test this and now that I have things working, I’m just not interested). Very lame indeed. To fix this, kill your rails dir and re-checkout version 1.2.3:

rm -rf /home/username/blog_directory/vendor/rails
rake rails:freeze:edge TAG=rel_1-2-3

My final gripe was the lack of even a mention that older themes may not work. I had built a custom typo theme which used some custom views. But of course I didn’t know it was the theme until I spent a little time digging through the logs to figure out why things were still broken. Turned out my theme, based on the old Azure theme and some of the old view logic for displaying articles, was trying to hit code that no longer existed. Yes, my theme was using an old view and the old layout, both of which were hitting no-longer-existing code. But better API coding for backward compatibility would have made sense, since they did give you the option to use a theme to override views and layouts. Or at the very least, a warning would have been real nice. “Danger, danger, you aren’t using a built-in theme! Take the following precautions, blah blah blah, Jesus loves you.”

How do you fix the theme issue, though, if you can’t even log in to the blog to change it? Well, like all good programmers who are obsessively in love with databases, the typo team decided to store the config data in the database. And like all bad open-source programmers, they stored that data in an amazingly stupid way. I like yaml, don’t get me wrong – it’s amazingly superior to that XML crap everybody wants to believe is useful. But in a database, storing data in yaml format seems just silly.

<rant>

PEOPLE, LISTEN UP, if you’re going to store config that’s totally and utterly NOT relational, do not use a relational database. It’s simple. Store the config file as a yaml file. If you are worried about the blog being able to write to this file, fine, store your data in the DB, but at least store it in a relational sort of way. Use a field for each config directive if they’re not likely to change a lot, or use a table that acts like a hash (one field for blogid, one for settingname, one for setting_value). But do something that is easy to deal with via SQL. Show me the SQL to set my theme from ‘nerdbucket’ to ‘azure’ please. When you can’t use your database in a simple, straightforward way, you’ve fracking messed up. Yes, there are exceptions to every rule, but this blog software is not one of them. It would not have been hard to store the data in a neutral format that would make editing specific settings easy.

</rant>

Sorry. Anyway, how to fix this – the database has a table called “blogs” that has a single record for my blog. This record stores the base url and a bunch of yaml for the site config. You edit the field “settings” in the blogs table, and change just the part that says “theme: blah” to “theme: azure”. If you don’t have access to a simple tool like phpmyadmin, then you’ll likely have to retrieve the value from your mysql prompt, edit it in the text editor of your choice, and then reset the whole thing, making sure to use newlines properly so as not to screw up the yaml format…. Then you are up and running and can worry about fixing the theme at your leisure.

Now, to be fair, I think I could have logged in to the admin area without fixing my theme, and then fixed it there. But with all the problems I was having, I thought it best to set the theme in the DB to see if that helped get the whole app up and running. Obviously it wasn’t the theme that was killing my admin abilities (and I can’t even remember anymore what it was). But once I hit that horrible config storage, my stupidity felt ever so much smarter compared to the person who designed typo’s DB.

Typo is pretty sweet when you don’t have to delve under the hood. But “little” things like that can make or break software, and I hope to <deity of your choice> that the next upgrade is a whole lot smoother.

UPDATE UPDATE HOORAY

One more awesome annoyance. It seems all my old blog articles are tagged as being formatted with “Markdown”. When I created them, I formatted them with “Textile”. If you’re not up on these two awesome formatting tools, take a look at a simple example (the first is how Textile appears when run through the Markdown formatter):

This “website”:http://www.nerdbucket.com is really sweet, dude!
This website is really sweet, dude!

I’ve been using Markdown lately as I kind of prefer it now. But my old articles are in Textile format. I don’t know why upgrading my fracking blog loses the chosen format, but boy is it fun going through old articles and fixing them!!

Digg this!

June 11, 2007June 27, 2007

How not to benchmark software

I’ve just stumbled upon an amazingly misinformed benchmark about Flex, from an actual Adobe employee, Matt Potter.

This guy benchmarks JSON, AMFPHP, and XML as ways to transmit data between PHP and a Flex app. His findings show that XML is generally faster than either JSON or AMFPHP. This “discovery” could revolutionize the way we send and receive data on the net! Who’d have thought that XML is so efficient? Truly amazing results!

But if we choose to drop back down to Earth from the blissful land of Ignoramia, we may find that even Adobe devs can make horrible mistakes.

So why is this year-old article worth dissecting? Simple – it comes up FIRST when you search google for “json flex”, which makes it a great tool of misinformation for people looking for ways to incorporate the awesomeness of JSON into flex! Note that if it were a random article that was at least moderately hard to find, I probably wouldn’t care too much.

So Matt Potter compares XML, AMFPHP, and JSON. His first and most amazing mistake is that he’s using raw XML, but converting data structures in PHP into JSON and AMFPHP. XML is expensive to create as well as to read, so skipping that step completely invalidates his article in my opinion. But worse still, he tests against a local server. The network overhead of XML is going to be significantly worse than JSON in most cases (no idea about AMFPHP as I’ve never used it), so ignoring the 2-3x bigger data really doesn’t do much for providing a valid test.

One of the comments also mentions that there’s a PHP extension for JSON that’s better than what Matt used, and Matt’s response: “I used the Zend Framework instead of the json php extension because I really think that the Zend Framework is the easiest to setup and use, and I have other examples of using the ZF that I’m going to publish”. So instead of looking for the best tool for the job, he went with the easiest tool. But for XML testing he went with the hardest but most efficient “tool”: manual creation of XML with no conversion from objects, no use of XML creation tools, nothing.

I dislike ignorance when one tries to present facts, but this article actually makes me suspicious that his intention was to “prove” XML was the best technology of the three, and was willing to manipulate data in any way necessary to provide evidence. It’s pretty despicable to have a position of influence (adobe employee) and abuse it to prove a totally BS point.

It should be noted that some of the comments, particularly Blaine McDonnell’s, ripped Matt apart better than I can. But when ignorance and/or deception rear their ugly head, it never hurts to point them out one last time.

June 4, 2007June 27, 2007

Bloodsport Colosseum Finished…

No, I don’t mean the programming is complete. I mean that I’m pretty much done working on it and it’ll live in its current state indefinitely. It’s fully playable of course, but it’s missing two or three features I would consider core, and has a bunch of stuff I wish weren’t there…. Unfortunately, however, I am finding that I just don’t have the drive to keep working on the game, as it is no longer anything like what I had planned to build.

I have other things I want to build, and this game has been in development for over two years now. If you count the PHP and Perl versions I had to scrap early on, a total of probably 750 hours have gone into it, and I just don’t have the free time to dump that much into a single game when I have so many other ideas I want to play with. Had it been a better game, I certainly would have kept working on it, but I just didn’t keep it focused on the main aspect of the game properly. For more info, read below as I dissect what I think are the biggest problems with BC. This is actually more for myself than anybody else, as I am hoping not to make the same mistakes in my next games.

What went wrong?

Poor Focus

Are you playing to build up an army of gladiators, or to build up the wealth and power of yourself, the manager? The answer is unfortunately both, and very strongly both.

My goal was a fantasy-sports-style game with gladiators. The gladiators themselves were expendable units. You could train them, equip them, whatever. But at the end of the day, you were merely supposed to be building a team to further yourself as a manager.

I don’t know how all fantasy sports games work, but the one I did play had very basic players that you controlled in a football (American) league. There were a few stats on each player, as far as passing, punting, blocking, etc. But for the most part it was about building a team that worked well together, and reading the game commentary each week to see how well you did.

Well, I got so wrapped up in the coolness of my RPG stats for gladiators that I made it cumbersome to manage them. Each gladiator needed several tabs to view all their details. The overview, which showed all the gladiators “at a glance” was unfortunately lacking enough information to really make meaningful choices. Add in all the ways weapons could modify a gladiator, and how different stats worked with equipment, and of course the ranks thrown in as a typical RPG leveling system, and you’ve got a lot of information to deal with.

In a game where you are the gladiator, this works out just fine, and in fact you’d probably want even more focus on stats and things. But when you’re just the manager, you find that managing your small team of 5 gladiators is a big pain.

Additionally, the focus being so split between gladiators and managers meant that building up your manager was never really emphasized. You had one stat, fame. It meant very little after about a month or two of play. You had money and equipment, but again, those meant nothing after a short amount of play.

No Team Spirit

This is sort of an extension of my lack of focus. In a fantasy sports football game, your team is a single unit. An injury in your quarterback means your whole team suffers, so you need to have a backup. Too much focus on speed and not enough on blocking, and your team is crap even though they have the best runners in the league.

In Bloodsport Colosseum, however, your “team” was a group that had no interaction except that they sometimes fought each other. That is totally not how a team in a fantasy sports game should act. It was essentially like managing a bunch of boxers, except that you couldn’t even properly choose matches because I didn’t want the players to be able to abuse the game (the computer chose matches each night).

If I’d done this as I meant to, your team would consist of at least 10 gladiators, and you’d need different specializations for your team to win. Or maybe not 10 gladiators, maybe fewer would be fine, but they would need to work together somehow.

Priorities

Tournaments should have been the first kind of match to exist. They were always on the list of things to do, but never made it to the top. Yet I think they make more sense than the green/blue arenas. Apocalypse matches were okay, but just too chaotic since I had no teaming mechanic.

Achievements should have been very high priority. You are managing a team of gladiators, and yet I never built in medals, trophies, or anything like that. While the effects on the game may have been minimal or none at all, the desire to be the best manager would have meant something! Comparing trophy cases, bragging about the elite “1000th kill” award, etc. Yes, eventually long-time players would grow bored of having every trophy available, but this would have at least made the manager a more tangible piece to the game.

Spending most of my time on gladiator stats and weapons was just a mistake. Complex gladiators aren’t necessarily a bad thing, but they shouldn’t be a burden. In a fantasy sports game, you might do basic training on your players, and you will likely choose some high-level organizational things (positions on the field and such), but you shouldn’t have to make several choices every single day on every gladiator in order to keep them working well. Having simpler stats, training, and equipment would have left a lot more time to do other things that should have been higher priority. Such as tournaments and achievements….

Manager stats should have been a priority, too. I had a plan to have managers gain specializations that helped out gladiators, with their own stats for attack, defense, money management, healing, whatever. After a certain amount of XP, you spend it to gain a new skill or something. This may not have worked well – it may have ended up being really confusing, in fact. But at least it was the right direction – focusing on the manager.

Fight logs sucked. They were just a bunch of “A hits B for X damage” kinds of messages. Making a robust combat engine should have been done before even going into closed beta testing. The fight engine was too simple, and it was one thing that could be complex as hell without confusing the player, since it was totally hands-off. Players should have been excited to see the fight log, to read a mini-story that was detailed and interesting, describing feints, parries, dismemberment (another dead idea), etc. Instead, it was always something I felt could wait until later.

Ideas For Next Time

I don’t know that there will be a new BC ever. But if there is, I have some ideas for it.

Gladiators will be much simpler. No levels (ranks), or if there are levels, they’ll represent experience without giving additional bonuses to stats and hit points. Gladiators will have different stats that represent more tangible abilities, like the derived stats do today. And your choice will be simpler – each stat will be set and never change. The choices will likely be word-based, such as “very weak”, “weak”, “average”, “strong”, and “very strong”. So you may have a gladiator who is “very strong” at Offense, “weak” at Defense, “average” at Speed, and “weak” at Toughness (hit points).
Recruiting stations will still exist in some form, but they won’t have such an effect on the gladiators. In all likelihood they’d have options that gave, at most, -1 or +1 boosts to specific stats, so that instead of all your stats averaging out to 3 (“average”), you may have them averaging 2.5 – 3.5.
Your gladiators will work as a team by default. Maybe I’ll still allow one-on-one challenges, but I’m not sure I like how challenges ended up working in BC. I definitely didn’t like the arena choices, as I couldn’t explain them well to people, they required you to choose an arena for every gladiator, and they made the system have to be out of sync in order to have pre-scheduled battles. It was just confusing – a simpler approach of setting your team in a league or something would be more interesting as well as more user-friendly, I think.
Training will be simple or nonexistent. Skills will be simple or nonexistent. If they’re included, skills will surely be complex behind the scenes, such as the combat training value is today, but the player won’t see it or have to deal with it. He’ll just see that a gladiator has a certain amount of experience with bladed weapons. When training happens, it’ll be a long-term thing. You set John Doe to train blades, and he’ll train every day until you change this preference. He’ll move up through 3 or 4 ranks of training, Basic, Advanced, and Expert or something. These will modify him in some way that will make fight logs more interesting, such as being able to parry or riposte where he previously couldn’t. Battle experience will affect attack chance and perhaps damage, while training will affect “moves” available. And it’ll all be something the player notices only passively, so it’s interesting but not cumbersome.
Gladiators will not have scarring. They’ll have critical injuries which require time out in order to heal (which of course should affect the team as a whole). They may lose limbs. They may die. The player won’t have much say in this at all, other than perhaps choosing an overall team strategy that’s risky. Gladiators missing limbs will almost certainly need to be retired, but mid-season it may be better to leave a one-armed gladiator in, if his experience and training are really good.
Equipment will be simple again. Simpler even than what I had when I first showed BC to the public. There will be a few choices for each group of weapons, and they’ll be very simple choices. Maybe 3 weapons per group, with maybe 3 levels of quality. And weapon damage would be the main stat, with a small modifier to speed. Some weapons would be better for parrying, perhaps, and blunt weapons would deal different damage than bladed (crushing limbs versus open wounds), but the player wouldn’t care about much other than damage and “oh, the sword will allow a parry more often, great.”
As I just alluded, there would be a little more in-depth combat damage. This would be added complexity to the backend, but not something that the players would ever have to pay attention to if they didn’t want to. The most important thing about adding complexity to this kind of game is to make sure the user doesn’t have extra micromanagement just for the sake of adding more to the game. Anyhow, the combat engine would be more sophisticated as I’ve stated, with things like parries, ripostes, sudden berserker-like rages, etc. But also, damage will be totally different. Hit points are great for a traditional RPG, especially one where the character is expected to survive many brutal battles. But in a game where the warriors are expendable, a much more interesting combat system should be looked into. I wouldn’t build a truly realistic system, otherwise most gladiators would die most of the time, but I would make it semi-realistic. Damage would be to specific body parts, death would usually be from blood loss or brain damage, etc. Hit points would exist perhaps on individual body parts to measure how useful they are, but they wouldn’t determine life left. For instance, if you destroy my arm, I can’t use it in battle anymore, but further hits to that arm don’t really do much to me – it’s probably already bleeding as much as it can.
As I stated above, the manager would be the focus. Players would be in the role of a manager, and would have more choices about their management than about the gladiators. Perhaps they’ll be able to gain experience, but no matter what mechanism I choose to deal with manager persistence, there would be ways to carry over something no matter how many seasons a manager played. A long-term player should be able to show trophies, medals, and other awards. There should be all kinds of random “top player” lists, showing obvious achievements like kills, wins, KOs, etc. Special awards would have to exist that players wouldn’t even know about until they won one, such as an award for crippling a large number of opponents. Maybe allow managers a long-term inventory of manager-specific “artifacts”, which would give minor boosts to his gladiators in addition to his own experience. Overall a long-time player shouldn’t be able to easily crush every n00b he encounters (although separate leagues for the newest players could alleviate this some), but he should have a small advantage for sure.

May 11, 2007June 28, 2007

Yet another Awesome Software Discovery!

This time it’s a piece of javascript to compute ideal body weight in a variety of ways, the most interesting of which claims to tell you what other people like you consider their ideal body weight. Very “slick” little system, if you care about such things.

I’m always on the lookout for crazy new technology, so when I found this “ideal weight calculator”:http://www.halls.md/ideal-weight/body.htm, I was overjoyed by how many different algorithms seemed to be present. When I looked at the source and found that the author was using javascript, I was again very excited. This meant I could look at (and possibly learn) his algorithms!

And so here they are: “javascript source for calculating ideal weight”:http://www.halls.md/ideal-weight/body2.js.

But read the copyright message with me and bask in the author’s sheer genius! Clearly he (or maybe she? No idea, don’t care) considers the algorithms to be proprietary and will MESS YOU UP if you steal them! So I guess I won’t bother to learn them. Hell, merely looking at them is probably illegal.

So aside from the author’s painful arrogance and stupidity, what can we learn about him from this script? Simple – he thinks he’s some sort of omniscient deity (don’t mess with me lest I strike ye down, mortal! And I will know if you try: “you won’t get away with copying this code”), and yet he doesn’t have even the tiniest iota of smarts when it comes to securing what he claims is “truly my unique creation and algorithms”.

O, Great and Wonderful Physican (yes, that’s right kids, he points out to all us lesser mortals that he’s a god damn physician!), I beseech thee! A bit of simple and kind advice for you: if you want an algorithm to be protected, don’t publish it on the web. In un-obfuscated javascript no less. Obfuscation isn’t bulletproof, not by a long shot, but it’s better than nothing.

And really, go for a server-side approach if you’re as paranoid as you seem to be. Once you use javascript, everybody who visits your site has copied it. This is not because they’re all thieves, but because of a little thing called the browser cache. Not only that, but anybody can view your proprietary algorithm and rewrite it. Copyright it all you want, a rewritten version of the algorithm is going to be COMPLETELY LEGAL! Copyrights only protect exact (or very nearly exact) duplication. You need a patent to protect an algorithm. For a basic description of the algorithm, read below. I was gonna rewrite it in javascript, but it’s really quite worthless, so explaining it should piss off our good doctor well enough.

The good news is that his script is so mundane and, dare I say it, not unique – most of the script is other people’s work on pretty standard formulas. Why, you ask, is this good news? Because he doesn’t actually need to worry about people stealing it!

His “secret formula” is well worth discussion, however:

You go to the site. You put in your height and weight. His script uses a very standard formula to calculate BMI. His “people’s choice” code then cuts BMI down by 40% or 50% (gender determines this) and then adds a gender-specific value (11.5 for men, 11 + age x 0.03 for women). Then reversing the very standard BMI calculation gives you what other people supposedly consider to be an ideal weight!

That’s right, a simple algorithm that tells you what other people just like you consider ideal! But because of the simplicity of the script, it gets worse – say you’re a 440 pound, 5’6″ adult male. According to this brilliant physician, the average person that height, weight, age, and gender think that 291 pounds is their ideal weight! That’s right, little ones. If you’re extremely obese, your beliefs of what is and isn’t an ideal weight become so skewed that you think being slightly less obese (but still very obese) is “ideal”. Funnier still, of course, is that as your weight changes, so will your ideal. So once our example 440lb guy gets down to 400, he thinks his ideal is 271lbs. Doesn’t matter if it takes him a month or fifteen years to drop 40lbs, his new ideal is still going to be 271.

BUT WAIT, THERE’S MORE! When you’re not an adult, the script tells you that your peers consider your desired weight to be something that is based entirely on height and weight! So the average 440 pound, 5’6″, 18-year-old male longs to weigh 131 pounds. The moment he’s older than 18.5 (no idea where the doc pulled these numbers from), he longs to weigh 291. Yup. One day he goes to sleep hoping to be in a healthy weight range, then he wakes up thinking he was wrong, and should in fact weigh more than twice his original goal.

Arrogance, stupidity, bad programming, and then weird assumptions followed by even more stupidity. This is possibly my best Awesome Software Discovery yet!

January 26, 2007July 12, 2007

Arch Reality gives spammers the edge

On the heels of my amazing discovery of the “PC Mesh Hide Files and Folders“:http://blog.nerdbucket.com/articles/2007/01/15/revolutionary-new-software software, I make yet another Awesome Software Discovery: “jcap”:http://www.archreality.com/jcap/!

CAPTCHA(Completely Automated Public Turing test to tell Computers and Humans Apart) technology is always trying to keep ahead of spam / bot technology. This is just another techno-arms race that will probably never end. But this company, “Arch Reality”:http://www.archreality.com, has devised a “clever” image-based CAPTCHA that is 100% javascript.

This Awesome Software Discovery is “special” because it may be the only CAPTCHA system that is run in the client’s browser exclusively. In most cases, you have to have server scripting (PHP, Ruby, Perl, ASP, etc) to process CAPTCHA information, which is a bit of a pain. You have to maintain state information to know that user X was shown picture Y and such. But with this system, All you need is a client running javascript! How awesome is that? Super easy to set up, even for a web novice.

Spammers, beware! As long as we have people like Arch Reality working on our side, your days are numbered!

…or are they?

Well, this is one of those theoretically sound ideas. Much like Communism and pyramid schemes. Any web programmer will notice very quickly that this is total BS. How do spammers operate? Do they single-handedly man a thousand computers simultaneously, working feverishly to send out their spam? NO. They automate everything they can. And let me tell you, when you automate something like a web-based form submission, the last thing you want to bother with is figuring out some javascript! So what do the spammers do? They fracking ignore it! Which leads us to a CAPTCHA that actually verifies that people who have a javascript-enabled browser are, in fact, real people. WOW.

This one blows my mind. PC Mesh has a pretty crappy concept, but these folks really take the cake! Arch Reality’s only saving grace is the disclaimer that came over a year after jcap’s release:

***NOTICE (01.10.2006): The developer assumes no liability with this resource and it is provided as is. This script is referred to as a “security development” because it can provide some minimal level of security. While it does seem to be an effective elementary form of security the developer does not claim that it is an impenetrable solution and thus the developer does not recommend implementing it for the protection of highly sensitive data.

And to me, even that disclaimer is full of crap. Their product will provide literally no security. If you want proof, hit their “demo page”:http://www.archreality.com/jcap/captcha.html, then disable javascript, then type ANYTHING YOU WANT, and click Submit.

Just like a JavaScript-ignoring bot, you too can break through this so-called security development with ease! I’d like to know where they got the idea that this garbage would be “effective” at anything other than pissing off clients! Almost makes me think Arch Reality is working for the spammers….

I’ve done a small amount of digging, and sadly there are people out there who use this product, and think it provides some measure of security. This kind of ignorance is so easily avoided if the people who write software would spend the half hour to research the actual problem they’re trying to solve.

If I can reach just one person, and that person keeps from hiring these horribly untalented hacks, I’ll feel this blog post was more than worthwhile.

January 15, 2007July 12, 2007

Revolutionary new software!

There is a company out on the fringes of technology. Making software that most of us only dream of being able to write. Scoffing at the current obsolete methodologies and practices, these brave new developers have recently pioneered an awesome new era in software development.

This software company is clearly just another one of your typical geniuses not recognized in their time, as the very unscrupulous “CNet / Downloads.com”:http://www.download.com/PC-Mesh/3260-20_4-6263078.html reviews have been far too harsh on this enterprising company.

“PC Mesh”:http://www.pcmesh.com is, of course, the company to which I refer. It is with the most sincere amazement I discovered this little gem of a company today. Or more specifically, the discovery was their “Hide Files and Folders”:http://www.pcmesh.com/hide-files-folders.htm software.

How can I make these claims about this company? Well, for starters, their web site tells us all we need to know: PCMesh Hide Files and Folders is a revolutionary new software product…. But I’m not an idiot – I know to do my homework and not take everything at face value, even a statement so indisputable as that one. So how do we know these guys are the real deal? I’ll go through their feature list, item by item, and explain just how brilliant they are. Some of what you’re about to read may be difficult to accept, but keep in mind that true brilliance will often challenge that which we have been taught to believe, and that challenge can sometimes be difficult to accept. Now, on with the -propaganda bashing- product highlights: * Invisible from the operating system, invisible from virus attack and invisible from spying eyes that won’t even know the cloaked files or directories are present. ** Wow. Just… wow. Okay, invisible files are protected from virus attack and spies. Humans won’t know to look for cloaking software, of course, because this concept is totally new and unique, and even now that it’s out, unauthorized people would never dream of doing research to learn of this exciting new software. As for viruses, yeah, they can’t infect what they can’t find. Too bad most people want to hide data files, not fracking executables. And too bad that when you make those files visible, a virus will then see the OS reading the files and infect them. And too bad a smart virus could easily be written to infect this POS program in such a way as to destroy the data as you try and make it visible. But other than that, yeah, this software is amazingly effective. * Encrypted files are still visible on the hard drive. This makes them vulnerable to attack from anyone who is interested enough in the content of the files to spend time trying to decipher them. And with more and more hackers intent on defeating modern encryption algorithms, a need exists for a better type of protection. ** In fact, this may be the only statement that’s partially true. Granted, most encryption today is nearly unbreakable, especially for home computers that don’t house highly-sensitive data, but otherwise this isn’t a “bad” thing to say. Better encryption standards are always a good thing. Questioning the strength of today’s encryption is certainly a worthy goal. Course, I’m not sure where they got the idea that “more and more hackers” are are intent on defeating modern encryption algorithms. Haven’t droves of hackers (and security specialists and general security enthusiasts) always been interested in defeating encryption algorithms? Without those people, we’d all still be using Caeser Shift Ciphers! * In addition to rapidly becoming obsolete, current encryption programs are slow. ** Rapidly becoming obsolete? Gosh, even the encryption algorithms that are considered to be broken are still pretty strong for the average computer user’s needs. And anybody with data so sensitive that it needs unbreakable encryption can probably deal with the fact that they need to update encryption methods every few years. * It takes as long as 10 minutes per 200 MB to encrypt or decrypt a file, while PCMesh Hide Files and Folders executes instantly regardless of the file size or number of files/folders being protected. Just one click is all it takes to render any file or directory invisible. ** Okay, I don’t know much about encryption speeds. I have to be honest, this could be completely true for a really awesome encryption algorithm. So let’s say they have two semi-true statements. Let’s note here that this software “executes instantly”, which means to me it flags files in some way (prefixing them with $sys$, perhaps?), and doesn’t do any kind of encryption. * Data that’s protected by PCMesh Hide Files and Folders is not visible, so it can’t be attacked. In fact, the software itself does not even run continually, so it does not announce its presence to snoopers and hackers. The only time the software is active is when it’s being used to hide or reveal protected files or directories. ** This statement (or series of statements) is so ridiculous I am amazed. “Security through obscurity”:http://en.wikipedia.org/wiki/Securitythroughobscurity is just plain stupid. If an attacker simply finds out about this garbage software, they’ll know to attack the “invisible” files. And since the files are still on the system, there is no way to truly make them hidden – if this software can get to them, so can an attacker. Worse, the authors actually believed that an attacker will need something continually running in order to realize what’s going on. I imagine PCMesh is populated by people who’ve never even read a single article on security, encryption, or hacking. If hackers had no access to the internet and didn’t know how to research new “protection” schemes, they really wouldn’t ever be a threat. * Better Than Encryption ** Though this is higher on the page than the last few items (its their header in fact), I thought I’d mention it here just after the security bit, to point out how absurd the claim is. Obscurity is /never/ better than encryption for sensitive files. It’s only better than encryption when it comes to files you don’t need strong protection on, and situations where you just want to keep the honest people honest. Nobody can currently break AES, but just spending some time hacking through this product’s disassembly (after unpacking their undoubtedly “proprietary” packed executable) would probably reveal how to find the “hidden” files. Though I suspect it’ll turn out to be similar to the “Sony rootkit”:http://en.wikipedia.org/wiki/2005SonyBMGCDcopyprotectionscandal BS from 2005. * Hide files or folders of any size instantly. There is no processing time. ** Most of the bullet point “highlights” are just repetitive crap from the “Better Than Encryption” section of this website. But this one struck me as funny. It’s really no big deal; it’s just that with computers (and pretty much anything), there’s no such thing as “no processing time”. I dunno, I’m picky, shut up.

So clearly this product kicks ASS. Go out and buy it today.