En el mundo moderno de hoy en día de aplicaciones basadas en navegador de varios gigabytes podemos llegar a estar abrumados por entornos gráficos que nos interrumpen continuamente. A veces es bueno reducir el tamaño y enfocarse al estilo VT100. Aprovechemos la potencia de la terminal para hacer las cosas con una selección de aplicaciones, utilidades y un par de juegos para la consola de Linux.
|
etiquetas: abstinencia , gráfica , entorno gráfico , gui , terminal , tui , vt100 
![Abstinencia gráfica: viviendo la vida en el terminal [ENG]](https://peta.meneame.net/backend/media?type=link&id=2987570&version=0&ts=1532691486&image.jpeg)
Cuando puedes administrar un directorio activo de Windows desde PowerShell será por alto
Sin embargo, para una persona que se encarga de un servidor que solo va a tocar un par de veces al año tener una interfaz gráfica para administrarlo es una bendición.
Es lo que he dicho.
De hecho si lo miramos todo tan estrictamente como decís algunos, si os creéis tan buenos programadores deberías escribir todo en ensamblador o incluso código máquina, y no en lenguajes de alto nivel. Por eso usar la consola y luego programar con lenguajes de alto nivel demuestra bastante hipocresía y cinismo para luego poner a parir o creeros mejor que las personas que usan la interfaz gráfica, porque no quieren poner comandos o perder el tiempo (por ejemplo copiar una serie de archivos de una carpeta con seis-siete niveles de subcarpetas) cuando con la interfaz gráfica, antes que se acabe de poner los comandos necesarios y más en linux, que no se quien se le ocurrió la genial idea de poner C: como dev/hda1/...dev/sda1... para complicarlo todo más, acabas antes.
Y sobre el tema de los manuales, está claro que muchos creadores de productos están más pensando en el dinero que van a ganar que en hacer bien su producto incluido los manuales que o son incompletos o son una mierda enorme. Esto hablando de los manuales de uso, ya no digo los técnicos...
Pero bueno viendo lo que algunos entienden de diseño, seguridad, optimización de un software, aplicación, juego... tampoco podemos pedir peras al olmo.
Llevo usando línea de comandos desde el nacimiento del CP/M y MSX-DOS 1.0 y sigo sin ver esa ventaja que decís algunas personas que hay. Y por cierto el buffer de comandos o memoria donde se guardan, no es infinito.
Salu2
Salu2
Hay cosas que un usuario normal también hace como renombrar conjuntos de ficheros. Eso con comandos script se arregla rápido.
Te olvidaste mencionar GNU, ¿o querías decir GNU al mencionar a Linux?
Ahora en serio, donde este nano que se quite vi/vim
- encontrar en un árbol de directorios todos los ficheros que se llamen de una determinada manera: find
- ver si contienen una determinada linea: find + xargs + grep
- sustituir ciertos caracteres de esa linea por otros: sed? tr? Dependerá de la complejidad de la sustitución, de los ficheros, etc., pero en principio puede valer.
- quedarme con el path de los ficheros modificados: salida de find + xargs + grep -l
Cuando tienes que utilizar miles de comandos (cada uno con sus parámetro) llega un momento que tienes que apuntarlo. Ahí ya pierdes eficiencia
. Para buscar (descartar, seleccionar..) por ejemplo logs con grep ya es una pesadilla comparado con sistemas tipo loghash, new relic,.. Sistemas que visualmente disminuyen el esfuerzo visual, y por tanto mejor. Autocompletar va bien, si recuerdas hasta un grado de parámetros, sinó, entonces no es una solución.
Tienen nano grabadora de macros y plugins? porque igual lo pruebo si es así
Para otras cosas sí que prefiero la GUI. En mi caso, uso lo que más me conviene para la tarea entre manos.
Pero es que entonces no es Linux sino POSIX
Glib por otra parte es la biblioteca de GNOME, no sirve para lo mismo que musl.
Y esos router con kernel linux + musl, ¿como llamamos al SO.?
Musl con Linux o Musl{/,-,+}Linux o sistemas Musl.
No hay forma corta de denominarlos.
¿Si la distribución utiliza herramientas de BSD como por ejemplo openssh debería llamarse GNU/BSD/Linux?
O esa denominación solo esta "marcada" por la librería de C contra la que estén enlazadas las aplicaciones.
Al final esto va a ser como el famoso "Linux is not unix".
Lo que define el SO es la API del mismo. Dicha API tiene su parte de espacio no privilegiado y de espacio privilegiado.
Hay por tanto dos componentes fundamentales: la biblioteca de C y el núcleo. La inclusión de OpenSSH no cambia el sistema operativo.
En la imagen adjunta hay un esquema del equivalente en Darwin en su variante (distribución) macOS. macOS es una distribución de Darwin + Cocoa y otras bibliotecas de Apple. Además de la de Apple sólo conozco otra variante de Darwin que es GNU Darwin. En el caso de GNU con Linux tienes variantes como Debian, Ubuntu, Fedora, Red Hat aunque todas comparten cosas como SystemD o GLib. De hecho es irrelevante porque todas admiten cambiar dichos componentes. Si quisieras cambiar la biblioteca de C o el núcleo tendrías que modificar un buen puñado (sino todos) los paquetes de sus repositorios y recompilarlos (todos) ...
Gracias por aportar algo interesante a este tema! Más de un centenar de posts y casi todo de trolls para ver quién la tiene más grande
Incluso se puede llegar a enlazar parte de la herramientas gnu contra musl.
En cuanto a que se puede llamar Linux, el propietario de la marca dice que todo lo que lleve el kernel.
Recordemos que mi mención fue a todo el ecosistema de kernel linux independientemente de si se utiliza glibc.
Algo similar a cuando nos referimos a unix que englobaría linux.
Si nos atenemos a la lista de las distribuciones "dignas" de llevar el GNU este es el resultado según la FSF:
www.gnu.org/distros/free-distros.html
Si utilizas aplicaciones enlazadas con Musl dichas aplicaciones están diseñadas para Musl (con Linux o el núcleo que sea). ¿Qué es sino Wine?
¿No es posible acaso virtualizar un sistema operativo dentro de otro? ¿Qué es sino LXC? ¿VirtualBox?
¿Significa eso que las aplicaciones con Wine están hechas para Linux? ¿y lo que ejecutes dentro de VirtualBox también? ¿y lo que ejecutes con LXC también?
La respuesta es no.
Linux es una marca registrada, pero no es una marca de sistema operativo sino de núcleo de sistema operativo.
Y lo siento, pero el ecosistema de Linux no es único. No existe eso de «ecosistema Linux». Musl es incompatible con GLibc entre otras razones porque no implementa el GNU C. Aquí tienes una comparativa básica entre distintas bibliotecas de C: www.etalabs.net/compare_libcs.html
Los programas han de ser programados específicamente para cada biblioteca de tiempo de ejecución de C.
Por otra parte decir "kernel Linux" es redundante.
Tampoco comprendo para qué preguntas nada.
El listado de distribuciones de GNU con Linux que indicas es de distribuciones 100% libres. Que no sean 100% libres no significa que no sean sistemas operativos de GNU con Linux.
es.wikipedia.org/wiki/Biblioteca_estándar_de_C
No son ningún emulador.
Creo que esta discusión se esta alargado porque usted piensa que siempre hay que pasar por glibc para llegar al API del kernel.
Estamos hablando del proceso de lanzado (link) de programa al construir el binario.
Un par de ejemplo de distribuciones que no se autodenominan GNU:
www.centos.org/about/
www.gentoo.org/get-started/about/
En Centos podría tener sentido ponerle el GNU porque funciona casi exclusivamente utilizando glibc, pero en el caso de Gentoo te mentirían porque puedes construir el sistema sin glibc.
Otra cosa es como le gustaría a la FSF que se denominaran, que no es obligatorio.
Y esa orden al menos en vi es un salir a las bravas guardando
Wine tampoco es ningún emulador. WINE significa Wine Is Not an Emulator.
La Biblioteca estándar de C es una cosa.
La Biblioteca estándar de C de POSIX es otra cosa.
La Biblioteca estándar de C de GNU es otra cosa.
La Biblioteca estándar de C de Musl es otra cosa.
La Biblioteca estándar de C de uClibc es otra cosa.
La Biblioteca estándar de C de Bionic es otra cosa.
WINE (o Wine) implementa la Biblioteca estándar de C de Microsoft. Y ésta es otra cosa.
Todas ellas incompatibles entre sí.
Cómo se denominen a sí mismas las distribuciones de GNU con Linux es irrelevante. La extrema derecha no se autodenomina como extrema derecha y no por ello dejan de ser extrema derecha.
En los repositorios de Gentoo tienes software preparado para GNU con GNU Hurd. Igual que en Debian. Ese mismo software está preparado para GNU con Linux. Gentoo además dispone de software preparado para Musl con Linux y uClibc con Linux. Eso son tres sistemas operativos distintos.
GNU-Linux es Linux junto con la biblioteca de tiempo de ejecución de GNU, las utilidades nucleicas de GNU (coreutils), las utilidades binarias de GNU (binutils) y un largo etcétera entre los que se incluye el dialecto de C de GNU. El uso de cualquiera de ellos convierte al programa en diseñado para ser compatible con GNU.
Si se llama biblioteca de tiempo de ejecución de GNU (GNU C runtime library) es por algo
Y es que dispone de funcionalidad específica de GNU y que si eres compatible con GNU eres incompatible con otros SOs salvo que lo hagas multiplataforma y tengas código que abstraiga todas las particularidades para poder explotar al 100% cada SO. La biblioteca de tiempo de ejecución de GNU realiza operaciones que otras bibliotecas de tiempo de ejecución no realizan.
Una comparación con algunas cosas: www.etalabs.net/compare_libcs.html
Con la GNU C runtime library también se incluye GNU ld, el cargador de binarios ejecutables y bibliotecas. Por cierto, dlopen() se incluyó en POSIX 2001 después de llevar bastante tiempo en la GNU C runtime library.
POSIX.1-2001 describes dlclose() and dlopen(). The dlmopen() function is a GNU extension.
The RTLD_NOLOAD, RTLD_NODELETE, and RTLD_DEEPBIND flags are GNU extensions; the first two of these flags are also present on Solaris.
Luego está también el tema de la ABI, caso en el cual todos imitan la de GCC ... así que si fuera por eso todo sería GNU pero supongo que eso ya no gusta.
Extensiones GNU C: gcc.gnu.org/onlinedocs/gcc/C-Extensions.html#C-Extensions
Extensiones sólo para GNU C++: gcc.gnu.org/onlinedocs/gcc/C_002b_002b-Extensions.html#C_002b_002b-
ABI de GNU:
* gcc.gnu.org/onlinedocs/libstdc++/manual/abi.html
* gcc.gnu.org/onlinedocs/libstdc++/manual/using_dual_abi.html
Explicaciones acerca de la ABI: en.wikipedia.org/wiki/Application_binary_interface
* Convención para llamadas a procedimientos
** en.wikipedia.org/wiki/Calling_convention
** Arquitectura x86 dispone de múltiples formas. En el mundo POSIX actual se utiliza la de GCC (GNU): en.wikipedia.org/wiki/X86_calling_conventions
* Formato del binario. Aunque hay un estándar, el ELF, si usas GNU ld o gold el binario tiene ciertas extensiones con información adicional, útiles para depurar o modificar el comportamiento a la hora de buscar bibliotecas: en.wikipedia.org/wiki/Rpath Gracias al Rpath configurado por GNU ld puedes modificar en un sistema GNU-Linux el archivo /etc/ld.so.conf con rutas adicionales para bibliotecas. Siempre habrá otros que lo imiten para ser compatibles con GNU.
* Cómo hacer las llamadas a sistema. La GNU libc provee facilidades para realizar llamadas a sistema mediante la función syscall().
En serio, déjalo.
En los repositorios de Gentoo tienes software preparado para GNU con GNU Hurd. Igual que en Debian. Ese mismo software está preparado para GNU con Linux. Gentoo además dispone de software preparado para Musl con Linux y uClibc con Linux. Eso son tres sistemas operativos distintos.
Y no se pueden instalar al mismo tiempo. Son incompatibles entre sí. Se requiere recompilar dicho software.
Como ejemplo esta Alpine Linux.
La incompatibilidad de la que usted habla solo ocurre si se utilizan las extensiones de GNU.
Ejemplo sencillo.
====== hola.c =====
#include <stdio.h>
int main(void)
{
printf("Hola Mundo");
return 0;
}
=================
$ musl-gcc -o hola_musl hola.c
$ ./hola_musl
Hola Mundo
$ objdump -T hola_musl
hola_musl: formato del fichero elf64-x86-64
DYNAMIC SYMBOL TABLE:
0000000000000000 DF UND 0000000000000000 puts
0000000000000000 DF UND 0000000000000000 __libc_start_main
0000000000601030 g D .data 0000000000000000 _edata
0000000000601038 g D .bss 0000000000000000 _end
0000000000400390 g DF .init 0000000000000002 _init
0000000000601030 g D .bss 0000000000000000 __bss_start
00000000004004dc g DF .fini 0000000000000002 _fini
$ gcc -o hola_gcc hola.c
$ ./hola_gcc
Hola Mundo
$ objdump -T hola_gcc
hola_gcc: formato del fichero elf64-x86-64
DYNAMIC SYMBOL TABLE:
0000000000000000 w D UND 0000000000000000 _ITM_deregisterTMCloneTable
0000000000000000 DF UND 0000000000000000 GLIBC_2.2.5 puts
0000000000000000 DF UND 0000000000000000 GLIBC_2.2.5 __libc_start_main
0000000000000000 w D UND 0000000000000000 __gmon_start__
0000000000000000 w D UND 0000000000000000 _ITM_registerTMCloneTable
0000000000000000 w DF UND 0000000000000000 GLIBC_2.2.5 __cxa_finalize
¿Como se ha producido el milagro? No utilizando las extensiones de GNU.
Incluso podemos hacer un cutre programa demo sin pasar por librería estándar (versión solo para amd64).
====== syscall_a_pelo.c =====
void _start() {
asm("mov $60,%rax; mov $0,%rdi; syscall");
}
=========================
gcc -nostdlib syscall_a_pelo.c
Evidentemente si quiero Gnome tengo que utilizan glibc.
Es evidente que si usas extensiones de GNU tendrás que enlazar con la GNU C o cualquier otra compatible con GNU C. Y si no utilizas extensiones de GNU utlizarás el C normal o el POSIX que ha sido influenciado por GNU. ¿Y qué tiene eso de relevante? Tu aplicación será compatible con GNU y otros sistemas operativos.
¡Viva el vino! ¡viva el Wine! ¡no soy de extrema derecha!
Que no uses las extensiones de GNU no significa que tu programa no se esté ejecutando con la ABI de GNU. Y no significa que tu programa no esté diseñado para funcionar con GNU. ¿Cuál es el cargador que estás utilizando para el binario?
La primera aplicación diría que es para Musl con Linux:
La primera aplicación utilizas el linker y cargador de Musl:
%(cc1_cpu) -nostdinc -isystem /usr/include/x86_64-linux-musl -isystem include%s
dynamiclinker /lib/ld-musl-x86_64.so.1 -nostdlib %{shared:-shared} %{static:-static} %{rdynamic:-export-dynamic}ls -d /usr/include/x86_64-linux-*
/usr/include/x86_64-linux-gnu /usr/include/x86_64-linux-musl
Y la segunda aplicación es para GNU con Linux. Pero el mismo binario no te funcionará con los dos sistemas operativos.
GNU con Linux y Musl con Linux. ¡Que chorprecha!
Paquete musl-tools en Debian. También podrías recompilarla contra Wine y tendrías una aplicación compatible con Windows. Esa misma aplicación la podrías recompilar para Darwin y sería una aplicación para Darwin además de GNU o Musl. Felicidades, has realizado una aplicación portable. Eso no cambia el sistema operativo que esté usando según contra qué esté enlazado y con qué sea cargado el binario en el momento de su ejecución.
Pues acabo de aprender el :wq! Para forzar escribir en archivos de solo lectura y salir.
En #135 hace una afirmación asombrosa. Que la biblioteca estándar de C (ISO C99) , posix (POSIX.1-2008), musl y uClibc son incompatibles.
Lo que yo conozco:
Posix engloba todo el ISO C mas sus funciones.
Glibc engloba todo Posix y por ende ISO C mas sus funciones.
Musl engloba todo Posix y por ende ISO C mas sus funciones con la excepción de pthread.h
uClibc engloba Posix y por ende ISO C. Es modular siendo posible excluir por ejemplo IPV6 u otros compones. Es muy util para sistemas empotrados.
Por lo tanto si se realiza un programa que cumpla con ISO C es enlazable con todas las anteriormente mencionadas. Como los cutre ejemplo que puse.
Otra afirmación asombrosa es la realizada en #138 "También podrías recompilarla contra Wine y tendrías una aplicación compatible con Windows". Realmente lo que se puede hacer es lo contrario. Programa fuente diseñado para windows.... compilarlo y enlazarlo como ELF incluyendo la conversión de llamadas win a linux syscall, D3D a opengl y mfc a Xwin entre otras conversiones. Pero insisto... la dirección es Windows ---> Linux.
Hay otro concepto que nombra en #138, donde menciona un tal "cargador". No se si se refiere al compilador, el enlazador, el ensamblado.
Si se refiere al compilador... no es importante, puesto que utilizando clang, el compilador de intel, u otro que cumpla con ISO C99 los cutre ejemplos que puesto funcionaran. Lo realmente importante son las opciones de enlazado (linker) que son las que dictaminan si se necesitaran librerías dinámicas y cuales serán.
Siempre es instructivo: www.calleerlandsson.com/posts/the-four-stages-of-compiling-a-c-program
Una forma de comprobar las llamadas en un ELF es objdump -T <binario elf> si existen las llamadas a librerías dinámicas y al kernel.
En el caso del ejemplo enlazado con musl hay 0 llamadas que no al sean al kernel.
En el caso de Alpine Linux dice usted que debería llamarse Alpine Posix.
alpinelinux.org/about/
¿Y en el caso de Gentoo? ¿A veces GNU/Gentoo a veces Posix/Gentoo? ¿Depende/Gentoo?
Le recuerdo que si utiliza solo aplicaciones posix en gentoo como openrc, xfce, xorg, etc... puede migrar de glibc a uClibc y viceversa recompilando el sistema.
P.D.: No entiendo la invocación a la ultra-derecha.
Todo ese rollo para decir lo que ya he dicho: que si compilas con el ISO C influenciado por GNU igual que POSIX C también influenciado por GNU el programa es portable y funcionará con cualquier sistema operativo, incluyendo Windows aunque no lo quieras reconocer. Pero ese hecho no cambia que el sistema operativo en ejecución sea GNU con Linux, Musl con Linux o GNU con GNU Hurd o GNU con NT.
Si no sabes qué significa "cargador" (del inglés loader) difícilmente comprenderás el funcionamiento de Wine, lo que es normal ya que tú mismo has dicho que es un emulador. Y no es un emulador. ELF, PE, Winelib o Mach-O. Todo es lo mismo. El cargador lo abstrae.
wiki.winehq.org/Wine_Developer's_Guide/Architecture_Overview
Insiste todo lo que quieras, Wine va en dos direcciones.
En el caso del ejemplo enlazado con musl hay 0 llamadas que no al sean al kernel.
En ninguno de los dos casos hay llamadas al kernel. Sólo hay llamadas a la biblioteca de tiempo de ejecución de C.
El ejemplo que pusiste a posteriori utilizando la llamada a sistema directamente elimina el uso de una biblioteca de C del sistema operativo que haya por defecto en la máquina. De hecho es una reimplementación de la biblioteca de C del sistema operativo, creando tu propia variante de SO.
¿Y en el caso de Gentoo? ¿A veces GNU/Gentoo a veces Posix/Gentoo? ¿Depende/Gentoo?
Le recuerdo que si utiliza solo aplicaciones posix en gentoo como openrc, xfce, xorg, etc... puede migrar de glibc a uClibc y viceversa recompilando el sistema.
xfce.org/download/changelogs/4.12
GTK+ dependency >= 2.24 and GLib >= 2.30.
mirrors.edge.kernel.org/pub/linux/libs/uclibc/Glibc_vs_uClibc_Differen
XFCE utiliza GTK, depende de Glib que es la biblioteca de GNOME, perteneciente al proyecto GNU, casualmente pensada para Glibc. Cada sistema operativo con Linux habrá realizado las adaptaciones que haya creído convenientes.
OpenRC no es más que un conjunto de scripts y un proceso init que los ejecuta, eso no parte definitoria del sistema operativo. No cambia la API del SO. Pero sí que es cierto que dicho proceso init debe estar preparado para ser compatible con GNU, Musl, uClibc, Bionic o lo que sea.
Si migras de una a otra recompilando significa que ya tienes que andar adaptando de un sistema operativo a otro. De hecho las diferencias entre uClibc y Glibc (o cualquier otra biblioteca) te obligan a realizar trabajo adicional para portar programas, por mucho que cumplas con POSIX. Las bibliotecas también tienen bugs y cada una tiene los suyos. Por otra parte nadie se ciñe exclusivamente a POSIX. Es una definición básica e insuficiente. Eso sí, cada vez meten más cosas de GNU, igual que en el ISO C.
R no compila con uClibc (2012): stat.ethz.ch/pipermail/r-help/2012-August/321428.html
Qt no se ha portado a Musl (2017): github.com/voidlinux/void-packages/issues/6893 Los de void Linux no han continuado con el port. Así que no tienes Qt 5.9 en Musl con Linux. Por el momento. Habrá que conformarse con Qt 5.43:
Yo para compilar programas de C de linux en windows solo he conseguido resultados con Mingw.
stackoverflow.com/questions/11828270/how-to-exit-the-vim-editor
Para mi el mas util es el :wq! para salir por las bravas guardando o el :q! para salir sin guardar
Y dirás "Podemos discutir si xfce+gtk3+cairo+etc fuera de GNU con Linux es seguro o eficiente, pero posible es." Y eso sólo es posible con la labor de porting necesaria, como la labor de porting necesaria para tener Qt en Windows. Es decir, estás programando específicamente para el sistema operativo que sea: GNU, uClibc, Musl, etc. Cada SO tiene sus propios bugs y aunque uClibc pretenda ser compatible con GNU nunca lo será con sus bugs. Si quiere 100% compatibilidad ha de imitar incluso los bugs de GNU. Si no los imita entonces la aplicación deberá ser modificada para soportarla.
No son programas de Linux, porque no existen los programas para Linux. Y por lo que veo no sabes compilar un programa ISO C contra Wine o contra Windows. He dicho compilar para cada sistema operativo, no he hablado de binario único en ningún momento. Empieza por ahí y quizá termines entendiendo algo de todo este galimatías.
Usted afirma que eso no existe. Me parece bien, es una opinión respetable.
Son programas para distintos sistemas operativos, entre ellos GNU con Linux, Musl con Linux y uClibc con Linux.
No son programas para Linux. El ELF no define el sistema operativo para el que está diseñado un programa como tampoco lo define el valor del parámetro EL_OSABI (ELFOSABI). Lo que define es para qué núcleo de sistema operativo o sistema operativo se ha generado el binario.
Está bien que ignores todo lo que se te ha rebatido. Sigue así, llegarás lejos. ¿Te crees que los demás son tontos o qué?
Los valores hard coded no son definitorios (como tampoco lo es el GNU/Linux que aparece al ejecutar el comando uname -o). De todas maneras pongo aquí cómo está definido EI_OSABI y sus posibles valores. El valor 0x03 de EI_OSASBI se corresponde con ELFOSABI_GNU.
sourceware.org/git/?p=glibc.git;a=blob;f=elf/elf.h;h=7e2b072a7f75451c0
135 #define EI_VERSION 6 /* File version byte index */
136 /* Value must be EV_CURRENT */
137
138 #define EI_OSABI 7 /* OS ABI identification */
139 #define ELFOSABI_NONE 0 /* UNIX System V ABI */
140 #define ELFOSABI_SYSV 0 /* Alias. */
141 #define ELFOSABI_HPUX 1 /* HP-UX */
142 #define ELFOSABI_NETBSD 2 /* NetBSD. */
143 #define ELFOSABI_GNU 3 /* Object uses GNU ELF extensions. */
144 #define ELFOSABI_LINUX ELFOSABI_GNU /* Compatibility alias. */
145 #define ELFOSABI_SOLARIS 6 /* Sun Solaris. */
146 #define ELFOSABI_AIX 7 /* IBM AIX. */
147 #define ELFOSABI_IRIX 8 /* SGI Irix. */
148 #define ELFOSABI_FREEBSD 9 /* FreeBSD. */
149 #define ELFOSABI_TRU64 10 /* Compaq TRU64 UNIX. */
150 #define ELFOSABI_MODESTO 11 /* Novell Modesto. */
151 #define ELFOSABI_OPENBSD 12 /* OpenBSD. */
152 #define ELFOSABI_ARM_AEABI 64 /* ARM EABI */
153 #define ELFOSABI_ARM 97 /* ARM */
154 #define ELFOSABI_STANDALONE 255 /* Standalone (embedded) application */
Definición de EI_OSABI:
EI_OSABI The eighth byte identifies the operating system and
ABI to which the object is targeted. Some fields in
other ELF structures have flags and values that have
platform-specific meanings; the interpretation of
those fields is determined by the value of this byte.
For example:
ELFOSABI_NONE Same as ELFOSABI_SYSV
ELFOSABI_SYSV UNIX System V ABI
ELFOSABI_HPUX HP-UX ABI
ELFOSABI_NETBSD NetBSD ABI
ELFOSABI_GNU GNU ABI // también conocido como ELFOSABI_LINUX (alias de compatibilidad): code.woboq.org/userspace/glibc/elf/elf.h.html
ELFOSABI_SOLARIS Solaris ABI
ELFOSABI_IRIX IRIX ABI
ELFOSABI_FREEBSD FreeBSD ABI
ELFOSABI_TRU64 TRU64 UNIX ABI
ELFOSABI_ARM ARM architecture ABI
ELFOSABI_STANDALONE Stand-alone (embedded) ABI
¿Sabías que en www.kernel.org/ encontrarás el código fuente de Linux y que Linux se define a sí mismo como sistema operativo? ¿Sabías que dicha definición fue cambiada al pasar a Linux 2.x? ¿sabías que la definición original, que se corresponde con la realidad, era la de núcleo de sistema operativo?
Yo entiendo que cuando usted habla de GNU/Linux esta acotando al uso de glibc y que cuando alguien habla de Linux se refiere a una clasificación mas genérica.
Pero me niega que se pueda hacer una clasificación superior. Igual puede negarme el uso del termino "Sistema Operativo" que sería una clasificación aun superior.
En todo caso es un asunto controvertido y mi actitud con el tema es flexible. En ningún momento quito relevancia a las implementaciones GNU, que en general son las mejores y utilizo masiva-mente.
Cuando hablo de GNU con Linux no acoto sólo al uso de Glibc. También a ld.so y Linux. Acoto a un sistema operativo.
github.com/torvalds/linux/blob/master/include/uapi/linux/elf.h#L38
No se puede realizar una clasificación más genérica. De GNU con Linux, Musl con Linux o uClibc con Linux se pasa a sistemas operativos con Linux o UNIX - System V, puesto que como ya hemos visto, el ABI del ELF es del todo irrelevante cuando se habla de sistemas tipo Unix.
Porque, ¿qué ocurre con las aplicaciones Windows que funcionan con Wine? ¿y qué ocurre con las aplicaciones para Android? ¿significa eso que las aplicaciones Wine están diseñadas para GNU con Linux? ¿y LXC? ¿y VirtualBox?
El formato del ejecutable es irrelevante, no define en ningún momento el sistema operativo objetivo. Basta con que ld.so reconozca el formato de ejecutable requerido para que cargue el binario y busque las bibliotecas dinámicas requeridas para dicho formato de binario.
¿Bash es para GNU o para Linux o para UNIX System V? (ELFOSABI_NONE 0 /* UNIX System V ABI */ ELFOSABI_SYSV 0 /* Alias. */)
readelf -h /bin/bash
Encabezado ELF:
Mágico: 7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00
Clase: ELF64
Datos: complemento a 2, little endian
Versión: 1 (current)
OS/ABI: UNIX - System V
Versión ABI: 0
Tipo: DYN (Fichero objeto compartido)
Máquina: Advanced Micro Devices X86-64
Versión: 0x1
Dirección del punto de entrada: 0x31520
Inicio de encabezados de programa: 64 (bytes en el fichero)
Inicio de encabezados de sección: 1111712 (bytes en el fichero)
Opciones: 0x0
Tamaño de este encabezado: 64 (bytes)
Tamaño de encabezados de programa: 56 (bytes)
Número de encabezados de programa: 9
Tamaño de encabezados de sección: 64 (bytes)
Número de encabezados de sección: 28
Índice de tabla de cadenas de sección de encabezado: 27
En #80 yo hablo de tuberías (pipes), expansión de parámetros, expresiones regulares. Todo esto se puede conseguir, sin utilizar GNU, contra un ABI de núcleo Linux con software ya existente. De igual manera se puede crear un ELF en estático para el ABI de kernel linux sin incluir nada de GNU.
Como este tema esta hiriendo sensibilidades en el futuro empleare el termino "Sistemas con ABI de kernel Linux" y le pido disculpas por utilizar algunas fuentes de información incorrectas como las siguientes:
www.gentoo.org/get-started/about/
www.openssh.com/portable.html
www.centos.org/about/
en.wikipedia.org/wiki/Linux
Las tuberías aquí no tienen nada que ver. Sin utilizar GNU, pero utilizarás otra cosa porque esto es un sistema tipo UNIX y el núcleo no lo tocas ni con un palo. Al crear una tubería puede que obtengas un descriptor de fichero reutilizado por la Biblioteca de tiempo de ejecución de C que mantuviera en espera para mejorar el rendimiento, como ocurre con la memoria dinámica o los hilos en el caso de GNU OpenMP y GNU NPTL. La ABI que utiliza el usuario es la de GNU o Musl o la del espacio de usuario que sea. La ABI del núcleo solo la utiliza la ABI de la Biblioteca de tiempo de ejecución de C correspondiente, da igual si está integrada en la aplicación o se carga dinámicamente. La aplicación utiliza la ABI de la Biblioteca de tiempo de ejecución de C. No es posible acceder a la ABI del núcleo porque interferiría con las gestiones de la Biblioteca de tiempo de ejecución de C.
Es una pena que pretendas utilizar como fuentes webs que utilizan conceptos erróneos continuamente.
No comparemos servidores de oficina con servidores de internet o supercomputadores... es como comparar patinetes de xiaomi con ferraris o camiones...
Ventaja principal: Scripting, concatenación de comandos, volcado de salidas, etc.... lo scripteas una vez y lo tienes para siempre.
Lo de la "genial idea" de llamar a C: como /dev/sda1, etc, es para poder distinguir discos en unidades Raid o LVM, en los que tu "c:" puede ser mezcla de 4-5 o mas discos duros fisicos diferentes, de diferentes tamaños actuando como uno único (¿magia verdad? Y si supieras que puedes usar la RAM como disco.... hay que ver que cosas se pueden hacer con algo de conocimiento y el sistema adecuado)