Tag Info

Hot answers tagged

37

The whole ABI is different, not just the binary format (Mach-O versus ELF) as sepp2k mentioned. For example, while both Linux and Darwin/XNU (the kernel of OS X) use sc on PowerPC and int 0x80/sysenter/syscall on x86 for syscall entry, there's not much more in common from there on. Darwin directs negative syscall numbers at the Mach microkernel and ...


23

Does Cygwin work like wine? No. Does it provide a compatibility layer inside a foreign OS? Yes. Wine can run Windows executables on Linux, but Cygwin cannot run Linux executables on Windows. Instead, Linux programs have to be compiled specifically for Cygwin, whereby the aim of the Cygwin project is to make that as straightforward as possible, i.e. it's ...


17

I'm not sure what issues you're constantly experiencing but I run Gentoo on Lenovo Thinkpad without problems (fingerprint reader does not work) - with possible problems with removal of BKL in recent kernels (however 2.6.33 worked ok). Previously I used IBM Thinkpad. From my small experience with them: Thinkpads seems to have a community which helps ...


14

Why OSX applications won't run natively on linux: First of all OSX uses a different binary format than Linux, so Linux can't execute binaries compiled for OSX (the same way it can't execute binaries compiled for Windows or BSD). Second of all, if you're talking about GUI applications, Apple's GUI toolkit Cocoa a) is only available for OSX and b) does not ...


10

The best I have come up with is this "two-line shebang" that really is a polyglot (Bourne shell / Node.js) script: #!/bin/sh ':' //; exec "$(command -v nodejs || command -v node)" "$0" "$@" console.log('Hello world!'); The first line is, obviously, a Bourne shell shebang. Node.js bypasses any shebang that it finds, so this is a valid javascript file as ...


9

No, not all scripts intended for bash work with dash. A number of 'bashism' will not work in dash, such as C-style for loops and the double-bracket comparison operators. If you have a set of bash scripts that you want to use for dash, you may consider using checkbashisms. This tool will check your script for bash-only features that aren't likely to work in ...


7

The short answer is no, they're not 100% compatible. But most the shells are pretty close to the basic, so you would only rarely bump into inconsistencies. In fact, most shells differ not much by added syntax, but by some extra features like tab-completion and similar. Also, dash is sort of a descendant of ash - or port from BSD to linux, to be precise. ...


6

#!/bin/sh //bin/false || `which node || which nodejs` << `tail -n +2 $0` console.log('ok'); //bin/false is the same thing as /bin/false except that the second slash transforms it into a comment for node, and that's why it's here. Then, the right side of the first || gets evaluated. 'which node || which nodejs' with backquotes instead of quotes ...


6

Very interesting finding. Although I've never used ls -s to check whether a file is empty or not, I would have assumed, that it reports 0 for empty files, too. To your question: As Mat already commented, show them your test results. To explain the results to them, state that ls -s reports the amount of allocated blocks in the filesystem, not the actual size ...


6

They are not necessarily binary compatible. That being said, most packages will probably work fine. I've done this on occasion and I've never had a problem. Although, it's not recommended to mix Debian and Ubuntu packages on a single system. If you're going to do it try to keep it at a minimum. If you're pulling in too much of the other, then perhaps you ...


5

Don't parse ls if you can help it. Depending on what you're doing, the test utility might be a better alternative. test -r filename will return success if the file is readable with the current user's permissions, and will follow symbolic links automatically. Likewise, -w and -x will tell you if the file is writable or executable. The test command is ...


5

My experience is mostly with Dell latitude series of laptops. Looking for Linux compatibility, their actual series is a go, and, on Fedora, they work with all the power saving features (suspend, resume, disk spinning...) I am not biased, but Intel hardware (Centrino brands, Core2 Duo, new Core i3, i5 and i7) are good to go, mostly because all of the ...


5

The problem with notebooks with Linux preinstalled is which distro comes with them. I've bought one which had an unknown distro (Satux) that was Debian-based, but included proprietary drivers and no access to the sources for the distro or drivers. When I finally decided to install Ubuntu over it, I started to have to chase drivers all around the internet, ...


4

The C locale is not the default locale. It is a locale that is guaranteed not to cause any “surprising” behavior. A number of commands have output of a guaranteed form (e.g. ps or df headers, date format) in the C or POSIX locale. For encodings (LC_CTYPE), it is guaranteed that [:alpha:] only contains the ASCII letters, and so on. If the C locale was ...


4

Unlike most (if not all) other file systems, ZFS doesn't preallocate a static array of inodes. Creating an empty file on ZFS will then use a new block of data which is the one reported by ls -s. I suspect GFS to have to store synchronization/lock data leading to the other non zero result.


3

The most important reason why OS X apps will not run on Linux is because those OSes used different syscalls. Some previous answers mentioned libraries but that is generally not the case - Core Foundation is largely open sourced by Apple under the name CFLite and readily portable to any platform (the Windows version of iTunes actually sits atop of a Windows ...


3

No, Debian and Ubuntu are not binary compatible. Debian and Ubuntu may use different compilers with different ABI, different kernel versions, different libraries, different packages/version etc. As not all Ubuntu packages are in Debian (and vice versa) deb packages may also depend on uninstallable versions. RedHat and CentOS are the same as CentOS basically ...


2

My advice would be to install an older distribution (CentOS 4, if that's what you're used to) in a chroot and run your application in there. It'll use up a few GB of disk space but it's likely to be a lot less time-consuming than finding a way to make the binary work with current libraries. I don't have a procedure to offer you to install CentOS in a ...


2

The argument is that figuring out where a given binary should be ( / or /usr ) is needless complication that serves no purpose. Systems have already not been able to boot without /usr for some time now so there is no longer a reason to keep two directories. See http://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge for more details.


2

A better reason for extensive (careful) use of symlinks... Symbolic links do for filesystems (a kind of hierarchical database) what foreign keys do for relational databases. With judicious use of both "forward" and "backward" symlinks (though I've not heard them referred to that way before), a distro could be designed where most things in /etc, /bin, /lib, ...


2

You are a bit confused, I think. The "C locale" is a locale like any other, which, as you point out, is conventionally a synonym for 7-bit ASCII. It's built into the C library, I suppose so that the library has some kind of fallback -- there can't be no locale. However, this does not have anything to do with the how programs built from C code deal with ...


2

The /proc filesystem is not real, it is a view into kernel-internal data, exported to look like files. It exists in Linux and in Solaris (from where the idea was shamelessly pilfered), and maybe other Unixy systems. The format is very system-dependent (and has even changed substantially among Linux kernel versions). There really isn't any halfway portable ...


2

If you won't mind creating a little .sh file, I've a little solution for you. You can create a little shell script to determine which node executable to use, and use this script in your shebang: shebang.sh: #!/bin/sh `which node || which nodejs` $@ script.js: #!./shebang.sh console.log('hello'); Mark both executable, and run ./script.js. This way, ...


2

The Darling Project was started a short while ago and, while it is far from ready, is probably what you are looking for. It is a Wine-like compatibility layer for running OS X applications on Linux, and looks pretty promising.


2

There's not a complete one. Bear in mind that Mac OS X started life as NeXTSTEP, of which OpenStep is a compatible implementation. Or rather, was at one time, so the story goes. Since then at Apple the NextStep frameworks have evolved into Cocoa. Cocoa has over 10 years of additions, extensions and improvements that don't exist in OpenStep. From what I ...


2

Since wine is a re-implementation of the Windows API - you're looking for a re-implementation of the Macintosh API or various "kits" that Apple provides to let OSX apps link to the system frameworks. I don't know of any that fit the bill. The only thing even close is the Chamelion Project which brings the UIKit from iOS to Mac OS X. Since I don't have a ...


2

Merging them will work fine. Cygwin proper doesn't store anything in your HOME directory. On first running Cygwin with a fresh home directory, default versions of .bash_profile and such get put there, but again, there is no conflict with things that already get put there. I, too, find it frequently convenient to be able to use Cygwin on things that live ...


1

Well, it's in the GNU, FreeBSD, OpenBSD, and general BSD ls implementations, so I'd say it's pretty likely to be anywhere.


1

ls -s reports the number of blocks that are allocated for the file, not including whatever is stored directly in the directory entry. In most cases, the number of blocks is the number of bytes divided by the block size in bytes, rounded up. The number of blocks can be less than that for a sparse file. For example, on most filesystems, this will create a ...


1

According to the project's README you can use glibc with 2.4 kernels, but you will lose some functionality: When working with Linux kernels, the GNU C Library version 2.4 is intended primarily for use with Linux kernel version 2.6.0 and later. We only support using the NPTL implementation of pthreads, which is now the default configuration. Most ...



Only top voted, non community-wiki answers of a minimum length are eligible