Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 8 years ago.
Improve this question
I am a computer science minor and I do appreciate *nix a lot more since i started to delve into computer science. I used to be a windows fan boy and now i own two macs (as well as my PC which has windows and ubuntu on it).
I want to learn more about how linux was developed. I know that linux is only the kernel and the GNU is actually the most of what i am interfacing with. So when i type ls -al on my mac which uses unix how is it different from when i type ls -al on my Ubuntu boot on my PC? Does the difference actually lie in the differences between linux and unix? Or does unix use a non-GNU libraries for stuff like ls and cd?
So what exactly are the difference of linux and unix? Does Unix use GNU libraries for ls, cd, and all those common terminal operations?
First of all, you need to know that ... Linux Is Not UniX. :)
Good question, but it's difficult to give a straight answer.
The kernel is different. The design is different. The software is different (!)
That said, if you have Mac OS X (UNIX), you can build almost any command-line tool that was written for Linux.
Most of the free open-source software is compatible with both Linux ans UNIX, so depending on your level, you might never know the difference.
But technically, there's a huge difference. If you're on a hardware and driver-level you will start noticing differences, but if you're above those levels, you can easily write portable code.
Some people would claim that Linux is the poor-man's UNIX (which is probably also true), while others would say that Linux fixes the problems that UNIX has.
Due to the nature of the question (it's fairly broad), it's difficult to go in details.
I work with both and do not feel a huge difference. My UNIX was set up for me, so I'm basically a novice user there, but I had to install and configure parts of my Linux system myself.
I would say (in my own opinion) that most of the time, Linux is something you build yourself, you decide which components you want. UNIX on the other hand is a little more "one big package", though you can still add components.
Looking at it from a different angle: Linux is open-source and free, where some versions of UNIX aren't. UNIX is often found in enterprise servers from large companies.
Take a command like 'ls' as you mentioned. Older versions of UNIX had a command called 'lc' which listed directories instead of files (as far as I recall). This command does not exist in the UNIX that Mac OS X is based upon, so there's a difference between UNIX and UNIX.
On the other hand, Linux did not make a straight copy of the UNIX command 'ls'. The output often differ slightly, and the switches are different. But!
If you're running Bash, then Bash on your Mac OS X is most likely exactly the same Bash you've got on Linux, just the version differ.
If you got 'curl' on your Mac, and 'curl' on Linux, then it IS the same tool, because it's built from the same sources; it's just built for two different Operating Systems.
GCC is the same as well. (GNU is Not Unix - but it works well on UNIX).
If you install the gitolite server (which I'm quite fond of), you will experience that it will not install on the stock Mac OS X 10.5.8; this is because the arguments for the 'cp' command differ. The author refused to correct the problem, when I suggested him a solution that would work on all platforms. So 'cp' may not always be 100% compatible, and I do not know whether or not it would be a good idea to 'upgrade', because the 'cp' that you have now is compatible with the scripts that Apple provided with your system. Upgrading 'cp' to a different version could break compatibility, which could mean that your system got corrupted and would need a re-install. -So it's better to not upgrade that particular command. ;)
Related
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 7 years ago.
Improve this question
I recently switched from Linux to OSX. I use console heavily, and previously I was able to do things like
ls ./dir -sgh
cp ./file ./dir -Rf
and so on. If I missed an option, it was enough to press up and just add it. OSX forces me to put options before arguments, like this:
ls -sgh ./dir
cp -Rf ./file ./dir
This behavior is frustrating, it is easy to forget about an option and you have to navigate to the beggining of a line just to add it. It is also hard to add another option if you forget about one.
Is there an easy way to fix this behavior and make it work the linux way? I guess it involves replacing default programs like ls with some counterparts.
OS X's userland is a mash of BSD, (outdated) GNU, and Apple utilities.
If want your utilities to behave like their Linux counterparts, you should probably install the entire GNU coreutils suite with something like
Homebrew.
Once Homebrew is installed, just use it to install the coreutils:
$ brew install coreutils
Edit: I didn't have to update my $PATH personally, but YMMV.
If your shell isn't finding the Homebrew-installed coreutils, make sure /usr/local/bin (or your custom path, if Homebrew was configured as such) is before /usr/bin and /bin on $PATH.
In the best-case scenario, all programs dynamically link the system libc and use getopt to process their arguments. getopt only looks at arguments until it finds the first non-option argument, then stops. You cannot change this behavior of getopt. You would have to replace the system libc with one having a different implementation of getopt.
However, there is no guaranteed that all programs load libc dynamically; some might link statically, in which case replacing the system libc would have no effect. Others may not even use getopt. In either case, the only option is to replace the program with one that behaves the way you want.
Option processing is not a feature of the shell. You'd need to patch the argument processing logic in each individual utility.
Alternatively, you could install e.g. the corresponding GNU utilities. They are not completely option-compatible with the default *BSD utilities, so you can't replace the system binaries; but you can arrange your PATH so that the locally installed versions are preferred for your personal use. Homebrew is popular for managing this.
In Bash, ctrl-A jumps to the beginning of line, and M-n jumps past the first token.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 7 years ago.
Improve this question
I would like to get help. Soo one day i got this book: http://linuxcommand.org/images/51vgLTkNsIL._SL500_AA300_.jpg And i have learned some "basic of terminal + linux". I have read the full book, but i want more, u guys now, i wanna be better and better... But i got no idea what books can i read, what sities should i read, at what turtionals video i should look. I just want learn more linux as typical user/administration (linux is soo fun :P) I don"t want learn linux as programmer.
I just search a places to learn more linux, like i said, i got only a linux basic from this book: http://linuxcommand.org/images/51vgLTkNsIL._SL500_AA300_.jpg But i would like to learn more, any ideas at what should i look?
I completely agree with Optavius, mucking around in the trenches is the only way to get dirty ;)
I would like to add that, given the wide variety of linux distributions available, another way to learn more is to start out with two or three different ones. For example, get things running on a Debian derivative (e.g. Ubuntu), and start comparing the subtle differences with say a RedHat derivative (e.g. Fedora).
For example, you would learn a good deal just by comparing the differences of installing / managing packages with apt-get on Ubuntu, and yum on Fedora. With apt-get, if you want to search for a package you would have to do apt-cache search <package_name>, and when you find it then you would do apt-get install <package_name>. Whereas with yum, you would just do yum search <package_name> and yum install <package_name>.
Personally, if you want to become very experienced with system administration, I strongly recommend installing Fedora. The reason is because it is very forward, and constantly updating and evolving. This comes at a significant price. Yes, you have all of those shiny new tools that many other distributions would have to install from source. But this also makes it very unstable, and will break frequently. A kernel update may require you to go in and fix things with dracut for no apparent reason!
The other side of the coin is that Ubuntu has an extremely vast user-base, and when you end up having a problem it is much more likely that you will find a current solution for Ubuntu.
The bottom line: play around and have some fun!!! Maybe setup RAID or create some shared partitions. Say you had Windows and Linux, and wanted to have all of your music on one separate partition that both could access. Then make an exFAT partition for both to share, and learn how to auto-mount this in Linux (how depends on the distribution).
If you really, really, REALLLLLY want to learn about linux from the ground up, there's a solution for that too: cook your own distribution! You've demonstrated you aren't opposed to reading a book or two, Linux from Scratch may be exactly what you are looking for. This is not for the faint-hearted, though...
I hope one of those thoughts sparks something of interest to you!!!
I recommend you install Linux instead and play around with it instead of reading about it. But it really depends really what you intend to achieve with using Linux.
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.
The community is reviewing whether to reopen this question as of 8 days ago.
Improve this question
What does "opt" mean (as in the "opt" directory)? I commonly see this directory in Unix systems with development tools inside.
Is it an abbreviation?
In the old days, "/opt" was used by UNIX vendors like AT&T, Sun, DEC and 3rd-party vendors to hold "Option" packages; i.e. packages that you might have paid extra money for. I don't recall seeing "/opt" on Berkeley BSD UNIX. They used "/usr/local" for stuff that you installed yourself.
But of course, the true "meaning" of the different directories has always been somewhat vague. That is arguably a good thing, because if these directories had precise (and rigidly enforced) meanings you'd end up with a proliferation of different directory names.
The Filesystem Hierarchy Standard says this about "/opt/*":
"/opt is reserved for the installation of add-on application software packages."
By contrast it says this about "/usr/local/*":
"The /usr/local hierarchy is for use by the system administrator when installing software locally."
These days, "/usr/local/*" is typically used for installing software that has been built locally, possibly after tweaking configuration options, etcetera.
It's usually describes as for optional add-on software packagessource, or anything that isn't part of the base system. Only some distributions use it, others simply use /usr/local.
OPTional
It holds optional software and packages that you install that are not required for the system to run.
Add-on software packages.
See http://www.pathname.com/fhs/2.2/fhs-3.12.html for details.
Also described at Wikipedia.
Its use dates back at least to the late 1980s, when it was a standard part of System V UNIX. These days, it's also seen in Linux, Solaris (which is SysV), OSX Cygwin, etc. Other BSD unixes (FreeBSD, NetBSD, etc) tend to follow other rules, so you don't usually see BSD systems with an /opt unless they're administered by someone who is more comfortable in other environments.
It is an abbreviation for 'optional' , used for optional software in some distros.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 4 years ago.
Improve this question
I was wondering that how is Linux and GNU related to each other. Can anyone clear my doubt in it?
Thanks!
GNU, founded by Richard Stallman, is a collection of tools which more or less help to create a fully functional operating system. GNU's goal was to create a fully free, open source replacement of UNIX.
Linux was created by Linus Torvalds with no connection to GNU. Linux functions as an operating system kernel. When Linux was created, there were many GNU components already created but GNU lacked a kernel, so Linux was used with GNU components to create a complete operating system. There is now a kernel created by the GNU team in development (GNU Hurd) which can be used instead of Linux producing a fully GNU-based operating system. However, GNU Hurd is still in development stages (and has been for 20 years) and Linux is a more mature kernel.
It is possible also (such as in the case of Android) to have a Linux-based operating system which has no GNU components.
But usually a complete operating system will consist of Linux + many GNU components, which is sometimes referred to as GNU/Linux.
Originally, GNU was a project to build a complete Unix-compatible operating system piece by piece.
The plan was to rewrite each small utility according to specification, testing it on a working Unix by replacing the original one. It went very well, except for the kernel, where progress was especially slow, probably because several good developers couldn't agree on the absolute best design.
The planned HURD kernel had in fact a very advanced design, with a lot of innovations, but it seemed that it wouldn't be completed any time soon.
Meanwhile, Linus Torvalds was writing his own kernel, mainly to teach himself how to control low-level aspects of the Intel 80386 processor. At first it was just a task switcher, but he quickly implemented most of the old syscalls specifications, until he managed to run most of MINIX (another Unix-like system, mostly used in education) environment on top of the new kernel.
Soon, other people suggested using GNU utilities instead of MINIX ones, and got a much more complete system. It worked so well that most GNU developers just adopted the Linux kernel instead of perpetually waiting for the HURD kernel.
The resultant OS is commonly called just "Linux", but it's true that Linux is just the kernel. All the GNU utilities are a lot more lines of code, so it would be more properly be called GNU/Linux.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 5 years ago.
Improve this question
Which is the best light weight distro for learning linux kernel development. It should have lot of debugging and profiling tools available along with it :)
LFS. Then install every debugger and profiler you can find.
I've heard Linus himself uses Fedora. I'd recommend Gentoo which lets (intends) for you to hand customize your kernel, it's the perfect setting for it (and I've spent many hours squeezing out every last bit of performance for the fun of it).
Naturally Ubuntu is my preferred distro, but you may have trouble if you start hijacking and removing expected kernel features. Gentoo won't complain, and doesn't expected them around to begin with.
I've enjoyed using Gentoo for fiddling around with the kernel.
The distro does not really matter. It is what you want to do with the kernel and do development/testing its feature.
Here are few things to do.
a. Turn on the kernel debugging and the logging options. Those would definitely help you in debugging.
see useful linux kernel debug options to turn on
b. Getdebuggers tool like Valgrind that checks for memory leak. See doc like https://www.kernel.org/doc/Documentation/kmemleak.txt
c. Found a good editor for editing. I don't want to start a vim vs emacs war. It is really a personal preference, just make sure you follow the linux kernel coding style guidelines. https://www.kernel.org/doc/Documentation/CodingStyle
d. Get familiar with the log systems and proc system, as they provide valuable information.
e. Read the documentation in the directory /usr/src/linux/Documentation Very good starting point to understand the kernel
The distro probably doesn't make much difference since you'll be working on your own kernel and not the "kitchen sink" kernel the distros tend to provide with a bunch of patches in most cases.
If you're doing kernel development work then I suppose you want a distro that boots quickly, something like puppy might be ideal here and do your actual coding from something like Ubuntu.
Buildroot
Buildroot is a set of scripts that generates tiny distros with rootfs images smaller than 10MiB.
It downloads everything from source and compiles it, so it is trivial to patch packages up.
The generated images are so tiny, that it becomes possible to understand the entire userland setup, which will make it easier to focus on the kernel.
Advantage over LFS: everything is fully automated. Because of this, Buildroot is used professionally in large organizations.
I have created this setup to automate things as much as possible: https://github.com/cirosantilli/linux-kernel-module-cheat