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.
Related
I want to build from source a recent Linux kernel (e.g. 4.13.4 in end of september 2017) on my Debian/Sid/x86-64 with all (or most) currently loaded modules configured as hard-built in the new kernel.
(I believe that I have read something like this somewhere, but can't remember where and can't find it)
It would be some make configfromloadedmodules (but of course it is not exactly configfromloadedmodules makefile target, but some other target that I did not easily find).
That is, for most (ideally all) currently loaded modules (as given by lsmod) it would answer Y (not m) for each of them at make config time and give me some good enough .config; but I don't want a bloated kernel with all drivers -even those that I don't use and which are not currently loaded- built in.
Does that exist, or was what I have probably read some wish or some non standard feature of experimental kernels?
This would avoid any initrd thing and give me a kernel suited for my hardware and habits.
The current kernel is a standard Debian one 4.12.0-2-amd64, so I have its /boot/config-4.12.0-2-amd64 (so I want to automatize the replacement of CONFIGxxx=m with CONFIGxxx=y there, according to the currently loaded modules, e.g. as given by lsmod).
See also this answer; I still believe that device trees are not essential to Linux, but they are a useful convenience.
A near variant of my question is how to easily configure a kernel, suited to my computer and hardware and set-up, without ìnitrd, without any modules (e.g. with CONFIG_MODULES=n) and without (or with very few) useless drivers, which would work as nicely as my current Debian kernel.
I believe, you should read about "make localmodconfig" and "make localyesconfig" and use one as per your requirement.
This, This and This are helpful links.
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.
Is it true that the Debian system uses FreeBSD kernel and the Redhat system uses GNU kernel. Does it make any difference to use Free BSD kernel or GNU kernel?
Well the comment grew too long so I might as well post an answer. It is quite unclear what you are asking for, since you don't present any specific problem. At first glance this question does not belong to SO. But I assume since posted here you ask about difference from coders point of view.
1st to clear up, the BSD kernel is rather the alternative one like Hurd, so a Debian system can use FreeBSD kernel, it's not default. Actually its status is "official port".
Probably the biggest difference lies in the philosophy the user believes and their peace of mind, alternatively the hood they grew up in. Unless you are a distro developer or work even lower on the system.
Generally as a programmer you work with standard library implementation (libc,libc++,libstdc++ or whatever), they need to follow the standard, and the differences are really small. On debian this is natively provided with gnu toolset. You can assume to work in gnu wonderland. The kernel lies even lower, and you would need to work on really low-level kernel related stuff to notice difference of the kernel itself. Usually you work few layers from it and kernel should pleasantly abstract.
So no need to worry unless you acutally run into trouble.
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