Support for older Intel Graphics Chipsets in Lucid Lynx

For those having trouble getting Intel Brookdale G [82845G/GL] and similar chipsets to work on Ubuntu 10.04, I have good news. The Ubuntu Wiki has a page containing workarounds and fixes for the issue. My preferred choice right now is to install the backported Maverick kernel. This is also good news, because Ubuntu 10.10 should be expected to work on these machines without adjustment. Of course, if you just want the system to work with basic office-style functionality, VESA mode is a good alternative, but it will disable accelerated video.

Linux can do this

Nuff said.

Tutorial on making colored maps

This Tutorial uses a Python script and free SVG maps to make maps based on csv data files! I know what I'm going to be doing tonight when I get off work!

How to make a US county thematic map using free tools [flowingdata.com]



Edit:
Michael made his own version of the same map following the tutorial! Here it is:

Video, State of Free Software

Listen to this video of Eben Moglen's presentation on the State of Free Software.

Oregon's E-Cycle program flawed

We are required by law to print the following three lines on receipts for purchases of new computers or monitors, or to distribute one of several graphical alternatives:

Oregon E-Cycles: Free Recycling
for Computers, Monitors and TVs
www.oregonecycles.org 1-888-5-ECYCLE

Unfortunately, the Oregon E-Cycles program is seriously flawed and could hurt the freedom of the economy and the freedom of choice of consumers. Don't get me wrong. I support and encourage recycling and care for the environment, but this law over-reaches its purpose. The e-cycle website states: "Only those brands listed as pending or compliant may be sold in or into Oregon. If a brand is not listed, it may not be sold. Sales restrictions apply to all types of sales including retail, catalog, phone and Internet sales."

The DEQ decides the fee that a particular manufacturer must pay to register. If they don't pay up, they aren't allowed to sell their product [legally] in Oregon. DEQ determines the fee based on statistical information which they acquire in order to determine the market share held by the brand in question. They start with national statistics and adjust it based on a limited amount of local statistics. The minimum fee right now is $40. If a brand has more than 0.01% market share based upon DEQ's manipulated statistics, the fee goes up to $200. For brands with more than 1%, the fee is $15,000, which is the amount they are apparently collecting from prominent national manufacturers such as Dell and HP-Compaq.

Imagine if every state implemented an identical program. Dell would have to pay three quarters of a million dollars every year just to be an authorized manufacturer, and that money does not go towards recycling. The manufacturers pay for the recycling fees themselves. A little shop that assembles generic computers would have to pay a combined $2000 to all fifty states, which might be more than they make in computer sales during the year, especially if new computer sales is not their main line of business.

This is, of course, a bad scenario. It is unlikely that all fifty states would demand payment from a vendor. The states would have to become aware of that brand being imported into their state before they would likely make such a demand, and even so, is it enforceable if another state demands that you pay them a fee just because someone carried your product across state lines?

Also, what's to say that a particular state can't raise the rates or file you in a higher market-share tier in order to pressure you out of the business. If I was a vendor in another state, and Oregon DEQ contacted me, I would be tempted to simply disable shipping to Oregon on my website, and place a warning label on my packaging saying that the product may not be imported into Oregon by the original owner--that's right! Used and refurbished equipment is exempt from the program.

Here's the bad part of the law: Oregon is shooting itself in the foot because it is trying to force manufacturers around the world to comply with its fees, which could reduce the choice that customers living in Oregon have on what they may purchase. Someone will have to set up a company just across the border that will purchase a new computer for you from a non-compliant manufacturer, then resell it to you as used equipment.

Frankly, I shouldn't have to pay fees to any other states, and other companies shouldn't have to pay fees to my state. No taxation without representation! If the states want to have purchasers pay fees because they purchased a computer or monitor, then the state should include this on the tax forms for their own residents.

