eatcomics wrote:As per this whole C/Go file path thing, I'm lost as well Nico :P
Go was just an example. My point is that programs that are not written in C/++ are annoying to deal with in the linux directory structure. And that even when you write C/++ programs, the files are scattered around the entire system, which means that i have no idea where i would put the different parts, even if i wrote a C/++ program, to make it fit the system.
For C/++, libraries go in /usr/lib, binaries go in /usr/bin, and headers go in /usr/include.
Also, it's not that linux doesn't allow other languages to integrate well (have you seen D? That integrates almost perfectly), it's that Go simply doesn't want to. If its developers wanted to, they could have it integrate into the system by default. Hell, if you wanted to you could do it too, with some messing with compiler/linker flags and some copying or symlinks. Java, however, is another story. It's just... weird.
I get your point.
However im not quite sure if i get why the linux directory structure is superior to the windows' concerning installation of programs. You say that "Java, however, is another story. It's just... weird" But yet in windows it dosen't feel "hacky" at all. Basically why is the Linux approach where everything is scattered everywhere superior to having each program to have its own directory under a "programs" directory?
Well, although it may seem unintuitive at first, it makes a lot of sense.
/bin (where all system tool binaries are) and /usr/bin (all the other or "user" binaries) are typically automatically in PATH, and even when they aren't they provide an easy place to look for any application.
/usr/lib and /usr/include are really for the compiler's ease, because it means you only have to look in one location for all the headers and libraries.
/usr/share is for shared resources like icons and the like.
/etc is (don't quote me on this tho) a unified location for global settings.
All this allows a good amount of organization that doesn't put EVERYTHING in one location, rather, the different parts are in different locations, but they can still interact easily. Just an example, much of the files in /usr/bin, you may find, aren't actually applications, they're scripts. However, because all the executables are placed in a single location, you can use them as though they are actually binaries. You probably could do something like this to put java applications into the filesystem just like this, but they don't do it by default, and you'd have to do it yourself (often customized on a per-application basis).
Quit procrastinating and make something awesome.
Ducky wrote:Give a man some wood, he'll be warm for the night. Put him on fire and he'll be warm for the rest of his life.
Ginto8 wrote:Well, although it may seem unintuitive at first, it makes a lot of sense.
/bin (where all system tool binaries are) and /usr/bin (all the other or "user" binaries) are typically automatically in PATH, and even when they aren't they provide an easy place to look for any application.
/usr/lib and /usr/include are really for the compiler's ease, because it means you only have to look in one location for all the headers and libraries.
/usr/share is for shared resources like icons and the like.
/etc is (don't quote me on this tho) a unified location for global settings.
All this allows a good amount of organization that doesn't put EVERYTHING in one location, rather, the different parts are in different locations, but they can still interact easily. Just an example, much of the files in /usr/bin, you may find, aren't actually applications, they're scripts. However, because all the executables are placed in a single location, you can use them as though they are actually binaries. You probably could do something like this to put java applications into the filesystem just like this, but they don't do it by default, and you'd have to do it yourself (often customized on a per-application basis).
Okay, then while you are at it, could you clarify the similarities, differences, and roles of the following as appose to just /usr/{bin/lib/include}
Ginto8 wrote:
just curious, how is a JVM written in C++ ironic? It needs to be able to interpret bytecode, sometimes JIT portions, and basically run as an abstraction layer. I see no irony in the choice of C++ as an abstraction layer for the bytecode
Because he used JVM as an example of something that doesn't fit into the Linux file system well.
Falco Girgis wrote:It is imperative that I can broadcast my narcissistic commit strings to the Twitter! Tweet Tweet, bitches!
Maybe I'm over reacting on this but as soon I got EQ running in linux I had to spend 2 days debugging to find that newline characters were read in from files and fucked our content.
Maybe a bit off topic but does anybody know what Microsoft's deal with safety functions is?
avansc wrote:Okay, then while you are at it, could you clarify the similarities, differences, and roles of the following as appose to just /usr/{bin/lib/include}
OK, to find the answer I had to look at the Filesystem Hierarchy Standard (which is available here if you're interested), and here is the fairly comprehensive layout:
/bin: essential binaries to be used by all users
/sbin: essential binaries intended for use by root user
/boot: bootloader files
/dev: device "files"
/etc: host-specific configuration. Has subdirs:
/etc/opt: configuration for /opt packages
/etc/<app>: configuration files/dirs for <app>
/home: user home directories, not required
/lib: essential shared libs/kernel modules
/lib<qual>: a different version of /lib for different binary formats, optional
/media: removable media mount point
/mnt: temporary mounted filesystems
/opt: add-on software packages, layed out like /opt/<pkgname> or /opt/<provider> (sort of like the Windows Program Files dir)
/root: optional root user home dir
/srv: data for system services
/tmp: temporary files
/usr: sharable and read-only; mainly non-essential binaries, libraries has some subdirs:
/usr/bin: user commands
/usr/sbin: non-essential system binaries
/usr/include: headers
/usr/lib: libraries for programming and packages
/usr/lib<qual>: /usr/lib but for different binary formats, optional
/usr/local: used by sysadmin for installing software locally; protected from overwrite when system software is updated. Has subdirs:
/usr/local/bin: local binaries
/usr/local/sbin: local system binaries
/usr/local/etc: host-specific system configuration for local binaries
/usr/local/games: local game binaries
/usr/local/include: local C headers
/usr/local/lib: local libs
/usr/local/man: local online manuals
/usr/local/share: local architecture-independent hierarchy
/usr/local/src: local source code
/usr/share: architecture-independent data
/var: variable data files, such as spool directories/files (queues), administrative/logging data, transient/temporary files. Has subdirs:
/var/cache: application cache data
/var/lib: variable state information
/var/local: variable data for /usr/local
/var/lock: lock files, ie for package databases
/var/log: log files/directories
/var/opt: variable data for /opt
/var/run: data for/about running processes
/var/spool: application spool data
/var/tmp: temporary files preserved even after reboot
Quit procrastinating and make something awesome.
Ducky wrote:Give a man some wood, he'll be warm for the night. Put him on fire and he'll be warm for the rest of his life.
N64vSNES wrote:Maybe I'm over reacting on this but as soon I got EQ running in linux I had to spend 2 days debugging to find that newline characters were read in from files and fucked our content.
I think this is just as much a windows problem as it is a linux problem. I read this blog post once, and i think it can be the explanation.(http://www.codinghorror.com/blog/2010/0 ... chism.html)
Basically windows puts "\r\n" at the end of lines and linux only puts "\n". I guess that this means that if you use windows "endlines" and open the file in linux all lines would end with "\r"
