As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I want to play around with some embedded linux. I want it to be able to run on an x86 processor (for start, it will be running on my regular PC). I have looked online, but the ones I have found seem hard to setup or lack proper documentation. So what are some good embedded x86 compatible linux distros that are easy to setup or have good documentation on how to get things setup?
Since the definition of "embedded" vary depending on who you talk to, what is considered an embedded Linux distribution will also vary.
As other have said, you can go with distribution building tool kit, like :
T2 SDE
OpenEmbedded
LinuxFromScratch
Buildroot
You can also use any "standard" Linux distribution, which can often be customized for an embedded environment. They have the advantage of being heavily tested in their normal environment. So you can choose any of :
Fedora (with Revisor, Instalinux)
OpenSuse (with SuseStudio, Instalinux)
Debian (with Reconstructor, Instalinux)
Ubuntu (with Reconstructor, Instalinux)
Gentoo
Slackware (with NimbleX)
CentOS (with Instalinux)
gNewSense (with Builder)
Finally, you can also build your own completely, from source. In that case, BusyBox will probably be helpful since it provide a lot of functionalities and common application. To help you with that, there is the nice 3 parts series : Building Tiny Linux Systems with Busybox (part 1, part 2, and part 3)
You may want to take a look at the OpenEmbedded project. It is a meta-distribution, meaning it's more of a distribution construction kit rather than ready distribution. But using it may take effort on your part. The same applies to all embedded solutions, though.
BusyBox
BusyBox is designed to be a small executable for use with the Linux kernel, which makes it ideal for use with embedded devices. It provides a fairly complete environment for any small or embedded system.
What do you actually mean by "Embedded Linux"? It depends what you want to run on that.
For example you can use OpenWRT, but there are surely others which might better fit your purpose.
If you want to build some multimedia thing, Moblin might be a solution as well.
You might want to look at the Beagle Board.
It's not x86, but decent community of developers, and it will give a good idea how to build and run embedded Linux.(i.e. flash file system, somewhat limited RAM...) and its real cheap!
I can also recommend these two books:
Building Embedded Linux Systems and
Embedded Linux Primer
I'd start by having a look at the output of the buildroot tool which comes with busybox.
You are suggesting that you want to make your own Linux distribution, this is fine but you really need to know how to use an existing one first. I am assuming you understand fully how Linux boots and works on a basic level. You'll need
Some kind of boot media (in some cases this CAN be a rom, but usually isn't) that the firmware can boot from (in most cases the firmware on x86 is some kind of bios, or bios-like - except on things like Macs)
A boot loader - I like to use syslinux because it's easy (and boots from a dos filesystem)
A kernel
A root filesystem of some kind - you can use an initramfs for this in which case, it's loaded by the bootloader and expanded at boot time. Initramfs is cool, it avoids the need for a "real" root fs or block device drivers etc (at the expense of some ram, but ram is easy).
A C library (unless all your exes are static linked)
Some userspace software
I'd strongly recommend using an emulator (such as vmware) to test this, it reduces turnaround time a lot. A development system will need to have rather a lot of disc space, as you'll probably need to compile everything in the above list, and possibly some other tools as well (such as gcc and C library) which aren't small. Your build box will probably need to be running a proper Linux distribution.
I have done this and it's good fun, but frustrating at times (debugging can be a mission in itself)
Happy hacking :)
Busybox + LFS, Gentoo, Arch all do the job well
First to you'd compile your stuff in a chroot jail on dev computer, last you don't need to compile but you need to mirror/keep your own repository because you can't get old packages from official arch repositories.
I suggest debian
Related
I am a non CS/IT student, but having knowledge of C, Java, DS and Algorithms. Now-a-days I am focusing on operating system and had gained some of its concepts. But I want some practical knowledge of it. Merely writing algo code in java/c has no fun in doing. I have gone through many articles where they mentioned we can customize source code of Linux-kernel.
I want to start customizing the kernel as I move ahead in the learning of OS concepts and apply the same. It will make two goals achievable 1. I will gain practical idea of the operating system 2. I will have a project.
Problem which I face-
1. From where to get the source code? Which source code should I download? Also the documentation if possible.
https://www.kernel.org/
I went in there but there are so many of them which one will be better?
2. How will I customize the code once I have it?
Please give me suggestions with detail about how I should start this journey (of changing source code to customize Linux).
Moreover I am using Windows 8.
I recommend first reading several books on OSes and on programming. You need a broad CS culture (if possible get a CS degree)
I am a non CS/IT student,
You'll better become one, or else spend years of work to learn all the stuff a CS graduate student has learnt.
First, you need to be very familiar with Linux programming on user side (application programs). So read at least Advanced Linux Programming and study the source code of several programs, including shells (and some kind of servers). Read also carefully syscalls(2). Explore the state of your kernel (e.g. thru proc(5)...). Look into https://kernelnewbies.org/
I also recommend learning several programming languages. You should in particular read SICP, an excellent introduction to programming. Read also some book like programming language pragmatics. Read something about continuation and continuation passing style. Read the Dragon book. Read some Introduction to Algorithms. Read something about computer architecture and instruction set architecture
Merely writing algo code in java/c has no fun in doing.
But the kernel is also written in C (mostly) and full of algorithmic code. What makes you think you'll get more fun in it?
I want to start customizing the kernel as I move ahead in the learning of OS concepts and apply the same.
But why? Why don't you also consider studying and contributing to some user-level code
I would recommend first reading a good book on OSes in general, notably Operating Systems: Three Easy Pieces. Look also on OSdev.
At last, the general advice about kernel programming is don't. A common mistake is to try adding code inside the kernel to solve some issue that can and should be solved in user-land.
How will I customize the code once I have it?
You probably should not customize the kernel, but if you did you'll use familiar tools (a good source code editor like emacs or vim, a compiler and linker on the command line, a build automation tool like make). Patching the kernel is similar to patching some other free software. But testing your kernel is harder (because you'll often reboot).
You'll also find several books explaining the Linux kernel.
If you still want to customize the kernel you should first try to code some kernel module.
Moreover I am using Windows 8.
This is a huge mistake. You first need to be an advanced Linux user. So wipe out Windows from your computer, and install some Linux distribution -I recommend Debian- (and use only Linux, no more Windows). Become familiar with command line.
I seriously recommend to avoid working on the kernel as your first project.
I strongly recommend looking at some existing user-land free software project first (there are thousands of them, notably on github, e.g. choose some package in your distribution, study its source code, work on it, propose the patch to the community). Be able to build from source code a lot of things.
A wise man once said you "must act your way into right thinking, as you cannot think your way into right acting". In your case, you'll need to act as an experienced programmer would act, which means before we write any code, we need to answer some questions.
What do we want to change?
Why do we want to change it?
What are the repercussions of this change (ie what other functions - out of all the 10's of millions of lines of source code - call this function)?
After we've made the change, how are we going to compile it? In other words, there is a defined process for this. What is it?
After we compile our new kernel/module, how are we going to test it?
A good start, in addition to the answer that was just posted, would be to run LFS (Linux from Scratch). Get a successful install of that and use it as a starting point.
Now, since we're experienced programmers, we know that tinkering with a 10M+ line codebase is a recipe for trouble; we need a bit more direction than that. Here's a list of bugs that need to be fixed: https://bugzilla.kernel.org/buglist.cgi?chfield=%5BBug%20creation%5D&chfieldfrom=7d
I, for one, would be glad to see the one called "AUFS hangs on fanotify" go away, as I use AUFS with Docker on a daily basis.
If, down the line, you decide you'd rather hack on something besides the kernel, there are plenty of other options.
From your question it follows that you've already gained some concepts of an operating system. However, if you feel that it's still insufficient, it is OK to spend more time on learning. An operating system (mainly, a kernel) has certain tasks to perform like memory management (or memory protection), multiprogramming, hardware abstraction and so on. Neither of the topics may be neglected - they are all as important. So, if you have some time, you may refer to such useful books as "Modern Operating Systems" by Andrew Tanenbaum. Special books like that will shed much light on all important aspects of a modern OS. Suffice it to say, Linux kernel itself was started by Linus Torvalds because of a strong inspiration by MINIX - an educational project by A. Tanenbaum.
Such a cumbersome project like an OS kernel (BSD, Linux, etc.) contains lots of code. Many people are collaborating to write or enhance whatever parts of the kernel. So, there is a common and inevitable need to use a version control system. So, if you have an intention to submit your code to the kernel in future, you also have to have hands on with version control. Particularly, Linux relies on Git SCM (software configuration management - a synonym for version control).
So, once you have some knowledge of Git, you can install it on your computer and download Linux source code: git clone https://github.com/torvalds/linux.git
Determine your goals at Linux kernel modification. What do you want to achieve? Perhaps, you have a network card which you suspect to miss some features in Linux? Take a look at the other vendors' drivers and make an attempt to fix the driver of interest to include the features. Of course, this will require some knowledge of the HW, and, if the features are HW dependent, you will unlikely succeed to elaborate your code without special knowledge. But, in general, - if you are trying to make an enhancement, it assumes that you are an experienced Linux user yourself. Otherwise, how will you understand that some fixes/enhancements/etc. are required? So, I can't help but agree with the proposal to postpone Windows 8 for a while and start using some Linux distribution (eg. Debian).
If you succeed to determine your goals (eg. if you find a paper describing some desired changes in Linux kernel or if you decide to enhance some device drivers / write your own), you will be able to try it hands on. However, you still might need some helpful books, but, in this case, some Linux-specific ones. Also, writing C code for the kernel itself will require one important detail - you will need to comply with a so called coding standard, otherwise Linux kernel maintainers will not be able to accept your patches.
So, I made an attempt to outline some tips based on your current question. Of course, the job of kernel development has far more broad prerequisites, but these are which are just obvious.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 8 years ago.
Improve this question
I see that this question may appear broad, but it's actually very specific, and should have a specific answer.
I've come across many job postings in the past few years that list 'linux' as a required skill. In my experience as a developer, I've mostly worked out of a Windows operating system, and I'm aware that some of the C++ code I've used is specific to the Windows OS, and I'd assume that many of the shell commands are also specific to Windows.
So what I wonder is: when someone says you should 'know' Linux, what exactly are they referring to, or, in other words, what things specifically should I know about Linux to be able to call it a skill?
You should know
the shell language (and the relevant commands like grep, sed, ...)
the most popular package-managers/package-formats and how to use them (deb, rpm, ...)
how and where to configure basic system-wide things (e.g. grub, fstab, ...)
the basic architecture of linux systems (boot stuff, init system, kernel, userland)
common concepts (e.g. POSIX, FHS)
toolchain things (as Hi-Angel already outlined: gcc, clang, gdb and other tools)
I advise against installing things like gentoo for getting into linux. That is quite unrelated and you'll have to deal with a lot of distribution-specific pitfalls (I am a gentoo dev).
Use something which is commonly used, like OpenSUSE or Debian to learn things.
Linux is part of the *NIX family of Operating Systems. If Linux is a job requiement, then it probably means that your employer uses *NIX OS's and therefore want you to be familiar with how Linux and similiar operating systems work.
The most important thing you need to know is how NOT to use a gui, but rather a text-based console.
That does mean you ought to know at least basic GNU/Linux commands, and understand at least abstractly how are things work there (i.e. what is kernel, what is X server/client, what is window manager, what is file rights, users, groups). Actually it is easy to learn, just try to install some linux distro from a source code. E.g. Gentoo. It would teach you how things are works there.
Also, since you are looking for a developer job, you ought to have a little
coding experience in GNU/Linux. As I recall what could wonder you as you came from Windows®, it is the fork() function, and a missing need to tackle with wchars — because there is everything in UTF8. Also in GNU/Linux you may find something like offline MSDN — so called manual. If you install a few developer man packages, you may find there an offline description for many system and C-specific functions.
A few more tips: α) The /proc/ filesystem. You may find there directories which are actually PIDs of running processes. You may find there many useful info. E.g. the /proc/somePID/exe is a symbolic link to the executable file of the running process. β) Almost every GNU/Linux distro contain many tools which would be useful for programming. gcc (compiler), nm (list symbols from object files), md5sum, hexdump, gdb (debugger), objdump. γ) Everything is a file. That does mean that e.g. if you wanted to create an image of a usbstick, you don't even need a specilized tools, you may just find it's file in the /dev/ directory, and with dd utility, which just copying a file content, write it to a file. δ) Everything you installed you can next launch from a terminal, that is, you don't need to seek for executable. An executable file usually installed somewhere in /usr/bin/, but anyway, it would always be in your $PATH variable.
difference between Linux kernel and UNIX kernel(such as FreeBSD) from programmer's point of view.
I searched several articles about this. They compared these from User's view and Administrator's view also from Company's manager's view.
Can any body find article or say something from programmer's view?
The programmer I means, both user land programmer or kernel level programmer?
Any hints or enlightenment is really appreciate.
Wish this is not a cliche question make everybody sick. :P
From a standards point of view there really isn't any difference. Linux is a "POSIX" compliant OS, FreeBSD, Mac OS X and Solaris are also all "POSIX" compliant. In theory at least.
Once you move past the standards there are quite a few differences. Linux as inotify, udev and a bunch of other systems that are unique to it. FreeBSD has kqueue. There are differences in their exact implementations of things like ptrace. For example Mac OS X's ptrace has almost no functionality that you will find in the other Unix systems.
Beyond custom libraries there are differences in development tools. Solaris and FreeBSD have dtrace. Linux has valgrind. Mac OSX has instruments.
What level you are looking at will affect what differences you see or don't see.
For a userland programmer, there is no difference. The userland programming will be coding to a language VM like C and it will be up to the C library routines to translate that into lower level system calls.
Those using other tools such as Perl, Python, Java and so on, are even more removed from the kernel so it will not directly affect them either.
In terms of the kernel programmer, the differences are likely to be significant since the kernels themselves are different. I haven't seen the FreeBSD internals although I've done a fair bit of work inside Linux, so I can't comment intelligently on the low-level differences but (and this final bit is informed opinion, not gospel), since they run independent development streams, the chances of having exactly the same view is small.
I would like to generalize a build system to compile on several (somewhat similar) platforms. What is a good method for determining the type of host that the shell script or Makefile is running on. I would like to distinguish between mac and linux, but also different specific distributions of linux (e.g. RHEL, Ubuntu). Cygwin is not important for me, but if you include it in your response I am sure others will find it valuable.
The rationale may include using the host type to fetch and install the correct versions of binary packages when it is more convenient to do so than compile from source. In addition, some commercial software is binary-packaged for specific distros, so part of the motivation is to grab the right binary.
Thanks,
SetJmp
Autotools to the rescue. It has tons of macros that help you do this kind of stuff.
http://www.lrde.epita.fr/~adl/autotools.html
uname -a to distinguish major *nix variants
Not so sure what the best way to distinguish red hat from ubuntu would be - could look for package managing tools and query installed packages, eventually helping you narrow down different debian derivatives, etc. There's probably something more obvious and up front though.
linux variants generally store distro information in /etc/issue.
most kernels will put info in /proc/version
It's not completely straightforward. You can use uname to find out the general parameters but to differentiate between distributions is a harder task. Maybe you should consider using something like autoconf to generalise your build system?
Just in case you're using Qt, there's this really nice set of defines, Q_OS_*, that guide you to the Operating System you're compiling on:
Q_OS_AIX
Q_OS_BSD4
Q_OS_BSDI
Q_OS_CYGWIN
Q_OS_DARWIN
Q_OS_DGUX
Q_OS_DYNIX
Q_OS_FREEBSD
Q_OS_HPUX
Q_OS_HURD
Q_OS_IRIX
Q_OS_LINUX
Q_OS_LYNX
Q_OS_MAC
Q_OS_MSDOS
Q_OS_NETBSD
Q_OS_OS2
Q_OS_OPENBSD
Q_OS_OS2EMX
Q_OS_OSF
...
They are defined in QtGlobal. There are even defines that help you figure out the compiler used Q_CC_* or the target Windowing System Q_WS_*.
But if you're not using Qt and want to go for a generic method, you most likely have to fall back to the Autotools package or CMake.
Determining Linux distributions is pretty tricky, but not hard. You first have to figure out what distributions you care about and then make all kinds of distribution specific file/configuration checks like in this example for the ones you've chosen, since you can't really support all of the myriad of Linux distros available out the. :-)
As for the Mac side i'll let the Mac experts answer, but it shouldn't be that hard, since at least the diversity issue is out of the question.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 7 years ago.
Improve this question
I would like to write my own OS, and would like to temporarily jump over the complicated task of writing the kernel and come back to it later by using the Linux kernel in the mean time. However, I would like to provide the OS as closed source for now. What license is the Linux kernel under and is it possible to use it for release with a closed source OS?
Edit: I am not interested in closing the source of the Linux kernel, I would still provide that as open sourced. I am wondering if I could use a closed source OS with an open source kernel.
Further edit: By OS, I mean the system that runs on top of the kernel and is used to launch other programs. I certainly did not mean to include the kernel in the closed source statement.
You can of course write whatever closed-source OS over the Linux kernel that you like provided you are compatible with the licensing of components you link against.
Of course that's likely to include the gnu C library (or some other C library). You may also need some command line utilities which will probably be GPL to do things such as filesystem maintenance, network setup etc. But provided you leave those as their own standalone programs, it should not be a problem.
Anything that you link into the kernel itself (e.g. custom modules, patches) should be released as open source GPL to comply with the kernel's licence.
The Linux kernel is released under the GPLv2 and you can use it as part of a closed-source OS but you have to keep the kernel and all modifications released GPLv2.
Edit: Btw, you may want to use something like OpenSolaris instead. It's much easier to work with, in my opinion (obviously very subjective), and you can keep modifications closed-source if you so choose, so long as you follow the terms of the CDDL.
I think you're going to have to be more specific about what you mean by 'OS'. It's by no means a clear concept. Some would say that the kernel is all of the OS. Others would say that the shell and core utilities such as 'ls' are part of the OS. Others would go as far as to say that standard applications such as Notepad are part of the OS.
IANAL, but I don't believe there's anything to stop you from bundling the Linux kernel with a load of closed-source programs of your own. Take care not to use any GPL library code however (LGPL is OK).
I do question your motives.
It's GPL version 2 and you may certainly not close its source.
You must keep the source open, and any works derived from the code, however, if you use the Kernel, write your own application stack on top of that (pretty much ALL the GNU stuff) then you don't have to open that up.
The GPL says that "derived" works... so if you're writing new code, instead of expanind on, then that's fine. In fact, you could even, for example, use the GNU toolchain, the Linux Kernel, and then have your own system on top of that (or just a DE) that is closed source.
It's when you modify/derive from something that you have to keep it open!
Linux has the GPL (v2) as its licence, which means you have to open source any derivative works.
You may want to use BSD, its license is a lot les restrictive in what you can do with derived works
If the filesystem you use is to be linked into the kernel itself, and if you plan to distribute it to others, the GPL pretty unambiguously requires that the filesystem be GPL'ed as well.
That being said: one way to legally interface Linux with a GPL-incompatible filesystem is via FUSE (filesystem in userspace). This has been used, for example, to run the GPL-incompatible ZFS filesystem on top of Linux. Running a filesystem in userspace does, however, carry a performance penalty that may be significant.
It is GPL. Short answer -- no.
You can always keep any extensions (modules) and/or applications you write closed source, but the kernel itself will need to remain open source.
There's a not-so-obvious aspect of the GPLv2 that you can exploit while testing the system: you only need to release source code to those who have access to the system. The GPLv2 states that you need to give full access to the source code to anyone with access to the binary/compiled distribution of the program. So, if you are only going to use the software inside of the company that is paying to develop it, you don't need to distribute the source code to the rest of the world, but just them.
Generally I would say that you're allowed to do such a thing, as long as you provide the source for the kernel, but there's one point where I'm unsure:
On a normal Linux system between the (GPL) kernel and a non-GPL compatible application, there is always the GNU libc, which is LGPL and thus allows derived works that are non-free. Now, if you have a non-free libc, that might be considered a derived work, since you are directly calling the kernel, and also using kernel headers.
As many others have said before, you might be better off using a *BSD.
If you're serious in developing a new operating system and want a working kernel to start with I suggest that you look into the FreeBSD kernel. It has a much more relaxed license than Linux, I think you might find it worthwhile.
Just my 2 cents...
I agree with MarkR but nobody has stated the obvious to you. If you are serious, you need to consult a lawyer with expertise in this area.