Portada
mis comunidades
otras secciones
#6:
Traducción de DEEPL
¿Sabes que Ken Thompson y Dennis Ritchie crearon Unix en un PDP-7 en 1969?
Bueno, alrededor de 1971 se actualizaron a un PDP-11 con un par de paquetes de discos RK05 (1,5
megabytes cada uno) para el almacenamiento.
Cuando el sistema operativo creció demasiado para caber en el primer paquete de discos RK05 (su
sistema de archivos raíz) dejaron que se filtrara en el segundo, que es donde vivían todos los
los directorios personales de los usuarios (por eso el montaje se llamaba /usr). Ellos
replicaron todos los directorios del sistema operativo debajo de este (/bin, /sbin, /lib, /tmp...) y
escribieron archivos en esos nuevos directorios porque su disco original estaba sin
espacio. Cuando consiguieron un tercer disco, lo montaron en /home y reubicaron todos
los directorios de usuario allí para que el SO pudiera consumir todo el espacio de ambos
discos y crecer a TRES MEGABYTES enteros (¡oh!).
Por supuesto, hicieron reglas sobre "cuando el sistema arranca por primera vez, tiene que subir
para poder montar el segundo disco en /usr, así que no pongas cosas como
el comando de montaje /usr/bin o tendremos un problema de huevo y gallina al arrancar el sistema".
el sistema". Bastante sencillo. Tambien bastante especifico para v6 unix de hace 35
años atrás.
La división /bin vs /usr/bin (y todas las demás) es un artefacto de esto, un
detalle de implementacion de los 70's que fue llevado a cabo por decadas por
burócratas que nunca se preguntan _por qué_ hacen las cosas. Dejó de tener
sentido antes de que se inventara Linux, por múltiples razones:
1) El inicio del sistema es el resultado de initrd e initramfs, que se ocupa de
con los problemas de "este archivo es necesario antes de ese archivo". Ya tenemos un sistema
sistema temporal que arranca el sistema principal.
2) las bibliotecas compartidas (introducidas por los chicos de Berkeley) impiden
actualizar independientemente las partes /lib y /usr/bin. Las dos particiones tienen que
coincidir_ o no funcionarán. Este no era el caso en 1974, entonces tenían
tenían un cierto nivel de independencia porque todo estaba enlazado estáticamente.
3) Los discos duros baratos superaron la marca de los 100 megabytes alrededor de 1990, y
y el software de redimensionamiento de particiones apareció por entonces (partition magic
3.0 salió en 1997).
Por supuesto, una vez que existió la división, algunas personas crearon otras reglas para justificarla.
Root era para las cosas del sistema operativo que se obtenían de la corriente principal y /usr era para los archivos locales del sitio.
archivos locales. Entonces / era para las cosas que obtenías de AT&T y /usr era para las
que tu distro, como IBM AIX o Dec Ultrix o SGI Irix, le añadía, y
/usr/local era para los archivos de tu instalación específica. Entonces alguien decidió que
que /usr/local no era un buen lugar para instalar nuevos paquetes, ¡así que añadimos /opt!
Todavía estoy esperando que aparezca /opt/local...
Por supuesto, con 30 años de diferencia, esta división hizo que aparecieran y desaparecieran algunas reglas específicas de la distro.
reglas específicas de la distribución aparezcan y desaparezcan de nuevo, como "/tmp se limpia entre
reinicios pero /usr/tmp no". (Por supuesto, en Ubuntu /usr/tmp no existe y
en Gentoo /usr/tmp es un enlace simbólico a /var/tmp que ahora tiene la regla de "no se limpia
entre reinicios". Sí, todo esto es anterior a tmpfs. Tiene que ver con los sistemas de archivos
de lectura, /usr siempre va a ser de sólo lectura en ese caso y
/var es donde se encuentra el espacio de escritura, / es _en su mayoría_ de sólo lectura a excepción de partes de
de /etc que intentaron mover a /var pero realmente el symlinking de /etc a
/var/etc sucede más a menudo que no...)
Las burocracias de los estándares, como la Fundación Linux (que consumió al Free
en su creciente disco de acumulación hace años) documentan y añaden felizmente este tipo de complejidad.
documentan y añaden este tipo de complejidad sin tratar de entender
por qué estaba allí en primer lugar. 'Ken y Dennis filtraron su SO en el
equivalente a casa porque un paquete de discos RK05 en el PDP-11 era demasiado pequeño" pasa
por encima de sus cabezas.
Estoy bastante seguro de que la instalación de busybox sólo pone los binarios donde otras versiones
de esos binarios han ido históricamente. No hay ninguna razón real para nada de
de esto. Personalmente, yo enlazo simbólicamente /bin /sbin y /lib a sus equivalentes de /usr
en los sistemas que armo. Los chicos embebidos tratan de entender y
simplificar...
¿Sabes que Ken Thompson y Dennis Ritchie crearon Unix en un PDP-7 en 1969?
Bueno, alrededor de 1971 se actualizaron a un PDP-11 con un par de paquetes de discos RK05 (1,5
megabytes cada uno) para el almacenamiento.
Cuando el sistema operativo creció demasiado para caber en el primer paquete de discos RK05 (su
sistema de archivos raíz) dejaron que se filtrara en el segundo, que es donde vivían todos los
los directorios personales de los usuarios (por eso el montaje se llamaba /usr). Ellos
replicaron todos los directorios del sistema operativo debajo de este (/bin, /sbin, /lib, /tmp...) y
escribieron archivos en esos nuevos directorios porque su disco original estaba sin
espacio. Cuando consiguieron un tercer disco, lo montaron en /home y reubicaron todos
los directorios de usuario allí para que el SO pudiera consumir todo el espacio de ambos
discos y crecer a TRES MEGABYTES enteros (¡oh!).
Por supuesto, hicieron reglas sobre "cuando el sistema arranca por primera vez, tiene que subir
para poder montar el segundo disco en /usr, así que no pongas cosas como
el comando de montaje /usr/bin o tendremos un problema de huevo y gallina al arrancar el sistema".
el sistema". Bastante sencillo. Tambien bastante especifico para v6 unix de hace 35
años atrás.
La división /bin vs /usr/bin (y todas las demás) es un artefacto de esto, un
detalle de implementacion de los 70's que fue llevado a cabo por decadas por
burócratas que nunca se preguntan _por qué_ hacen las cosas. Dejó de tener
sentido antes de que se inventara Linux, por múltiples razones:
1) El inicio del sistema es el resultado de initrd e initramfs, que se ocupa de
con los problemas de "este archivo es necesario antes de ese archivo". Ya tenemos un sistema
sistema temporal que arranca el sistema principal.
2) las bibliotecas compartidas (introducidas por los chicos de Berkeley) impiden
actualizar independientemente las partes /lib y /usr/bin. Las dos particiones tienen que
coincidir_ o no funcionarán. Este no era el caso en 1974, entonces tenían
tenían un cierto nivel de independencia porque todo estaba enlazado estáticamente.
3) Los discos duros baratos superaron la marca de los 100 megabytes alrededor de 1990, y
y el software de redimensionamiento de particiones apareció por entonces (partition magic
3.0 salió en 1997).
Por supuesto, una vez que existió la división, algunas personas crearon otras reglas para justificarla.
Root era para las cosas del sistema operativo que se obtenían de la corriente principal y /usr era para los archivos locales del sitio.
archivos locales. Entonces / era para las cosas que obtenías de AT&T y /usr era para las
que tu distro, como IBM AIX o Dec Ultrix o SGI Irix, le añadía, y
/usr/local era para los archivos de tu instalación específica. Entonces alguien decidió que
que /usr/local no era un buen lugar para instalar nuevos paquetes, ¡así que añadimos /opt!
Todavía estoy esperando que aparezca /opt/local...
Por supuesto, con 30 años de diferencia, esta división hizo que aparecieran y desaparecieran algunas reglas específicas de la distro.
reglas específicas de la distribución aparezcan y desaparezcan de nuevo, como "/tmp se limpia entre
reinicios pero /usr/tmp no". (Por supuesto, en Ubuntu /usr/tmp no existe y
en Gentoo /usr/tmp es un enlace simbólico a /var/tmp que ahora tiene la regla de "no se limpia
entre reinicios". Sí, todo esto es anterior a tmpfs. Tiene que ver con los sistemas de archivos
de lectura, /usr siempre va a ser de sólo lectura en ese caso y
/var es donde se encuentra el espacio de escritura, / es _en su mayoría_ de sólo lectura a excepción de partes de
de /etc que intentaron mover a /var pero realmente el symlinking de /etc a
/var/etc sucede más a menudo que no...)
Las burocracias de los estándares, como la Fundación Linux (que consumió al Free
en su creciente disco de acumulación hace años) documentan y añaden felizmente este tipo de complejidad.
documentan y añaden este tipo de complejidad sin tratar de entender
por qué estaba allí en primer lugar. 'Ken y Dennis filtraron su SO en el
equivalente a casa porque un paquete de discos RK05 en el PDP-11 era demasiado pequeño" pasa
por encima de sus cabezas.
Estoy bastante seguro de que la instalación de busybox sólo pone los binarios donde otras versiones
de esos binarios han ido históricamente. No hay ninguna razón real para nada de
de esto. Personalmente, yo enlazo simbólicamente /bin /sbin y /lib a sus equivalentes de /usr
en los sistemas que armo. Los chicos embebidos tratan de entender y
simplificar...
#2:
Porque el Linux se regodean poniendo los nombres más oscuros que encuentran y luego te acusan de que eres tú que no le pones esfuerzo.
Comentarios
Porque el Linux se regodean poniendo los nombres más oscuros que encuentran y luego te acusan de que eres tú que no le pones esfuerzo.
#2 La culpa de que Linux vaya como el culo es siempre del usuario.
No hagas ruido. Ya verás como pican
#3 es tan horrible tener un ordenador de hace 20 años con Linux que funciona como el primer día y uno con Windows de hace 5 que necesita respiración asistida para arrancar
Piqué
#4 será con un linux de hace 20 años
#18 no te digo yo que no
#4 contestándote desde mi pc que me compre en 2013, te digo , NO.
#3 No, la culpa es de los padres, que lo visten como p...
#2 Con lo fácil que es Windows que tiene todo fácil de encontrar Fijate, la configuración de todo el software instalado en un único registro masivo...
#7 ¿La única excusa es que Windows también lo hace mal? ¿No queréis que Linux sea superior?
#11 No es ninguna "excusa". Es una comparación.
Traducción de DEEPL
¿Sabes que Ken Thompson y Dennis Ritchie crearon Unix en un PDP-7 en 1969?
Bueno, alrededor de 1971 se actualizaron a un PDP-11 con un par de paquetes de discos RK05 (1,5
megabytes cada uno) para el almacenamiento.
Cuando el sistema operativo creció demasiado para caber en el primer paquete de discos RK05 (su
sistema de archivos raíz) dejaron que se filtrara en el segundo, que es donde vivían todos los
los directorios personales de los usuarios (por eso el montaje se llamaba /usr). Ellos
replicaron todos los directorios del sistema operativo debajo de este (/bin, /sbin, /lib, /tmp...) y
escribieron archivos en esos nuevos directorios porque su disco original estaba sin
espacio. Cuando consiguieron un tercer disco, lo montaron en /home y reubicaron todos
los directorios de usuario allí para que el SO pudiera consumir todo el espacio de ambos
discos y crecer a TRES MEGABYTES enteros (¡oh!).
Por supuesto, hicieron reglas sobre "cuando el sistema arranca por primera vez, tiene que subir
para poder montar el segundo disco en /usr, así que no pongas cosas como
el comando de montaje /usr/bin o tendremos un problema de huevo y gallina al arrancar el sistema".
el sistema". Bastante sencillo. Tambien bastante especifico para v6 unix de hace 35
años atrás.
La división /bin vs /usr/bin (y todas las demás) es un artefacto de esto, un
detalle de implementacion de los 70's que fue llevado a cabo por decadas por
burócratas que nunca se preguntan _por qué_ hacen las cosas. Dejó de tener
sentido antes de que se inventara Linux, por múltiples razones:
1) El inicio del sistema es el resultado de initrd e initramfs, que se ocupa de
con los problemas de "este archivo es necesario antes de ese archivo". Ya tenemos un sistema
sistema temporal que arranca el sistema principal.
2) las bibliotecas compartidas (introducidas por los chicos de Berkeley) impiden
actualizar independientemente las partes /lib y /usr/bin. Las dos particiones tienen que
coincidir_ o no funcionarán. Este no era el caso en 1974, entonces tenían
tenían un cierto nivel de independencia porque todo estaba enlazado estáticamente.
3) Los discos duros baratos superaron la marca de los 100 megabytes alrededor de 1990, y
y el software de redimensionamiento de particiones apareció por entonces (partition magic
3.0 salió en 1997).
Por supuesto, una vez que existió la división, algunas personas crearon otras reglas para justificarla.
Root era para las cosas del sistema operativo que se obtenían de la corriente principal y /usr era para los archivos locales del sitio.
archivos locales. Entonces / era para las cosas que obtenías de AT&T y /usr era para las
que tu distro, como IBM AIX o Dec Ultrix o SGI Irix, le añadía, y
/usr/local era para los archivos de tu instalación específica. Entonces alguien decidió que
que /usr/local no era un buen lugar para instalar nuevos paquetes, ¡así que añadimos /opt!
Todavía estoy esperando que aparezca /opt/local...
Por supuesto, con 30 años de diferencia, esta división hizo que aparecieran y desaparecieran algunas reglas específicas de la distro.
reglas específicas de la distribución aparezcan y desaparezcan de nuevo, como "/tmp se limpia entre
reinicios pero /usr/tmp no". (Por supuesto, en Ubuntu /usr/tmp no existe y
en Gentoo /usr/tmp es un enlace simbólico a /var/tmp que ahora tiene la regla de "no se limpia
entre reinicios". Sí, todo esto es anterior a tmpfs. Tiene que ver con los sistemas de archivos
de lectura, /usr siempre va a ser de sólo lectura en ese caso y
/var es donde se encuentra el espacio de escritura, / es _en su mayoría_ de sólo lectura a excepción de partes de
de /etc que intentaron mover a /var pero realmente el symlinking de /etc a
/var/etc sucede más a menudo que no...)
Las burocracias de los estándares, como la Fundación Linux (que consumió al Free
en su creciente disco de acumulación hace años) documentan y añaden felizmente este tipo de complejidad.
documentan y añaden este tipo de complejidad sin tratar de entender
por qué estaba allí en primer lugar. 'Ken y Dennis filtraron su SO en el
equivalente a casa porque un paquete de discos RK05 en el PDP-11 era demasiado pequeño" pasa
por encima de sus cabezas.
Estoy bastante seguro de que la instalación de busybox sólo pone los binarios donde otras versiones
de esos binarios han ido históricamente. No hay ninguna razón real para nada de
de esto. Personalmente, yo enlazo simbólicamente /bin /sbin y /lib a sus equivalentes de /usr
en los sistemas que armo. Los chicos embebidos tratan de entender y
simplificar...
#6 Yo pongo un busybox en android o sshd en cualquier birria y ya me pienso que estoy liando con el router...
Malditas pestañas!
#6 3 MEGABYTES ENTEROS.
Les das recursos y los despilfarran.
#0 Pon que está en inglés.
Cuanto menos maquetas el HTML más Linuxero eres
#9 sigo sin entender que se usen los mailing list como sitio para encontrar info.
#15 Pues la verdad que ese aspecto feo y quizás poco práctico hace una gran labor desanimando a la gente "normal". Así sólo escriben los que han hecho el esfuerzo de meterse un poco en el tema y saben de lo que hablan.
Democratizar internet, la web 2.0, las redes sociales... sonó muy bonito en su momento, pero hacer tan fácil que cualquiera pueda publicar en internet lo que ha provocado es que efectiva y literalmente cualquiera pueda escribir cualquier estupidez para regodeo de la piara. Internet tenía menos ruido cuando sólo lo utilizaban por así decirlo "usuarios avanzados".
Seguramente los mailing list no se mantengan por esta razón, pero creo que el efecto "filtro de cualquieras" es un efecto colateral que ha ayudado a que sobrevivan.
#23 suena mal lo que has dicho pero tienes toda la razón. Muchos pensamos que a día de hoy internet o más bien la web 2.0 está rota y estamos usando cosas como Gémini o Gopher que es como volver a los 90. Además tanto las listas de correo como el IRC se están volviendo a usar mucho por lo que tú dices. Como ejemplo tenemos los comentarios a este artículo donde el 90% son comentarios chorras o de gente que no tienen ni idea y no aportan nada. Por cierto, hay un libro medio en serio medio de coña que critica todas esas cosas de UNIX y de los sistemas operativos que siguen su linde
#24 Qué tiempos suspiro
¿nos puedes dar el nombre del libro?
#25 perdona el retraso https://web.mit.edu/~simsong/www/ugh.pdf
#23 Igual se puede conseguir ese filtro de otras formas, pero no voy a entrar en eso. Eso me recuerda a cuando se vendió la partida de ajedrez entre la humanidad contra una IA (era deep blue?). Era una partida en la que la gente votaba que partida se jugaba, y eso es un auténtico despropósito, el voto de un maestro del ajedrez vale lo mismo que el de cualquier persona, y es imposible que esa inteligencia sume, solo resta como conjunto.
#23 este comentario representa elitismo mas triste que he visto nunca
#10 Estaría bien, que ya se ha intentado, un sistema de archivos basado en etiquetas.
Recientemente en Linux Mint me saltó una actualización para mezclar directorios, por lo que leí en el 2012 algunas distribuciones pasaron /bin, /sbin, /lib y /lib64 al directorio /usr, dejando los directorios raíz como enlaces simbólicos.
Unification (en)
Y por supuesto no falta la típica respuesta "no tienes ni puta idea, inútil" con su toque pasivo-agresivo:
Tal vez deberías simplificar realmente y eliminar los directorios por completo. ¿Quién los necesita? Sólo añaden follón. Simplemente vuelca todo en / y haz que todos esos molestos directorios históricos sean sólo enlaces simbólicos a / o entre sí. Entonces tendrás todo a mano en un solo lugar. Y, como ventaja añadida, puedes incluso ahorrar algo de espacio eliminando el comando cd.
#8 me parecía una troleada hasta que me paré a pensarlo y hasta tiene lógica, lo que está claro es que el tinglado actual no tiene sentido alguno
#10 El hombre tiene parte de razón. La historia es muy interesante y curiosa y no dudo que sea cierta.
Peeero... su protesta pierda fuerza al no contar toda la verdad...
Y es que para mucha gente y en varias situaciones sí tiene todo el sentido del mundo tener la separación triple. Sí, triple, porque además de las estructuras en / y /usr también está /usr/local.
El caso más típico es una red de ordenadores Linux donde:
- / está montado en local y tiene lo mínimo para levantar el sistema y los comandos más utilizados.
- /usr es un punto de montaje NFS (o sea, una unidad de red) con las aplicaciones más pesadas o menos utilizadas.
- /usr/local está montado en local y ahí los usuarios pueden compilar e instalar sus programas (de hecho, suele ser el destino por defecto de las Autotools de Linux, el famoso ./configure).
Está bien seguir el hilo para ver las respuestas, así como el ataque pasivo-agresivo que comenta #8.
#17 Es el destino por defecto y no solo para las autotools, sino que todo el sistema gira en torno a que por defecto los programas que no vengan en paquetes de distro se instalen ahí. Por ejemplo en el $PATH /usr/local/bin siempre va por delante de /usr/bin y en el ld.so.conf /usr/local/lib tiene preferencia antes que /usr/lib.
#17 Desde que existe el initramfs no hace falta tener nada en /. Los binarios se dividían entre /bin y /usr/bin al azar.
De hecho, había otro acrónimo: USR = Upper Second Root.
Pero realmente era una leyenda urbana.
Ya podrían tenerlo todo bien ordenadito y sin tanto follón como en FreeBSD donde sabes dónde va cada cosa sin tener que pensarlo nada.
Es curioso que al final explica como se llega a esa situación pero no cómo se usan actualmente.