It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 10 years ago.
I'm not sure how to ask this question so here goes...
Software sometimes says available on all "*nix" and that means osx and linux, or it may say available on linux and not mac or vice versa. So when I ask what makes them similar/different, I guess I'm asking what are these operating systems made up of and what allows them to be different and similar at the same time. I read somewhere that mac osx is based on bsd and something about debian and kernels and window managers and..... I'm just very confused.
OS X is not Linux. OS X is UNIX.
The lower level system APIs are very similar (identical in many cases) - C, 'nix, POSIX, and so on. A program using these interfaces can be ported easily to the other (consider the of libraries which are compatible on both and require little to no platform specific features).
There are of course differences. The OS X kernel is a microkernel (Darwin), while Linux is monolithic. Divergence beyond core user-land layers happens pretty quickly, particularly wrt the user interfaces.
Linux is not the general variant, Unix is. Linux is a form of Unix, as are the BSD derivatives (including OS X), Solaris, AIX, and a number of others.
What makes a Unix, officially, is compliance with (and, preferably, certification of) the Open Group's Unix specification. Most Unixes also provide functionality (and standard functions) beyond that specification, however, and it's in that area that you most often run into compatibility questions, although questions of device driver availability and other things not directly related to OS interfaces come in to it as well.
Related
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.
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 9 years ago.
I'm trying to migrate an application from linux to Win and already I'm having a lot of difficulties with heap size, ram and ...
what is it about Ram that most people prefer to work on linux instead of Win?
The only reason I know of is: you have a bug in your original code.
There are two main differences in managing memory:
1) Linear
Under Unix systems, you grow your heap as required and the addresses are therefore allocated linearly, increasing from the end of your data segment up. In most cases that is transparent. However, if you do reinterpret_cast<>() (or C-like casting) between pointers and integers, you may have problems there too (if you went from Linux 32 to Windows 64, for example.)
2) Clear
Windows clear the RAM (set it to all zeroes) in a different way than Linux. That's in most cases what causes grieves as you describe. This also applies to stack data.
In debug mode, also, Windows debug libraries, on purpose, set the RAM to different values (such as 0xCC or 0xFE). This is useful to detect bugs and it could very well be that you have bugs in your Linux version, only it "works" just because.
Also in regard to the stack, because the cl and gcc compilers do it completely differently, the stack is completely different. So the only thing you're seeing is that you have a bug in your original code...
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 10 years ago.
I would like to know Board bring up package underlaying architecture dependent? What actullay wanted to know can we have 64 bit architecture running 32 bit bsp code or BSP code always be 64 bit since BSP code is architecture specific.
Yes, absolutely. The BSP is very specific to the architecture of the procesor and the board itself. Having said that, it's possible that there aren't that many changes needed to run at 64-bit. One thing that most BSP's contain is a piece of startup code that initializes the hardware registers in the system. Some of these MAY change when you move to 64-bit.
The second part is the bootloader, which loads the kernel/OS/whatever into RAM (typically - it may just initialize the ROM region to be executable and set it up correctly). Again, this may need changing, as it probably "jumps to the OS in 32 bit", and the OS may expect a 64-bit jump.
Then you have the OS/kernel itself, which clearly needs recompiling.
How much work you actually need to do depends on what architecture the board is, the processor you're using and, most importantly, the requirements from the OS and upper layer software to operate in 64-bit mode - does the memory setup by the init-code or bootloader need to change? When does the switch from 32- to 64-bit happen - inside the OS or outside?
This may not be the answer you were looking for, but I think no one, except those who know the BSP intimately will be able to say exactly what you need to change - I'm pretty sure it's not a complete rewrite, but there may be a load of assumptions along the lines of "we know a pointer is 32 bits, so an int will hold a pointer" or "we know a pointer is four bytes, so we reserve four bytes here..."
Mats pretty much covered it. Like any other application it is a combination of the two or multiple platforms you are targeting and the desires and design of the application. The architectures may be so far apart that it makes no sense at all to try to target them with a single BSP. If the architectures are similar enough you could target them with a single BSP, but you may or may not choose to. Linux or the BSDs are a perfect example, there is a fair amount of the code that is multi-platform, with some platform specific parts. A bsp is no different, often just less complicated, most of your code is generally C or some similar language so it is whatever you compile to that is the target, the bootstrap and some other similar parts are asm and those would be target specific. FreeRTOS is probably even better of an example than Linux or the BSDs.
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.
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.