¿Qué deben saber los desarrolladores sobre los sistemas basados ​​en UNIX?

8

Estoy un poco sorprendido de que esto aún no haya sido preguntado por nadie, pero a un alto nivel, ¿qué debe saber todo desarrollador acerca de trabajar con sistemas basados ​​en UNIX?

Mi experiencia con * nix es muy limitada, porque no tengo absolutamente ninguna razón para usarlo en Windows para mis propios fines, pero tengo dos entrevistas por venir donde las compañías idealmente quieren a alguien con experiencia en * nix. No tengo ningún problema para conocerlo si hacen una oferta que quiero hacer, pero no vale la pena la inversión cuando la mayoría de mis ofertas se refieren a sistemas Windows; Esperemos que esto sea comprensible.

¿Qué herramientas debo saber? ¿Alguna peculiaridad que debería tener en cuenta? ¿Existe algún recurso bueno y conciso que se pueda leer rápidamente para obtener una comprensión amplia?

rwar
fuente
¿Qué tipo de desarrollo estás haciendo? Para la programación de alto nivel, conocer los comandos básicos en el terminal sería una gran ventaja, junto con quizás conocer uno de los principales editores de texto (vi, emacs). Para la programación de nivel inferior, necesita saber más sobre las llamadas al sistema, los archivos de encabezado específicos del sistema y cómo se manejan los subprocesos a nivel del sistema. Por ejemplo, C ++ multiplataforma tiene muchos matices: ahora tengo un sistema que se compila en todos los principales sistemas operativos, excepto Solaris.
Thomas Owens
Oh, lo siento. Estoy interesado principalmente en la programación de nivel inferior, pero conocer los comandos también es útil.
rwar
También puede leer esto: programmers.stackexchange.com/questions/89249/…
WarrenFaith
1
Unix, especialmente Linux / FreeBSD / etc., son más baratos que Windows para ejecutar servicios. Por lo tanto, si puede entregar tanto en Unix como en Windows, su empresa es más competitiva.
Incluso las chicas jóvenes lo saben youtube.com/watch?v=dFUlAQZB9Ng
MattyD

Respuestas:

8

Además de lo básico, como cómo usar la línea de comando, etc., creo que lo fundamental es entender cómo está estructurado el sistema.

Creo que la mayor diferencia cuando uno viene de Windows a Unix es entender cómo encaja el sistema. Windows encaja por medio de su API y los componentes subyacentes del sistema operativo como COM. Aunque esto a menudo se abstrae del programador, uno que codifique durante mucho tiempo sabrá sobre el modelo de subprocesamiento COM, GDI, etc. Unix encaja de una manera completamente diferente. Unix se basa en la idea de construir componentes pequeños y construir sistemas más grandes a partir de ellos utilizando IPC (a menudo a través de tuberías simples).

Solicitas un recurso conciso y, al menos para mí, el único punto de partida para entender cómo funciona Unix como entorno de programación es el libro de Kernighan y Pike Unix Programming Environment . Si bien el libro en sí se siente un poco anticuado, es el ejemplo perfecto de cuál es la filosofía de Unix y cómo se puede aprovechar la "forma de Unix" al codificar.

Si al menos hojea sus páginas, entenderá cómo usar Unix para ayudarlo a crear mejores programas. Incluso si te identificas como un chico de Windows, el conocimiento que obtendrás de él es más o menos universal, como lo son los patrones de diseño o las prácticas de ingeniería de software.

Si quiere saber más, tal vez por su trabajo o simplemente porque le gustó, después de leer el entorno de programación Unix, pruebe la programación avanzada en el entorno UNIX (R) de Stevens. Complementa bien el libro de Kernighan y Pike y, después de ambos, habrás cubierto la mayor parte de lo que espero que sepa un programador de Unix. También hay un libro de Stevens sobre programación en red, también se recomienda.

Además de Linux, vale la pena probar dos sistemas operativos: uno es Plan9 , que de alguna manera es un Unix mejor que Unix, y el otro es OpenBSD . OpenBSD está construido por un pequeño equipo, por lo que es muy consistente y está muy bien documentado, por lo que es divertido hurgar en él.

Vitor Py
fuente
5

Si una organización utiliza sistemas operativos tipo Unix, todos los desarrolladores deben conocer los comandos básicos del terminal para navegar por la estructura de archivos, crear nuevos archivos y directorios, eliminar archivos, herramientas de construcción de línea de comandos, usar el control de versiones en la línea de comandos y quizás scripts de shell básicos para ayudar a automatizar tareas repetitivas. En mi opinión, el poder de la terminal y la disponibilidad de herramientas de línea de comandos en sistemas similares a Unix es una gran ventaja, junto con lo fácil que es escribir scripts para automatizar una serie de tareas complejas que podrías estar realizando de forma regular base.

Hay una serie de aplicaciones de línea de comandos con las que quizás desee familiarizarse. Herramientas tales como cat, grep, head, tail, more, y lessson útiles para una serie de tareas, que van desde la búsqueda a través de archivos para encontrar coincidencias de texto, a través de la lectura de archivos de registro para ayudar en la depuración de aplicaciones. La capacidad de utilizar tuberías y resultados de alimentación a través de estas aplicaciones también es útil para ayudarlo a analizar la información disponible.

