Recently I bought Huawei EC-121 modem from Omnnea (Iraqi CDMA operator) with monthly subscription , it works fine on Windows but when I plugged it in Ubuntu 8.10 NetworkManager didn’t detect anything….however, dmesg showed 3 modems detected by the kernel ttyUSB0…ttyUSB2…if it takes long time to detect the modems just try to rmmod usb-storage to ignore the embedded CD-Drive emulator.

Getting this thing to work under Linux wasn’t hard at all , prepare your wvdial configuration :

sudo gedit /etc/wvdial

replace the contents of the file with the fo

[Dialer Defaults]
Init1 = ATZ
Init2 = ATQ0 M1 L1 X3 V1 E1 S0=0 &C1 &D2 +FCLASS=0
Modem Type = Analog Modem
ISDN = 0
Abort On No Dialtone = False
New PPPD = yes
Phone = #777
Modem = /dev/ttyUSB0
Username = omnnea
Password = omnnea

Now try to connect using wvdial :

sudo wvdial

you will get something like this :

WvDial: Internet dialer version 1.60

Cannot get information for serial port.

Initializing modem.

Sending: ATX3

ATX3

OK

Sending: ATQ0 V1 E1 S0=0 &C1 &D2 +FCLASS=0

ATQ0 V1 E1 S0=0 &C1 &D2 +FCLASS=0

OK

Modem initialized.

Sending: ATM1L3DT#777

Waiting for carrier.

ATM1L3DT#777

CONNECT 153600

Carrier detected. Waiting for prompt.

~[7f]}#@!}!} } }=}!}$}%\}”}&} } } } }#}%B#}%}%}&.|&p}’}”}(}”qW~

PPP negotiation detected.

Starting pppd at Thu Dec 11 14:10:23 2008

Pid of pppd: 6515

Using interface ppp0

local IP address 10.10.6.148

remote IP address 192.168.2.2

primary DNS address 192.168.1.1

secondary DNS address 4.2.2.5

For some reason wvdial doesn’t change the DNS name servers so you have to do it manually :

sudo gedit /etc/resolv.conf

and add the following name servers :

nameserver 192.168.1.1

nameserver 4.2.2.5

]]> http://www.hasanen.com/?feed=rss2&p=25 http://www.hasanen.com/?p=19 http://www.hasanen.com/?p=19#comments Mon, 04 Aug 2008 20:31:35 +0000 admin http://www.hasanen.com/?p=19 This article has been taken from: http://www.cyberciti.biz/tips/10-ultimate-rules-for-effective-system-administration.html The following 10 items are guidelines more than rules, that I have learned over the years doing intensive work on the IT infrastructure. These guidelines are mostly common sense and can be helpful for anybody who administers an IT system, including Linux/Windows Administrator, Network Administrator and DBA. 1. Keep it simple. In [...]]]>

This article has been taken from:

http://www.cyberciti.biz/tips/10-ultimate-rules-for-effective-system-administration.html

The following 10 items are guidelines more than rules, that I have learned over the years doing intensive work on the IT infrastructure. These guidelines are mostly common sense and can be helpful for anybody who administers an IT system, including Linux/Windows Administrator, Network Administrator and DBA.

1. Keep it simple.

In technology environment, keeping things simple takes lot more effort and maturity than keeping it complex. As an administrator, when it comes to implementing a particular functionality or solving a problem, there are always several options available. It is best to learn all the available options, including the complex ones to understand how it works. However while implementing, try to keep it as simple as possible. The option you choose should be simple and have the following characteristics:

• Easy to maintain in a long run
• Does not add additional over head to the system
• Solves the primary business/technical problem

Whenever you are in a dilemma of whether to choose a bleeding edge technology or proven technology that has been around for a while, always go with the proven technology for production implementation.

2. Backup regularly

Is both your personal laptop and servers at work, getting backed up regularly? If not, stop everything you are doing now and implement a backup solution on those systems immediately. Seriously! Start planning for your backup right now. Everybody knows that backing up data on a regular basis is critical. Only those who got burnt out on few occasions without having a backup, really understands the importance of having a reliable backup solution. Don’t learn the importance of backup after loosing your critical data.

It is only a matter of time, when you’ll be in a situation where a system crashed, data got deleted accidentally or laptop with critical data is lost. Spend quality time and implement a reliable backup solution for both your personal laptop and servers at work.

3. Test your backup regularly

