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.
Related
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.
Questions asking us to recommend or find a tool, library or favorite off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.
Closed 9 years ago.
Improve this question
Can anyone recommend a good IDE for general C coding and kernel development under Linux?
A few conditions would be:
NOT ECLIPSE - or any other heavy-weight Java based monstrosity that has esoteric compatibility issues, and runs like a pig.
Must work and play nice with Cygwin - or other ways of running it remotely (through X, or - I'm open to alternatives).
KDevelop is a wonderful IDE and it actually supports some Kernel-type of projects such as writing device drivers, etc.
Isn't vim + ctags + gdb enough?
In short no.
I used pida for a while, which was cool, but a bit buggy. Looks like they've had another release since then so might be worth a try. It's python focused but perfectly usable for other things. http://pida.co.uk
I use gvim, with the git plugin http://github.com/motemen/git-vim
And just make tags, gitk, gitg, git grep.
Code::Blocks
I use it for both app dev and kernel dev.
Now I was scared by Eclipse as well and for the same reasons.
But it ended up being the only IDE I found so far that is able to handle the set of Linux kernel symbols for the WHOLE kernel source tree (functions, defines, structures, everything). It is able to parse the whole kernel sources in a decent time, some tens of minutes (one time operation for each kernel tree). So I at least use it as a very smart symbol browser.
What does this bring you? Full instant code navigation:
When studying kernel and developing kernel modules, this happens to be a HUGE time saver:
To follow a function call, move the mouse cursor to the (called) function name, press Ctrl, click on the symbol, bingo, it loads the source module and instantly gets you to the function source code. Press the back arrow, you're back at the call place.
You can follow whole call chains / stacks / programming trees this way, and just naturally following code paths.
Link from a var usage to a var definition, then follow up to the struct definitions and back...
And finally, I found that Eclipse was actually perfectly integrated in Linux:
It runs just like a native app and is not sluggish like I expected it to be. I didn't feel its large size. Now to get it working and achieve that, I had to install the latest / greatest Sun Java and make that the default java machine -- the open source Java package didn't cut it.
Just my 10c...
Well, NetBeans is a java monstrosity, but it's bearable, even on my netbook. I like the vi/vim plugin, and the undockable windows so that you can have a nice big editor window with the other stuff off in a separate window. Yes, it does a lot more than just Java, even C.
screenshots on my site
vim + gedit + acme, combination.
vim is good for console environment.
gedit with plugins is good for multiple files open.
acme just another way to open multiple files.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
I live in the linux terminal all the time under my slackware GNU/linux system (an EeePC). By default, GNU Emacs won't start if It can't find several Xorg libraries. Assuming I will never use X software at all, would it make sense for me to drop all this Xorg stuff and compile emacs again ?
Are you aware of anything that could get me into troubles or making GNU Emacs not working at all ? Are there any advantage for me to keep all these dependencies ?
I am asking since as said, my main box is an eeepc with little storage and I am dangerously hitting the limits ;-)
At the very least, what would be smallest and minimal Xorg libraries one should keep to launch xterm (with a deported display) ?
Regards
You should be fine building an Emacs without X as long as you're happy having it locked up inside a terminal.
On several (remote) machines I work on, I've always installed/built Emacs without X-Windows for similar reasons.
Emacs is pretty easy to build, though you might have to spend some time getting the build options right. The included INSTALL file is pretty good.
Since it's mainly a text-based tool, Emacs works well in a console. (Who uses the silly toobar anyway?!) And the menu bar's main advantages are for discovering the features of newly installed libraries and for printing. But you can even access that from a tty with M-x tmm-menubar.
Having said that, you do have to reckon with the loss of a few key combinations which some Emacs packages make default use of. For example, one of the great reasons to use Emacs these days is org-mode, which makes heavy use of modifier keys + arrows to manipulate outline structures. In a Linux console, some of these are take for other purposes, so you have to live with a few workarounds. I've seen other convenience packages (for moving around visible windows, for example), that also use those keys.
Good luck.
As long as you're happy living without the mouse, there is no disadvantage to using Emacs as a terminal-only editor. And I see no advantage to having it loaded if you're not using it.
If you were using a more sophisticated Linux distribution, such as Debian, you could install something like emacs23-nox and get Emacs compiled without linking to any X library. You might see if Slackware provides a similar package. Or if the alien tool can convert the Debian package. Or as a last resort, change distros.
If Slackware doesn't provide a suitable package, you certainly have grounds for requesting one.
(Having said all that, I probably would find that the best use of my time is just to live with whatever version of Emacs my distro provides.)
Well... I'm usually using vim... ;-)
I usually install Debian's vim-nox package which is simply vim compiled with everything except GUI; I do that even on my workstations, where I do have full GNOME environment. I simply like the way vim works in the same terminal window I do other things.
When I tried emacs some time ago, the first thing I changed was to disable its GUI; I don't actually know how much did I lose, because I didn't know emacs very well--still I found no essential functionality removed.
You should try. You can always go back to the standard compilation.
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
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.