También sería útil el conocimiento de uno de los principales editores de texto (vi o emacs). Cuál usa usted es una opinión personal, pero recomendaría usar lo que usa su equipo (de esa manera, si tiene preguntas, habrá alguien en su equipo para responderlas). En mi experiencia, muchos desarrolladores de Unix "hardcore" prefieren estas herramientas a los IDE. Yo prefiero un IDE (incluso en un entorno similar a Unix), pero los editores de texto tienen sus ventajas al leer archivos. Su naturaleza de línea de comandos facilita la búsqueda a través de archivos con las herramientas que mencioné en el último párrafo y luego abre todos los archivos coincidentes dentro de uno de estos editores.

Más allá del uso de las herramientas proporcionadas con el sistema operativo, también querrá conocer las diferencias en las bibliotecas. Las bibliotecas que realizan llamadas al sistema (las cosas que implican subprocesos vienen a la mente, como un ejemplo específico) probablemente serán diferentes entre los sistemas operativos. Los archivos MAKE que tienen marcas para compilar en una arquitectura específica o para un sistema operativo específico también pueden presentar problemas. Saber qué sistemas operativos se usan facilitaría esto: puede encontrar referencias que aborden cómo implementar ciertas funciones dentro de ese sistema operativo. Sin embargo, esto es algo que esperaría que pueda recoger en el trabajo (especialmente para los sistemas operativos que generalmente se usan en entornos empresariales y a los que las personas a menudo no tienen acceso, como Solaris).

Thomas Owens
fuente
3

El libro que utilicé en mi clase de UNIX fue "UNIX para programadores y usuarios" de Glass and Ables . Una buena introducción sólida a los comandos del sistema, las herramientas de archivo y programación, la descripción general del sistema y las redes y los diversos shells. Bastante corto también si es algo caro nuevo. Viene en un sabor de Linux también.

Para mayor profundidad: "La interfaz de programación de Linux" . No es una introducción liviana, pero si alguna vez necesitara un manual de referencia para finalizar todos los manuales de referencia en la programación a nivel del sistema en los sistemas de la familia * nix, elegiría esto.

Ingeniero mundial
fuente
Estoy a la mitad de "La interfaz de programación de Linux" en este momento. Es una lectura muy profunda, y la información que contiene es extremadamente beneficiosa. Incluso habla de cosas que son portátiles y qué tan portátiles son, lo que también es muy útil.
Michael Trausch
-1

En primer lugar, recomendaría instalar ubuntu , que es un buen punto de partida, en una partición de su computadora. Intenta jugar un poco con él. Por ejemplo, ver un video con códecs extraños ... ¡Entonces probablemente necesites usar la terminal para ejecutar algunos apt-get installcomandos y golpear! estás aprendiendo a usar un sistema tipo Unix. Eso es. Comience a codificar y sentirá la necesidad de aprender mientras codifica.

Una lista rápida que viene a la mente:

  1. apt-get - cómo instalar paquetes
  2. top - procesos en ejecución
  3. ps: procesos de lista, acceso directo: ps -fea | grep "nombre_proceso"
  4. kill -9 PID - mata un proceso
  5. cmd sudo: ejecuta el comando con permisos de root
  6. Archivo vi: abre el editor rápido, google for vi y aprende a usarlo
  7. gedit: aprenda cómo usarlo y expandirlo con complementos (es muy posible que funcione como un IDE con todas las funciones)
  8. tail -fn500 file: sigue un archivo e imprime las últimas 500 líneas, muy útil para verificar registros
  9. hombre cmd - hombre !!! debería haber sido el primero en la lista ... Básicamente obtendrá toda la ayuda que necesita con respecto a un comando llamado cmd
  10. aprender scripts .sh bash. Búscalo en Google y agrégalo a tu kit de herramientas para programadores. Un día lo vas a usar.
  11. carpeta de cd - navegación
  12. ls: lista de archivos en un directorio
  13. ll - acortar a ls -l, listar archivos con detalles

Si está dispuesto a saber realmente cómo funciona un SO y cómo funcionan los sistemas tipo Unix, comience por echar un vistazo a minix y leer el libro de SO de Tanenbaum .

wleao
fuente
2
De ellos, apt-getprobablemente sea inútil y geditdebería ser familiar para cualquiera que haya usado un editor de texto anteriormente. Cada distribución de Linux (y sistema operativo basado en Unix) tiene una herramienta de instalación / actualización diferente, y no esperaría que un desarrollador tenga que mantener el entorno como lo haría TI. Además, olvidó mencionar emacscomo alternativa a vi: el que use depende mucho de las preferencias personales (y, en mi opinión, las preferencias del equipo).
Thomas Owens
1
¡si! emacs! Debes aprender a usarlo. Bueno, estoy hablando de ubuntu (por lo tanto, apt-get) aquí ... Y sí, debes aprender a administrar tus paquetes ... De lo contrario, te quedarías atascado algún día tratando de arreglar alguna dependencia y es posible que necesites purgealgo ... . Nunca sabes.
wleao
Desearía tener un personal de TI para mantener mi entorno de desarrollo listo para funcionar todo el tiempo = /
wleao
Como dije, en cualquier empresa de tamaño decente, ningún ingeniero de software debería instalar software. Si es necesario instalar algo en el sistema, TI debe manejarlo.
Thomas Owens
1
@Thomas, para los sistemas de desarrollo que involucran TI generalmente es solo una pérdida de tiempo. El sistema de producción es otra cosa.