Marcelo Toledo

Our new baby is about to born, look how beautiful:

If you enjoyed this post, make sure you subscribe to my RSS feed!

I was looking for something related to the linux kernel, went to fall in ibm website displaying these two documents, written almost three years ago, introducing some very basic idea of the linux 2.6 kernel, two sets of around 20 pages each, interesting introductory material:

Hacking the Linux 2.6 kernel, Part 1: Getting ready

Hacking the Linux 2.6 kernel, Part 2: Making your first hack

If you enjoyed this post, make sure you subscribe to my RSS feed!

This is an interesting position that just opened, if you are interested, mail me:

Company:
Pioneer in the implementation of hotspot networks and in the development of Wi-Fi access systems in a Global way, Vex’s goal is to provide easy and fast wireless Internet access in public locations. We make our infrastructure available for our partners – Telecom Operators and Internet Service Providers around the World - that offer the network service to their customers and end-users. In this sense, Vex operate as an infrastructure wholesaler.

Description:
This position requires in-depth knowledge of and previous experience with embedded operating systems, IPC mechanisms, I/O subsystems and hardware interfaces. Must have worked in kernel space and be very familiar with the Linux Open source issues. Be able to do coding in C/Assembly. Must have worked with embedded software components such as boot loaders, board support packages, device drivers and kernel modules. Must be capable of analyzing and debug kernel and application level anomalies and interactions in an embedded Linux environment. Must have strong experience in low-level system software concepts including interrupt handling, multi-tasking, and multi-platforms. Must be conversant with embedded software development tools, debuggers, compilers, etc. Must have experience working in operating system internals.

Requirements:

• Min 3-9 years of experience in C programming.
• At least 1-2 years experience specifically in Linux Kernel Programming and overall good familiarity with Linux kernel Code.
• This position requires a knowledgeable, experienced software engineer with significant embedded Linux kernel experience.
• Possess a good track record of contribution to Linux code, experience with coding device drivers, strong knowledge of C, and an understanding of microprocessors at the machine level (x86, mips, arm, …). Knowledge in other embedded OS or PC architecture will be an advantage.

Details:

• Location: Brazil, São Paulo (Morumbi)
• Compensation: R$60k - R$78k (CLT)

If you enjoyed this post, make sure you subscribe to my RSS feed!

It’s not a big deal since it’s not the first time this happens, but it’s good to recall what hapenned:

Dan Nicolaescu started the thread in 2007/06/04:

Do you still plan to turn over Emacs maintenance to
someone else?
 
Have you made a decision on who is going to be the new
Emacs maintainer(s)?

RMS replied:

I would still like to do so.
I have not made a plan.

A long thread goes by the next 7 months until RMS decides:

Stefan and Yidong offered to take over,
so I am willing to hand over Emacs development to them.

Welcome Stefan and Yidong, my best wishes.

If you enjoyed this post, make sure you subscribe to my RSS feed!

My friend Camilo Telles did his master thesis on this exact subject, he projected this camera entirely in wood and cheap web cameras, he also wrote a software to integrate all the images in one single, it’s not his work, but it’s similar and very interesting.

Reference: http://adn.blam.be/papervision/

If you enjoyed this post, make sure you subscribe to my RSS feed!

If you look major book sellers for Linux Kernel books, you will be disappointed, there aren’t many titles available, I remember a long time ago, when Alessandro Rubini wrote his first book about Linux Device Drivers, I think it was the first big hit, then shortly it became obsolete, as Linux runs fast.

Accordingly to Amazon the most popular Linux Kernel book nowadays is Linux Kernel Development written by Robert Love, in it’s second edition focused in version 2.6.

I was deeply involved in other subjects, reading piles of books when it came out few years ago. Right now in my vacations I had the opportunity to start reading it, you know, writing kernel code makes me relax, and I must say, Robert has talent, it’s very well written, clear and a not so simple subject becomes accessible, I recommend.

If you enjoyed this post, make sure you subscribe to my RSS feed!

Some guy started studying the Linux Kernel, gently Linus rejected all of his patches, he obviously got frustrated and asked him a question:

On Tue, 21 Dec 2004, Jesper Juhl wrote:
>
> Should I just stop attemting to make these trivial cleanups/fixes/whatever
> patches? are they more noice than gain? am I being a pain to more skilled
> people on lkml or can you all live with my, sometimes quite ignorant,
> patches?
> I do try to learn from the feedback I get, and I like to think that my
> patches are gradually getting a bit better, but if I’m more of a bother
> than a help I might as well stop.

