So you’re a Linux enthusiast. You love Linux, and wish to spread the love to other computer users. “How exactly can I ensure that they be happy Linux users?” you ask yourself when thinking about people that are about to convert to Linux.

Well, there are serveral things that one must do to ensure that the newbie Linux user will have a smooth computing experience.

1) Make sure it’s a CD–and a LiveCD

Do not give them a DVD, USB key, or a printed bit of paper containing a large mass of 1′s and 0′s for them to install Linux with. Make sure it’s a CD. Why?

DVDs are bad in case the computer they want to install it on does not have DVD reading capabilities. Remember, Linux has the reputation of running on older computers like a champ. Don’t ruin that ability with a DVD.

USB keys are bad because they often require configuring the BIOS to make the USB key bootable. If you are giving Linux to non-technical users, you definitely want to make sure that they do not need to fiddle around with the BIOS.

Direct installation CDs are bad because it does not let the user test out his or her hardware to see whether or not it is supported by default. It may be the case that the user is not interested in a whole lot of configuration, and does not want to install Linux if it does not have perfect out-of-the-box support for his or her hardware.

Also, don’t just point the new user to an ISO that they have to download and then burn. Many new users do not know how to burn ISOs, and may not have the software that is capable of burning them.

2) Put all the necessary information about the CD on the CD

Don’t give the users a separate sheet of paper, a URL, or some other reference to find out information specific to the type of Linux that you are giving them. They might lose or forget the reference that you give them. To solve this, put all the necessary information straight on the CD.

Information that you should definitely put on the CD include:

• Name of Linux distribution. It’s definitely not enough just to label the CD as Linux.
• Version (and if applicable, version codename) of the distribution on the CD.
• Architecture–so they do not attempt to run an x86 LiveCD on an old PPC Mac.
• A place to get more information. I prefer to give my email address for this purpose for the following reasons:
  • If I give them a forum, mailing list, IRC channel, etc. to contact, they may be treated unkindly by trollish Linux users.
  • I know about the CD that I gave them, and they have probably already told me what kind of computer that they are going to run this on. If you give Linux CDs to lots of people, you might need to find some way to manage this information outside of your brain.
  • They do not have to sign up for an account for a forum or IRC serve

If you give your email address to the new Linux user, that does not mean that you have to spend days debugging their system should it encounter problems. You can just reply back with some useful links or Google search terms that they might find useful if they need your help.

3) Show them how to boot and use the CD

Given that most LiveCDs have the ability to install themselves on the disk, and potentially wiping out the entire drive; it is very important for the user to know which options will install Linux, and which options will not install Linux.

Of course, it is very difficult to unknowingly erase data using a Linux LiveCD. The main issue is the user’s potential fear that there may be data loss due to use of the LiveCD. That potential fear may prevent the user from using Linux.

However, if the user is given a quick tutorial on how to not erase a hard drive, then the user can proceed with confidence.

4) Make the distribution and architecture choice based on what they need

Don’t just give them any CD you have lying around. If they plan to run Linux on an older computer, the latest AMD64 Kubuntu might be a poor choice.

Talk with them about what kind of computer they want to run Linux on, and explain to them how you narrow down the Linux distribution choices to find the one that should work the best for them.

—–

These tips, if followed, should reduce the chances that the Linux newbie should have significant troubles. Got more tips? Tell us in the comments below.

Introduction

Recently, the Twitter clone identi.ca launched. Identi.ca interests me more than the microblogging services Jaiku, Pownce, or Plurk because identi.ca is open source.

Of course, identi.ca has gotten some criticism. At the time of this writing, identi.ca is shockingly featureless. There are also some minor bugs, and it appears to be unstable at times. I have seen PHP errors on the page, timeouts, and identi.ca messages (informally called by the community as dents) not appearing. Identi.ca supporters counter that identi.ca was released early and it is expected to have problems.

But this raises an interesting question. Should a microblogging service open up to the public when it has few features, or when it is fully polished? Open source applications traditionally allow input from the community at a very early stage. But when a product is released to the public, it generates a lot of buzz, which is useful in getting people to use the product. This buzz can go away when people get bored of talking about the product, and it is possible that potential users could become uninterested with the service and not come back when it has new features and bugfixes.

