WARNING: Some of the suggestions below will void your guitar’s and parts’ warranty. Use discretion. Employ a guitar technician if you get out of your depth.
Many guitarists find themselves in this situation: they end-up with a guitar that is simply too dark, sometimes so dark it’s muddy. This is often the result of inexperienced or beginner guitarists buying badly built, or badly setup guitars, or it can happen during your (seldom ending) quest for Tone. The Tone.
They are the same as Seymour Duncan humbucker conductor color codes, as seen in Dean’s scarce pickup wiring instructions, and Seymour Duncan’s pickup color codes comparison chart.
I’m talking 4-wire conductor humbucker pickups.
For better or worse, it has come to this. I used your operating systems because I had to – everyone was developing for your sick platforms. “You don’t like it? Switch to Linux.” I would, MS, I really would, if the other players would just develop the software I use for Linux. Till then I’m stuck with you. I even learned to love your idiosyncratic way of doing things.
But it is now, when my high end computer (2.1 GHz dual-core processor, 3.5 GB of RAM) streaming HD internet video on a 22 MB/s pipe can’t play 1080p without choking, that I whole-heartedly issue “Fuck you, fuck you Microsoft, fuck you, you fucking piece of shit bastard company.” Fuck your fucked up DPC system, fuck your idiotic driver model, fuck everything about you that renders top-of-the-line hardware obsolete while still fresh from the assembly line. Fuck you. Fuck you, do you hear?
My two year old shitty Creative headset finally gave in, after going through a “mono period” (yes, I had to rewire it following breakage of the right driver, and it came out nice, but mono). It was a mic-headphones combo one would use for instant messaging and some gaming, but would be ashamed to admit to actually listening to music through it. May it RIP.
The audiophile and amateur musician within myself organized a subsequent inner insurrection, demanding that I buy them a pair o decent headsets, once in this lifetime, for God’s sake! Naturally, I set my mind on a pair of Audio Technica ATH-M50 studio monitors, thinking they would be great for my mini-studio, also. Well, they most certainly would. Just two things: they can barely be called portable, and they’re rather expensive (over £130).
Hashing provides one-way encryption. This means there is absolutely no way of recovering the original string that was hashed, from the hash string. Hashing has a significant ammount of mathematical theory behind it, most of which you needn’t know. However, I encourage you to have a read of the relevant Wikipedia articles.
Hashes are used for two main purposes:
- to uniquely identify some information: this is achieved by hashing that information into a string that is unique within the key-space of the hashing algorithm. This is how you can quickly compare two files, for instance – by hashing their contents, then comparing the hashes. If they match, the files are identical. With one caveat: collision risk, meaning that a certain (usually very small) percent of non-identical information will yield an identical hash. This is, apparently, mathematical inevitability, it is algorithm dependent, and can be used in attacks attempting to break the algorithm. With a strong enough hash algorithm, this should not be a concern for most problems.
- to obscure information: this is why we use them for password storage, where uniqueness is not the problem.
How to store passwords (of your website’s users), you wonder? There has never been a simpler question in website security, with such a straight forward answer:
Never-ever store passwords
Store hashes of your users’ passwords, never the passwords themselves. I don’t care if you plan on storing passwords in a file or in a database table, whether in plain-text (…yes, there have been cases, some notorious) or two-way encrypted. Forget all that. Just use good password hashes, always. Hashing is one-way encryption, meaning the result (hashed string) cannot ever be used to directly retrieve the original text, as opposed to two-way encryption, where the string can be decrypted back to the original, using the encryption key.
Your mighty user authentication mechanism, which you’ve spent countless hours developing and testing, and is now, theoretically, full-proof, will be rendered useless if you or your users choose to use weak passwords. Hence the need to enforce strong passwords.
Without going into to much explaining, what makes a weak password?
- password is short: the shorter the string, the easier to guess it, and the inherent drop in potential complexity only helps guessing: boob2 is a weak password.
- password contains common words: “dog”, “bread”, “bacon”, “concupiscence”, you name it. If the word can be found in a dictionary, it is a common word. Avoid l33t speak, too.
- password contains special words: the very user name, the name of the website/system where the password is being used
- one (upper or lower) case letters only: this automatically halves the potential complexity of the password string.
- no digits: there are no digits (0-9) in the password string.
- no special characters: there are no special characters (e.g., *^&£:]’) in the password string.
There are two main ways to implement security in a system. They should always be used together, for reasons that will become obvious.
Security through obscurity
This means keeping critical parts of the system you’re designing a secret. Keeping your code closed source, not disclosing the structure of your system, etc.. The extreme example would be keeping the domain name of your website a secret…
Where do I store my database credentials?
There comes a point, in security matters, when developers run into the age-old question: “Who was first? The chicken or the egg? Or the hen? Perhaps the fowl?”
You (your scripts) need an user name and password to access the database server. Where to securely store these? Yes, in a database table! What an elegant, secure solution! Oh, wait… You need an user name and password to access the database server in order to retrieve the user name and password required to access the database server.
The (generically titled) “system” directory of your website or web application should be the one containing all the scripts required for system administration, completely separated by all other files. To achieve maximum security in this regard, here are some important guideliness:
System directory name
- do not name the “system” directory “system”, or “admin”, or “root”, etc.. Instead, choose an unusual and cryptic name, and use a global variable in your code to hold this name. This way, the default “system” directory can me renamed and moved deeper into the file system, provided the global variable is hard-coded with the same value (eventually including the relative path). If you’re building a system that get’s deployed to others, teach the (future) admin to do this before going live.
- URL rewriting to access the “system” directory should only be used on top of the action described above.
- “system” directory name should not be made apparent to any visitor or registered user, except system administrators, who would get a link taking them to the admin interface located in this directory
- scripts running in the “system” directory (say, example.com/system_dir_name/some_settings.php) should display no direct outbound links (to other websites)! Reason being, the HTTP Referer header will contain the URL, compromising the secrecy of the “system” directory name.