Now, from the retailer point of view. Other than my purchasing options being limited by a list of brands put out by DEQ, which is quite disturbing, I also notice that I had the choice of using the three lines shown above on my receipts, or including one of the other printed materials of which there is a wide variety. The problem? All the materials are in color, and the section on logos specifically says that if you need alternate format logos including B&W that you must contact DEQ manually to request it. Why would a recycle program require me to print in color? They must want me to recycle my cyan and yellow toner cartridges on my laser printer more often. Well, I opted for the three lines instead to conserve toner, and to avoid showing the logo of this program which I detest.

Think about how much time and money is wasted handling all the extra paperwork, calculating annual market share reports, and certifying manufacturers. This process needs to stop.

If you too find this law to be over-reaching and limiting of your freedom, or believe that it does not serve the interests of recycling or caring for the environment, please contact your state senators and let them know that the flaws of this program need to be exposed so that action may begin to correct it and implement proper recycling legislation in its place.

Response to .DOC Attachment

What do you do when you receive an email file attachment in Microsoft's .DOC format? Sure, we could open it in OpenOffice.org and go about our business, but there's no guarantee that this will remain true for future versions of .DOC. Use of proprietary formats are a danger to interoperability and to future innovation. One good thing to do is to reply to the email and explain why they should send the attachment in a standard format. I've seen several canned email responses in the past, but most are too brief to explain the issue, or too harsh in their wording to satisfy my tastes. I was prompted to write a response after receiving such an email attachment today, and I have combined some of the best ideas from elsewhere and added some of my own. Here is what I would recommend:

The document you have sent was not saved in an accepted format for Internet mail.

It was saved in a proprietary format that is unreadable on several types of computers because the method for decoding the document is kept secret by Microsoft and is purposefully changed with each new release of Microsoft Word so that existing users of Microsoft Word will be forced to pay for expensive upgrades in order to continue to read Word Documents sent by others. For example, in 2010, Microsoft Office Home & Business 2010 was priced at $279.99, and Microsoft Office Professional 2010 was priced at $499.99.

Recent versions of Word have started using a newer, patented OOXML format. In many countries, it is actually illegal for other products to decipher this format. This is a lock-in technique used by Microsoft to maintain their monopoly on Office software, and by extension, their monopoly on the operating system market, since they have not released a cross-platform version of Microsoft Office compatible with other operating systems.

In most cases, the size of the file saved in Microsoft's secret, proprietary format is also substantially larger than a standards compliant file containing the same information and the same formatting.

It is also important to note that Microsoft Word documents are often infected with viruses. Excel, Access, and Power Point files are also vulnerable to infection. This potential for infection is largely due to the Macro language and the "Visual Basic for Applications" language which are built into the format to provide powerful programming capabilities. While powerful, these features were not protected with proper security precautions, and the majority of users do not actually use these features or even know that they exist.

What to do instead:

If you continue to use Microsoft Word, please have the courtesy to “Save As” one of the following formats: ODT (if available), DOS Text, HTML, or Portable Document Format (PDF) and after saving, send the resulting file as an attachment.

Alternatively, you could use a product such as AbiWord, KOffice, Google Docs, NeoOffice, or OpenOffice.org that allows you to save your document in the Open Document Text Format (ODT), which is an ISO/IEC International Standard, and is supported by such notable companies as Apple, Adobe, Google, IBM, Intel, Nokia, Novell, and Sun Microsystems. If you don't have one of these programs, I would recommend OpenOffice.org, which may be downloaded free of charge and used for any purpose, personal or commercial.

A third option is to simply type your message directly into mail (instead of typing into Microsoft Outlook or Microsoft Word) so that you won't need to use an attachment at all.

In the highly unlikely event that your document cannot be converted to an open, non-proprietary format, consider printing it and mailing it by post, or scanning it, and sending it in a standard graphic format such as PNG or JPG.

Thank you.

Open Database Conventions

I've been using a set of database table and field naming conventions and related standards that have been gradually adopted and refined over the last 10 years. I decided today that it would be a good idea to share these with others, particularly because I decided to bring Jim from UVOG in on a database project I'm starting on. I realized that sharing them with others on an even wider scale might be a good thing on the off-chance that, if someone else out there adopts them, and if our code ever ends up crossing paths, we will gain greater interoperability and understanding on account of using the same techniques.