Of course, a lot of open source applications can still be open to the public early and generate the most buzz at the right time. Firefox is one example of this. Even though many people had tried out the Firefox 3 alphas, betas, and release candidates, Firefox still got a lot of buzz during Download Day.

But the thing about Firefox 3 and Download Day was that Firefox generated a lot of buzz by attempting to go for a world record. Attempting something like that is much more difficult for smaller organizations.

But so far, I seem to have overlooked an option. I have only mentioned going public early or staying completely private until the service is, for the lack of a better term, done. There is always the option of the invite-only phase. In this situation, the user base grows as people invite others, but the growth is slower as people have to be able to obtain an invite to be able to use the application. Invite-only testing also gives more control over how many users join, because the application developers control the invites. This means that the growth of the userbase can be slowed or even stopped should scaling problems appear.

Also, I’ll note that in my idea of an invite-only microblogging service, anybody can view the messages of a user, but only those with invites can register accounts and post replies.

Below are the advantages and disadvantages of going public from the start, staying private until the product is finished, and

Going public from the start

Advantages:

• You have more eyes looking out for bugs.
• You have more time to build a community, which is a big part with Twitter clones.

Disadvantages:

• If you are not careful about how you market it, people could see your service as uninteresting as people have already talked about it.
• The community might not come if your service doesn’t have necessary features or is buggy when they tried it.

Staying private until the application is polished

Advantages:

• The application is abundant with features.
• The developers have the ability to radically change the service without worries. There are no users to be affected by the changes.
• If the application is tested properly, bugs are caught quickly and before the bugs annoy any users.

Disadvantages:

• The developers cannot listen to the wishes of the users. This means that time might accidentally be spent on features that the users do not think are completely necessary.
• Usability testing is limited to very few people.

Going with an invite-only testing phase

Advantages:

• Control over the growth of the user base.
• Hype as not everybody can get a first-hand look at the service.
• Benefits involving the community without the negatives of going public early.

Disadvantages:

• Microblogging generally works well when you have a large community. Having a small community reduces the use of microblogging as fewer people can respond to a user. Because of this, the user is given more incentive to invite other people to contribute to the discussion.

Conclusion

None of these paths for microblogging services are perfect. I say that it depends on the developers. If there is a clear plan for marketing the service, going public from the start looks like a good choice. If the developers think it is best to gradually increase the userbase to test see if the application scales up properly, invite-only seems like a good option. If the developers want a grand opening, or some other better reason, staying private until a later stage might work for them.

UPDATE: As you can see, several people have pointed out spelling and grammar mistakes and I have corrected some of them.

Remember back when a lot fewer people were using Twitter and it was being talked about all over the Internet. Of course, Twitter has always been instable unstable, but it’s just gotten worse.

Now, in my small group of close friends, I am pretty sure that I was the first to be using Twitter. Either that or it took a long time for my friends to realize that I had a Twitter account. Now, if I had gone parading around saying that Twitter was the most awesome web service ever, I’d look a little silly now.

A lot of other people have gone parading around and shouting how great Twitter is, while secretly hoping that the small downtime issues would get resolved as Twitter grew. Of course, the downtime issues didn’t go away. If they [the downtime issues] did, the downtime wasn’t gone for long.

A lot of that parading and shouting behavior comes from the desire to be the FIRST to give the news. Humans seem to have some obsession with being first. If you take a stroll through online communities that are not moderated very strictly, you might see a post that only says, “First!” But now some of those people that wanted to be the first about Twitter to crown Twitter as the next best web application probably wish that they had doubted Twitter.

This raises an interesting question. Should we learn from Twitter and wait to see how the service scales up? Well, if there weren’t so many people going around shouting about Twitter, Twitter wouldn’t have grown as quickly, forcing everybody to wait even longer to see how the service is going to scale up. So, then what? If always wanting to be the first to talk about the best is not a very smart thing to do, and waiting takes forever, what is the best course of action?

