Showing posts with label howto. Show all posts
Showing posts with label howto. Show all posts

2009/10/29

How to argue on the Internet


Rule #1:


Do not argue on the internet, unless you absolutely have to, or unless you know your opponent personally. (or unless you are a troll).



Why? Because:


  1. Unless you know your opponent personally, you will be trying to prove your point to a stranger you probably won't ever meet. In general, no matter whether you win or lose, nothing will change.
  2. Writing takes time. A lot of time. Good, cold-blooded, intelligent argument, supported by research (or at least by the Google search) might take from 30 minutes to a few hours to finish, even if you are typing 400 characters per second. In general, your time isn't worth the result - you in most cases you won't get satisfaction, even if you "win". Also, eventually someone else will join the discussion without reading your arguments first. So it will be a waste of time.
  3. Arguing sometimes takes emotions. If discussion becomes "heated", you might start to feel angry, etc. This also isn't worth the result.

Exceptions from rule:
It makes sense to argue, if one of following conditions applies:

  1. Your life is directly affected by result of argument.
  2. You have warranty that your opponent(s) is sane, is not a troll, and can provide good arguments.
  3. You truly enjoy the process.

Of course, it is easy to say "do not argue", but how to deal with annoying/insane arguments? Here goes


Rule #2


Add "I think" ("He/She thinks") in front of opponent's arguments before reading them.


Why?


Because every argument on the Internet is an opinion. However, people very frequently forget to mention (by adding "IMHO") that what they write is merely their opinion. And some unique individuals will truly believe that what they think is some kind of absolute truth. The problem is that when you see something outrageous that doesn't fit what you know/believe in, and this thing presented as a fact (or some kind of absolute truth), your brain (mine, at least) for some reason wants to prove that your point of view is right, and this argument is not. However, for some reason, opinions of other people are easier to dismiss/ignore than something that is presented as a fact.


How to use it (example):


You log into forum. The user XYZ posted a message saying (keep in mind, this is just an example) "The universe was created by a big purple pipe-smoking rabbit with a pitchfork!" Now, it doesn't fit your religious beliefs and makes you enraged (keep in mind, it is still an example). Before starting a flamewar, add "I think that" in front of original sentence, and read it again. Now the message turns into "I think that the universe was created by a big purple pipe-smoking rabbit with a pitchfork!". Now for some reason it doesn't feel enraging, because If this dude thinks so, it is his problem with his head, opinion of some random dude (you never met) doesn't matter for you, and he will not be able to provide interesting discussion anyway. So you ignore this guy, and move on instead of wasting next hours in flamewar.


Rule #3


Avoid discussions about religion at all costs


Why? Because:


Faith frequently blinds people, and makes them think they are right affects both atheists and believers) and their opponents are not. There are very few(less than 1% of population, I think) people that can easily analyze/and change their beliefs when they are trying to prove they are right. During my life I never saw any religious that didn't end in flamewar. I also don't remember anyone in such discussion ever convincing someone else. So, in general, it will be a waste of time (unless you are troll, of course). Of course, there are always nice people that calmly follow their religion (or atheism) and don't bother anyone. However they normally don't have a need to participate in discussions about religion.


Rule #4


Unless you are dealing with science, any opinion (including yours) can be wrong and is not a universal truth Best applied to discussions about religion, in case you skipped Rule #3.


Why? Because:


Imagine that you live in a city and know that population of your town is 5000000. The problem here is that you do not know, but believe that population is around 5000000 people. This is because information about size of population was given to you by some kind of authority you trust(which is supposed to provide correct information), and you cannot really verify number of people yourself. If this authority gave you invalid information, your knowledge about city population will be invalid. The problem here is that nearly everything you know comes from some kind of trusted authority. Perhaps you never been to South Pole, but you believe that it exists, because someone told you so. The bigger problem is that first trusted authorities you use are your senses. So if you think about it, entire world around you could be an illusion or result of your imagination, without any way to be absolutely sure that anything besides you is real (that's where "Cogito ergo sum" comes from). If we skip philosophy part, and return to simpler terms, this means that both you and your opponent most likely have incomplete or invalid information about the subject. For example, you or your opponent may refer to online resource that is not guaranteed to have valid information, and so on. Yes, it is possible to at least try to make sure that your information is valid, and trace/verify all sources you are using, but people rarely do it. So it makes sense to keep in mind that anyone can be wrong. And if you want to make things more fun, add Murphy's law to that ("Anything that can go wrong will go wrong."), which will mean that in any discussion is probably wrong at one place or another.


Rule #5


Remember that you don't have to agree with someone.


Why? Because:


There are many people in the world, and they all have different opinions, believe in different things, follow different religions, etc. And there is no absolute, universal truth, at least it isn't easily accessible. It is not possible make everyone agree, and it is not necessary. It makes sense to argue in situation when something serious depends on result - life of millions, perhaps. Clearly most Internet arguments and flamewars doesn't qualify as such situations, so participating in them is nearly always a waste of time (well, unless you are a troll and enjoy provoking other people). In most cases it is perfectly fine to disagree with anyone, as long as your position looks valid to yourself. And it makes sense to ignore "incorrect" opinions of other people, unless your life (or life or friends, relatives, etc) is directly affected by them. It makes sense, because people
don't like being told that they are wrong, proving something to someone takes time, and doesn't always provide useful result.


End of article.


Hope this helps someone.

2009/05/07

How to become a programmer, How to choose programming language


Introduction


On many message boards and forums I've seen many wannabe programmers.
"Guys, I want to become a programmer! Can you help me?". Sounds
familiar, isn't it? Those wannabes were asking same basic questions, over and over:

  • "Which programming language should I learn?"
  • "Which programming language is the best?".
  • "Can you recommend a good book about programming?"

Each of those guys (well, maybe there also were few girls) appeared, asked question, got some answers, disappeared and was never heard of again. I assume that some of them maybe were able to learn something, and maybe even became a really skillful professionals, but I believe most of those people have failed to become programmers. Because to my opinion they were doing it wrong from the beginning.

What you should never do if want to become a programmer



  • Never ask "Which programming language is the best?" on any message board.

    This is because there is no "the best" programming language, but many people will think otherwise. Typically, asking this question anywhere will provoke horrible flamewar where each person will attemp to prove that their language is "the best one". Of course, few first responses might be helpful for you, people even might provide some polite, useful, and unbiased info, but (in most situations) the thread will quickly turn into flamewar, or people will start demonstrating various language features using complex constructs (which will be completely uncomprehensible for a wannabe). Either way, there will be a very good chance that all discussion won't be helpful for a newbie.

  • Don't waste your time searching for "the best book" about your programming language.
    You will waste more time searching than you could spend programming. You will need a book, but it isn't really important to get best available book, especially if you are just a beginner. The practice and writing code is more important than books, at least in the beginning. So if you are in doubt (about which book to read), pick any book about your language, and use it for study.


What is really important


Book and choice of language are secondary things. Here is a list of requirements to become a programmer:

  • You should have a really good motivation or a goal. "I want to become a professional and get paid a lot of $$$" won't work - because you don't need to be programmer in order to earn cash. However "I want to make my own game" will be perfect.
  • Programming should be always interesting and fun for you. If it isn't interesting, if you aren't having fun when you write programs, then you won't be able to learn it quickly and efficiently. If your first programs look like a miracle/wonder for you, and you feel joy and happiness once it is finished, then you will have no trouble learning more difficult aspects. However, if you are bored to death each time you want to write something, you are not going to learn much. You will probably decide not to learn programming.
  • Do not try to pick "the best" language. Try to pick language which is "the best" just for you. If you are more comfortable with Python than with C++, then you probably will achieve more with Python.
  • When you are practicing, you should stick with stuff which is interesting for you. Making test program that inverts matrices is boring - pure math, not much to do. However, making "tetris" is not boring. Try to avoid boring examples from book. Keep books nearby and frequently use it as reference, but in order to learn more you should solve interseting, real-life problems.


Specialization: one important question you should answer before you start


You can't (easily) become universal programmer that can write in every language on every operating system. You should decide what you want to program, and pick your language accordingly.
Below is a short list of languages with short descriptions and explanations about how they are commonly used.


  • Assembler

    Not really a langauge. Assembler is simply a mnemonic representation of CPU instruction codes. So, (although there were some advanced assembler packages, like MASM), it is tightly tied to CPU, and will be mostly useful when programming low-level otpimized routines for that CPU. It won't be easy to use it for large projects.

  • C

    One of the popular languages, right now mostly used with OpenSource software, mostly on Unix/Linux/BSD and other unix-like system. It is very close to assembler (you still manipulate memory directly), but isn't tied to CPU type, so, unlike Assembler, C code is portable.

  • C++

    High-level language, with some of C features, and with higher-level features: objects, templates, etc. This language is really complex, and although you can learn syntax in few days, it might year or two to master it. C++ is used in most applications on many platforms, in many different tasks. It is portable.

  • Python

    High-level interpreted language. Platform-independant, isn't supposed to be compiled into machine code.

  • Java

    High level language which is meant to be completely platform-independant. Java program compiles into pseudo-code of non-existent processor. The code is run using interpreter, which is available for several platforms. So it is a hybrid of compiled and interpreted language.

  • C# and .NET

    Microsoft's attempts to make another java. Also compiles into pseudocode, but resulting application will be windows-only, because interpreter is developed only for windows (yes, I know about "Mono project", and I know it isn't frequently used).

  • Perl

    Interpreted language suitable for text processing, scripts, making tools, also for web.

  • PHP

    Interpreted language, used on the web servers.

  • JavaScript

    Used in web-pages, hardly for anything else.

  • Shell

    Unix shell script language. Used for making tools and scripts.