I could’ve combined this as part of rule#2. But, I strongly believe testing the backup deserves special attention. I have seen on several occasions, where administrators thinks they have a valid backup, only to find out during disaster, they couldn’t restore from the backup successfully. A backup solution without testing it on a ongoing basis is only as good as not having the backup. Just having faith in the backup that it will work is not good enough. You should have a process to test your production backup every month. You’ll have a peaceful sleep at night just by implementing rule#2 and #3.

4. Proactive Monitoring

Are you always working in a fire fighting mode? Is your users calling you to indicate that a system is down or having problem? Experienced administrators knows that they should spend majority of their time implementing solutions to avoid problems, instead of fixing the problems after it happens. Make sure to implement a strong monitoring solution that will monitor and alert you about a problem before it happens. You should never be solving the same issue more than once. Following two points will help you to achieve the proactive monitoring.

Sit and identify all the equipments, services and applications that needs to be monitored through out the enterprise. Define an acceptable warning and critical levels for those systems. Define who should be notified and how often they should be notified and the method of notification. Once you have these identified, spend time implementing a monitoring system.

Despite proactive monitoring, there will be times when you’ll be putting out a fire. Once you put off the fire, the first question you should ask yourself: How I could’ve avoided this issue from happening? Once you have the answer for that, make sure to implement an appropriate monitoring solution to prevent this particular incident from happening in the future.

5. Document Everything

You should document everything that you perform on the system. This is not a pleasant topic for administrators, as most of us hate to write documentation. An experienced administrators knows that documenting the environment and his work is key for his success and growth. I’m not talking about spending several hours creating a huge document with all fancy formatting.

Anytime you implement a solution or fix a problem, just scribble down the high level steps that was performed in a text file. You can simply copy/paste the commands you’ve executed along with one line description. This in itself is a huge step towards documentation for most administrators who are not used to documenting their work.

Following are some of the primary reasons for documenting every technical activity performed by administrators:

• Don’t learn the same topic twice. When you implement something new, you have spend enough time learning the technology and understanding the steps to implement it on your specific environment. During this process, write down all the steps and refer to those steps the next time you want to perform the same task on a different server.
• There will be situations when you want to delegate tasks to others. For e.g. when you are going on vacation or when you want to delegate a particular routine task to a junior administrator who is eager to learn. If you had the practice of consistently documenting everything, you can simply pass those text file documentation to the other administrator.
• Sharing your knowledge with others is one of the efficient ways to grow your knowledge. So, document everything and share with others.
• Don’t waste the valuable RAM space on your brain by remembering everything. Instead off-load some of the items from your brain’s RAM to a simple text file and use your brain’s RAM to explore new technology.

6. Plan and Execute it well.

When you are implementing a solution, have a clear plan on what you will do next and when. You should be Project Manager for your own tasks and projects. I.e Analyze all the potential risks involved in implementing a solution. Make sure to give sufficient time to test a particular solution. Come up with a clear test plan and get your users involved in testing process. On your next assignment, try the following and see the benefits for yourself. This forces you to think about all the possible scenarios even before you start the project.

• Write down the objective of your project. I.e What is the problem you are trying to solve. What is your success criteria on this project/task?
• List down all the tasks required to complete this particular activity and assign appropriate dates for it.
• Even when nobody is requesting you to complete a project by certain date, hold yourself responsible by putting a completion date for your project/task.

When you really get this implemented on the projected date, give yourself a pat on the back and enjoy your accomplishment. Planning and executing projects well on a consistent basis could potentially become one of a huge motivation factor for administrators to start taking up bigger and complex technology projects.

7. Use Command Line more than GUI

Use the command line as much as possible. Whether you are configuring a VLAN on a switch or setting up LDAP/NIS authentication on a Linux server, always use the command line instead of GUI. Following are the advantages of using command line.

• You can do things very quickly on command line.
• GUI prevents you from understanding and learning the functionality happening behind the scenes.
  Repetitive things can be automated easily using command line.
• Your brain will have fun and Thank you for it.

8. Automate repetitive tasks

If you perform a task more than once, you should find a way to automate it. It may be very tempting to do the repetitive tasks manually, as can complete the task quickly and know the exact steps to perform the task. But, avoid this temptation and spend some extra effort in automating the task, which will free-up your mind from thinking about that routine tasks. Once you’ve automated the tasks, you can use your time effectively in learning other new fun stuff.

9. Support your users and developers

Administrators are technically very sophisticated and sometimes get frustrated with end-users who don’t understand technology. But, keep in mind that you have your job mainly because they don’t understand technology and need your expertise. When user reports an issue that is totally not related to the system and mainly because of user-error, be nice to the person and explain in a non-technical term about why this is not a system issue.

