hi guys.i already know python and i've been programming with it in linux.but i want to learn my second language.consider this that my goal is to create my own distro.which language i have to learn ? C or C++ ?

Bash and POSIX shell scripting. POSIX shell (typically dash) scripts are used for initial ramdisk support -- booting environment --, and Bash scripts for system startup, service scripts, and so on. This is what you will be mostly working with, if you develop your own distro.

To see what kind of work it is to develop a source-based distro, check out Linux From Scratch and its subprojects. For that sort of work, I recommend learning C (but only after you have mastered the shell scripts!), because the critical infrastructure -- the kernel, most libraries -- is written in C. If you break any of those, your distro is useless, no matter how bug-free your C++ stuff might be. You don't need to be able to write much C, but you must be able to apply patches, and read C well enough to see if the patches are applied correctly and make sense. It's not easy, though.

However, I'd recommend you base your work on top of a well-known distro, maybe Debian or Fedora. Not only do you benefit from the massive amount of work already done, but you only need to tweak the bits you feel can be done better. In that case, I'd concentrate on the shell scripts (because almost all distribution development tools rely on reliable scripts), and especially development tools: autotools (especially configure script use), make, cmake, install, filesystem hierarchy standard (and the differences to your chosen base distro), and any guidelines related to your chosen base distro. Being at all versed in that stuff is orders of magnitude more important than being able to read or write C or C++ (or any other programming language).

I'm sure you'll get replies to the tune of "why waste time developing yet another distro, when you could be contributing to an existing one?". Ignore them. The best way to learn this stuff is to try to do it all yourself. Expect you'll rewrite your build scripts and massively overhaul your approach, possibly even switch base distro, as you go along. All that knowledge is something you can only get by doing it yourself. There are already enough contributors that know their own small corner, but are completely oblivious to the rest, or indeed to the whole; strive for something more, please. At some point you will notice you have enough skills to be really useful to any Linux distribution, and that point is where you choose whether you wish to contribute to one or more existing distributions or start your own.

1 members found this post helpful.

thank you for your answer.about LFS.i created an os based on lfs. but it's just copy and paste the command and there's no useful information and i don't learn anything.do u know any books or sites that could help me where to start.because i don't know where to start !

You must have read a different Linux From Scratch book, then. The hints alone contain a wealth of useful information, to say nothing of the Beyond Linux From Scratch subproject.

If LFS is too in-depth for you, start at Debian Derivatives, especially the Debian Derivative Guidelines and DEX. I don't know your background and what you already know, so I cannot be much more specific than that; you'll just have to try to find out what you need next. I recommend picking something that is immediately useful to you, and then just keep expanding your knowledge from there.

There is no single guide or book about Linux, or even how to build your own Linux distribution. Not one I'd ever recommend, anyway.

Experiment, build, and do not be afraid of making errors. Just following perfect instructions to building "your own" distribution has very little educational value; you won't learn anything that way. You should be making tweaks that make the end result fit you better; and when those tweaks break things, you should find out why. Knowing what works is not enough: you need to know what does not work.

1 members found this post helpful.

i read the exact book you're saying. but maybe i didn't read it carefully. i also went through BLFS, but just before making GNOME, i dropped it.i mean it was just like do this, do that, execute that command. my point is is which state i should start making changes on the packages that i'm installing.for example i know that i should make a few changes in gnome package to adjust it as my standards, but should make change in packages like alsa or libexec or something like that ?
as you may understand from my posts, i've never wrote a system programs.that's the most weakness of mine that i should work on it.
what's deep about it. most of it is just copy and past the commands. but i do admit that i learn a lot of things about compiling the kernel.

System libraries? Well, no. You can make some of them a bit faster or smaller by supplying correct compilation flags (-O3 -fomit-frame-pointer -march=native -mtune=native or -Os -fomit-frame-pointer are a good start). On embedded architectures you have very slow storage media, so minimising library size yields often a noticeable boot speedup.

However, adjusting the compilation flag has a nasty tendency to break fragile code. It means that a simple thing like above, surprisingly often leads to a broken library. Therefore, you need to run the test cases, and check their results. That's how I caught one test error in glibc myself.