There are also several languages I never used much:

  • Haskell
  • Prolog
  • Common Lisp
  • OCaml

I"ve heard a lot of good things about those but I didn't need to use any of them. All of those languages are supposed to be powerful, but they are not "mainstream", and they aren't used frequently. Anyway, many people recommend at least to take a look at them.


Things you should keep in mind when you select language



  • Interpreted languages have better development speed, but worse performance, when compared to compiled languages. I.e. You might create Python program using less time, but C++ program are likely to have better performance. Notice that this a not always true, but in most cases. It is easy to make slow C++ program, especially if you don't know what you are doing. Keep in mind that although you don't need always need maximum performance or maximum development speed, in some situation they are important. For example, you wouldn't want to throw all power of C++ to make a simple text processing program - it will be faster to make it using shell script, python, perl, etc. On other hand, it won't be wise to make a raytracer in python - it is possible thing to do, of course, but for this application you will need a good performance, low-level memory access, etc. Notice, that in this situation you might consider assembler, but development time will be too high, and good C++ compiler might be able to produce better code than you.
  • You might not want to be tied to just one operating system, architecture or platform. If you want to be able to switch platforms later, then you should avoid Assembler(it is linked to just one CPU type), C# and all .NET languages (right now they are basically Windows-only), and you should be extra careful with C++ and compiled languages. Several companies provide language extensions which will be a lot of trouble if you ever decide to port your application to another platform (or simply if you decide to use another compiler). FIne example of that is microsoft's "safe" version of C string manipulation routines - "strcpy_s" and similar. They are not in C++ standard, so if you decide to port your application, you will have to write those routines yourself, or replace them with something else. Also, all compiled languages need libraries to interact with operating system, or create GUI windows, etc. This is because that standard for those compiled languages typically doesn't define libraries for all tasks. Because of this you should be careful about what libraries you use - they shouldn't be available only on one platform.
  • Some languages (typically interpreted or high-level: java, python, etc) try to help you and do some things for you - manage memory, for example (Python, Java, etc). Other languages assume that you are the "smart one" and you know what you are doing. They don't babysit you, and you are supposed to free memory yourself (C, C++ in some cases). Some people like automatic memory management, some don't like it. Typically, if you want to have all things under your control, you won't like automatic memory management. Keep that in mind when selecting language.
  • If you want to program for web, then you will probably have to use interpreted languages: Perl, Python, PHP, JavaScript. Compiled languages can be used to the some extent, but they won't help you much. This is because PHP and Javascript are easy to integrate into page, and you can't do same thing with C++ program.
  • IF you are using Linux/Unix-like system, then the first thing you might want to learn are shell scripts. This is because they are used very frequently. Also you might want to learn Perl or Python - because they are also very popular and frequently are being used for making simple unix/linux tools.