Sometimes developers may deploy something on the server causing some undesirable results. Don’t get mad on them and blame the problem on the developer. Instead, help the developer to identify the root cause of the problem, by providing sufficient data from the system to narrow down the problem.

10. Keep learning and have fun.

If you have mastered the skill on how to do all the above 9 items effectively, you’ll have more free time on your hand. Keep learning all the times. Anytime someone reports an issue, be curious and treat it as an opportunity to learn something new. Once in a while step aside your computer and spend quality time with your family. On top of all, have fun and enjoy doing the system administration activities.

This is a problem I noticed when I moved from SuSE 10.3 to Ubuntu.

This fix is easy , just link /usr/lib/win32 to /usr/lib/codecs

sudo ln -s /usr/lib/win32 /usr/lib/codecs

How do you recognise good programmers if you’re a business guy?

It’s not as easy as it sounds. CV experience is only of limited use here, because great programmers don’t always have the “official” experience to demonstrate that they’re great. In fact, a lot of that CV experience can be misleading. Yet there are a number of subtle cues that you can get, even from the CV, to figure out whether someone’s a great programmer.

I consider myself to be a pretty good programmer. At the same time, I’ve spent a fair amount of time on the business side of the fence, filtering technical CVs for projects, interviewing people, etc. Thanks to this, I think I have a bit of experience in recognising good programmers, and I want to share it in this article, in the hope that it may help other “business guys” to recognise good programmers. And, who knows, perhaps some programmers who have the potential to be good but haven’t really exploited this can also read this and realise what they need to do to become good (although, as I’ll argue, that’s definitely not accessible to all programmers!).

In his article The 18 mistakes that kill startups, Paul Graham makes the following point:

“… what killed most of the startups in the e-commerce business back in the 90s, it was bad programmers. A lot of those companies were started by business guys who thought the way startups worked was that you had some clever idea and then hired programmers to implement it. That’s actually much harder than it sounds—almost impossibly hard in fact—because business guys can’t tell which are the good programmers. They don’t even get a shot at the best ones, because no one really good wants a job implementing the vision of a business guy.

In practice what happens is that the business guys choose people they think are good programmers (it says here on his resume that he’s a Microsoft Certified Developer) but who aren’t. Then they’re mystified to find that their startup lumbers along like a World War II bomber while their competitors scream past like jet fighters. This kind of startup is in the same position as a big company, but without the advantages.

So how do you pick good programmers if you’re not a programmer? I don’t think there’s an answer. I was about to say you’d have to find a good programmer to help you hire people. But if you can’t recognize good programmers, how would you even do that?”

I disagree with Mr Graham on this one. I think there are a number of very strong indicators of a “good programmer” (and, conversely, strong indicators of a “not-so-good programmer”) that even a business guy can recognise. I’ll summarise some key indicators and counter-indicators in a list at the end of the article.

#1 : Passion

In my corporate experience, I met a kind of technical guy I’d never met before: the career programmer. This is a person who’s doing IT because they think it’s a good career. They don’t do any programming in their spare time. They’re shocked when they find out I have a LAN and 3 computers at home. They just do it at work. They don’t learn new stuff unless sent on a training program (or motivated by the need to get a job that requires that technology). They do “programming” as a day job. They don’t really want to talk about it outside of work. When they do, they talk with a distinctive lack of enthusiasm. Basically, they lack passion.

I believe that good developers are always passionate about programming. Good developers would do some programming even if they weren’t being paid for it. Good programmers will have a tendency to talk your ear off about some technical detail of what they’re working on (but while clearly believing, sincerely, that what they’re talking about is really worth talking about). Some people might see that as maladapted social skills (which it is), but if you want to recognise a good developer, this passion for what they’re doing at the expense of social smoothness is a very strong indicator. Can you get this guy to excitedly chat up a technology that he’s using, for a whole half hour, without losing steam? Then you might be onto a winner.

#2 : Self-teaching and love of learning

Programming is the ultimate moving target. Not a year goes by without some new technology robbing an old, established standard blind and changing half the development universe. This is not to say that all good programmers pick up these changes and ride the bleeding edge. However, there’s a class of programmers that will never, ever pick up a new technology unless forced to, because they don’t like learning new stuff. These programmers will typically have learnt programming at university, and expect to get by on whatever skills they picked up there, plus whatever courses their company is willing to send them on.

If you’re thinking of hiring someone as a programmer, and he ever utters the words “I can work with that, just send me on a training course for a week and I’ll be good at it”, don’t hire that guy. A good programmer doesn’t need a training course to learn a new technology. In fact, the great programmer will be the one talking your ear off about a new technology that you haven’t even heard of, explaining to you why you must use it in your business, even if none of your staff knows how to use it. Even if it’s a technology he doesn’t know how to use yet.