Feel free to take some or all of these ideas and implement them in your own projects. I am willing to hear feedback and incorporate it back into the standard if you think there's a better way to do something that I've mentioned.

Some of these conventions will apply specifically to MySQL, while others will apply to the greater spectrum of databases. My experience spans MS Access, MS SQL Server, dBase, FoxPro, the Apollo Database Engine, and MySQL, with some very light experience in SQLite and PostgreSQL, but the bulk of my work today happens in MySQL.

Naming the Database

The name of the database itself is the least of my concerns. I would just recommend that in code that operates with or upon the database, this value should be easily configurable along with the hostname, port, and authentication credentials, so that any database could be selected.

Naming Tables

The name of a table should be a succinct name descriptive of what is to be represented by a single record in the table. If each record in the table represents an account, for example, name the table "account" (in the singular, all lowercase.) The reason we use singular forms is so that dot notation naming of fields makes sense when read out loud, for example, account.balance. There are many reasons we use all lowercase. Most production Database servers are case sensitive, and by using all lowercase we can eliminate the possibility of an error relating to case. It also improves code readability when SQL statements are written out with keywords and function names capitalized and with table and field names in lowercase.

There is a special case of naming in the event of a junction table. (A junction table is used to create a many-to-many relationship between two tables, and consists of nothing more than an id field, and foreign keys for the two tables whose records it is tying together.) The name of a junction table should be the name of the other two tables mashed together, with the name of the greater entity first. For example, if I have a company table and an customer table, and customers are potentially associated with multiple companies, I would name the junction table companyemployee, and it would contain id, kcompany, and kemployee, in that order. If there is a toss-up in determining which entity is "greater," place the two table names in alphabetical order.

Naming Fields

Always name your fields as though they are going to be used in dot notation. We want account.balance, not account.accountbalance, so do not redundantly repeat the table name within the field name. Avoid abbreviations that seem like a hack. For example, number is better than "no" or "num." Widely used abbreviations like ipaddress, ssn, or id are ok--be particularly careful to avoid expanding acronyms that are not expanded in common speech.

The Primary Key

In order to be properly maintained, every record needs to be addressable by a unique identifier. This identifier should not be meaningful in any real-world way for reasons that are explained in depth elsewhere, but I will give one brief example. If you were making an employee database, you might be tempted to use a person's SSN as the primary key for the employee table. Three years after the program is written, your company might hire someone who is in the country on a work visa, and therefore does not have an SSN, and now your system is broken. One will follow this line of thinking out and conclude that the key should be completely arbitrary and meaningless so that no such conflicting situation may ever occur. Additionally, for the sake of consistency, the primary key field in each table you make should be of the same name and type. I recommend naming the first field of each table "id", setting it to "auto_increment," and setting it to become the PRIMARY KEY index.

The value of this id field should be used internally for programming purposes and for describing relations between tables, but it should never be shown prominently to the user. If it is shown, it is merely for debugging or reference purposes. The number in this field, once generated, should not be changeable by the user, is not guaranteed to be sequential with the records around it, and is not guaranteed to fall into any range of values more specific than those allowed by an int (11) field.

Foreign Keys

A foreign key can be thought of as a "pointer" referring from the current record out to another record in another table (or possibly another record in the same table.) All foreign keys should be prefixed with the letter "k" (meaning key), and should either be named "parent" if the key is referring back to the same table for the purpose of producing a hierarchical system, or if referring to another table, it should be given the name of the table into which it points. If more than one key in a record must point to the same table for different purposes, the purpose should be appended to the name followed by an underscore. For example, kaddress_from and kaddress_to would be pointers to two records in the table named "address." The relation to one of them is described as "from" and the other as "to." This is the only time an underscore is permitted to be used in a field name, and the purpose of the underscore is to make the table name unambiguous.

When possible, try to put keys to parent records or records which are considered to "own" the current record near the top of the field listing, following just after id.

If these standards are followed for the primary key and foreign key fields, I could look up any reference using the following technique:

Given a field whose name begins with "k": Take everything in the field name following the "k" up to the end of the name, or up to (but not including) the first encountered underscore "_" character, and consider this to be the "lookup table name," if such a table exists. Retrieve the data by issuing a query in the form of:

SELECT * FROM [lookup table name] WHERE id = [value of the field]

Choosing Appropriate Data Types for Fields

Always choose the most restrictive type that can safely store the data, including valid values that you might not anticipate.

KEY FIELDS

For id fields or foreign key fields, use INT (11)

For boolean (yes/no or true/false) fields, use TINYINT (1) A value of zero means false, and any nonzero value means true. You can distinguish between individual nonzero values for record housekeeping if you wish, as long as others reading the data as merely true or false will not be under a misconception from not making such a distinction.

CURRENCY

For currency values less than a million dollars, use DECIMAL (8, 2) --- increase the first size by a sufficient number of digits if you need larger currency values.

NUMERIC DATA

For numeric data involving whole numbers or integers only, use INT (11) --- unless the size is astronomical, in which case, you will need to upgrade to a larger type.

For weights or non-integer quantities less than ten thousand, use DECIMAL (8, 4) --- increase the first size if values beyond ten thousand are needed, or both sizes if more precision than four decimal positions is needed. Four decimal places was chosen so that a number like 12.05% could be fully represented as 0.1205.

DATES AND TIMES

For date or time values or stamps where the "time part" has meaning (particularly in sorting), use the DATETIME type. A value of "0000-00-00 00:00:00" means not entered or unknown.

For date values where the time is irrelevant, use the DATE type. A value of "0000-00-00" means not entered or unknown.

MULTIPLE CHOICE

For multiple choice values: If there are a discrete number of choices presently and in the near future, few choices (about 8 or less), and little or no benefit would be had by allowing the user to customize the set of choices, an enumerated value may be used. Example: alignment ENUM ('left', 'right', 'center') DEFAULT 'left'

For multiple choice values where the choices are numerous or user defined or potentially user managed, a foreign key and a lookup table should be used instead of an enum.

STRINGS OF TEXT (NO MULTI-LINE VALUES)

For any string data: If the options are very well established, choose the smallest size category from the table below that can hold all possible values, or for data that is free-form, choose one category larger than you think is really necessary. I will give some example with each size category:

VARCHAR (4) -- A standard name suffix like Jr., Sr., II., III.

VARCHAR (8) -- Data known for certain to be less than or equal to 8 characters.

VARCHAR (16) -- A zip code. (Minimum to store a US zip code is presently 9 digits plus one hyphen.)

VARCHAR (24) -- A phone number, with decorations. The following number is 23 characters long, including spaces: +1 (541) 375-0448 x8888

VARCHAR (32) -- Product codes, SKU numbers, or generated numbers that are guaranteed to be less than or equal to 32 characters.

VARCHAR (48) -- A first(given) name by itself, or a last name(surname) by itself.

VARCHAR (64) -- A full name field (first and last name together.)

VARCHAR (128) -- An email address.

VARCHAR (248) -- A web address.

PARAGRAPHS OF TEXT, NOTES, MESSAGE CONTENT, CODE SNIPPETS

For anything multi-line, or potentially longer than 248 characters, use the TEXT type. If the data or text will be more than a couple of kilobytes, investigate the LONGTEXT type.

IMAGES OR BINARY FILES

I don't like big files taking up space in my InnoDB tables and slowing down my replication server. Instead, I store the original filename only (and only as a convenience) in a VARCHAR field, and then save the file separately named based upon the table name and record number the file is associated with. If I need to replicate these files, I let rsync take care of that. If the "attached" files MUST be synchronized with the other data in the record at any given moment, then it might be acceptable to resort to BLOB fields.

Order of Fields

When creating tables, the order of the fields really doesn't matter to the database engine. The sequence, therefore, should be chosen for purposes of clarity in documentation.

Well, that's all I have for now. Have at it, tear it up, and send me suggestions.