Well, that answer isn’t easy. Growing and dying is part of a web service’s lifecycle. Plenty of excellent services that probably could scale up very well have died.

But that still doesn’t answer the question. What is the best course of action when you see a promising web service? Unfortunately, it doesn’t seem like there is one. It’s nearly impossible to accurately predict the future time and time again.

The best advice is just not to put all your eggs in one basket and know that even the biggest are not immune.

On Sunday, Chris Pirillo posted some short Wall-E reviews from other people. He got those reviews by asking people on FriendFeed of what he thought of Wall-E. Now, some people didn’t like this. Can you ask others to generate content for you, and then post that content on your own blog, where you can make money off of it?

Well, I would have to say yes. First of all, Chris Pirillo also linked back to the FriendFeed pages of those that contributed to his post. Giving proper credit is important in the blogging world, and I think that Chris Pirillo did a good job of that in this case.

Also, I think that it is good for a blog to display the opinions of others, and not just through comments on posts. Not everybody bothers to read the comments. I like the fact that Chris Pirillo took the time to display the opinions of others, and not just himself, on his blog right in the spotlight. He didn’t stuff the reviews in a sidebar, put them at the bottom, etc.

But in the original FriendFeed post, Chris Pirillo didn’t tell those that replied to his original question that he was going to blog about what others’ had said. Was that wrong? Well, I think that many people quote without telling the original content generator about it. I don’t really see what was wrong about that.

Also, would there be a change in the responses if he had appended to his original request, “Just so you know, I’m going to post all these reviews on my blog.” ? I think so. All the people that didn’t approve of Chris putting the FriendFeed comments on his blog certainly wouldn’t have offered Chris a short Wall-E review.

If I were face-to-face with you, and I told you that I was going to conduct an experiment on your blinking, wouldn’t you suddenly become more conscious of your blinking when I’m around? I think that applies when you know what is going to happen to content that you submit.

But what’s really happened here is that Chris accidentally touched on a bigger issue, which is the question, “Who owns blog comments?”

These days, everybody has so many accounts at various web services. This is a known fact. Look at FriendFeed. One of it’s purposes is so people can view the online activity of their friends in one place. That means that you don’t have to go to all those separate websites to catch up on what your friends are doing.

But that’s not the only change. Before, people really liked it when all you had to do was sign up for a free account to use a service. Now, that’s not the case. Signing up for an account, keeping track of the username and password, logging in from time to time, and all that work just seems like too much when you have to do it for so many web services.

So now, there are many web services that you can use without signing in. I’ll use FriendFeed as an example here. There have been a couple blog posts that talk about how to get the most out of FriendFeed without signing up for an account.

An example is typing the below string into your URL.

http://friendfeed.com/public?service=blog

What it does is show you what all the FriendFeed users are blogging about. With URL tricks like this, you can get quite a bit of functionality without logging in.

Another example. My dad has recently discovered Digg. He doesn’t have an account, because he doesn’t need one to read interesting news. He is able to use a service without logging in.

What does this all mean? It means that new services have to come up with ways for users to try out their service without having to sign up. Of course, it’s impossible in some cases, like for webmail services (Gmail). If the ONLY way to use your service is to register an account, your service is at a disadvantage.

So, what is the latest in using services without having to sign up? Well, there is Posterous. You can start a blog without actually having to register an account. You use your email account, a service that you already signed up for, to make your first post to your blog. You are then give a reply email that asks if you want to get a password. Getting a password allows more functionality, like the ability to choose your own subdomain name, instead of having an automatically generated one.

So, what is in the future of web services and accounts? I think we will just have to wait and see.

I’m a fan of FriendFeed. FriendFeed, to me, is total awesomeness. At the time of this writing, I’ve written fifteen posts on FriendFeed (including this one). Robert Scoble loves FriendFeed too. But now, I love FriendFeed even more. Why? Because it’s possible to create truly excellent applications with the FriendFeed API.