#3 : Intelligence

Some business people assume that lack of social tact and lack of intelligence are the same. Actually, intelligence has several facets, and emotional/social intelligence is only one of them. Good programmers aren’t dumb. Ever. In fact, good programmers are usually amongst the smartest people you know. Many of them will actually have pretty good social skills too. The cliché of the programmer who’s incapable of having a conversation is just that - a cliché. I’ve been to a few meetings of the London Ruby User Group and I can say that with only a very few exceptions, most people there are smart, talkative, sociable, have varied interests, etc. You wouldn’t look at them chattering away in the pub and think “what a bunch of geeks!” - at least until you approach a group and realise they’re talking about the best way to design a RESTful application with a heavy UI frontend.

This doesn’t mean that they’ll all feel comfortable in every social context. But it does mean that if the context is comfortable and non-threatening enough, you’ll be able to have as great a conversation with them as you would with the most “socially enabled” people (perhaps better, since most good programmers I know like their conversation to revolve around actually useful topics, rather than just inane banter).

Don’t ever hire a dumb person thinking they’re a good developer. They’re not. If you can’t have a great conversation with them in a relaxed social context, they’re very likely not a good programmer. On the other hand, anyone who’s clearly very smart at the very least has a strong potential to be a good or great programmer.

#4 : Hidden experience

This is correlated with the “Passion” point, but it is such a strong indicator that I’d like to emphasise it with its own point.

I started programming when I was about 9, on a Commodore 64. I then migrated onto the PC, did some Pascal. When I was 14 I wrote a raycasting engine in C and Assembler, spent a large amount of time playing with cool graphic effects that you could get your computer to do by messing directly with the video card. This was what I call my “coccoon stage”. When I entered that stage, I was a mediocre programmer, and lacked the confidence to do anything really complicated. When I finished it, I had gained that confidence. I knew that I could code pretty much anything so long as I put my mind to it.

Has that ever appeared on my CV? Nope.

I strongly believe that most good programmers will have a hidden iceberg or two like this that doesn’t appear on their CV or profile. Something they think isn’t really relevant, because it’s not “proper experience”, but which actually represents an awesome accomplishment. A good question to ask a potential “good programmer” in an interview would be “can you tell me about a personal project - even or especially one that’s completely irrelevant - that you did in your spare time, and that’s not on your CV?” If they can’t (unless their CV is 20 pages long), they’re probably not a good programmer. Even a programmer with an exhaustive CV will have some significant projects that are missing from there.

#5 : Variety of technologies

This one’s pretty simple. Because of the love of learning and toying with new technologies that comes with the package of being a “good programmer”, it’s inevitable that any “good programmer” over the age of 22 will be fluent in a dozen different technologies. They can’t help it. Learning a new technology is one of the most fun things a programmer with any passion can do. So they’ll do it all the time, and accumulate a portfolio of things they’ve “played around with”. They may not be experts at all of them, but all decent programmers will be fluent in a large inventory of unrelated technologies.

That “unrelated” bit is the subtle twist. Every half-decent java programmer will be able to list a set of technologies like “Java, J2EE, Ant, XML, SQL, Hibernate, Spring, Struts, EJB, Shell scripting”, etc.. But those are all part of the same technology stack, all directly related to each other. This is possibly hard to recognise for non-programmers, but it is possible to tell whether their technology stack is varied by talking to them about it, and asking them how the different technologies they know relate to each other. Over-specialisation in a single technology stack is an indicator of a not-so-good programmer.

Finally, if some of those technologies are at the bleeding edge, that’s a good positive indicator. For instance, today (November 2007), knowledge of Merb, Flex, RSpec, HAML, UJS, and many others… Please note that these are fairly closely related technologies, so in a couple of years, someone who knows all these will be equivalent to someone familiar with the Java stack listed in the previous paragraph.

Update: As a clarification to this point, there’s in fact two indicators here: variety and bleeding edge. Those are separate indicators. A good variety of technologies across a period of time is a positive indicator, whether or not the technologies are bleeding edge. And bleeding edge technologies are a positive indicator, whether or not there’s a variety of them.

#6 : Formal qualifications

This is more a of non-indicator than a counter-indicator. The key point to outline here is that formal qualifications don’t mean squat when you’re trying to recognise a good programmer. Many good programmers will have a degree in Computer Science. Many won’t. Certifications, like MCSE or SCJP or the like, don’t mean anything either. These are designed to be accessible and desirable to all. The only thing they indicate is a certain level of knowledge of a technology. They’re safeguards that allow technology recruitment people in large corporations to know “ok, this guy knows java, he’s got a certification to prove it” without having to interview them.

