Portada
mis comunidades
otras secciones
#7:
#5 A parte de lo cansino de la típica pedantería que sueltas, que lleva siendo cansina desde hace 20 años, es que no tienes razón.
iproute2 es una herramienta para administrar el networking del kernel Linux, conectándose directamente al kernel via netlink y modificando las tablas internas del kernel. No es una herramienta GNU ni específica para distribuciones GNU/Linux, funciona en cualquier sitio donde haya un kernel linux con networking y soporte para netlink.
iproute2 es una herramienta para administrar el networking del kernel Linux, conectándose directamente al kernel via netlink y modificando las tablas internas del kernel. No es una herramienta GNU ni específica para distribuciones GNU/Linux, funciona en cualquier sitio donde haya un kernel linux con networking y soporte para netlink.
#38:
#32 En realidad no es exactamente así. Es cierto que el nombre "systemd", en origen, era el del reemplazo de init, pero poco después se convirtió en un "proyecto paraguas". Es algo así como "el proyecto gnome" o "KDE", que en realidad son "proyectos paraguas" que aglutinan muchas cosas independientes (el escritorio, utilidades, applets...). Actualmente "systemd" comprende, por un lado, el binario que reemplaza a init (y es un binario que SOLO hace las funciones de init). Luego, dentro del proyecto "systemd" hay más utilidades, pero son binarios independientes y cada uno hace su tarea, para lanzar entornos CHROOT, para UDEV, LOGIN, LOGs, etc. Pero, y esta es la clave, cada uno es un binario que hace una sola cosa, y la hace bien, igual que en el UNIX original. De hecho, en muchos casos no es más que la herramienta original, que antes iba "a su bola" pero ahora está integrada dentro del mismo proyecto. La diferencia es que, dado que es inevitable que una herramienta dependa de otras, al estar en un proyecto paraguas te aseguras de que un cambio en una que afecte a las demás se corregirá de inmediato en ellas, en lugar de lo que pasaba antes, que cambiaban algo en un lado, y hasta un par de semanas después no salía la nueva versión de la herramienta X que fallaba por el cambio.
Un ejemplo: ifconfig es una herramienta que hace una sola cosa y la hace bien, pero necesita que los datos en los ficheros virtuales de /proc estén en un formato concreto. Si un día los programadores de linux cambian ese formato por el motivo que sea, hay que modificar también ifconfig para que los reconozca. Si ifconfig está en un proyecto independiente del núcleo, si la comunicación entre ambos no es buena se producirán retardos y habrá un periodo en que habrá problemas.
La idea de hacer "systemd" un proyecto paraguas no es otra que, precisamente, garantizar una buena comunicación entre todos los desarrolladores de los elementos clave del arranque del sistema y evitar estos problemas que pueden hacer que una máquina, directamente, no arranque. Pero cada utilidad dentro de él sigue "haciendo una sola cosa, y haciéndola bien".
Un ejemplo: ifconfig es una herramienta que hace una sola cosa y la hace bien, pero necesita que los datos en los ficheros virtuales de /proc estén en un formato concreto. Si un día los programadores de linux cambian ese formato por el motivo que sea, hay que modificar también ifconfig para que los reconozca. Si ifconfig está en un proyecto independiente del núcleo, si la comunicación entre ambos no es buena se producirán retardos y habrá un periodo en que habrá problemas.
La idea de hacer "systemd" un proyecto paraguas no es otra que, precisamente, garantizar una buena comunicación entre todos los desarrolladores de los elementos clave del arranque del sistema y evitar estos problemas que pueden hacer que una máquina, directamente, no arranque. Pero cada utilidad dentro de él sigue "haciendo una sola cosa, y haciéndola bien".
#19:
#12 Tenenos un cluster HP-UX en arquitectura Itanium con máquinas que contienen VM y su vez contienen contenedores de máquinas HP con arquitectura PA-RISC. Es un truñardo de dimensiones épicas. Eso sí, en dos bastidores hemos metido lo que antes estaba en dos filas enteras del CPD.
En cuanto a Linux tenemos muchos contenedores, pero nos sale más a cuenta esperar a que le cliente deje de tener la necesidad de ejecutar cierto software que corre en esos servidores que los costes de la migración. Además de algunos casos de éxito tenemos algunos casos de sonados fracasos.
Lo mismo con Solaris. Al mes de estar todo funcionando en un nuevo entorno nos llegan quejas de que ciertas funcionalidades ya no funcionan.
Y dependiendo de cómo funcione el contenedor se pierden algunas carateristicas que en la máquina física se tenían y que no conviene perder.
El mundo de los sistemas legacy es apasionante.
En cuanto a Linux tenemos muchos contenedores, pero nos sale más a cuenta esperar a que le cliente deje de tener la necesidad de ejecutar cierto software que corre en esos servidores que los costes de la migración. Además de algunos casos de éxito tenemos algunos casos de sonados fracasos.
Lo mismo con Solaris. Al mes de estar todo funcionando en un nuevo entorno nos llegan quejas de que ciertas funcionalidades ya no funcionan.
Y dependiendo de cómo funcione el contenedor se pierden algunas carateristicas que en la máquina física se tenían y que no conviene perder.
El mundo de los sistemas legacy es apasionante.
#15:
Si dan información errónea o incompleta me parece normal no usarlos y cambiarlos. No sé porqué en las distribuciones no usan el concepto de depreciación de las bibliotecas de programación.
Que pongan esos comandos en cuarentena unas cuantas versiones, con avisos grandes y una lista de alternativas y a la siguiente iteración las eliminan. Si alguien no se hubiese enterado no sería porque no le han avisado.
Por otro lado me resulta curioso que digan que una pega es que esas herramientas están haciendo algo ineficiente leyendo de los ficheros de /proc. ¿Dónde quedó eso de que todo en Unix es un fichero? ¿No estamos complicando y heterogeneizando el sistema con diferentes interfaces con la excusa del rendimiento?
Antes mirabas en /proc si no alcanzabas a entender algún estado del sistema. Luego se inventaron /sys. Ahora igual tienes que mirar en los netlink esos y en el futuro vete a saber... Supongo que los desarrolladores saben porqué lo hacen, pero a veces están en su burbuja y ver más allá se hace difícil, con los consecuentes errores imprevistos o daños colaterales que no previeron
Que pongan esos comandos en cuarentena unas cuantas versiones, con avisos grandes y una lista de alternativas y a la siguiente iteración las eliminan. Si alguien no se hubiese enterado no sería porque no le han avisado.
Por otro lado me resulta curioso que digan que una pega es que esas herramientas están haciendo algo ineficiente leyendo de los ficheros de /proc. ¿Dónde quedó eso de que todo en Unix es un fichero? ¿No estamos complicando y heterogeneizando el sistema con diferentes interfaces con la excusa del rendimiento?
Antes mirabas en /proc si no alcanzabas a entender algún estado del sistema. Luego se inventaron /sys. Ahora igual tienes que mirar en los netlink esos y en el futuro vete a saber... Supongo que los desarrolladores saben porqué lo hacen, pero a veces están en su burbuja y ver más allá se hace difícil, con los consecuentes errores imprevistos o daños colaterales que no previeron
#10:
#1 Solonsi actualizas. Yo seguiré con mis lavadoras HP-UX 11.00 y mis RedHat 7 aguantando al pie del cañón en un entorno donde la empresa que hizo el software que corre en esos servidores ya no existe pero la necesidad de seguirlo ejecutando si. No corren en nada mas moderno.
El tiempo pasa, las herramientas evolucionan y aunque duela es hora de actualizar scripts.
El tiempo pasa, las herramientas evolucionan y aunque duela es hora de actualizar scripts.
Comentarios
#12 Tenenos un cluster HP-UX en arquitectura Itanium con máquinas que contienen VM y su vez contienen contenedores de máquinas HP con arquitectura PA-RISC. Es un truñardo de dimensiones épicas. Eso sí, en dos bastidores hemos metido lo que antes estaba en dos filas enteras del CPD.
En cuanto a Linux tenemos muchos contenedores, pero nos sale más a cuenta esperar a que le cliente deje de tener la necesidad de ejecutar cierto software que corre en esos servidores que los costes de la migración. Además de algunos casos de éxito tenemos algunos casos de sonados fracasos.
Lo mismo con Solaris. Al mes de estar todo funcionando en un nuevo entorno nos llegan quejas de que ciertas funcionalidades ya no funcionan.
Y dependiendo de cómo funcione el contenedor se pierden algunas carateristicas que en la máquina física se tenían y que no conviene perder.
El mundo de los sistemas legacy es apasionante.
Si dan información errónea o incompleta me parece normal no usarlos y cambiarlos. No sé porqué en las distribuciones no usan el concepto de depreciación de las bibliotecas de programación.
Que pongan esos comandos en cuarentena unas cuantas versiones, con avisos grandes y una lista de alternativas y a la siguiente iteración las eliminan. Si alguien no se hubiese enterado no sería porque no le han avisado.
Por otro lado me resulta curioso que digan que una pega es que esas herramientas están haciendo algo ineficiente leyendo de los ficheros de /proc. ¿Dónde quedó eso de que todo en Unix es un fichero? ¿No estamos complicando y heterogeneizando el sistema con diferentes interfaces con la excusa del rendimiento?
Antes mirabas en /proc si no alcanzabas a entender algún estado del sistema. Luego se inventaron /sys. Ahora igual tienes que mirar en los netlink esos y en el futuro vete a saber... Supongo que los desarrolladores saben porqué lo hacen, pero a veces están en su burbuja y ver más allá se hace difícil, con los consecuentes errores imprevistos o daños colaterales que no previeron
#15 bueno, la cuestión es que ya hay problemas de rendimiento reales con ifconfig y demás cosas que intentan parsear cosas de /proc y /sys . Un ejemplo: en sistemas que corren VMs de openstack o contenedores con centenares de bridges, un `ifconfig -a` puede tardar más de 20 minutos solo en listar los interfaces. `ip a` lo hace en menos de 1 segundo...
#25 ¿Pero ese problema es por "parsear" el fichero en serie mientras que con netlink se puede hacer en paralelo? ¿Porque el núcleo tarda mucho en generar el fichero en /proc u otra razón?
Quizás la tecnología "todo es un fichero" ya no escala en estos tiempos, pero da la impresión de que parche aquí, parche allá, al final tenemos multiples subsistemas, cada uno con sus reglas y forma de hacer las cosas diferentes entre sí. Al final eso genera un batiburrillo complicado de aprender.
#14 no son lo mismo?
#4 te recomiendo aprovechar la situación y aprender a usar ip que es mucho más versátil y potente
Como no me habian tocado bastante los webos con el p***o systemd, ahora me van cambiando mas herramientas?
Vale, que todo evoluciona poero no me digais que no es tocapelotas, 4 o 5 años despues sigo buscando el maldito initd
#26 Ya tenía que salir alguien mentando systemd. Tanto init cómo estás herramientas se están cambiando en sistemas modernos porque tienen limitaciones insalvables, así de simple.
Pero nadie te obliga a usarlas, hay mucha gente con mucho tiempo libre y muy poco que hacer que se dedica a mantener SOs con herramientas antiguas. Si tanto te gustan, pásate a esos. Por ejemplo Devuan.
#28 Tienes acciones de systemd o que?
#30 No. Simplemente se en que lado de la historia estoy.
Estoy en el mismo lado que la totalidad de distribuciones serías de GNU Linux que se utilizan para sistemas de producción enormes de alta disponibilidad. Igual estamos todos equivocados y los genios con nicknames entrecomillados de Devuan (https://devuan.org/os/team/) tienen razón, pero no me suena ver ningún caso de uso relevante para su SO, por algo será.
CC #32
#28 Una de las grandísimas ventajas de unix era que las herramientas hacen una sola cosa pero la hacen bien.
Systemd va en contra de esa filosofía que tan bien había funcionado hasta ahora.
#32 En realidad no es exactamente así. Es cierto que el nombre "systemd", en origen, era el del reemplazo de init, pero poco después se convirtió en un "proyecto paraguas". Es algo así como "el proyecto gnome" o "KDE", que en realidad son "proyectos paraguas" que aglutinan muchas cosas independientes (el escritorio, utilidades, applets...). Actualmente "systemd" comprende, por un lado, el binario que reemplaza a init (y es un binario que SOLO hace las funciones de init). Luego, dentro del proyecto "systemd" hay más utilidades, pero son binarios independientes y cada uno hace su tarea, para lanzar entornos CHROOT, para UDEV, LOGIN, LOGs, etc. Pero, y esta es la clave, cada uno es un binario que hace una sola cosa, y la hace bien, igual que en el UNIX original. De hecho, en muchos casos no es más que la herramienta original, que antes iba "a su bola" pero ahora está integrada dentro del mismo proyecto. La diferencia es que, dado que es inevitable que una herramienta dependa de otras, al estar en un proyecto paraguas te aseguras de que un cambio en una que afecte a las demás se corregirá de inmediato en ellas, en lugar de lo que pasaba antes, que cambiaban algo en un lado, y hasta un par de semanas después no salía la nueva versión de la herramienta X que fallaba por el cambio.
Un ejemplo: ifconfig es una herramienta que hace una sola cosa y la hace bien, pero necesita que los datos en los ficheros virtuales de /proc estén en un formato concreto. Si un día los programadores de linux cambian ese formato por el motivo que sea, hay que modificar también ifconfig para que los reconozca. Si ifconfig está en un proyecto independiente del núcleo, si la comunicación entre ambos no es buena se producirán retardos y habrá un periodo en que habrá problemas.
La idea de hacer "systemd" un proyecto paraguas no es otra que, precisamente, garantizar una buena comunicación entre todos los desarrolladores de los elementos clave del arranque del sistema y evitar estos problemas que pueden hacer que una máquina, directamente, no arranque. Pero cada utilidad dentro de él sigue "haciendo una sola cosa, y haciéndola bien".
#26 a ver, que se lleva avisando al menos 10 años de que ifconfig y netstat quedan obsoletos y que pases a ip y ss...
Ala.. a cambiar los scripts
#1 Bueno, teniendo en cuenta que algunas herramientas como ifconfig se las han cargado igualmente y su salida ya no es igual que antes...
#1 Nadie te va a obligar a desinstalar las net-tools.
Pero vaya, que iproute2 ya iba por la 3.0 en 2011. No creo que esta recomendación pille por sorpresa a nadie.
#3 Si no recuerdo mal, debian stretch por defecto no las lleva instaladas. A mi me pilló desprevenido al reinstalar una máquina que, (siguiendo la ley de murfy) se quedó sin internet
#1 Solonsi actualizas. Yo seguiré con mis lavadoras HP-UX 11.00 y mis RedHat 7 aguantando al pie del cañón en un entorno donde la empresa que hizo el software que corre en esos servidores ya no existe pero la necesidad de seguirlo ejecutando si. No corren en nada mas moderno.
El tiempo pasa, las herramientas evolucionan y aunque duela es hora de actualizar scripts.
#10 una buena oportunidad para intentar hacer correr ese software en contenedores
#12 ¿Contenedores Linux o de la basura?
#10 Siendo un novato absoluto en el tema, ¿no sería posible mejorar ifconfig de manera que pueda ofrecer la salida correcta, completa, de información usando un switch específico, de manera que los nuevos scripts puedan usarlo, pero que no rompa los scripts que ya hay?
En cuanto a la forma de trabajar de cada comando, ¿qué problema hay en que coexistan ifconfig e ip, como han venido coexistiendo hasta ahora, y que cada admin use el que más le convenga en cada momento?
#45 No hay ningún problema en que coexistan. Vienen en paquetes distintos y extraen su información de lugares distintos.
El problema de compatibilidad es que las herrameintas antiguas, y los scripts que las utilizan, no contemplan la posibilidad de que una misma interfaz tenga por ejemplo más de una IP, por ejemplo. Así que en los casos donde solo tienen una configurada podrías incluso desinstalar el paquete donde viene ifconfig y crear un alias o un script llamado ifconfig que llame a ip y que muestre la salida como la muestra ifconfig, pero hay casos donde no es posible.
Luego hay que pensar en quien viene después. Cuando uso ifconfig quiero la salida de ifconfig y cuando uso ip la que muestra IP. Espero que mi predecesor no me haya hecho ñapas de eliminar binarios básicos y cambiármelos por scripts que igual mañana me dejan de funcionar.
Qué raro ver una meneo de esta categoría en portada
#20 ¿Acabas de descubrir que meneame es frikilandia?
(Me incluyo, eh)
#24 Calla, que mi primera portada fue un artículo sobre un fallo de Linux, y mi segunda portada una aclaración desmintiendo/corrigiendo la primera…
El hispterismo llega hasta Linux ... Yo por el ifconfig mato, me entiendesssss ? MA-TO!!!!
Pues el emacs es una mierda. Yo me quedo con vi.
Era aquí donde se dan opiniones sobre opciones? Me tengo que poner al día ahora es ifconfig o ip.
#13 No es parte del kernel, pero es una herramienta para administrar el kernel Linux. Puedes usarlo en Linux sin GNU, pero no puedes usarlo en GNU/FreeBSD, por ejemplo.
#41 Como muchas herramientas GNU
#41
netlink también está en FreeBSD.
https://www.freebsd.org/cgi/man.cgi?query=netlink&sektion=7&manpath=SuSE+Linux/i386+11.3
Por eso decía sólo lo de GNU y opcionalmente GNU/Linux si quieres ser más específico.
De hecho util-linux está diseñado para ser multiplataforma: https://mirrors.edge.kernel.org/pub/linux/utils/util-linux/v2.32/v2.32-ReleaseNotes (sirva de ejemplo el cambio en libblkid para FreeBSD).
# 49 ( usuario bcc2c436cab )
o sea que según tú, un software es específico para un SO si el binario compilado para este SO usa las librerías de dicho SO? Que se haya compilado contra la libc de GNU no quiere decir que dependa de GNU, también se podría haber compilado contra otra libc. Ahora mira el binario "ip" en Android a ver contra qué está linkado.
Creo que estás intentando tratar un tema que no dominas mucho.
----
Un poco ruin eso de responder a alguien y luego meterlo en ignorados para que no te pueda replicar a la tontería que has dicho
#56
Cree lo que quieras, pero diciendo eso demuestras que no dominas nada.
#53 te da más detalles si quieres leerlos claro.
Y lo que es ruin es votar negativo a un comentario que ni es racista, ni hace spam, ni insulta, ni es xenófobo.
#13 iproute2 se aloja en kernel.org. https://git.kernel.org/pub/scm/network/iproute2/iproute2.git
Todo util-linux se ejecuta en userspace y es parte del proyecto del kernel, auque luego a nivel de código no tenga nada que ver https://en.wikipedia.org/wiki/Util-linux
Joder, tengo que reinstalarme Linux de ya y ponerme al día
Cuando hagan que la salida de un "ip address show" sea tan práctica y legible como la de un "ifconfig", empezaré a usar ip.
#31 con ip a te vale.
#34 Si, pero no me quejo de la cantidad de teclas que tengo que presionar sino del formato del resultado. Es muchísimo más legible el de ifconfig. Por ejemplo:
.
#36 En realidad, bastaría con añadir una línea en blanco entre interfaces... no es un cambio demasiado grande...
#39 Y algunas tabulaciones o algo para que salga más encolumnado, no se.
Lo mismo me pasa con ip route vs. route (o netstat -rn) aunque reconozco que el ip route y el ip addrees permiten más cosas que un simple ifconfig o un route xx la salida es mucho más fácil de leer:
.
#51
Que no tenga significado no significa que no tenga sentido.
La verdad es que el nombre apropiado tendría que ser util-kernel y no util-linux, pero el ego a algunos le juega malas pasadas.
#72
En ningún momento he dicho que Netlink sea GNU.
La afirmación incial es que ip está diseñado para GNU y FreeBSD, no sé si otros sistemas operativos están implicados.
Glibc hace chequeos previos. Si metes 127 ese valor no llegará al núcleo.
#76
Eso si puedes compilarlo con LLVM y Musl.
Pero insistes en que no está pensado para GNU cuando lo que estoy diciendo es que está pensado para GNU y otros sistemas operativos aunque aparte de FreeBSD no sé cuales. ¿Los basados en Musl? Puede, no lo sé.
#79
Sinceramente, cualquiera que lea el hilo de comentarios encontrará una explicación a todo lo que cuestionas.
#62
1- Está diseñado para GNU, se convierte automáticamente en un software para GNU aunque su autoría no sea la de GNU.
2- No he dicho lo contrario.
Y por favor, eso de linkado está muy feo. Enlazado o vinculado.
#63 Es que ip no está diseñado para GNU, está diseñado para linux.
#64
Está diseñado para GNU y otros sistemas operativos como FreeBSD.
#65 Se diseñó para gestionar interfaces de redes en linux. Netlink lo implementa Alexey Kuznetsov[1] porque necesita un mecanismo para comunicarse entre el kernel y userspace y ninguna de las alternativas existentes era satisfactoria [2]. Y el mismo Alexey Kuznetsov hace iproute2[3].
Es completamente ABSURDO hablar de GNU y netlink cuando netlink es un tipo de socket, de modo que se implementa en kernelspace y lo unico que hace glibc es que cuando llamas a socket te admite en el protocolo AF_NETLINK, que al final es meter en la lista de protocolos una entrada con #define AF_NETLINK 16 (si, he ido a buscarlo)
Otra cosa es que algunos BSD hayan implementado netlink porque les convenció igual que linux probablemente acabe implementando pledge de openBSD.
1- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/net/core/rtnetlink.c
2- https://pdfs.semanticscholar.org/6efd/e161a2582ba5846e4b8fea5a53bc305a64f3.pdf
3- https://wiki.linuxfoundation.org/networking/iproute2
#67
No es absurdo hablar de GNU y netlink puesto que GNU es quien permite a los programas acceder a la implementación netlink del núcleo subyacente, como ocurre en GNU/kFreeBSD.
Tú mismo lo dices, permite comunicar espacio de usuario con espacio de núcleo. Si GNU no soporta Netlink el usuario no podrá usar netlink. Las cabeceras se distribuyen con GNU y la gestión previa a la comunicación con el núcleo se hace con GNU.
Nótese que GNU Hurd también soportará Netlink. Código fuente de GNU Libc:
./sysdeps/mach/hurd/ifaddrs.c
./sysdeps/unix/sysv/linux/bits/socket.h
./sysdeps/unix/sysv/linux/mq_notify.c
./sysdeps/unix/sysv/linux/Versions
./sysdeps/unix/sysv/linux/if_index.c
./sysdeps/unix/sysv/linux/check_pf.c
./sysdeps/unix/sysv/linux/Makefile
./sysdeps/unix/sysv/linux/netlink_assert_response.c
./sysdeps/unix/sysv/linux/netlinkaccess.h
./sysdeps/unix/sysv/linux/ifaddrs.c
./sysdeps/unix/sysv/linux/check_native.c
./nscd/connections.c
./nscd/nscd-client.h
./nscd/selinux.c
#70 No tiene ningún sentido lo que dices. La función socket espera una serie de parámetros, y cuando metes AF_NETLINK lo que hace es que tiene una definición de que AF_NETLINK = 16. Y eso se le pasa al kernel tal cual le llega (hazme caso, que he comprobado el código)
Si en vez de meterle AF_NETLINK le metes 127 (que cabe) glibc se lo pasa igual al kernel, otra cosa es que el kernel luego te devuelva un error.
Ahora, si netlink es GNU porque porque la gente de glibc ha añadido una linea que pone
#define AF_NETLINK 16
Pues ahi ante esa lógica aplastante ya no digo nada.
> Nótese que GNU Hurd también soportará Netlink
HURD tambien soporta TCP y creo que no por ello nadie diria que TCP es GNU.
#66
No sé cuál es la intención de tu mensaje. Linux adoptó ELF en 1995: https://www.linuxjournal.com/article/1059
Los binarios generados por o para GNU tienen secciones propias de GNU y están enlazados con la GNU libc. Linux en sí mismo está pensado para GNU utilizando la API del C de GNU (GCC).
EDITADO: Le di a enviar sin querer
#68 Pues que no existe tal cosa como enlazar con GNU. Enlazas ficheros ELF y luego tienen que coincidir los parametros,pero eso es tema de la llamada a la función en si y da igual linkado estático dinámico etc.
$ readelf -h /sbin/ip
> Los binarios generados por o para GNU tienen secciones propias de GNU y están enlazados con la GNU libc.
> Linux en sí mismo está pensado para GNU utilizando la API del C de GNU (GCC).
ELF Header:
Magic: 7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00
Class: ELF64
Data: 2's complement, little endian
Version: 1 (current)
OS/ABI: UNIX - System V
ABI Version: 0
Type: DYN (Shared object file)
Machine: Advanced Micro Devices X86-64
Version: 0x1
Entry point address: 0xba00
Start of program headers: 64 (bytes into file)
Start of section headers: 590520 (bytes into file)
Flags: 0x0
Size of this header: 64 (bytes)
Size of program headers: 56 (bytes)
Number of program headers: 11
Size of section headers: 64 (bytes)
Number of section headers: 30
Section header string table index: 29
El formato del binario en si es ELF generico, no tiene ninguna extensión GNU. En las secciones solo mete información del compilador:
$ readelf --sections /sbin/ip
There are 30 section headers, starting at offset 0x902b8:
Section Headers:
[Nr] Name Type Address Offset
Size EntSize Flags Link Info Align
[ 0] NULL 0000000000000000 00000000
0000000000000000 0000000000000000 0 0 0
[ 1] .interp PROGBITS 00000000000002a8 000002a8
000000000000001c 0000000000000000 A 0 0 1
[ 2] .note.ABI-tag NOTE 00000000000002c4 000002c4
0000000000000020 0000000000000000 A 0 0 4
[ 3] .note.gnu.propert NOTE 00000000000002e8 000002e8
0000000000000030 0000000000000000 A 0 0 8
[ 4] .note.gnu.build-i NOTE 0000000000000318 00000318
0000000000000024 0000000000000000 A 0 0 4
[ 5] .gnu.hash GNU_HASH 0000000000000340 00000340
0000000000000c3c 0000000000000000 A 6 0 8
[ 6] .dynsym DYNSYM 0000000000000f80 00000f80
0000000000003330 0000000000000018 A 7 1 8
[ 7] .dynstr STRTAB 00000000000042b0 000042b0
0000000000001b86 0000000000000000 A 0 0 1
[ 8] .gnu.version VERSYM 0000000000005e36 00005e36
0000000000000444 0000000000000002 A 6 0 2
[ 9] .gnu.version_r VERNEED 0000000000006280 00006280
00000000000000f0 0000000000000000 A 7 4 8
[10] .rela.dyn RELA 0000000000006370 00006370
00000000000037e0 0000000000000018 A 6 0 8
[11] .rela.plt RELA 0000000000009b50 00009b50
0000000000000e58 0000000000000018 AI 6 23 8
[12] .init PROGBITS 000000000000a9a8 0000a9a8
0000000000000017 0000000000000000 AX 0 0 4
[13] .plt PROGBITS 000000000000a9c0 0000a9c0
00000000000009a0 0000000000000010 AX 0 0 16
[14] .text PROGBITS 000000000000b360 0000b360
0000000000056e31 0000000000000000 AX 0 0 16
[15] .fini PROGBITS 0000000000062194 00062194
0000000000000009 0000000000000000 AX 0 0 4
[16] .rodata PROGBITS 00000000000621a0 000621a0
0000000000013c19 0000000000000000 A 0 0 32
[17] .eh_frame_hdr PROGBITS 0000000000075dbc 00075dbc
0000000000001444 0000000000000000 A 0 0 4
[18] .eh_frame PROGBITS 0000000000077200 00077200
0000000000008868 0000000000000000 A 0 0 8
[19] .init_array INIT_ARRAY 0000000000280790 00080790
0000000000000008 0000000000000008 WA 0 0 8
[20] .fini_array FINI_ARRAY 0000000000280798 00080798
0000000000000008 0000000000000008 WA 0 0 8
[21] .data.rel.ro PROGBITS 00000000002807a0 000807a0
0000000000001110 0000000000000000 WA 0 0 32
[22] .dynamic DYNAMIC 00000000002818b0 000818b0
0000000000000230 0000000000000010 WA 7 0 8
[23] .got PROGBITS 0000000000281ae0 00081ae0
0000000000000518 0000000000000008 WA 0 0 8
[24] .data PROGBITS 0000000000282000 00082000
0000000000005c40 0000000000000000 WA 0 0 32
[25] .bss NOBITS 0000000000287c40 00087c40
0000000000049dd0 0000000000000000 WA 0 0 32
[26] .gnu.build.attrib NOTE 0000000000000000 00087c40
0000000000006900 0000000000000000 0 0 4
[27] .gnu_debuglink PROGBITS 0000000000000000 0008e540
0000000000000024 0000000000000000 0 0 4
[28] .gnu_debugdata PROGBITS 0000000000000000 0008e564
0000000000001c18 0000000000000000 0 0 1
[29] .shstrtab STRTAB 0000000000000000 0009017c
0000000000000135 0000000000000000 0 0 1
Key to Flags:
W (write), A (alloc), X (execute), M (merge), S (strings), I (info),
L (link order), O (extra OS processing required), G (group), T (TLS),
C (compressed), x (unknown), o (OS specific), E (exclude),
l (large), p (processor specific)
Esas secciones se pueden quitar si haces un strip del binario. Son fundamentalmente los DWARF. Pero porque está compilado en fedora. Si lo compilas con clang no tiene nada de eso.
#69
$readelf -e /bin/ip
Encabezados de Programa:
Tipo Desplazamiento DirVirtual DirFísica
TamFichero TamMemoria Opts Alineación
PHDR 0x0000000000000040 0x0000000000000040 0x0000000000000040
0x00000000000001f8 0x00000000000001f8 R 0x8
INTERP 0x0000000000000238 0x0000000000000238 0x0000000000000238
0x000000000000001c 0x000000000000001c R 0x1
[Requesting program interpreter: /lib64/ld-linux-x86-64.so.2]
LOAD 0x0000000000000000 0x0000000000000000 0x0000000000000000
0x000000000007ead8 0x000000000007ead8 R E 0x200000
LOAD 0x000000000007f7d0 0x000000000027f7d0 0x000000000027f7d0
0x0000000000007470 0x0000000000051240 RW 0x200000
DYNAMIC 0x00000000000808d0 0x00000000002808d0 0x00000000002808d0
0x0000000000000220 0x0000000000000220 RW 0x8
NOTE 0x0000000000000254 0x0000000000000254 0x0000000000000254
0x0000000000000044 0x0000000000000044 R 0x4
GNU_EH_FRAME 0x000000000007501c 0x000000000007501c 0x000000000007501c
0x000000000000143c 0x000000000000143c R 0x4
GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000
0x0000000000000000 0x0000000000000000 RW 0x10
GNU_RELRO 0x000000000007f7d0 0x000000000027f7d0 0x000000000027f7d0
0x0000000000001830 0x0000000000001830 R 0x1
#71 Eso no son secciones, son cabeceras, y las ha metido el linker, insisto, si lo compilas con llvm no estrían
#69
La ABI de GNU es específica de GNU. Por suerte ésta es estable.
No he hablado de enlazado dinámico o estático precisamente porque es irrelevante. Simplemente con ldd mostraba las bibliotecas con las que estaba enlazadas y por tanto con las que «ip» tiene que ser compatibles/estar diseñado para.
#74 Paso de discutir más, todo lo que hay especifico de GNU lo ha metido el compilador o en su defecto, si compilas con musl y llvm (cosa que puedes hacer) no te sale nada de eso.
Tampoco hay que correr en circulos gritando pudiendo desinstalar los paquetes obsoletos y creando aliases de los antiguos comandos con la nueva sintaxis.
entiendo que sea importante, y que medio menéame sean informáticos, pero que esto sea portada me parece demencial
#60 A mi me parece muy cabal, cuando Menéame molaba hace años, había mínimo cada dos días una noticia sobre software libre.
Después vino el grafeno, los gatos y ahora estamos en la época forocoches.
#60 Lo que es demencial es la política a todas horas, teniendo en cuenta que menéame empezó como una comunidad que venía de barrapunto.
#60 Y por qué te parece demencial??
Si sabes que medio MNM son informáticos... y que este envío para ellos es importante... que parte es lo que te parece demencial??
Porque, aunque a ti la informática o siendo más específico, los comandos de los OS UNIX , no te digan nada; que un artículo como este haya llegado a portada, no creo que te haya impedido leer o comentar en cualquiera de los otros envíos que hay en la portada.
#27 Y Naik se pronuncia naiki...
pero el pueblo habla... mal... pero habla.
#61 Los ingleses dicen "naik", los estadounidenses "naiki" y los griegos que adoraban a la diosa que da nombre a la marca de ropa "nike". Así que...
ifconfig o ifconf o ipconfig o ipconf? bienvenido sea ip!
Mientras que podamos seguir eligiendo entre lo viejo y lo nuevo yo no veo problema en que existan nuevas herramientas.
Estas cosas con Windows no pasan.
Partiendo de la base de que Linux no se administra, el artículo es erróneo. GNU o GNULinux. Linux -> núcleo.
#5 No se si es una batalla perdida...
El lenguaje está vivo. Cuando se hizo famoso dejó de estar en manos de sus creadores.
A pesar de “estar mal escrito” , mucha gente sobreentiende a Linux como el SO entero y su entorno.
#6 Pontelo en tu epitafio macho .... "Se dice GNU Linux copón!!!"
#5 A parte de lo cansino de la típica pedantería que sueltas, que lleva siendo cansina desde hace 20 años, es que no tienes razón.
iproute2 es una herramienta para administrar el networking del kernel Linux, conectándose directamente al kernel via netlink y modificando las tablas internas del kernel. No es una herramienta GNU ni específica para distribuciones GNU/Linux, funciona en cualquier sitio donde haya un kernel linux con networking y soporte para netlink.
#7 zascaaa
#11 Es una herramienta para administrar la red. No es técnicamente parte del kernel. Hay que ver si forma parte del paquete del kernel y me temo que no. Ahora.... ni idea si es de GNU o no.
#7 Kame...hame... ha!!!!
#7
Es gracioso porque estás equivocado. Analiza el binario ip y verás que está diseñado para GNU/Linux:
ldd /bin/ip
linux-vdso.so.1 (0x00007fff18f2a000)
libelf.so.1 => /usr/lib/x86_64-linux-gnu/libelf.so.1 (0x00007f623acd2000)
https://sourceware.org/elfutils/
libmnl.so.0 => /lib/x86_64-linux-gnu/libmnl.so.0 (0x00007f623aacc000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f623a8c8000)
https://www.gnu.org/software/libc/
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f623a4d7000)
https://www.gnu.org/software/libc/
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f623a2ba000)
/lib64/ld-linux-x86-64.so.2 (0x00007f623b1bd000)
https://www.sourceware.org/binutils/
De hecho el núcleo Linux está diseñado para pertenecer a GNU puesto que se compila con GCC y se usan las macros y API de dicho compilador. Las páginas de manual que hay en www.kernel.org contienen la versión de GNU.
#49
Ah ... y netlink también está en FreeBSD.
https://www.freebsd.org/cgi/man.cgi?query=netlink&sektion=7&manpath=SuSE+Linux/i386+11.3
Por eso decía sólo lo de GNU y opcionalmente GNU/Linux si quieres ser más específico.
De hecho util-linux está diseñado para ser multiplataforma: https://mirrors.edge.kernel.org/pub/linux/utils/util-linux/v2.32/v2.32-ReleaseNotes (sirva de ejemplo el cambio en libblkid para FreeBSD).
#49 Qué tendrá que ver como esté linkado un determinado binario con su diseño.
#58
Otro que no lee.
Para poder enlazar un programa con una biblioteca ha de ser compatible con esta. Si puede enlazarse con GNU es que ha sido diseñado para GNU, además de otros sistemas operativos como se puede ver en la página util-linux.
Cosas de las API y ABI.
#59 La llamada a funciones en c en sistemas derivados de unix tiene más años que yo, no es nada que haya inventado linux o GNU.
Hablando de GNU, GNU aloja un libro gratuito en savanah llamado programming from the ground up que explica por encima el tema. O si quieres algo a más bajo nivel tienes esto:
https://software.intel.com/sites/default/files/article/402129/mpx-linux64-abi.pdf
Ni linux ni GNU han inventado nada en cuanto a ELF o linkado (o enlazado si te quedas más contento), en system v estaba todo inventado.
PD: Digo ELF por poner el formato usado en los binarios que mencionas pero que si quieres mirarte la parte de los binfmt_ del kernel viene a ser lo mismo.
#59 Si, eso es obvio, iproute2 puede funcionar con sistemas GNU (enlazar con glibc) o no y también tiene licencia GPL2 de GNU, pero eso no les convierte en software GNU.
Este es el directorio con todo el software GNU
https://www.gnu.org/software/
Allí no está ni iproute2 ni las net-tools, por lo tanto no son software GNU, por lo tanto y volviendo al tema, no es correcto corregir a la gente por llamarlo Linux a secas. Es más, en mi opinión no es correcto llamarlo GNU/Linux a no ser que solo uses software GNU con Linux.
Lo de imponer a todo el mundo llamar GNU/Linux viene de cuando no salía HURD adelante y ya tenían hecho el resto de aplicaciones, utilidades y librerías, solo les faltaban acabar el kernel y entonces Linus publicó el suyo con licencia GPL, las distribuciones y la gente los combinaba y a todo ello lo llamaban Linux. Como es lógico que la gente lo llamase solamente Linux causó la irritación de Stallman, ya que era un sistema basado en un kernel relativamente sencillo y mientras las herramientas GNU con mucho curro detrás y que son las que hacen realmente útil un sistema operativo, pasaban al olvido.
Pero a día de hoy que se usa mucho software que no es GNU, me parece más justo decir "sistemas basados en Linux" o "sistemas Linux" o ponga el nombre de su distribución aquí. Es decir, kernel Linux y el resto.
¿Porqué si mi distribución tiene Apache, OpenSSH y Firefox no tengo que decir entonces que uso OpenBSD/Apache/Mozilla/GNU con Linux?
#49
1- Que un proyecto esté compilado con gcc y que utilice glibc no lo convierte automáticamente en GNU. Por ejemplo, systemd solo funciona con glibc y no es GNU (aunque sea GPL) porque no forma parte de los proyectos alojados en GNU.
2- Que esté linkado contra librerías de glibc no quiere decir que solo pueda depender de estas, ip puede funcionar perfectamente con musl.
#5 Estás confundiendo la acepción secundaria "núcleo" por la acepción primaria "sistema que usa ese núcleo".
#29
Estamos hablando de un nombre propio, no tiene significado. No tiene definición.
#50 Entonces no te quejes del uso que se le de. Si no tiene significado ni definición, no puedes decir que esté bien o mal nada.