The FriendFeed API is far from perfect, but what’s making me love it is NoiseRiver. So, who is behind this masterpiece of an API application? directeur on FriendFeed is responsible for this masterpiece of an API application.

So, what do I like about it? First off, the user interface is excellent. It takes the simplicity of FriendFeed’s user interface and entwines it with an elegance that is so hard to achieve when building a good user interface. Click on the below thumbnail to see the screenshot full-size.

Now, it does more than serve up a pretty user interface. It actually solves some of FriendFeed’s most basic problems. What does it solve?

Well, several people have talked how noisy FriendFeed users can drown out the posts of less-frequent FriendFeed users. Now, if you like the posts of the noisy and quiet FriendFeed users, you’re at a bit of a disadvantage. It’s more difficult to hear the quiet FriendFeed users, and there may be some cases when you’re more interested in what the quiet users have to say.

NoiseRiver to the rescue! It allows you to select which users you like more than others.

Okay, but the noisy FriendFeed users might also talk about topics that you aren’t interested in or don’t like at all. What do you do about that?

No problem. NoiseRiver solves this problem by allowing you to insert keywords and rate those too.

Now, I might really like NoiseRiver, but you are annoyed with something in NoiseRiver’s user interface. What do you do?

Wel, there’s the NoiseRiver FriendFeed room where you can post suggestions, and a lot of the suggestions are acted upon immediately.

In conclusion, NoiseRiver is a top-notch web application that has a great user interface and solves some of FriendFeed’s problems.

For some additional reading, you can check out Louis Gray’s coverage of NoiseRiver.

UPDATE: Apparently some people think that NoiseRiver actually has a chance of being acquired.

Introduction

PHP 5 has been out for a long, long time. Yet there is a disturbing trend. I still see servers with PHP 4 installed. Why would you have PHP 4 installed? Really, keeping PHP 4 won’t help you very much in the long run. It might be more convenient as you already know that all your script work in PHP 4, but I believe that it is worth it to upgrade to PHP 5.

Get PHP 5. It’s good for you.

1) PHP 5 has features that have been in other languages for a long time.

PHP 5 introduces exceptions. As many beginner programmers use PHP, having them learn PHP 5 exceptions means that they will be familiar with the concept when they move onto other languages.

2) It allows you to use tools that only support PHP 5.

Remember that content management system that you thought would be perfect for your site? But wait! It’s for PHP 5 only. Since you’re running a PHP 4 server, you miss out.

3) Because support for PHP 4 has been dropped.

What, so you’re going to continue using something unsupported when PHP 5 is right there?

Also, if you attempt to ask a developer friend for PHP help, there is a good chance that your developer friend will tell you to upgrade, unless he or she is also running PHP 4. If your friend is running PHP 4, you should send this article to him or her. ^_^

4) You don’t annoy people that write PHP code for your server.

Let’s bring back that developer friend of yours. You have a cool idea for a PHP web application. He or she asks which version of PHP 5 you are running. You say, with an embarrassed smile, “I’m running PHP 4.4.8.”

If your developer friends are used to PHP 5, it makes it much more difficult for them to write PHP code for your sever. Friends are good, save them a headache.

Introduction

When a friends of mine ask me for help with some CSS, a regular expression, or a Python script, it can take a while for me to figure out what  the problem is. Why? Because they don’t ask questions properly. Being able to ask questions properly accomplishes two things:

• Your question is more likely to be answered more quickly.
• The person you’re asking gets less frustrated. A less frustrated person is also more able to answer your questions.

So, asking questions well is an important skill to learn. But how do you do it?

How to ask good questions

1) Don’t come up with your own solution, and then ask if your solution already exists.

One of my friends, new to cascading style sheets, asked me a question if a certain HTML tag existed. I didn’t actually understand why in the world he would think such a tag existed until he described to me what his problem was. I told him what his problem was and how to use CSS to fix it.

A lot of time was wasted when I was trying to decipher his original question. If that friend had not jumped to the conclusion that an HTML tag had to exist to fix the problem, we could have saved some time in finding the solution to his problem.

2) Be descriptive.