If you’re hiring for a small business, or you need really smart developers for a crack team that will implement agile development in your enterprise, you should disregard most formal qualifications as noise. They really don’t tell you very much about whether the programmer is good. Similarly, disregard age. Some programmers are awesome at 18. Others are awesome at 40. You can’t base your decisions about programmer quality on age (though you might decide to hire people around a certain age to have a better fit in the company; please do note that age discrimination is illegal in most countries!).

As a final note to this, in my experience most average or poor programmers start programming at university, for their Computer Science course. Most good programmers started programming long before, and the degree was just a natural continuation of their hobby. If your potential programmer didn’t do any programming before university, and all his experience starts when she got her first job, she’s probably not a good programmer.
Disclaimer

None of the indicators above or below are sure-fire indicators. You will find great programmers who break some of those moulds. However, my view is, you’ll rarely find a great programmer that breaks all of them. Similarly, you may find poor programmers that meet (or appear to meet) some of these criteria. But I do strongly believe that the more of these criteria a programmer meets, the more likely they are to be one of those elusive “good programmers” that, as a business guy, you need to partner with.
The criteria in bullets

So, in summary, here are some indicators and counter-indicators that should help you recognise a good programmer.

Positive indicators:

* Passionate about technology
* Programs as a hobby
* Will talk your ear off on a technical subject if encouraged
* Significant (and often numerous) personal side-projects over the years
* Learns new technologies on his/her own
* Opinionated about which technologies are better for various usages
* Very uncomfortable about the idea of working with a technology he doesn’t believe to be “right”
* Clearly smart, can have great conversations on a variety of topics
* Started programming long before university/work
* Has some hidden “icebergs”, large personal projects under the CV radar
* Knowledge of a large variety of unrelated technologies (may not be on CV)

Negative indicators:

* Programming is a day job
* Don’t really want to “talk shop”, even when encouraged to
* Learns new technologies in company-sponsored courses
* Happy to work with whatever technology you’ve picked, “all technologies are good”
* Doesn’t seem too smart
* Started programming at university
* All programming experience is on the CV
* Focused mainly on one or two technology stacks (e.g. everything to do with developing a java application), with no experience outside of it

Thanks for reading.

by Bruce Byfield

Operating systems come with cultures as much as codebases. I was forcibly reminded of this fact over the holidays when several family members and neighbors press-ganged me into troubleshooting their Windows computers. Although none of us had any formal computer training, and I know almost nothing about Windows, I was able to solve problems that baffled the others — not because of any technical brilliance, but because the free software culture in which I spend my days made me better able to cope.

The origins of these cultures are more or less obvious. Windows and other proprietary software are the products of a commercial software market. In this culture, information flows mainly in one direction — from the manufacturer — and companies’ obsession with so-called intellectual property and vendor lock-in encourages them to force users into the role of unquestioning consumers.

By contrast, free software culture has two sources. The first is the Unix culture that Eric Raymond describes in The Art of Unix Programming, with its emphasis on excellence. The second is the Free Software Definition’s four freedoms.

True, end-users are unlikely to be interested themselves in the freedoms to study or improve the program. But the availability of these freedoms for developers conditions everybody’s expectations. Moreover, the freedoms to run and redistribute programs relieve everyone of some of the more unwelcome aspects of proprietary culture. At any rate, together these sources create a more active, more demanding set of users than is found in proprietary software.
Unsurprisingly, these differences in origins lead to entirely different sets of expectations. Exceptions do occur, of course, and, the more expertise users have, the less pronounced the differences are. Moreover, free software like FireFox and OpenOffice.org are becoming more commonplace on proprietary platforms. And, similarly proprietary culture is seeping into free software as it becomes big business.

Still, for the most part, you can expect free software users to differ from proprietary in a number of fundamental ways. Furthermore, whether you are aware of these differences can have considerable impact in your success when marketing or developing software.

1) Free software users expect open licenses and no activation methods

Proprietary vendors like Adobe and Xara who have experimented with GNU/Linux versions of the software usually conclude that free software users will not buy commercial software. However, as companies such as Mandriva and Red Hat have proved, such conclusions are more of a failure to conceive of alternative business methods than an observation of reality. If nothing else, business users will often buy commercially in order to have the comfort of a traditional relationship with a vendor.