Many low-level applications do have off-tree patches. For example, I like to have a backup mail client on my servers. I also use Maildir mailboxes. Last time I compiled those from sources, I had to apply various patches to get Maildir support for my clients. These are not as likely to break anything, but some packages have build-time tests you can run.

If you happen to have a slow machine, or an embedded one (Raspberry Pi, and pico-SAM9G45 are both very small and should be fun to play with), optimizing the boot process yields immediate rewards; you can cut a lot off the boot time. You can also play with the boot sequence, making it completely graphical, and use your own graphics.

When doing that, you also learn how the parts slot together: how the kernel first loads and runs the initial ramdisk (if configured to do so; you don't have to use one), which loads all required kernel modules and populates the /dev, then mounts the root filesystem and runs init which in turn starts running the init scripts and/or inittab. If I had time, I'd replace the traditional init with runit or systemd, and streamline the boot system.

When you get bored, you can use your Python skills, and create useful applications or fun little games to run on that embedded device. Both pico-SAM9G45 and Raspberry Pi are quite affordable. pico-SAM9G45-X costs about $105 USD with a 4.3" and $120 with a 7" touch-screen display, Raspberry Pi only about $35, if you can get hold of one. Raspberry Pi connects to a HDMI monitor, and has an auxiliary graphics processor (running proprietary firmware) to display HD video and do 3D graphics; pico-SAM9G45 is just a framebuffer device without acceleration.

The amount of detail. If you just follow the commands without reading the discussion (or the hints), never apply any patches or try to tweak the compile flags, it's just a cumbersome installation. When you do tweak them, you'll find the book has warnings about the most common caveats, and the hints and the mailing list provides a lot of useful info (about what has been tried and working, what does not, and so on).

Following guides and reading the background material is like taking a course. It gives you a set of tools. You need to apply those tools to real problems, to get the hang of it, the "motor memory" for their use. I mean, knowing how those tools work is academic knowledge. You need to have experience on how they are applied, how they are used to solve real problems.

Could you start with something that you need right now? Better boot splashes? Boot sequence optimization? A full-blown server?

Just following something like LFS and BLFS will only show you exactly how to build a working Linux distribution from scratch. Using something like Debian as a base distribution will just get there faster. The point is, you need a purpose for your distribution, a reason why the existing distributions are not good enough. (Compiler flags are one reason if you have nothing else, but don't expect miracles.) The purpose will also tell you whether you should go with a from-scratch like LFS/BLFS or Gentoo, or using something like Debian as the basis.

The amount of information applied when building a full distribution is astounding. Every single part of it is tweakable, malleable. Both when building from scratch, but also when using something like Debian. (Typically, you'd probably have to build or rebuild some packages from scratch too.) Many times you have multiple alternative solutions. For example, you can replace udev with something else. If you don't need hotplug, say you have an embedded reader or something, you can remove udev, initial ramdisks, and minimize the system footprint, also making boot times shorter.

I don't think it is possible to learn much of that information by following guides or books. You need to poke and prod to see what happens. If you do that without a goal, you're not going to learn that much.

The system libraries and basic services (like init scripts, udev, cron, syslog, etc.) are the lowest level part. This stuff is pretty stable, but you do have alternatives and different approaches. Services and applications built on top, can be either patched, or configured. For example, I've developed a method for server administration that uses local groups as the access control, where all administration is done using personal user accounts; the roles are distinct from the user accounts, defined via group membership. It exists completely in the configuration files. Apache default configuration is utter crap, it really only works for a single-site server. Anything more complicated, and you're better off writing the configuration from scratch entirely. In fact, I even move it to a different directory (from /etc/apache2 or /etc/httpd to /etc/www) so distribution updates won't b0rk it up.

I'd warmly recommend you first think of a problem you'd like to solve, and then see how you could go about it. Is reconfiguration (rewriting config files) enough? Do you need to apply patches? Do you need to rebuild binaries?

If you think of something, I might be able to help you with some ideas and approaches you might find not just useful, but fun, too.

thank you for your great answer.
i've been working with linux for almost one year an half and before that i studied microsoft and cisco, and you won't believe how much i love linux.it's fast, easy and more important every second i'm working with linux, it teaches me a lot of thing. it even make me feel that i didn't know anything before.so my main purpose is to learn this great OS, and not just be able to work with it like i've been doing, but i want to explore and touch it.of course because i studied cisco i want to add features to my distro so i can work more easily with cisco switches and routers.
so for sum things up, you think the LFS should satisfy my needs ?

If you want to make it easier for servers and workstations to work with Cisco stuff (say management or monitoring?), I'd actually go with Debian instead. I don't know what kind of functionality is lacking from current tools, as I haven't administered Cisco switches or routers in a very long time. But certainly the base OS is solid, so then you could concentrate on developing the utilities.

To do that, you'd obviously need to first delve into how Debian manages network resources. Interfaces and their aliases, routing, firewall (iptables), and services like dhcpd and NetworkManager or WiCD.

On the other hand, I remember having trouble analysing network outages (stuff like broken cables, b0rked PHYs, and so on), when laptops were much bigger, and affordable tablets were Sci-Fi. Nowadays a small tablet is probably excellent for that stuff -- or perhaps even an embedded ARM machine with a custom Python GUI. I'd loved to have one with tools like connecting to switches, showing a nice GUI (since there is really no room for a real keyboard on such a device), pinging, SSH etc. clients, maybe even a minimal HTTP/DHCP server with tcpdump capability to find out workstation connection problems. Think like the smartphone of network diagnosis tools. If you want to build an appliance like that, then I'd say LFS is a better way to go (you can make it really, really tight; not need much resources, probably would even run on a $100 reader!), although Debian would be an okay choice for that, too.

In other words, I think LFS will give you a better picture of the low level stuff. Something like Debian will let you concentrate on the applications and services, the higher level stuff.

Why not do both? I have a pretty powerful workstation (Athlon II X4 640, 6GB RAM, two-disk soft-RAID0/1), which easily runs a couple of virtual machines for testing. That way you save a lot of trouble rebooting, have a very nice user interface at all times (without having to install X11 on the development machines [virtual images]). Why not do the same? It would allow you to have many images, and really, only the amount of RAM you have limits the number of images you can run in parallel. They don't eat that much CPU, when not doing any significant work.

Pick something you want your Linux server/workstation/embedded appliance to do better, and start hacking! In my opinion, that is the absolutely best approach. It is even better if you do not limit yourself to one approach, but try something on top of LFS, and something else on top of Debian, and something yet totally different on RHEL/CentOS/ScientificLinux. Recognising the differences will help you see the underlying logic through their commonalities.

thank you.one more question.what do u think about suse studio ? could it help me to developing my distro ?

I have no idea. Because of the business agreements done by the maintainers (Novell and Attachmate), I have not (and will not) touch it even with a ten-foot pole.

Pity; years ago, it was a very good distribution.

At this point, there are a couple of distributions I will not touch:

• SUSE
  Business agreements with e.g. Microsoft. An attempt to imply that somehow Linux infringes some Microsoft property. SUSE owners must know that there is no basis for that, but apparently they see it as a good business: scaring customers away from competing Linux distributions, hopefully locked into their hands.
  I consider those kinds of business deals not only reprehensible, but I think they should be illegal (wrt. antitrust law).
• OpenSUSE
  Simply due to their association with SUSE. Although it is a separate project, there are still some ties left behind, and I really don't want to get tangled in any of those.
• Oracle Linux
  Oracle does not care about their customers, they care only about making money off their customers. Oracle Linux itself is a badly packaged, inferior clone of Red Hat Enterprise Linux. Why anyone would use it is beyond my understanding.
• Mandriva Linux
  For a few years now Mandriva S.A. has had financial difficulties. I fear it will be sold to an entity hostile to free software: to be used for fear-mongering among Linux users, or a showcase for how Linux users need some kind of patent protection or similar nonsense.

Remember, this is just my opinion. Others certainly disagree.

thank you for your answers.