| /linux/Documentation/translations/sp_SP/process/ |
| H A D | management-style.rst | 12 Este es un documento breve que describe el estilo de gestión preferido (o
20 que reglas simples de estilo de codificación, por lo que este documento
22 eso no significa que no pueda ser realmente cierto. Tendrás que decidir
26 personas lideres técnicas, no de las personas que hacen la gestión
28 alguna idea sobre el presupuesto de tu grupo, es casi seguro que no eres
35 haciendo dolorosamente obvio para el interrogador que no tenemos ni idea
45 Todos piensan que los gerentes toman decisiones, y que la toma de
50 El nombre del partido es **evitar** tener que tomar una decisión. En
52 que decidas sobre esto”, estas en problemas como gerente. Es mejor que
53 las personas a las que diriges conozcan los detalles mejor que tú, así
[all …]
|
| H A D | 6.Followthrough.rst | 11 Llegados a este punto, ha seguido las directrices dadas hasta ahora, lo que
13 de parches perfectos. Uno de los mayores errores que incluso los
14 desarrolladores de kernel experimentados pueden cometer es concluir que su
19 Es raro un parche que sea tan bueno en su primera publicación que no haya
22 publicado. Y usted, como autor de ese código, se espera que trabaje con la
23 comunidad del kernel para asegurarse de que su código esté a la altura de
25 probable que impida la inclusión de sus parches en la línea principal.
31 otros desarrolladores a medida que revisan el código. Trabajar con los
39 código en él cinco o diez años después? Muchos de los cambios que se le
40 pueden pedir que haga, desde ajustes de estilo de codificación hasta
[all …]
|
| H A D | handling-regressions.rst | 10 *No causamos regresiones* -- este documento describe la que es la "primera
11 regla del desarrollo del kernel de Linux" y que implica en la práctica para
13 Documentation/admin-guide/reporting-regressions.rst, que cubre el tema
20 #. Asegúrese de que los suscriptores a la lista `regression mailing list
24 * Cuando se reciba un correo que no incluyó a la lista, inclúyalo en la
31 #. Haga que el bot del kernel de Linux "regzbot" realice el seguimiento del
36 respuesta (con la lista de regresiones en CC) que contenga un párrafo
37 como el siguiente, lo que le indica a regzbot cuando empezó a suceder
69 Asegúrese de que el programa de gestión de regresiones del kernel de Linux
74 * Cuando se recibe un informe por email que no tiene en CC la lista,
[all …]
|
| H A D | 1.Intro.rst | 15 kernel y los tipos de frustraciones que los desarrolladores y sus
16 empleadores pueden encontrar allí. Hay muchas razones por las que el
27 herramientas y listas de correo. Se anima a los desarrolladores que deseen
38 las herramientas que pueden ayudar a garantizar que los parches del kernel
47 :ref:`sp_development_followthrough` cubre lo que sucede después de publicar
51 etapa. Se advierte a los desarrolladores que no asuman que el trabajo está
66 libre más grandes y activos que existen. Desde sus humildes comienzos en
68 del sistema operativo que se ejecuta en reproductores de música digital
69 de bolsillo, PC de escritorio, las supercomputadoras más grandes que
74 desarrolladores (y empresas) que desean participar en su desarrollo. Los
[all …]
|
| H A D | 5.Posting.rst | 11 Tarde o temprano, llega el momento en que su trabajo esté listo para ser
14 kernel ha desarrollado un conjunto de convenciones y procedimientos que se
25 Hay una tentación constante de evitar publicar parches antes de que
27 problema. Sin embargo, si el trabajo que se está realizando es complejo,
28 hay mucho que ganar al obtener comentarios de la comunidad antes de que
31 que los desarrolladores interesados puedan ponerse al día con su trabajo
34 Al publicar código que aún no se considera listo para su inclusión, es
36 cualquier trabajo importante que aún falte por hacer y cualquier problema
37 conocido. Menos personas mirarán los parches que se sabe que están a
38 medias, pero aquellos que lo hagan vendrán con la idea de que pueden
[all …]
|
| H A D | submitting-patches.rst | 11 Para una persona o empresa que desee enviar un cambio al kernel Linux,
14 que pueden aumentar considerablemente las posibilidades de que se acepte su
26 Esta documentación asume que está usando ``git`` para preparar sus parches.
27 Si no está familiarizado con ``git``, le recomendamos que aprenda a
40 que se puede descargar con::
44 Tenga en cuenta, sin embargo, que es posible que no desee desarrollar con
58 subyacente que le motivó a hacer ese trabajo. Convenza al revisor de que
59 hay un problema que merece la pena solucionar y de que tiene sentido que
62 Describa el impacto relativo al usuario. Cosas que estropeen el kernel y
65 código, describa el impacto que cree pueda tener en los usuarios. Tenga en
[all …]
|
| H A D | 4.Coding.rst | 11 Si bien hay mucho que decir a favor de un proceso de diseño sólido y
13 kernel está en el código resultante. Es el código lo que será examinado por
14 otros desarrolladores y lo que será incluido (o no) en el árbol principal.
15 Por lo tanto, es la calidad de este código lo que determinará el éxito
19 algunas de las maneras en que los desarrolladores del kernel pueden cometer
21 herramientas que pueden ayudar en dicha búsqueda.
34 código en el kernel que no cumple con las pautas de estilo de programación.
38 El primero de estos es creer que los estándares de programación del kernel
39 no importan y no se aplican. La realidad es que agregar nuevo código al
41 estándar; muchos desarrolladores solicitarán que el código sea reformateado
[all …]
|
| H A D | 2.Process.rst | 15 ha tenido que adaptar varios procesos para mantener el desarrollo sin
41 continuo que está integrando continuamente cambios importantes.
45 se dice que la "merge window" (ventana de fusión) está abierta. En ese
46 momento, el código que se considera lo suficientemente estable (y que es
53 (Aparte, vale la pena señalar que los cambios integrados durante la
59 tiempo, Linux Torvalds declarará que la ventana está cerrada y publicará
62 5.6-rc1. El lanzamiento -rc1 señala que el tiempo para fusionar nuevas
63 características ha pasado y que el tiempo para estabilizar el siguiente
66 Durante las próximas seis a diez semanas, solo los parches que solucionen
68 más significativo, pero tales ocasiones son raras; los desarrolladores que
[all …]
|
| H A D | howto.rst | 18 este archivo, que se encuentra en la parte superior del documento.
22 ¿De modo que quiere descubrir como convertirse en un/a desarrollador/a del
26 que debe pasar, y con indicaciones de como trabajar con la comunidad.
28 de la forma en que lo hace.
30 El kernel esta principalmente escrito en C, con algunas partes que son
33 cualquier arquitectura) no es necesario excepto que planee realizar
43 bien se adhiere al estándar ISO C89, utiliza una serie de extensiones que
45 sin depender de la biblioteca C estándar, por lo que algunas partes del
48 entender las suposiciones que el kernel hace respecto a la cadena de
49 herramientas y las extensiones que usa, y desafortunadamente no hay
[all …]
|
| H A D | 7.AdvancedTopics.rst | 12 proceso de desarrollo. Sin embargo, ¡todavía hay más que aprender! Esta
13 sección cubrirá varios temas que pueden ser útiles para los desarrolladores
14 que desean convertirse en una parte regular del proceso de desarrollo del
23 la gestión de versiones de software que incorporó ciertamente no lo fue.
30 desarrollador, especialmente a medida que crece el volumen de esos
32 es una herramienta joven y poderosa que aún está siendo civilizada por
36 proceso de desarrollo del kernel en particular. Los desarrolladores que
43 y en varios tutoriales que se encuentran en la web.
47 parches a disposición de otros. Un desarrollador que usa git debe ser
60 Cuando esté listo para comenzar a publicar árboles de git para que otros
[all …]
|
| H A D | maintainer-kvm-x86.rst | 14 normas/directrices que contiene. Todos cometemos errores y todos hemos sido
17 aprenda de los errores que cometa, será recibido con los brazos abiertos,
34 directamente al árbol principal de KVM, mientras que todo el desarrollo
36 improbable caso de que una corrección para el ciclo actual se dirija a
40 Tenga en cuenta que se espera que este periodo de transición dure bastante
41 tiempo, es decir, que será el statu quo en un futuro previsible.
50 en en camino, y tener que rechazar una solicitud de pull debido a errores
66 temática de KVM x86, normalmente la semana antes de que Linus abra la
80 margen de maniobra en función del tamaño de la serie, los parches que están
82 actual y/o árboles estables, consiguen saltar la cola. Los parches que se
[all …]
|
| H A D | 3.Early-stage.rst | 14 que conduce al éxito es mejor realizarlo antes de escribir la primera línea
25 problema real con la solución propuesta, lo que puede generar dificultades.
27 Consideremos un ejemplo: hace algunos años, los desarrolladores que
30 el sistema. La solución a la que llegaron fue un módulo del kernel
39 amplia del kernel, se veía como un uso indebido del marco LSM (que no está
40 diseñado para otorgar privilegios a procesos que de otro modo no los
47 particular que habían implementado; no estaban dispuestos a aceptar
66 que por un módulo específico. La moraleja de la historia es centrarse en el
73 - ¿Cuál es exactamente el problema que necesita ser resuelto?
90 - Es posible que el problema ya esté siendo abordado por el kernel de
[all …]
|
| H A D | coding-style.rst | 11 Este es un breve documento que describe el estilo preferido en el código
13 puntos de vista sobre nadie, pero esto vale para todo lo que tengo que
14 mantener, y preferiría que para la mayoría de otras cosas también. Por
27 tienen 8 caracteres. Hay movimientos heréticos que intentan hacer sangría
36 Bueno, algunas personas dirán que tener sangrías de 8 caracteres hace que
38 pantalla de terminal de 80 caracteres. La respuesta a eso es que si
70 No ponga varias declaraciones en una sola línea a menos que tenga algo que
108 El estilo de código tiene todo que ver con la legibilidad y la
114 que exceder las 80 columnas aumente significativamente la legibilidad y no
117 Los descendientes siempre son sustancialmente más cortos que el padre y
[all …]
|
| H A D | deprecated.rst | 16 estos cambios de una única vez. Esto significa que las nuevas instancias
17 han de ir creándose en el kernel, mientras que las antiguas se quitan,
18 haciendo que la cantidad de trabajo para limpiar las APIs crezca. Para
25 Mientras que este atributo señala visualmente que un interface ha sido
28 porque uno de los objetivos del kernel es que compile sin avisos, y
30 que usar `__deprecated` es sencillo para anotar una API obsoleta en
38 "imposibles" tan elegantemente como se pueda. Mientras que la familia de
50 Nótese que la familia de funciones WARN() únicamente debería ser usada
51 en situaciones que se "esperan no sean alcanzables". Si se quiere
54 *panic_on_warn* sysctl para asegurarse que sus sistemas no continúan
[all …]
|
| H A D | adding-syscalls.rst | 13 :ref:`Documentation/process/submitting-patches.rst <submittingpatches>` que
22 tradicionales, existen otras posibilidades -- elija la que mejor se adecúe
25 - Si se puede hacer que la operación se parezca a un objeto filesystem,
28 funcionalidad en un módulo del kernel en vez de requerir que sea
32 notifica al userspace que algo ha pasado, entonces retornar un nuevo
36 - Sin embargo, operaciones que no mapean a operaciones similares a
37 :manpage:`read(2)`/:manpage:`write(2)` tienen que ser implementadas
44 requiere que el filesystem relevante esté montado, lo que podría no ser
46 Evite agregar cualquier API a debugfs, ya que no se considera una
52 llamada al sistema multiplexada que esconde mucha complejidad, así que
[all …]
|
| H A D | email-clients.rst | 31 archivos adjuntos generalmente están mal vistos porque hacen que citar
35 También se recomienda encarecidamente que utilice texto sin formato en el
42 Los clientes de correo electrónico que se utilizan para los parches del
50 No deje que su cliente de correo electrónico ajuste automáticamente las
60 encabezados "References:" o "In-Reply-To:" para que el hilo de correo no
68 No utilice firmas PGP/GPG en el correo que contiene parches.
69 Esto rompe muchos scripts que leen y aplican los parches.
140 La única desventaja es que cualquier texto que escriba en el correo
141 electrónico no se ajustará a cada palabra, por lo que tendrá que ajustar
144 como borrador. Una vez que lo vuelva a sacar de sus borradores, estará
[all …]
|
| H A D | security-bugs.rst | 12 seguridad para que pueda ser corregido y divulgado lo más rápido posible.
21 oficiales de seguridad que ayudarán a verificar el informe del error y
23 favor, inclúyala con su informe, ya que eso puede acelerar considerablemente
24 el proceso. Es posible que el equipo de seguridad traiga ayuda adicional
31 si no tiene claro que información es útil. Cualquier código de explotación
33 que envia el error) a menos que ya se haya hecho público.
48 Coordinación debajo. Una vez que se ha desarrollado una solución robusta,
56 a 14 días de calendario si se acuerda que la criticalidad del error requiere
59 escala que requieren coordinación de lanzamiento.
71 que se haya levantado el embargo, en perpetuidad.
[all …]
|
| H A D | submit-checklist.rst | 11 Aquí hay algunas cosas básicas que los desarrolladores deben hacer si
12 quieren que sus envíos de parches del kernel sean aceptados más
15 Todo esto está más allá de la documentación que se proporciona en
19 1) Si utiliza una funcionalidad, #include el archivo que define/declara
20 esa funcionalidad. No dependa de otros archivos de encabezado que
21 extraigan los que utiliza.
42 por que tiende a usar ``unsigned long`` para cantidades de 64-bits.
48 Debería ser capaz de justificar todas las infracciones que permanezcan
52 configuración y se desactiva por defecto, a menos que cumpla con los
64 10) Use ``make checkstack`` y solucione cualquier problema que encuentre.
[all …]
|
| H A D | embargoed-hardware-issues.rst | 13 Los problemas de hardware que resultan en problemas de seguridad son una
14 categoría diferente de errores de seguridad que los errores de software
15 puro que solo afectan al kernel de Linux.
42 seguridad que lo ayudarán a coordinar un problema de acuerdo con nuestro
56 investigadores o individuos que hayan identificado una posible falla de
71 Las listas de correo encriptadas que se utilizan en nuestro proceso están
110 (expertos en dominio) que formarán el equipo de respuesta inicial para un
122 que ocurra una violación, el equipo de seguridad de hardware informará a
145 afectado, le animamos a considerar también que otro hardware podría estar
149 encriptada específica para el incidente que se utilizará para la discusión
[all …]
|
| H A D | 8.Conclusion.rst | 13 Documentación (Documentation) que se encuentra en la distribución del
51 Aun así, hay bastante buena información que se puede encontrar allí.
62 Felicitaciones a todos los que han logrado leer este extenso documento.
66 Al final, lo que importa es la participación. Cualquier proyecto de
67 software de código abierto no es más que la suma de lo que sus
71 kernel es un excelente ejemplo de lo que se puede lograr cuando miles de
76 que es igual de importante, la mayoría de los demás participantes en el
81 situación en la que todos los involucrados ganan. Encienda su editor y
82 únase a nosotros; será más que bienvenido.
|
| /linux/Documentation/translations/sp_SP/ |
| H A D | memory-barriers.txt | 37 sus maintainers en lugar de que como un oráculo infalible.
39 De nuevo, este documento no es una especificación de lo que Linux espera
44 (1) especificar la funcionalidad mínima en la que se puede confiar para
49 Tenga en cuenta que una arquitectura puede proporcionar más que el
53 Tenga en cuenta también que es posible que una barrera no valga (sea no-op)
54 para alguna arquitectura porque por la forma en que funcione dicha
110 (*) Cosas que hacen las CPU.
151 Cada CPU ejecuta un programa que genera operaciones de acceso a la memoria.
154 en el orden que desee, siempre que la causalidad del programa parezca
156 instrucciones que emite en el orden que quiera, siempre que no afecte al
[all …]
|
| H A D | index.rst | 18 aquellos que no entiendan inglés o duden de sus interpretaciones, o
19 simplemente para aquellos que prefieran leer en el idioma español. Sin
20 embargo, tenga en cuenta que la *única* documentación oficial es la que
26 es posible. Por tanto, no existe ninguna garantía de que una traducción
27 esté actualizada con las últimas modificaciones. Si lo que lee en una
28 traducción no se corresponde con lo que ve en el código fuente, informe
33 lo que los usuarios no encontrarán aquí ninguna información que no sea la
38 contribuciones que son puramente de interés relativo a la traducción (por
56 los maintainers pueden utilizar el español con el que dichos maintainers se
65 La traducción es incompleta, y podría encontrar advertencias que indiquen
[all …]
|
| /linux/Documentation/translations/sp_SP/scheduler/ |
| H A D | sched-bwc.rst | 16 El control de ancho de banda es una extensión CONFIG_FAIR_GROUP_SCHED que
40 Esta característica toma prestado tiempo ahora, que en un futuro tendrá que
48 Esto garantiza dos cosas: que cada tiempo límite de ejecución es cumplido
49 y que el sistema es estable. De todas formas, si U fuese > 1, entonces
50 por cada segundo de tiempo de reloj de una tarea, tendríamos que
56 La característica de ráfaga implica que el trabajo de una tarea no siempre
57 consuma totalmente la cuota; esto permite que se pueda describir u_i
66 probabilidades. De todas formas, si se mantiene la estabilidad, ya que
70 Es decir, supóngase que se tienen 2 tareas, ambas específicamente
72 que ambas tareas se ejecuten dentro de su cuota asignada y todo
[all …]
|
| H A D | sched-eevdf.rst | 20 de la CPU de forma equitativa entre todas las tareas que tengan la misma
22 ejecución virtual a cada tarea, creando un "retraso" que puede ser usado
25 positivo, es porque se le debe tiempo de ejecución, mientras que una
26 con "retraso" negativo implica que la tarea ha excedido su cuota de
30 ser ejecutada a continuación. Es importante darse cuenta que esto permite
31 que la tareas que sean sensibles a la latencia que tengan porciones de
36 en tareas que estén en un estado durmiente; pero en el momento en el que
42 a su retraso decaer a lo largo de VRT. Por tanto, las tareas que duerman
47 que sean sensibles a las latencias.
|
| H A D | sched-design-CFS.rst | 26 "una CPU multitarea ideal" es una CPU (inexistente :-)) que tiene un 100%
27 de potencia y que puede ejecutar cualquier tarea exactamente a la misma
32 En hardware real, se puede ejecutar una única tarea a la vez, así que
47 de CPU esperado" que una tarea debería tener.
56 p->se.vruntime más pequeño (i.e., la tarea que se ha ejecutado menos hasta el
74 artificio de "cambio de tareas" (algo que previamente era usado por el gestor
86 de esas tareas que están en la cola de ejecución.
89 tareas que pueden ser ejecutadas están ordenadas por su valor de
93 de forma continuada dando una oportunidad a cada tarea de ser la que
99 que el tiempo de uso de la CPU se ha completado, y se añade a
[all …]
|