However, given any sort of chance, free software users do reject proprietary licenses or activation methods that restrict their freedom to copy and redistribute software. Some may endure proprietary licenses if comparable functionality is unavailable elsewhere. Others may accept a proprietary license for non-essential software like games. But, at the first sign of an alternative, they will abandon a proprietary product. And many, of course, will not even accept these temporary compromises.

If you want to sell to the free software community, forget about making money on the software and see what services you can develop around the software. Or do you think it’s an accident that file-sharing and free culture have roots in the free software community?

2) Free software users expect regular upgrades and patches

Free operating systems are set up for instant gratification. You want a piece of software? Switch to the root account, and in five minutes you have it installed and ready to use without rebooting.

This daily functionality results in the same high expectations for upgrades and patches. In free software, upgrades and patches are not a once yearly event complete with beta versions and release candidates. They are closer to a daily occurrence. Project maintainers take this responsibility so seriously that many have been known to take personal time from work in order to get a bug or security patch out as quickly as possible.

3) Free software users expect to work the way they choose

Switching from Windows to GNU/Linux, the first thing that users are likely to notice is how many customization options are available just for the look and the operation of the desktop. If anything, they are likely to feel that too many options are available. Often, they cannot imagine ever wanting half the options.

These options are a direct result of the sense of control that free software encourages in its users. Not only do they expect to use menus, toolbars or keyboard shortcuts as their preference dictates, but they expect to control the color, widgets and even placement of desktop features easily and efficiently. If they cross the other way, going from GNU/Linux to Windows, they are apt to feel restricted, that they are being forced to do things the way that the developers want them to do, rather than consulting only their own preferences.

4) Free software users want control of their own systems

For a free software user, one of the most irksome aspects of Windows XP or Vista is that you are constantly being nagged by pop-ups. The system itself notifies you about available upgrades, possible security risks, and the current state of your system. And it’s not unusual for your manufacturer’s software to have its own messages as well as Java and several other programs. Meanwhile, the operating system and one or two other basic pieces of software are phoning home, and lockdown technologies are policing your computing. Sometimes, it seems like your work is being interrupted every 30 seconds or so.

Desktops in free software operating systems are starting to have notifications, but, so far, they are for the entire system. Even more importantly, they can be turned off. Experienced GNU/Linux or FreeBSD users know that routine system events belong in log files, where they can be read at leisure.

As for lockdown or surveillance technologies, forget it. Many free software users are suspicious of comparatively benign automatic survey tools like the Debian Popularity Contest or Smolt, let alone something that takes control from their hands.

5) Free software users explore

I was able to solve two of the Windows problems I faced over the holidays in a matter of moments. One was simply a case of plugging the monitor into the dedicated video card instead of the onboard on the mother board. The other was solved by using a file manager instead of the dedicated tools that came with the new hardware. Asked why they didn’t look around for solutions, those I was helping hemmed and hawed, but eventually they more or less admitted that they were afraid to try.

To me, these reactions epitomize the learned helplessness that proprietary software usually encourages. With only a limited number of tools visible from the desktop — many buried several dialogs down — and most of those tools giving no indication of how they achieve their results — the average Windows user has little incentive to learn how to administer their systems.

However, on free software systems, exploration is easy. Most configuration, for instance, is done using plain text files that you can view from your file manager. And since exploration leads to quick and effective results, the users of free operating systems are encouraged to explore and soon grow to expect the ability to do so. Place them on a Windows system, and they’ll probably complain that they are isolated from the system as effectively as if they were trying to type wearing mittens.

6) Free software users expect to help themselves

Free software users have no objection to help files. If anything, they love them. To the traditional Unix man pages, they have info pages at the command line, and online help on the desktop. But they are far less likely than proprietary users to expect formal technical support. Instead, what they expect are the means to help themselves — not only help files, but easily accessible configuration files (preferable in human-readable plain text), and mail forums and IRC channels where they can consult each other. A Do-it-yourself philosophy runs deep in almost every free software user. The longer they have been using it, the deeper it runs.

7) Free software users don’t fear the command line

To Windows users, the command line is a fearful place. And no wonder, considering its awkwardness and limitations; a new one was one of the features promised for Vista and dropped. But the command line is much more friendly in free operating systems than in Windows, and many users soon become comfortable with it.

In almost every case, a typed command has more options and power than its graphical equivalent in free software. Users will gladly use the graphical interface, but, when its limitation is reached, many still happily drop down into the command line. Partly, it’s a geek macho thing, but a large part of the habit is sheer practicality. Unless interface designers manage to offer the same functionality as the command line, that’s not going to change — and, frankly, not many are trying to do so.

Free software users learn software categories, not programs

