La gran entrevista *BSD
Matt Dillon, no el famoso actor
sino el miembro del Core Team de FreeBSD,
también conocido por escribir el compilador Dice C para Amiga, está aquí con
nosotros hoy para una entrevista en profundidad de todo lo relativo a FreeBSD
5.0. Éste es el SO que toda la gente vanguardista está esperando y calificándolo
como el SO libre más avanzado (técnicamente hablando) de hoy en día.
Adicionalmente, también incluimos dos mini-entrevistas con Theo de Raadt, el fundador de SD, y Jun-ichiro "itojun" Hagino, del
Core Team de NetBSD.
Matt Dillon, miembro del equipo de
FreeBSD, VM y kernel
1. Qué mejoras nos traerá BSD 5.0?
Matt Dillon: Hay por lo menos una docena de proyectos funcionando en
paralelo y hemos eliminado y reemplazado una gran parte del código por todo el
kernel; tanto que recientemente decidimos dar un año más a la fecha de salida de
BSD 5.0 para dar la oportunidad a todos estos proyectos de salir de la rama de
desarrollo a la rama estable. Debido a esto una cantidad importante de las
características de -current esta siendo lentamente MFC-ada a -estable. Aunque no
KSEs o SMPng.
KSEs y SMPng son los más visibles proyectos (SMPng está siendo
encabezado por John Baldwin), pero también hemos hecho un gran trabajo y
esfuerzo en la pila de red (network stack), controladores de red (especialmente
los drivers GigE), devfs (el cual es el default ahora en -current), generación
numérica aleatoria de cripto-calidad, escalabilidad, y nuevos ports. Estamos
activamente portando a IA64, PowerPC y Sparc64, y aunque la Alpha no está
teniendo el mismo "empuje", el port de alpha también está siendo activamente
desarrollado para asegurar que nuestro código de 64bit sigue siendo
limpio.
Una gran cantidad del trabajo ya ha sido MFCeado a estable. Por
ejemplo, -stable puede empujar más de 900MBits (120MBytes/sec ´netstat -in 1) en
una conexión TCP en un DELL2550 con GigE usando frames de tamaño "normal" (mtu
1500). Eso es plena saturación.
Por otra parte, una gran cantidad del trabajo
en el sistema de ficheros ha sido ya completado. El soporte de snapshots del
sistema de ficheros (para UFS+SoftUpdates) está siendo procesado de buena manera
y puede demostrar ser una de las más importantes características de los nuevos
sistemas de ficheros en la 5.x una vez se estabilice. Hay también dos
características nativas en UFS que se han estabilizado y que de hecho han sido
MFCadas a -stable: dirpref y dirhash. Dirpref viene directamente de Grigoriy
Orlov deSD y vuelve a trabajar la manera en la que los directorios son
dispuestos en el disco, consiguiendo una enorme ganancia en la representación de
stat/abrir/crear/borrar directorios o ficheros. Algunas operaciones del sistema
de ficheros han mejorado en un 6000%, y algunas de las más comunes han mejorado
en un 400%. Dirhash es un mecanismo integrado en el kernel de hasheado de
directorios enteros que mejora las operaciones con y en directorios de una
manera radical.
Hay mucho más, algunas cosas, tales como dirhash o dirpref,
pueden ser fácilmente MFCeadas a -stable. Otras, como el soporte de snapshots de
softupdates, probablemente no puedan ser MFCeadas a -stable debido a mayores
dependencias en otros proyectos "solo-current".
2. Cuál es una de las características que más te gustaría añadir al kernel
BSD?
Matt Dillon: Me gustaría ver procesos nativos y una capacidad de
migración descriptora a nivel de dispositivo. Esto no es una idea nueva (pocas
ideas en el mundo de las computadoras puede ser nunca llamada "nueva"), pero sí
que es una idea cuya hora a llegado. Me gustaría ver una habilidad para migrar
procesos, así como su estado a nivel de dispositivo, y un par de re-rutados
externos. Por lo que un descriptor E/S representando una conexión TCP podría
migrar enteramente fuera de la máquina en cuestión, por ejemplo.
La migración
de procesos es una buena base para el soporte Q.O.S. y la cuestión del
mantenimiento de las plataformas de hoy en día. Como el hardware de los
ordenadores cada vez es más potente y cada vez corremos más y más servicios (y
más conexiones, y más usuarios...) en cualquier equipo, la habilidad de migrar
todo fuera de una máquina, para realizar tareas de mantenimiento por ejemplo,
sin que los usuarios se den cuenta de que la máquina a la que creen estar
accediendo no está concetada (está offline), se ha convertido en algo realmente
importante. La razón es simple: si usas una máquina moderna a pleno rendimiento
usando toda su capacidad, y si el sistema se cuelga, estas interrumpiendo
potencialmente a miles de usuarios, más que a unas "pocas" docenas. El concepto
de "maintenance-window" trae el mismo problema, incluso con equilibrado de
carga, mantenimiento de conexión o distribución de tecnologías. Actualmente,
este concepto se está convirtiendo rápidamente en algo inaceptable en todo el
mundo.
Brevemente, la migración de procesos permitiría a la comunidadsource empezar a proveer niveles Q.O.S que tan sólo mainframes pueden
proveer hoy en día. Y si no me has oído mencionar las llamadas "clustering
solutions" actualmente disponibles de diferentes vendedores, es porque realmente
ellos no pueden entregar esas cosas - no verdaderos Q.O.S. Esa es mi opinión, de
todos modos. Usar un clúster para esconder el hecho de que el sistema se cae
regularmente es una manera extremadamente peligrosa de conseguir un entorno
computacional.
Voy a hacer un poquito de trampa y voy a darte la segunda
característica que deseo: quiero la replicación del sistema de ficheros nativo.
No me preocupo lo más mínimo del almacenaje de discos basado en servidores
comunes (common server-based disk storage): uno no consigue fiabilidad o
escalabilidad de ese modo. Quiero ver sistemas de ficheros distribuidos
(replicados, no particionados) que sean transaccionalmente coherentes, para
acompañar la migración de procesos claro :-)
3. Soft-update parece estar un paso más lejos del Journaling, ésta es la
manera "moderna" de hacer Journaling, y FreeBSD tiene esta capacidad. Sin
embargo, tenéis planes para añadir algunas de las características encontradas en
los sistemas XFS o JFS?
Matt Dillon: Yo calificaría las soft-updates como un paso adelante en
journaling. Por lo menos no como meta-data journaling. Es simplemente otra
manera de hacer las cosas. Incluso si soft-updates puede teóricamente funcionar
mejor que el meta-data journaling, el quid de la cuestión es que el ancho de
banda del disco tiene al menos 25 veces el throughput de un localizar/escribir
aleatorio. Por lo tanto, meta-data journaling tiene un impacto de funcionamiento
ligeramente más pequeño si puedes des-sincronizar el "resto". Soft-updates
trabaja extremadamente bien para UFS pero el concepto de soft-updates puede
venirse abajo con otros sistemas de ficheros - perfectamente podría ser
imposible implementar operaciones del estilo soft-updates en sistemas de
ficheros que implementen directorios como Btrees o hashes, por ejemplo. Por otra
parte, soft-updates puede llevar a cabo operaciones meta-data además de mantener
la integridad del sistema de ficheros, y puede hacerlo de una manera que de
manera natural nos lleva al paralelismo. Los sistemas de ficheros "journaleados"
típicamente no pueden hacer eso. Por lo tanto, la inutilidad de la teoría
depende fuertemente en cuales sean tus metas. Para un trabajo de propósito
general ambas teorías trabajan igualmente bien.
La mayoría de las súper
características de sistemas de ficheros específicos son altamente especializadas
y no útiles realmente para la basta mayoría de instalaciones de sistemas. XFS
tiene características de zoneado de datos (data zoning) y, por lo menos bajo
IRIX, la habilidad para garantizar la latencia del flujo de datos y el ancho de
banda. Puedo contar el número de aplicaciones que actualmente necesitan esas
características. La mayor ventaja de XFS es, como con todos los sistemas de
ficheros "jornaleados", la recuperación instantánea en caso de caída. Siendo
todo lo demás igual esta es la mayor ventaja de un sistema de ficheros
"journaleado" para actividades informáticas típicas, pero incluso así, darle las
opciones adecuadas al comando "newfs" cuando se crea un sistema de ficheros UFS
puede disminuir el tiempo de "fsck" en un orden de magnitud en grandes sistemas
de ficheros. La gente que usa UFS no está realmente en tanta desventaja. No
puedes proveer ningún tipo de Q.O.S si dependes de la rapidez de la recuperación
del sistema en caso de caída. Q.O.S significa tener hardware redundante; y sobre
JFS, no puedo opinar, puesto que nunca lo he usado.
Todos los campos BSD
hacen de la estabilidad y del rendimiento su primera y segunda prioridad
respectivamente. El rendimiento y la rápida recuperación, en caso de caída, son
irrelevantes si el sistema de ficheros corrompe datos o causa la caída del
sistema! Esto es especialmente verdad ya que la capacidad de los discos duros es
cada vez mayor y los sistemas de ficheros son cada vez mayores. Nunca he
terminado de comprender muy bien porque la comunidad Linux se "revoluciona"
tanto por el enorme número de sistemas de ficheros que mantienen (o dan apoyo).
Como si proveyeran así un sistema más efectivo! No consigues fiabilidad,
rendimiento y estabilidad a largo plazo jugando con los sistemas de ficheros, lo
consigues eligiendo o centrándote en uno o dos sistemas de ficheros que tengan
esas características. Dependiendo de las súper características del sistema de
ficheros, el código puede ser o no portable, lo que no es una buena idea.
En
cualquier caso, la mayoría de los desarrolladores BSD son felices con UFS. Oh,
cuando digo UFS realmente quiero decir UFS+FFS o UFS+FFS+SOFTUPDATES. UFS no es
la "bestia" bajo la cual algunos la han estereotipado. La estructura y teoría
básica era buenísima y sigue siendo todavía buenísima a día de hoy. A través de
los años hemos fijado bugs (los pocos que hemos encontrado), añadido capacidad,
mejor captura, reorganizado la estructura, reblocking reintroducido (básicamente
defragmentación al vuelo), softupdates, soporte para snapshots, etc etc etc
4. Después de que la burbuja de la comunidadsource explotara, muchas
compañías volvieron a estimar el soporte que, hasta el momento, habían dado a la
comunidadsource, y dejaron de contribuir código a Linux, a BSD, o a ambos.
Cómo a afectado esto al desarrollo BSD?
Matt Dillon: Ha creado una pequeña interrupción para la gente envuelta
en lo que se refiere a su habilidad para contribuir pero yo no creo que las
compañías vayan a tener ninguna clase de efecto en el movimientosource, en
Linux, o en el desarrollo BSD. Los mayores contribuidores BSD no son
trabajadores de una compañía que han sido específicamente enviados para
interactuar con la comunidadsource. Son gente que tienen un interés y amor
verdadero por la comunidadsource, y que trabajan en una compañía ocupando
un puesto alto.
Aunque han habido sorpresas, no ha sido nada que no se
esperara y ha tenido muchísimo menos impacto en nosotros. Todo lo que puedo
decir es: no será nuestra culpa (culpa de la comunidadsource)! Muchas de
las compañías Linuxeras estaban "leeching off the Linux name", y aquellos que no
estaban haciendo lo mismo no fallaron porque estuvieran usando Linux, sino que
fallaron porque no tenían un modelo de negocio con la mínima posibilidad de
poder sacarle provecho.source trabaja muchísimo más en la sombra de lo que
el ojo público advierte, y es difícil vender soporte a "hackers" que
efectivamente están pasando un buen rato tratando de imaginarse el problema.
Linux y BSD son candidatos bastante pobres para una comercialización porque son
"demasiado" buenos...simplemente no requieren el nivel de soporte que un
WindowsNT o Oracle pueden necesitar.
source ha creado más cambios e
interrupciones en los intereses comerciales que al revés. Pienso que ha sido
para bien, aunque algunas entidades comerciales (tales como MS) no están muy
felices de estar forzadas a ser más honestas con sus clientes (hmmm... de hecho
pienso que aun no han aprendido, y mira al efecto. MS se ha quemado tantas veces
en su guerra sucia contra el movimientosource que incluso compañeros
comerciales que llevaban tiempo con MS han dejado de creer lo que dicen!)
5. Qué opinas de que Linux haya acaparado la gran mayoría de la atención
en estos dos últimos años? Y de que haya sido capaz de moverse un poquito más
rápido hacia el terreno de escritorio? Es el mercado del escritorio de interés
para toda la gente de FreeBSD?
Matt Dillon: Lo encuentro un ejercicio interesante en ingeniería
social, economía y sicología.
Yo creo que el claro ganador aquí es elsource en general. Gran cantidad de lo que la gente etiqueta como Linux, no
es realmente Linux. Essource que compila tan fácilmente en FreeBSD (sin la
emulación para Linux) como en Linux. Tomad a GNOME o KDE como ejemplo. Ahí no
hay emulación para Linux por ningún lado! Las áreas en las que FreeBSD tenía
problemas, han sido casi enteramente relegadas a distribuciones (sólo binarios)
comerciales. Ahora bien, Linux es, indudablemente, lo que hace que muchos
proyectos se desarrollen. No creo que pudiéramos tener GNOME o KDE sin Linux.
Como conductor de interés, Linux se ha ganado su puesto en lo alto de la
lista.
El escritorio... bueno, no estoy muy seguro de lo que estás
preguntando exactamente. Linux y FreeBSD, ambos, están en el mismo barco...la
única manera de popularizar los escritorios son las máquinas preinstaladas con
el SO (el SO que sea) y con un escritorio, de manera que cuando lo enciendas,
estés preparado para trabajar. La única manera para los vendedores de hacer esto
es preinstalando Linux (o FreeBSD, o lo que sea).
Realmente no existe una
diferencia entre FreeBSD y Linux en lo que a entornos de escritorio se refiere.
Oh, podríamos integrar el sonido algo mejor, y sería genial conseguir hacer
trabajar una implementaciónL nativa, pero cualquier otra cosa ya esta ahí,
porque ambas plataformas están usando el mismo GUI.
6. Por favor explícanos que son SMPng (SMP de próxima generación) y KSE
(entidades programadoras del kernel). Qué nuevas características tendrá
BSD-5-current.
Matt Dillon: SMPng es el mutex de FreeBSD, threading interrumpido, e
implementación de borrado gigante. Potencialmente, el prevaciado del kernel es
también parte de la ecuación pero el jurado está todavía lejos de eso. El
propósito es ser capaz de tener varios procesos mainline y/o interrumpir
simultáneamente en el modo kernel. Esto es lo más importante en el asunto de
escalabilidad en cualquier sistema SMP. El trabajo hecho aquí es difícilmente
comparable al que se está llevando a cabo en Linux. Linux está un año por
delante de nosotros, pero tanto BSDs como Linux tienen mucho trabajo que hacer
para coger a Solaris.
KSE es una manera totalmente nueva (pero insisto, una
vieja idea) de implementar userland threads. Las ideas aquí son dos: (1)
eliminar cualquier requerimiento que el código userland entienda cuyas syscalls
puedan bloquear y cuyas sycalls puedan no bloquear. (2) cumplir con la
programación (schedule, no programación de algún lenguaje) de los threads y
switching en userland, donde cualquier CPU dada puede cambiar entre threads más
o menos igual que una llamada de subrutina.
Con KSEs si un proceso de un
usuario hace una llamada al sistema que bloquea, el kernel separará el contexto
del kernel (el cual ahora está bloqueado) y volverá directamente al programador
en modo usuario usando un "upcall". El programador en modo usuario puede
inmediatamente cambiar a otro thread. El bloqueado contexto del kernel corre de
una manera completamente asincrónica de los procesos de usuarios hasta que
acaban y puede potencialmente correr con otro KSE separado por el mismo proceso.
Cuando un KSE completa el kernel notifica al programador de los usuarios
permitiéndole reprogramar el thread bloqueado, que precisamente está volviendo
de la llamada que bloqueó el sistema.
La diferencia esencial entre KSEs y
select/kqueue-based threads y los threads basados en rfork es que con KSEs
consigues todo el paralelismo de SMP y todo el poder de un userland-context
switch entre threads (léase: cambios muy rápidos) sin ningún problema con el
kernel. Un programa puede estar corriendo literalmente miles de threads sin una
carga significante del kernel. Sólo syscalls bloqueadas pueden consumir recursos
del kernel. Adicionalmente, podemos conseguir más recursos del kernel para miles
de threads limitando el "pool" de KSEs que asignamos a cualquier proceso dado o
usuario o lo que sea. Por lo que si 500 de esos 1000 threads que bloquean el
sistema en una llamada al sistema, conseguimos una CPU algo menos
eficiente.
Actualmente, FreeBSD puede usar ambos tipos de threading
(select/kqueue y rfork (estilo Linux)). KSEs nos llevan un paso mas allá.
7. Desde el punto de vista técnico, como calificarías el kernel 2.4 de
Linux con el de los BSDs?
Matt Dillon: No sé lo suficiente sobre los kernels de Linux recientes
por lo que no soy capaz de calificarlos. Lo que sí que hago es seguir el trabajo
en la Memoria Virtual que se está haciendo en Linux, y en particular el trabajo
de Rik van Riel. Pienso que linux está pasando por una especie de transición
dolorosa puesto que se está yendo de la metodología de desarrollo estilo
Darwinista a algo más pensativo. Admito querer discutir con quienes critican el
trabajo en la Memoria Virtual de Rik y quienes simplemente no entienden la
diferencia entre optimizar unos pocos nanosegundos una rutina que raramente es
invocada, y gastar unos pocos ciclos CPU extras en elegir las mejores páginas a
reciclar a fin de evitar E/S al disco que costarían decenas de millones de
ciclos de CPU posteriormente. Es una actitud que tenía cuando tenía quizás 16
años...que cada ciclo de CPU importa, y no importa en que se haya gastado.
Carajo!
8. Cómo es la relación entre los programadores de FreeBSD y los deSD? Compartís código, opciones... cateáis regularmente... ? O todos los
proyectos BSD son completamente independientes unos de otros?
Matt Dillon: Los grupos BSD son como los círculos sociales del
colegio. No, en serio! Ésa es la mejor analogía que se me ocurre! Muchos
desarrolladores se centran tan sólo en su pequeña cuadrilla, mientras que otros
andan por muchos círculos. Hay desarrolladores que mantienen el mismo código de
un driver para varias distribuciones BSD diferentes. Hay desarrolladores que
centran su trabajo en una sola distribución BSD pero están unidos con
desarrolladores de otras. Si el trabajo es lo suficientemente interesante, tal y
como el trabajo "dirpref", desarrolladores que trabajan en otras distribuciones
BSD diferentes cogerán el código, lo parchearán y se lo llevarán. Así es como
FreeBSD consiguió su código "dirpref". Kirk lo importo deSD a
FreeBSD-current y yo lo MFCeé a -estable después de que hubiera sido probado en
-current.
Esta metodología de desarrollo nos da lo mejor de ambos mundos. Los
desarrolladores son libres de centrarse en las distribuciones que les son más
familiares y si el trabajo es suficientemente interesante, consigue llamar la
atención de varios desarrolladores de otras distribuciones que no sólo portan el
código, sino que también lo revisan. El testeado ocurre en todas las
distribuciones simultáneamente y si alguno encuentra un bug, será fijado en
otras distribuciones en unos pocos días. Los bugs de seguridad son verificados
independientemente pero habitualmente el fix es común para todos los BSDs y no
habrá necesidad de trabajar doble. Hay un prestado continuo entre los diferentes
BSDs e incluso entre BSD y Linux, especialmente en cuanto a código de
drivers.
9. Cual es tu opinión sobre .NET y crees que es posible que .NET cambie el
"mapa" de los SOs tal y como los conocemos?
Matt Dillon: Creo que .NET es vapor. Es un término de marketing ideado
por Microsoft que como por arte de magia se transformará en lo que a Microsoft
se le ocurra. MS anuncia ideas grandiosas con buenas frases publicitarias todo
el rato, y como buen vapor que es, siempre hay una base de verdad (aunque sólo
sea un poco). Sin embrago la realidad es algo diferente...recuerda, eso son
quienes pusieron por las nubes a WindowsME y todo lo que conseguimos fue un
asistente de instalación discurso-sintetizado de Windows! Esos son quienes
bautizaron al NT como el "mata-unix" y contó a la gente que era igual de fiable
que Unix. .NOT es probablemente un término más descriptivo para .NET (metáfora
que viene de NOT, que es NO en ingles). Mi opinión es que .NET se convertirá en
un tipo de rent-a-service propietario-Microsoft, y que introducirá más seguridad
que IIS.
10. Algunos dicen que FreeBSD tiene el mejor VM de toda
la historia comparado con cualquier otro sistema operativo. Crees que hay un
margen para seguir mejorando y que aun hay características para añadir?
Matt Dillon: Creo que hemos hecho un progreso genial al estabilizar el
sistema de la Memoria Virtual y trabajando en el asunto del rendimiento
relativos a máquinas con releases FreeBSD de la serie -4.x. las máquinas han
probado ser unos potros de prueba geniales en un ancho rango de aplicaciones y
que son capaces de proveer estabilidad a largo plazo y el rendimiento que sus
usuarios requieren. En líneas generales, la tecnología detrás del sistema de la
Memoria Virtual es bastante impresionante y no necesita mucha más mejora.
Obviamente en la -5.x mejoraremos (multi-threading para SMPng), pero los
algoritmos ineternos parecen funcionar bien en plataformas MP y 64bits, por lo
que no esperamos realizar grandes cambios fundamentales. Pero, claro
está...siempre hay un margen para mejorar...por supuesto! En el core MV de las
primeras y próximas releases de la rama -5.x, hay una gran cantidad de trabajo
planeado para mejorar la E/S y los subsistemas del caché de búffer (buffer cache
subsystems). Mi meta personal es quitar por completo el caché de búffer o al
menos, transformarlo en nada más complejo que un subsistema de E/S por
etapas.
Itojun, miembro del NetBSD Core
Team
1. Cómo es la relación entre los programadores de NetBSD y los deSD/FreeBSD? Compartís código, opciones... cateáis regularmente... ? O todos
los proyectos BSD son completamente independientes unos de otros?
Itojn: Sí, chateamos entre nosotros y compartimos opiniones y código.
Algunos de los desarrolladores tienen acceso y pueden modificar el código fuente
para multiples BSDs por medio de CVSs.
2.Incorporáis código de FreeBSD uSD a vuestro NetBSD cuando hay
cambios importantes en esos SOs?
Itojun: Sí, pero dependiendo de las características de los cambios. Si
es un cambio de una línea para una cuestión relativa a la seguridad, sólo la
integramos. Si es una adición de una gran característica, lo repasamos
tranquilamente y a veces integramos cambios, a veces no (conseguimos cambios
similares a los de los otros, los implementamos nosotros mismos, o lo integramos
con muchas mejoras).
3. Qué mejoras tiene programadas para nosotros la nueva versión de
NetBSD?
Itojun: SMP (para múltiples plataformas!) y el soporte de threads son
los objetivos más importantes a los que estamos atacando. Y por supuesto,
soporte para más plataformas.
4. El objetivo de NetBSD es portar el SO a tantas plataformas como pueda.
A qué plataformas tiene que ser portada NetBSD, y, es una prioridad hacer
eso?
Itojun: Playstation2 (ya esta portado, necesita integración).
Theo de Raadt, fundador deSD
1. Cómo es la relación entre los programadores deSD y los de
NetBSD/FreeBSD? Compartís código, opciones...cateáis regularmente...? O todos
los proyectos BSD son completamente independientes unos de otros?
Theo de Raadt: No hay relaciones formales de ningún tipo. De hecho,
puesto que es un mundo libre, hay numerosos desarrolladores que hablan con
integrantes de otros grupos. Incluso cuando no pasa eso, nuestro código fuente
es completamente visible en las mailing list públicas. Qué se más puede
pedir?
2. Incorporáis código de FreeBSD o NetBSD a vuestroSD cuando hay
cambios importantes en esos SOs?
Theo de Raadt: Claro, porqué no deberíamos?
3. Qué mejoras para nosotros tiene programadas la nueva versión deSD?
Theo de Raadt: Antes que nada, tengo que repetir lo que he venido
diciendo durante cinco años: el desarrollo deSD no es revolucionario, sino
evolucionario. Eso significa que entre una release y otra, no pasan muchas
grandes cosas, pero por el contrario deberíamos verlo como una serie de unos
pequeños cambios. Sobre una serie deSD, esa cantidad de
pequeños cambios, es una gran cantidad. Cualquier release de hace dos años es
muy diferente al código base que tenemos actualmente, pero etiquetar los grandes
cambios entre dos releases consecutivas es muy difícil. Miles de esos cambios
son bugs fijados, mejoras menores...cosas que calificaría como algo MÁS que
"nuevas características".
Sin embargo, esta siguiente release tiene una gran
cosa que la gente está deseando probar: hemos escrito enteramente un nuevo
packet filter / motor nat, y lo hemos integrado por completo en el sistema. La
gente que esté acostumbrada a ipf encontrará que pf es parecido a ipf, pero
tiene algunas mejoras que siempre habíamos querido hacer (y que la vieja
licencia de ipf no nos permitía hacer).
El port alpha ha sido mejorado
significativamente para soportar algunos de los modelos más altos y vamos a
"sacar" nuestra primera versión beta ultrasparc.
Y más que eso y que los
miles de pequeños cambios y mejoras por todas partes, también hay un grupillo de
otras cosas que probablemente haya olvidado.
4. El objetivo deSD es traernos la máxima seguridad a un servidor.
Patcheando los bugs y sólo aceptando software probado, ¿Crees que eso frena
vuestro desarrollo y que no os deja implementar algo nuevo al SO y "sacarlo"
rápidamente?
Theo de Raadt: No, yo creo que eso no afecta a la programación de una
release o al proceso de desarrollo
Entrevista original: http://www.osnews.com/story.php?news_id=153 | |