This shouldn’t even need to be on the list. It’s so obvious, yet why do so many people disobey this one?

3) Be extra careful in phrasing your question.

You should be careful when phrasing your question to avoid any misunderstandings. Use the best spelling and grammar that you are capable of, and something big to watch out for is misplaced modifiers.

Using good grammar also makes you look more professional, which is always a bonus.

4) Use a search engine.

On forums, IRC, and other places where you can ask questions, you are often told to use a search engine like Google or the forum’s search.

Now, there are some things that Google just doesn’t work well for searching. You should still try to gain some knowledge about the topic that you are asking about as that will make it easier to understand a complex answer.

5) Make sure that you understand the answer.

Remember in the first tip where I talked about my friend learning CSS? I made sure to explain the CSS that would fix his problem. Why? If I didn’t, he would come back later to ask the same question.

If your question-answerer doesn’t make sure that you understand the answer, ask for clarification.

———–

Also: 100th post! :D

You’re a beginner PHP programmer, and your server has just been upgraded to PHP 5. Yay! Time to rewrite that error handling code to include exceptions! One mistake that beginner PHP programmers make is that they go crazy with exceptions. They might turn the below code:

function checkUsername ($username)
{
    if (!is_string ($username))
    {
        die ('The username is invalid');
        /* Also acceptable are:
        *     trigger_error (<something>);
        *     ^-- If you the proper error handling
        *         setup for site visitors.
        *
        *     return <something>;
        *      ^-- Provided that the caller saves
        *      the return value and that the
        *      value is checked.*/
    }
    else
    {
        return true;
    }
}

oldCheckUsername ($username);

into:

class OMGYourUsernameIsNotValidException extends
Exception {}

function checkUsername ($username)
{
    if (!is_string ($username))
    {
        throw new OMGYourUsernameIsNotValidException
        ('Username = fail');
    }
    else
    {
        return true;
    }
}

try
{
    checkUsername ($username);
}
catch  (OMGYourUsernameIsNotValidException  $e)
{
    echo $e->getMessage ();
}

Exceptions are best used for things like a database connection failing. They aren’t really for simple things like form validation.

Uncaught PHP exceptions are considered E_FATAL errors, and I consider that a good measurement of whether or not you need exceptions. While you might want to terminate script execution in the case of improperly filled in forms, you wouldn’t want to use that error level for form validation.

A failed database connection seems to fit well into E_FATAL, and by that logic, it’s okay to use exceptions for it.

Disagree? Know a better way to handle errors in PHP? Tell me in the comments.

Just now, I finished watching an episode of Nova scienceNOW (yes, that’s how it’s capitalized). Covered in that episode is the work of Dr. Hany Farid and his work to develop software to detect photoshopped images.

One technique that he demonstrated with software is to detect parts of images that are identical. This is to detect whether the clone tool has been used on parts of the image.

Another technique demonstrated is to detect where light is coming from. If two people from two different images are cobbled together into one fake image, it is highly possible that the light sources in the original two images are in different places. This means that the two people are illuminated from different directions, and this is shown on the person. If one person is being illuminated from the left side, and another is being illuminated from the right side, you know that the image was originally two images that had different light sources.

Another way to see the light source, assuming that the image you are testing has at least two people with clearly visible eyes, is to analyze the shape and location of the light being reflected off; that is, the specular highlight. As the eye can act like a mirror, you can see a little bit about the light source, such as the shape of the light source. You can also see how the light source is hitting the person. If one person has a reflection of a square light source (like from a camera flash), and another person has a reflection of a circular light source hitting the person at a completely different angle, there is a good chance that the photo isn’t completely real.

Want to learn more about Hany Farid? You can check out (I grabbed all these links from here):

• Hany Farid’s home page
• Digital Forensics: An Interview with Dr. Hany Farid
• Adobe Tackles Photo Forgeries
• A Conversation With Hany Farid: Proving That Seeing Shouldn’t Always Be Believing
• Digital Doctoring: How to Tell the Real From the Fake (PDF Warning)

So, what’s your prediction on the future of the Internet, photography, and digital photo manipulation?