Blocked from easily learning about their operating system, consumers of proprietary software operate as if casting magic spells — ritual recipes that, if used exactly right, will give them the desired results. Added to the fact that proprietary software can be expensive, they tend to become familiar with one office suite, and one web browser and mail reader. As a result, switching software can be traumatic to them.

By contrast, free software users come to have both the system knowledge and the software selection to experiment. They may settle on one piece of software in each category, but only after experimenting with all the possibilities. Should they need a feature that their choice lacks, they’ll find a temporary or permanent replacement, trusting that other features they need will be in both programs. Far more than proprietary users, their loyalty is provisional, and dependent on quality and selection. They lack the financial investment that keeps proprietary users locked-in to a particular vendor, and see no reason to change that.

9) Free software users expect access to developers and other employees

The free software community prides itself on being a meritocracy, where status is the result of accomplishment and contribution. Since status depends on what you have done recently, it is less fixed than in a traditional office. Even where obvious leaders exist, they are more often first among equals than managers with direct control over others. That, in turn, means that community members cannot isolate themselves behind a wall of authority. Community members generally have direct access to project leaders, generally via email and IRC. Nor do most project leaders object to this arrangement.

Even in companies, traces of this flat structure exists. Instead of resisting it, sensible managers will accept it and claim a special place solely because of their position.

Conclusion

How long these characteristics of free software will continue to exist is uncertain. In the last few years, a new category of free operating system users has begun to emerge: those who remain entirely on the desktop. In the rush to become more user-friendly — which usually means more like Windows — the chance exists that the free software user culture will become unrecognizable to long-time users in the next few years.

However, that seems unlikely. For the most part, the purely desktop user’s sensibilities are not sapping the free software culture so much as being accommodated and isolated as a special case. Unless they are content to stay in their normal routines, within a year or two, desktop users will face some problem that they cannot solve without becoming either more adventurous or more in contact with the mainstream culture. When that happens, they will have taken the first steps away from being passive consumers and towards becoming the owners of their own machines.

I know how easy it is to make Unix machines authenticate to LDAP server, but with Windows to do that you need a Domain Controller !
If you just want to do simple LDAP authentication , then you can use this login replacement for windows : www.pgina.org

It is called pGIna , and works just like pam on linux , I tried it and it works very well with openldap , there are plugins for other things….like authenticating against MySQL database !

This is really cool. you can create users on LDAP or MySQL…..and no need for a Domain Controller. It also supports some Domain functions , like startup scripts, and mobile profiles.

This code is an example for using libUSB to deal with USB devices and controllering them without writing kernel modules.
It is usefull if you want to control homemade usb devices or if you want to write a driver for unsupported usb device in your OS.
The following example searches for any USB mouse attached to your system , removes the kernel driver , opens the device and keeps polling it for bytes and prints them.

#include < iostream >
#include < cstdlib >
#include < stdio.h >
#include < string.h >
#include < usb.h >
#include < usbpp.h >

#define DEBUG_LEVEL 0

#define PROTOCOL_MOUSE 2
#define PROTOCOL_KEYBOARD 1

using namespace std;

struct usb_bus *busses,*bus,*dbus;

int findDevice(int PROTOCOL,struct usb_device *device){
bool found=false;
struct usb_device *dev;

usb_find_busses();
usb_find_devices();
busses=usb_get_busses();
for (bus=busses;bus && !found;bus=bus->next){
for (dev=bus->devices;dev;dev=dev->next){
if (dev->config->interface->altsetting->bInterfaceProtocol==PROTOCOL) {dbus=bus;found=true;break;}
}//end of devices loop
}//end of busses loop
if (!found) return -1;
*device=*dev;
return 1;
}

