El expediente y el exploit se publicaron a través de todo Internet en todas las bases de datos de seguridad como en:
SecurityFocus: http://www.securityfocus.com/bid/25146/
Milw0rm: http://milw0rm.com/exploits/4248
Al día siguiente, la web del componente sacaba este aviso, con la versión 1.1 disponible:
Como es de suponer, gestionar la seguridad no es solo poner un banner en la web y echar la culpa a los que no se mantienen seguros. (Eso ya lo hizo Spectra hace años y no funcionó). Así que, cosas, tan flagrantes, están pasando. Por ejemplo, hoy, a día 8 de Agosto, en el expediente de securityfocus, en la parte de solución pone:
¿Dónde acaba la responsabilidad del proyecto? ¿Dónde empieza la del administrador? La verdad es que un buen administrador tiene que conocer dónde se publican TODAS las actualizaciones de seguridad de TODO su software y tener un plan de actulizaciones creado. Servicios como SANA de Hispasec u otros similares ayudan a centralizar estos problemas.
Ayer, un amigo "anónimo", me envió esta capturita de una web con Joomla, curiosamente la de El Libro Blanco del Software Libre, que tiene este componente vulnerable.
Y buscando ese hash me he econtrado que, ya está en listas de crack MD5 online. Ya sabéis, esas que tienen alta potencia de cálculo para problemas complejos.
Repito las preguntas, ¿Hasta dónde es responsabilidad del proyecto? ¿Cuando empiezan las obligaciones del administrador? ¿Cuanto sube la gestión y el tiempo de trabajo de un administrador en entornos como estos?
Y las preguntas del millón. Joder, esto es Software Libre, lleva el código fuente abierto (es un PHP!!!!) ¿No se lo leen los miles de usuarios de Gmaps? ¿Y los especialistas de seguridad que están para securizar y ayudar a la comunidad?
Saludos Malignos!
- Las obligaciones del administrador serían las mismas que podría tener con cualquier otro tipo de software/fabricante (incluído M$). Es decir, estar al día de las vulnerabilidades que van saliendo e ir parcheando.
ResponderEliminar- Las obligaciones del fabricante serían desarrollar código seguro en primera instancia y en última instancia (alegando que nadie es perfecto) liberar los parches cuando se descubran problemas de seguridad. Exactamente igual que con cualquier otro software.
- PHP siempre ha sido un lenguaje cuyas principales metas son la funcionalidad y la simplicidad. De ahí su éxito y de ahí la proliferación del inmenso número de proyectos y software que actualmente se realiza en ese lenguaje. Lo que también explica el elevado grado de inseguridad: 1) Muchos "programadores" de PHP son lo que podríamos calificar como junior (lo justo para conseguir que le funcione el programa, no se le puede pedir que encima sea seguro ;-)). Y de los que no lo son, un alto porcentaje (la mayoría) se centra en la funcionalidad y no en la seguridad. 2) PHP en sí de siempre ha sido inseguro. Se añadieron opciones a modo de parches (del estilo "safe mode"), tratando de capar agujeros. Aparte de las limitaciones de estas medidas, de vez en cuando aparece algún bug que permite saltarse la verificación de estos settings (por ej, alguna función que internamente nunca verifica el safe_mode). 3) Se pueden programar aplicaciones seguras en PHP, como en cualquier otro lenguaje (es más, el lenguaje lo facilita: por poner un ejemplo, hay funciones que escapan caracteres antes de que un string se use en un comando shell, en un texto HTML o en una sentencia SQL).
En fin, que se ve por donde quieres ir pero no nos convences :) No puedes asociar software libre a software inseguro, mirando precisamente las apps PHP, que en general (y ahí coincido contigo) suelen ser bastante inseguras (porque están mal programadas).
¿Por qué no miramos por ejemplo el conocido software libre Postfix? ¿Se podría decir entonces que el software libre es super-seguro y el comercial no? (compara con los bugs de seguridad de Exchange, por ej.)
Yo sí me he mirado el fuente (no al completo) de algunas apps. libres PHP que pretendía utilizar. En algunos casos he decidido no utilizarlas cuando he visto lo que he visto. Y en otros, al revés, viendo el estilo de programación (chequeos de parámetros de entrada, etc) me he quedado más tranquilo (te haces una idea de cómo de seguro puede ser el software, la preocupación o no de los desarrolladores en cuanto a seguridad, etc; no hace falta hacer una auditoría a fondo).
Por último, ¿cuántas aplicaciones en .asp son vulnerables a SQL injection? ¡La tira! ¿Es ASP inseguro?
Y cuando hablamos de SQL injection, ¿qué motor BBDD ha sido el clásico para demostrar toda clase de técnicas? SQL Server parece que es el más fácil de atacar, viendo el historial de papers, técnicas, etc. ¿Es más inseguro que MySQL?
-r
Preguntas muy válidas, sí señor. Eso sí, no esperes respuestas coherentes.
ResponderEliminarAlf
http://areino.com
Buenas, yo respondo a esta pregunta: "¿No se lo leen los miles de usuarios de Gmaps? ¿Y los especialistas de seguridad que están para securizar y ayudar a la comunidad?".
ResponderEliminarSi, se lee y se ayuda. Por eso aparecen las vulnerabilidades publicadas, si no, no lo harían. Esta es una opción. La versión de Joomla de hoy es más segura que la de ayer.
La otra opción es que no se lo lea nadie y que las vulnerabilidades se parcheen silenciosamente (por ejemplo: www.514.es/2006/11/fuga_de_informacion_en_paquete_1.html). lo que lleva a que los exploits no sean públicos y se pagen miles de euros por ellos y sea la mafia quienes los tenga. Por mafia me refiero a los phishers, spammers, nsa, idefense, o microsoft :-DD
Hola holita ...
ResponderEliminarEstoy de acuerdo con romansoft, no puedes juzgar al software libre porque los que apoyan a este no hayan descubierto este agujero de seguridad.
No hagas lo mismo que tanto críticas sobre los fanáticos de linux que lo son por ser la nueva generación hippiesoft del momento.
Ta lueee
Voy a recopiar el comentario que había puesto sin querer en el artículo equivocado. Tampoco es que tenga que ver directamente pero...
ResponderEliminarA mi esto me ha llegado al alma:
Atsiv: utilidad gratuita que permite saltarse las defensas de Windows Vista
Si, en kriptópilos lo han publicado... Aquí está la URL:
http://www.kriptopolis.org/atsiv
Es genial, se diseña un sistema para que sólo puedas instalar lo que está probado que funciona y no jode al sistema, y ya han encotnrado la manera de instalar cualquier cosa. Luego se quejarán de que su sistema se caiga o no rinda. Y encima tienen los santos webs de decir que es una estrategia de microsoft para que quien quiera desarrollar para Vista tenga que pagar pasta. Mola eh? Diseño un vehículo que quiero que todo el mundo tenga, y me dedico a poner trabas para que vendan su combustible en las gasolineras.
De verdad que esa noticia me ha sonado a "he conseguido trucar una moto de 50 para que se ponga a 200"-> "la moto me ha explotado, y eso que decian que era la más seguria, malditos mentirosos, mira que no poder echar nitroglicerina al depósito... seguro que están compinchados con las petroleras"
@RoMaNSoFt, que me hagas conectarme por la tarde estando en canarias,... vamos!!!
ResponderEliminarAl tema, estoy contigo, en que las obligaciones del administrador es la de parchear el sistema, pero lo que intento decir es que es responsabilidad del fabricante hacer "push". Eso de "la culpa es del administrador" fue el mal mensaje de Spectra (tu la llamas M$) al principio, por eso al TCI (Trustworthy Computing Iniciative) se basa en 4 pilares. 1) Seguro por defecto 2) Seguro por Diseño 3) Seguro en Deployment y 4) Comunicaciones (al usuario y/o administrador). Es lo que se llama el SD3+C y que llevó a que aparecieran los servicios WU, SUS, las newsletters periodicas, los programas de divulgación TEchnet y MSDN ampliaran sus funciones etc... que apareciera el MSRC (Microsoft Security Response Center), el MIIST (Microsoft Internet Investigation Security Team), ahora el MPC (Malware Protection Center), etc...
Lo de PHP en este post es meramente anecdótico.
El mensaje, del post, es: ¿No debería comunicar el proyecto, despues de tamaña cagada, con las bases de datos de seguridad para comunicar el parche? Al fin y al cabo, como dice la web del proyecto se entera por MilW0rm. ¿No debería tener todo proyecto una base de datos de seguridad?. ¿No debería tener una lista de seguridad ese proyecto? Al final todo es pull. Tiene que venir el admin y tirar.
Y dos... Lo del libro blanco ... Tiene su gracia, ¿no?. Y recuerda que yo pongo aquí también cuando la cagan en Spectra con las webs!. ;)
Saludos veraniegos!
@aramosf,
ResponderEliminarosea, que para ti, una cagada de SQL Injection, que aparece por un exploit en Milw0rm (que es como se entera el proyecto) es el camino? O sea, que cuantas más vulnerabilidades tenga publicas un proyecto mejor, ¿No?. Te voy a recomendar un sistema operativo que te va bien bajo ese criterio. Se llama Windows Millenium Edition y dicen que es la caña!!.
Este topicazo ya no se lleva compañero.
Graicas por el link a la web de 514 (creo que a Tarasco, Ramos, etc... los tengo resesados, pero gracias!) en el que habla, de un fallo ¿en drivers de terceros?. Y, te dejo un video, para que veas porque los exploits de Windows se pagan tan caros. ya hablamos de ello en el Security Day, están bien esas charlas, puedes venir a hablar de seguridad un día con todos.
Saludos.
@Gangrolf,
ResponderEliminarno te sulfures, lo que ha publicado el amigo de la ciudad de los krispis es una jilipollez como un piano. La herramienta usa un certificado de Microsoft para poder cargar drivers. Y cuando carga un driver legitimo, carga otro. ¿dónde está la magia? Se usa un certificado para ... saltarse el uso de certificados? Además, habla de dinero y no sabe de que va.
Por cierto, lo que no ha dicho, es que con una clave de registro la comprobación de firma de drivers en 64 bits se deshabilita, solo hay que usar google para mirarlo. En definitiva, lo único que sucede es que esta empresa se está jugando la renovación de su certificado para desarrollo de drivers. Así de sencillo. Ah, y no olvidemos, que tanto para cambiar la clave, como para instalar un driver hay que ser administrador, que en Windows Vista ya no es tan habitual.
@Er Bauty,
ResponderEliminarno compi, lo que digo es lo que le he contestado a RoMaNSoFt, hay que hacer push en el mercado, no basta con publicar en la web de tu proyecto un banner del tamaño que yo he puesto.
Repito, lo de PHP es una anecdota, pero lo del Libro Blanco,.... es gracioso!!
:P
@alfredo,
ResponderEliminarentre algunos sí, entre otros no. Los más fanáticos son los que menos suelen saber de seguridad. Los que saben discuten, pero no dicen que "algo es mejor pq se le han descubierto muchos fallos de seguridad".
o... muchos otros mitos!
@maligno, siento haber interrumpido tus vacaciones con Bill Gates! (seguro que habeis quedado en secreto jejeje). Veamos...
ResponderEliminarSi el mensaje iba en relación a ese proyecto en concreto, ¿qué pinta hablar de software libre, auditar su código *por ser abierto*, qué más da que esté en PHP o no, etc? A lo mejor soy yo el retorcido y he querido ver más allá... diría que no pero ... }:-)
Curioso esto del "TCI" y que propiciase la aparición de Windows Update, etc... No me suena que en Debian exista tal "concepto"/detonante (te-ce-qué? xD) pero sí lleva siglos actualizándose de maravilla con apt-get (¡además sin provocar pantallazos azules y sin tener que reiniciar -salvo excepciones como el paquete de kernel-!) y también dispone de un equipo de seguridad, repositorio de seguridad, listas de seguridad...
Estoy de acuerdo en lo del "push". Y también con que no son formas lo de enterarse por milw0rm de que el software que desarrollas tiene un agujero :) Y no defiendo a ningún proyecto (sea libre o no) que pase de la seguridad. Aunque no te paguen por ello, cuando un proyecto de software libre tiene ya una cierta envergadura (y número de adeptos), los desarrolladores tienen la "obligación *moral*" de responder a cuestiones importantes como puede ser la seguridad. No tiene perdón de Dios que se despreocupen totalmente de ella.
¿Cómo va ese Reto 4? Te interesa tenernos distraídos para que no escribamos tanto! xDDD
Saludos,
-r
@romansoft: Si ya lo dice Maligno en el post anterior: “All Input Is Evil! Until proven otherwise”.
ResponderEliminarY como bien comentas, las distros linux no sufren estos problemas, ya que manejan de forma muy cómoda las actualizaciones de seguridad (y las otras) desde los repositorios, así que igual estás disparando al sitio equivocado, maligno.
@romansoft,
ResponderEliminarte voy a pasar un cubo de rubik de 23 caras para tenerte entretenido!. A vel, a vel. El proyecto es en PHP y cuando lo digo, es para decir... Eh, se puede leer el código fácilmente.
La puntilla, o el argumento, que siempre he defendido es que por ser Software Libre no es mejor, lo que importa es lo que se haga con el código. Da igual si es código cerrrado o código abierto, lo que importa es el trabajo que se haga para securizarlo.
En segundo lugar, he querido resaltar "el mito" de los miles de ojos mirando el código así, a la ligera, no he querido generalizar, sino luchar contra la generalización contraria que dice "Al ser Software Libre es más seguro pq todos los auditan, todos lo corrigen"..
Sí, en Spectra, hasta la TCI en el año 2002 el foco no era la seguridad. Me alegra que Debian tenga algo "similar" (XD).
Creo que un SQL Injection de ese calibre es para pegarles!
El reto 4 va bien, pero quiero ver si hay suerte "y el premio se queda desierto" y sigo con el adorable matahumanos en mi casa. Así que vas a tener que estudiar esta vez!!. Nada raro, pero te voy a hacer pensar.... ;)
@romansoft,
ResponderEliminarte quería dejar el texto en Securmática del año 2006 sobre este tema. La Receta
@Bastian,
ResponderEliminarya se que me lees hace poco, así que te voy a dejar otro artículo que escribí para una revista hace un añito, va sobre eso, sobre las actualizaciones en las distros. No era el tema del post, pero...seguro que podemos discutir sobre él.
Manteniedno una infraestructura Actualizada
Saludos!
He leido tu "receta". En media (ahora explico qué quiero decir) se puede decir que coincido con ella: la balanza está bastante igualada.
ResponderEliminarLos principales argumentos están ahí:
- código abierto: más fácil de auditar y securizar, por tanto
- pero también más fácil de hacer un exploit
El asunto es: ¿qué interés hay en llevar a cabo alguna de las 2 acciones?
Yo me haría una matriz que tuviera en cuenta 2 aspectos: relevancia del proyecto y madurez del mismo. Mi categorización sería:
1) Proyectos relevantes/importantes Hay cierta garantía de que un número razonable de security researchers/hackers hayan analizado el código en busca de fallos (ya sea para corregirlos o bien para explotarlos). Por tanto:
+ si la madurez es baja, la aplicación va a ser más fácil de explotar si es código abierto. Por tanto, veo más seguro el código "cerrado" :)
+ si la madurez es alta e incluso teniendo el código no es fácil encontrarle fallos, quiere decir que es más robusto/seguro. Indudablemente tiene más mérito no ser hackeado cuando el código está disponible. Ganador en este caso: código abierto.
2) Proyectos poco relevantes. Aunque el código esté disponible, no se lo mira ni el tato. Luego casi mejor que sea "cerrado", desde un punto de vista de seguridad, para por lo menos ponérselo algo más dificil a un potencial atacante.
Asumiendo que los proyectos más relevantes suelen ser además los más maduros, el resumen sería:
- proyecto relevante: más seguro si es código abierto
- proyecto no relevante: más seguro si no es código abierto.
Casos prácticos:
- postfix vs exchange. Preferiría el primero (código abierto). Ambos son productos maduros y muy importantes, pero el primero ha resistido a los hackers, cosa que tiene su mérito teniendo en cuenta que tienen el código para mirarlo.
- apache vs iis. También me inclinaría por código abierto, por las mismas razones.
Vaya, sin quererlo me he ido hacia el lado del bien :) Pero es que, claro, a mí siempre me gusta utilizar productos maduros y ampliamente probados ;-)
-r
No, no he dicho que se haya de publicar el exploit, si no que el que se publique significa que se audita. El hacer chistes sobre si el codigo abierto se audita o no, está de más. Con pruebas como esa.
ResponderEliminarEl problema es que $pectra no publica el código e incluso así, hay veces que se audita :-D, si lo publicasen, seguramente en dos meses tendrian muchas vulnerabilidades solucionadas que actualmente solo conocen unos cuantos.
Sobre ese mensaje, dejando desvaríos y afirmaciones gratuítas aparte, un par de cosas.
ResponderEliminarSi con MS puedes administrar las actualizaciones de toda una red heterogénea (es decir, con cualquier versión de windows instalada), desde luego es un punto a favor.
Cuando yo hablo de las actualizaciones de un sistema de paquetes en una distribución linux, éstas no se limitan sólo al software que proporciona la propia distribución. Se pueden añadir repositorios de software de terceros (también privativo) e instalar las actualizaciones pertinentes de la misma manera. Si las herramientas que mencionas tú manejan no sólo actualizaciones de software de MS me quito el sombrero, pero me da en la nariz que es sólo para su propio software.
Hola romansoft, eres tan peleón como yo, ¿eh?. Tu reflexión es buena en todo pero yo generalizo más. Un proyecto maduro (sea código abierto o no) habrá sido más estudiado, (repito, sea codigo abierto o no). Ya que, como hemos hablado antes, los ojos son una parte ínfima en la búsqueda de fallos de seguridad en un código y son necesarias las herramientas automáticas de búsqueda de vulnerabilidades. Las de análisis estático y análisis dinámico, luego un proyecto maduro, como Exchange o IIS (ya que los nombras tú...) no dependen de si su código es abierto o no, sino de sí se han hecho las cosas bien o no. Por poner los ejemplos que has puesto tú, solo tienes que buscar los fallos que se le han encontrado a Apache y a IIS en los últimos 3 años y echar unos números. Si esa reflexión fuera cierta, cuanddo microsoft publicó hace ya más de un año el 80 % del código fuente del kernel de XP entonces deberían haber aparecido un nuevo montón de fallos (como un 80 % más) ya que antes de su publicación no había sido escrutado por security researchers/hackers. Y eso, como ya sabes, no ha sido así.
ResponderEliminar¿Postfix vs Exchange? Je, sí quieres te reto a montar una infraestructura en plan demo, con un relojito como el de ajedrez y una listita de funcionalidades. Para montar una infraestructura similar a las que se pueden hacer con Exchange 2007 creo que ibas a necesitar más de 20 productitos. :P :P :P :P
aramosf, me das mucho miedo. ¿cuantas conocéis perros que no habéis notificado? He llamado a Atar para que me mande tu teléfono y partirte las piernas, pero voy a tener que pasarme personalmente por la oficina tuya a arreglar esto personalmente! :P
ResponderEliminarNo creo que sea así, hace ya más de un año que el 80% del código fuente del kernel de XP es público y no han aparecido más vulnerabilidades pq el código ya es maduro. Además, tal y como lo hacéis vosotros, (fuzzers, análisis dinámico, un poquito de asm, y debugging) ¿cuantas vulnerabilidades han aparecido?. Spectra usa herramientas de análisis estático y dinámico y retroalimentación, cuando sale un código tiene un nivel de madurez alto.
Hola Bastian,
ResponderEliminarpues no, System Center, antes SMS, es un gestor de software de cualquiera, pero además, push. Como digo en el artículo, el sistema de actualización de las distros es un poco así. Para muestra un botón. Aquí tienes el último parche del kernel en RedHat Enterpise LinuX 5. Parche Kernel RHES 5. Como ves en los ficheros es la 2.6.18. (suponemos que con todos los parches) Sin embargo, si vas al proyecto del kernel, tenemos, en el ChangeLog que ha salido la 2.6.19 y todos sus parches, la 2.6.20 ...y todos sus parches, la 2.6.21 .... y todos sus parches y vamos por la 2.6.22... y todos sus parches... (velocidad?)
@maligno, necesitaría el enlace de descarga directo oficial de M$ que te permite bajarte el fuente del kernel de XP. Así hablamos con hechos :-)
ResponderEliminarLos últimos años de Apache/IIS han sido bastante malos para los script-kiddies, lo que es buena señal. Siendo ambos aparentemente seguros (ya se sabe que siempre es relativo...) tiene más mérito el que tiene sus entrañas al aire y a la vista de todos, esto es, open-source.
Déjate de retos, que aquí el único que tendría que estar currando en uno que yo me se eres tú! Además, yo no soy la tipa polaca esta (Rutkowska) ni Postfix es Blue Pill...
Aunque ahora que lo pienso, quieres comparar el tiempo de despliegue, ¿no? Mi pregunta: ¿después se compararía el rendimiento? ¿y por último la cuenta del banco a ver esas facturas por las licencias de Windows, Exchange, etc? xDDD Vamos a ver, ¿estamos hablando de seguridad o de todo lo demás?
Con mucho cariño :-*
-r
"pues no, System Center, antes SMS, es un gestor de software de cualquiera, pero además, push. Como digo en el artículo, el sistema de actualización de las distros es un poco así."
ResponderEliminarEsto es lo que dice MS, que no es lo mismo que dices tú: "Las soluciones System Center están pensadas para simplificar la gestión de sistemas y aplicaciones que ya tiene en su empresa, como pueden ser Microsoft SQL Server, Microsoft Exchange Server, Microsoft Office, o Microsoft .NET Framework. Además, las soluciones System Center pueden interactuar con herramientas de gestión de otros fabricantes"
Sobre el kernel y las versiones, creo que no es la primera vez que te comento que existen unas cosas llamadas backports, que consiste en hacer parches de una versión para aplicarlos a una anterior.
Y de lo que te quejas de las distintas versiones del software en las distintas distros, en Windows 2000 tampoco tienes IIS6 o IE7, o DirectX10 en WinXP.
@romansoft
ResponderEliminarno te preocupes, te lo busco y te lo envío, pero no solo eso, te paso unos cds que el año pasado repartimos miles de ellos por toda españa, con manuales, herramientas y como interpretar el código del kernel.
jaja, lo del reto es para que cuando montes los ciento y pico productos que vas a necesitar para igualar las funcionalidades de Exchange e IIS no te olvides de contar todas sus vulnerabilidades!!!
@bastian, si quieres te hago una demo, para que veas todo lo que se puede hacer. ;) Se puede distribuir todo el software que quieras y además, como te digo PUSH. échale un ojo a algún webcast de esos.
ResponderEliminarya me habías comentado eso, pero de nuevo te digo, las distros DAN SOPORTE (ese que PAGAS) y no te actualizan a las mismas versiones, como digo en el artículo, dos distros distintas totalmente actualizadas y ... magia, los productos no están en las mismas actualizaciones! No confundamos distintos productos (kernel 2.0 o kernel 2.4, (ie6 o ie7) con distintas actulizaciones). Saludos!
Si lo de los productos sí te vale, te diré que lo que comentas no son simples "actualizaciones", entendiéndolas como corrección de errores. Un kernel de los primeros de la rama 2.6 de allá por el 2003 no tiene nada que ver con un kernel 2.6.22. Hay muchas cosas que cambian de una versión a otra en cada minor-version. Ya comentó el propio Linus que no habría algún cambio cambio de major-version del kernel a no ser que significase un rediseño de la arquitectura que implicase una ruptura del API, lo cual es altamente improbable a día de hoy. Así que puedes pasar de la numeración y considerarlos "productos distintos" (eso sí, con las mismas actualizaciones, como ya te he comentado). :)
ResponderEliminarBueno, yo me planto, que quiero que mi fin de semana sea provechoso :)
ResponderEliminarMe apunto lo de los fuentes + CDs estilo howto-interpret-them. Aunque lo agradezco, sigue siendo un tanto sospechoso que me los tenga que pasar de tapadillo alguien cercano a M$ (gracias de nuevo xD), y que no se pueda bajar de la web lo que, entonces sí, habría supuesto que de verdad están al alcance de todos los security researchers y no sólo de algún enchufadillo como yo :-P.
Respecto a las features de IIS/Exchange, habría que ver quién tiene activas todas esas funcionalidades de las que hablas y les saca partido. Porque si sólo cuentas a esos power-users, entonces estaríamos hablando de una cuota de mercado bajísima (sí, es subjetivo :)) y no es lo que estamos comparando.
Si comparas Linux 2.0/2.4 con IE6/IE7... ¿con quién se corresponden los últimos 2.6? Supongo que con Firefox 2 ;-) Por cierto, yo instalé IE7 hace tiempo y lo tuve que quitar porque la mitad de las webs no funcionaban bien (y para algo que tiene el IE, que es la compatibilidad con el mundo mundial, con la v7 se pierde... es una pena, ahora que ya traía tabbed browsing -después de unos cuantos años de firefox jejeje-).
:-*
-r
@romansoft,
ResponderEliminarte dejo el link que te mandé por correo de acceso al código fuente.
Para que no sea "sospechoso"...
"habra que ver quien las tiene activas?". Te voy a tener que dar una turné por algunos CPDs en Madrid, para que los veas, como si fueramos al Zoo. XDXD
Por cierto, ahora que hablas del tabbed browsing, recuerda que había antes para IE que para Firefox (como plug in)
@bastian,
ResponderEliminarentendido, o sea, que cuando salga una actualización en un kernel, para los que tienen soporte en distro no cuenta hasta pasados ... ¿unos meses?. ¿Esa es la rapidez de reacción? Y de nuevo el problema, yo tengo RedHat y Ubuntu, ámbas con soporte y no tengo absolutamente ninguna garantía que teniendo los dos sistemas actualizados a la última versión con soporte de la distro tengan la misma versión del mismo producto.
Es que lo primero que deberías hacer antes de instalar una distro es enterarte de como funciona, que me parece que no lo has hecho. Y sí, si necesitas *exactamente* la misma funcionalidad en dos equipos sin partirte la cabeza, lo mejor es que en ambos instales la mismita versión del SO, pero tanto en Linux como en Windows, por mucho que te empeñes. ¿O MS sí me garantiza lo que tú dices?¿Acaso todos los windows llevan el mismo kernel?
ResponderEliminarJaja, maligno, muy bueno lo de los tabs. Definitivamente los debió inventar MS, como todo en la informática.
@bastian,
ResponderEliminargracias por darme la razón. Sí, todos los windows Server llevan el mismo kernel y todos los windows Vista llevan el mismo.
Respecto a las tabs en los browser, primero fue opera y luego un plugin para IE. Saludos!
Sobre darte la razón, en ningún momento había dicho que no sea así, vamos es de cajón que si necesitas sistemas exactamente iguales, uses el mismo SO, pero también con Windows, así que supongo que tú también me la estás dando a mí, ¿no? ;).
ResponderEliminarSobre los kernels, no me refiero a todos los Vista, cachondo. Me refiero a si Windows Vista lleva el mismo kernel que Windows XP o Windows 2000, por ejemplo. ¿Todos los windows server (2000, 2003, 2008) tienen el mismo kernel?
Sobre los navegadores, y las pestañas, no me importa demasiado si algún plugin lo incluyó antes, la cosa es que MS no lo ha hecho hasta hace nada. Aquí tienes la historia: http://es.wikipedia.org/wiki/Navegaci%C3%B3n_por_pesta%C3%B1as
Bueno Bastian, esto se está convirtiendo en un Flame, y ya tenemos otros posts para pegarnos. ;) Si te empeñas en hablar de Windows 2000 (kernel detenido en 1999) con RHEL 5 AS (de Marzo de 2007) no podemos seguir discutiendo sobre eso, pues tenemos un problema de base de discusión. ;) Sigo diciendo que la gestión de las actualizaciones (incluso para W2000) es pareja.
ResponderEliminarRespecto a lo de la historia de las pestañas, me alegra que tú mismo pongas el link dónde se dice. "...en 1997 en el navegador web Netcaptor". El problema de esto es que no lo revisen y se olviden de poner que Netcaptor no era un navegador sino una shell de Internet Explorer. En un blog en mozillazine se explica y en la wiki en inglés no se "han olvidado de este detalle". ¿Teoría de la conspiración?. Saludos Bastian.
Si Windows 2000 es equiparable a RHEL (que por cierto, no los he comparado en ningún momento) en la gestión de software desde luego no es out-of-the-box. Puede que si pasas por caja a por uno de los programas que comentabas, sí lo sea, eso ya lo desconozco.
ResponderEliminarPero sí, mejor que lo dejemos. En efecto hay un problema de base cuando reinterpretas lo que digo a tu antojo.
Yo creo que no lo hago Bastian, pero creo que lo mejor es acabar esta conversación con un café o un birra. Saludos! (pago yo!)
ResponderEliminar