Conclusion


This is it. Think about all that and pick language. If you still don't know what to choose, pick anything and start studying it, but remember that you can always select another language later.

2009/03/07

How to generate password on linux system


Every user eventually will need to create secure password (alphanumeric, not a common word, etc).
On linux, you can easily generate it without additional software

To generate eight characters long alphanumeric password use following line:

tr -dc '0-9a-zA-Z' </dev/urandom |head -c 8;echo


You can put this into shell script, if you are going to need it often.

In case you are a newbie and don't understand what this line does, explanation is below.

Explanation

/dev/urandom is one of a few special files on linux/unix systems (other files are /dev/zero, /dev/null and /dev/random).
/dev/urandom provides endless stream of pseaudo-random data, but even if you paste data from that file into text file, you won't be able to use it as password, because it will containt a lot of characters that doesn't fit into ASCII charset.
So that's why "tr" comand is used. "tr -dc '0-9a-zA-Z'" reads data from /dev/urandom and then prints to output only characters that fit into given character set (which is '0-9a-zA-Z'). See "man tr" for more details.
This means that if you want use another set of characters in password, you will need change character set to something else.
For example, '0-9' means only numeric characters, '0-9a-z' - numeric or lowercase latin letters, and '0-9a-zA-Z!@#$%^&*()_+-' will include extra characters to make your password more secure.

Because /dev/urandom is "endless", "head -c 8" is used to copy first 8 characters (see "man head" for explanation).
If you need more or less characters, change number accordingly.

"echo" command without arguments simply prints a newline. It is only useful if you want to print password into terminal (because without "echo" next shell prompt will be printed right after password - on the same line).

Possible problems
On system with UTF-8 locale, you won't be able to generate password with non-ASCII letters using this method. This is because tr handles only one character("byte") at the time, and UTF8-encoded non-ASCII character will use more than one byte.

2009/03/06

How to answer questions without wasting too much time


This text was originally posted on www.linuxquestions.org (here). It was created because there is already famous "How to ask questions the right way", but I don't remember any document for those answering questions.
Information should be useful for people that hang out on various forums/newsgroups answering questions and solving other people problems (mostly useful for linux users).




Okay, I've just got through another flamewar, so I decided to write a some info about answering questions without wasting too much time in the process. The content is based on personal experience, my own point of view, and isn't supposed to be absolute truth or something. I also don't expect someone to agree with me. Recommendations are written in random order, and are supposed to prevent wasting too much time typing replies, or breaking your keyboard too quickly.
Beware! Some people probably might find this thing offensive.

The recommendations are based on following assumptions:
  1. You want to help other people to solve their problem.
  2. You don't want to spend many hours per day doing that.
  3. You want to get satisfaction from giving out info - i.e. people should be grateful, or discussion should be interesting.
  4. You do not want to live on the forum, just post answers to some threads.
  5. You don't want to have a bad mood after helping someone.