int main(int argc, char *argv[])
{
struct usb_device *dev;
char *buf;
int n,x,r;
char string[50];
bool found=false;
usb_dev_handle *fdev;
usb_set_debug(DEBUG_LEVEL);
usb_init(); //initilize the usb library

if (findDevice(PROTOCOL_MOUSE,dev)<0){ //search for a USB mouse , you can change it to keyboard,joystick…etc
printf(”Unable to find the required device !nexsitingn”);
exit(1);
}

printf(”Now we are dealing with device from vendor ID : %d (%x) n”,dev->descriptor.idVendor,dev->descriptor.idVendor);
printf(”Trying to open the device…n”);
if (fdev=usb_open(dev)) printf(”Device opened successfully.n”); //Here we open the device , just like fopen
else { printf(”Operation failed :-(n”); exit(1);}

buf=(char*)calloc(1,100);
if (usb_get_driver_np(fdev,0,buf,100)) printf(”Kernel Using Driver : %sn”,buf); //Trying to get the kernel driver name (optional)
else printf(”Could not read the driver name :-(n”);

if (usb_detach_kernel_driver_np(fdev,0)) printf(”Device detached successfully from the kernel.n”); //detach the driver from the kernel , seems to be just like rmmod , but it always returns errors , however , it wroks
else printf(”Error detaching the device :-(n”);

if (r=usb_claim_interface(fdev,0)) printf(”Interface Claimed !!n”); //reserving the device interface for our applicatoin , if another driver/software is using the device , it will return ‘interface busy’
printf(”Interface Claim Status : %dn”,r);

printf(”Device Protocol : %dn”,dev->descriptor.bDeviceProtocol);
printf(”Report Length : %dn”,dev->descriptor.bLength);
printf(”Decriptor Type : %dn”,dev->descriptor.bDescriptorType);
printf(”End Points : %dn”,dev->config->interface->altsetting->bNumEndpoints);
printf(”Interface Class : %dn”,dev->config->interface->altsetting->bInterfaceClass);
printf(”Protocol : %dn”,dev->config->interface->altsetting->bInterfaceProtocol);
printf(”Interface Number: %dn”,dev->config->interface->altsetting->bInterfaceNumber);
printf(”Device Filename : %sn”,dev->filename);
printf(”Bus Dir Name : %sn”,dbus->dirname);

usb_get_string_simple(fdev,dev->descriptor.iManufacturer,string,sizeof(string));
printf(”Device Manfucaturer : %sn”,string);
usb_get_string_simple(fdev,dev->descriptor.iProduct,string,sizeof(string));
printf(”Product Name : %sn”,string);
usb_get_string_simple(fdev,dev->descriptor.iSerialNumber,string,sizeof(string));
printf(”Device Serial Number: %sn”,string);
printf(”End point addresses : 0x%xn”,dev->config->interface->altsetting->endpoint->bEndpointAddress);

while (string[0]!=3){
string[0]=string[1]=string[2]=string[3]=0;
r=usb_interrupt_read(fdev,0×81,string,4,0); //I am reading 4 bytes using interrupt read , note that not every usb device supports interrupt read/write
for (x=0;x<4 && r>0;x++)
printf(”%d “,string[x]);
printf(”n”);
usb_clear_halt(fdev,0×81); I need to reset the device node because of some devices (usually keyboards) keep sending the same bytes even after releasing the key !
}

printf(”Closing Device.n”);
usb_release_interface(fdev,0);
usb_close(fdev);

return EXIT_SUCCESS;
}
To compile this code , you need usblib and the library headers.
The output of this program will be 4 numbers
x1 x2 x3 x4

I got this problem with postfix 2 , when there is incoming mail for local user , it doesn’t create a maildir in /var/mail.
I have a user called ittest created in LDAP , and mapped to receive emails from another local user through /etc/aliases.
I fixed the problem by uncommenting this line from main.cf :
local_recipient_maps =
Leaving it empty like that means that postfix should accept emails for any loca user with no restriction , that was the default for postfix 1.x
There was no need to add any LDAP specific options to postfix.

Most newbies are asking me how to do things they used to do on Windows….
There are alternatives for almost everything…but when it comes to voice/video chat on Yahoo/MSN/GTalk , then it is a dead end !

It is true that Gyach Enhanced used to support voice/video for yahoo since more than 2 years….but it is not maintained anymore, and wasn’t working all the time.

Now I found a really good alternative for calling almost everything !

it is called gtalk2vip.com , read the faq here : http://gtalk2voip.com/faq.shtml

To start , you need a SIP client , any SIP client should work (ekiga,gizmo,linphone……) personally I use twinkle on linux and I already have a voip account.
If you don’t have a voip account configured , you can get free one from gtalk2voip…..or if you use Ekiga, it will create one for you during the first time wizard.
Once you have the voip account configure in your client , you can start calling other IMs :

# GTalk: user@domain.com can be reached by calling to sip:user_at_domain.com@gtalk.gtalk2voip.com
# MSN: user@domain.com can be reached by calling to sip:user_at_domain.com@msn.gtalk2voip.com
# Yahoo: user@yahoo.com can be reached by calling to sip:user_at_yahoo.com@yahoo.gtalk2voip.com

I tested it on GTalk ,MSN and the voice was very clear and quick….but it didn’t work with Yahoo Messenger for some reason.
Regarding Gizmo , last month I mentioned that the new version supports calls to yahoo/msn/gtalk. Later , I found that it uses the same gtalk2voip service. So it is not like they have done anything……(except importing your contacts).