Linus saw the frustration of the poor boy and replied with a motivational message:

To me, the biggest thing with small patches is not necessarily the patch itself. I think that much more important than the patch is the fact that people get used to the notion that they can change the kernel - not just on an intellectual level (”I understand that the GPL means that I have the right to change my kernel”), but on a more practical level (”Hey, I did that small change”).

And whether it ends up being the right thing or not, that’s how everybody starts out. It’s simply not possible to “get into” the kernel without starting out small, and making mistakes. So I very much encourage it, even if I often don’t have the time to actually worry about small patches, and I try to get suckers^H^H^H^H^H^H^Hother developers like Rusty to try to acts as quality control and a “gathering place”.

Btw, this is why even “trivial patches” really do take time - they often have trivial mistakes in them, and it’s not just because there are more inexperienced people doing them - most of _my_ mistakes tend to be at the truly idiotic level, just because it “looked obvious”, and then there’s something that I miss.

So at one level I absolutely _hate_ trivial patches: they take time and effort to merge, and individually the patch itself is often not really obviously “worth it”. But at the same time, I think the trivial patches are among the most important ones - exactly because they are the “entry” patches for every new developer. I just try really hard to find somebody else to worry about them

(It’s not a thankful job, btw, exactly because it _looks_ so trivial. It’s easy to point to 99 patches that are absolutely obvious, and complain about the fact that they haven’t been merged. But they take time to merge exactly because of that one patch that _did_ look obvious, but wasn’t. And actually, it’s usually not 99:1, it’s usually more like 10:1 or something).

So please don’t stop. Yes, those trivial patches _are_ a bother. Damn, they are _horrible_. But at the same time, the devil is in the detail, and they are needed in the long run. Both the patches themselves, and the people that grew up on them.

Linus

If you enjoyed this post, make sure you subscribe to my RSS feed!

I remember when I created my first website, totally different reality from today, the only tool to create a website for “normal” people was geocities and it was not as easy as to create a blog nowadays. Blog was a tool used exclusively by geeks, no normal people had one and it was not a very common word, my first website had one, coded with my own hands with comments and other resources, and since I used Emacs for everything I needed an interface to blog from Emacs.

I created one and worked smoothly, it had syntax highlighting differentiating the subject from the body, I could use flyspell to spell check while I typed, etc. Today I was looking for an interface for the famous wordpress, and what a surprise, we don’t have a wordpress.el, we do have a probably defuncted weblogger.el that don’t even exists in the download area.

It’s interesting how a few areas in Emacs just don’t evolve or die very fast, this blog package is just an example, Emacs is probably my favorite application, it’s an incredible text editor with almost unlimited capabilities because of it’s lisp virtual machine, but the time is passing and it’s not evolving how it should, but I saw many forks of it that didn’t go well, so might not be only the way it’s managed.

Probably it’s just adapting to the way it should be, today if you want to use an operating system like Linux you don’t need to learn how to use a text editor, you don’t need to learn how to program, and years ago it was a must, a requisite. Text editors was a hype, many fights from Vi and Emacs, releases was a boom, to have an idea of the type of the users we had, rms don’t like to release often, because he thinks you can just download the source, compile and use it unstable. See any possibility of hapenning this with new users? Absolutely not. The universe will decrease very fast, a lot packages of the editor will die, only programmers will use it, but I’ll keep using it happily.

If you enjoyed this post, make sure you subscribe to my RSS feed!

I grew up in the middle of hackers, people that learned assembly before even speak, intelligent gentleman seeking the understandings of computers and systems, real computer lovers. Being in front of a computer 20 hours a day couldn’t be considered work, we grew, the first one of us started working, then another one, until one day everyone was well employed and starting a business life.

I always though that we were the beginning of many similar generations, that in ten years we would see ten times more hackers doing brilliant things for the world, but I was wrong, months ago I had a position for a senior C/UNIX programmer and the number of candidates was a shame, seems like people are much more interested in visual basic, delphi and java, and it’s not because there are not many positions available, ten years ago we had almost none.

If you enjoyed this post, make sure you subscribe to my RSS feed!

Inkscape started using Launchpad, this is one of that moments where an image speaks better then a thousand words. Mark has more details about it.

If you enjoyed this post, make sure you subscribe to my RSS feed!