Here are recommendations:

  1. Always remember that you can ignore other people instead of trying to reason with them. By "ignoring" I mean ignore list, which is located at this page on linuxquestions and often present in other forums. Ignore list is a very handy feature.
  2. Never participate in threads about religion. There were many of those, and when there is a clash between believers and atheists (or simply followers of different religions), no matter which side you take, you'll never prove to "them" that you are right. Also, your opponents will never prove you that you are wrong. The thread will eventually degrade into pillow-fight, and someone will close it.
  3. Never post in "Linux vs Windows" threads. Yes, this is tempting, but should be avoided. Such threads either never ends or many of them eventually degrade into flamewar. Which side "wins" in case of flamewar depends on forum, but in most cases, moderators win. Providing non-biased info in such threads is difficult, and sometimes leads to disappointment - especially when you discover that someone asked the question you already answered in details one year ago in the same thread.
  4. If are feeling too emotional while typing a reply, do not type a reply. If you were offended, report incident to moderators. If you are angry, go outside and take a walk. If you don't like someone, ignore him or her (by adding into ignore list). Being furious or simply emotional causes too much typing. And too much typing means too much time wasted.
  5. When someone posts something that doesn't fit into your system of beliefs, and it enrages you, do not try to explain something to that guy/girl, ignore him/her. If he posted something gross, then report it to moderators. To my experience, trying to explain something to someone who don't want to listen is #1 cause of wasting time on the internet. This applies to the choice of distribution, operating system, religion, some questions about women, and so on. Same principle applies to trolls or any person that pisses your off.
  6. Do not reply in the threads started by spammers. They don't read it.
  7. When replying to "newbie" section, try to keep your replies extremely short, but informational. It is tempting to overwhelm newbie with the amount of things you know, but this guy might not need it. He might be simply interested how to watch DVD, and not in the mood for linux history lesson or detailed comparison of all available dvd-players.
  8. When you realize that you started to type extremely long, detailed instructions about "how to do something in linux", stop, put keyboard away, take a deep breath, relax, and then try to find howto on the subject you were writing about. There is high chance that someone already wrote what you were going to write right now, so you'll be reinventing wheel. If there is a howto on the subject, post a link to it or quote it (but still provide link). This will make howto more widespread and will save time for other people.
  9. When you found a good howto or manual, and want to put a link to them in reply, consider quoting them. Websites sometimes disappear, and seeing dead link 3 years later (and answering same thing again) isn't much fun. If the source of article doesn't look "stable" enough, quote good portion of it (but still provide link). If website is unlikely to disappear, then link should be enough.
  10. If you really pissed someone off, and was unable to pacify that person within small amount of replies (1..3), consider ignoring that person. This is because when someone thinks that you are "evil person that hates all people" (no matter what were your intentions, what did you post, how friendly you were, people might think that about you), you can waste considerable amount of time reasoning with that person and explaining your position. If you started such "clarification conversation", observe person's reaction, and if person is unlikely to change attitude quickly, don't waste your time. Some people can be reasoned with, some can't.
  11. When you see newbie poster (which has 1 message on the forum) with a short question (literally short - one statement with poor punctuation, small amount of info, etc), and you want to write really long answer, stop, and think about it again. Poster might be "fly by homework question author" - i.e. he will ask question, and then mysteriously disappear, while other people will waste their time explaining things to him and writing huge replies for few weeks. Not all newbies magically disappear, but you should consider that possibility.
  12. Don't do other people's homework, they normally won't truly appreciate it, and this will spoil your mood and take your time. I.e. if the guy asked how to make some script, do not engage in 3 hours of googling, researching and testing just to make that script for him, because in the end his "thanks" might not satisfy you. To my experience, answers that were written with little effort (link to howto, article) generate more positive emotional feedback (for you - i.e. you'll feel more happy) when people say "thanks" than answers where you spend hours to find solution. Making other people's homework makes sense only if the problem is extremely interesting for you and you really like to solve complicated problems. Notice, that even if you solved problem you still can choose not to provide info to the OP, if you think he is too lazy or didn't do his homework.
  13. Do not live on the forums. If you are checking forums for new messages every 3 minutes and looking for _any_ discussion to participate in, and occasionally attempt to derail existing threads, then you should probably turn off computer and go jogging, watch the movie, take dog for a walk, or do anything that is fun, takes at least hour and doesn't involve computers. Helping people is fine, forums are good, but, unfortunately, for some people participating in such discussion is a bit addictive. And when you start spending too much time on the forums, quality of your answers decreases.

Now this is it. I hope this information will be useful for someone.