• Facebook
• Twitter
• Reddit
• LinkedIn

Nuevo podcast de Paultdotcom en español. El primero del año 2013 ya está disponible con entrevista realizada por Carlos Perez a Ryan Dewhurst, creador de WPScan.

Puedes descargarlo desde aquí

• Facebook
• Twitter
• Reddit
• LinkedIn

En el vídeo que presentó Steve Jobs en la Macworld de 1997 en Boston, Steve Jobs anunció un acuerdo con Microsoft sobre el uso de patentes entre ambas compañías, el acuerdo que llegó con Microsoft para que este portara Microsoft Office a Mac y la decisión que tomó Apple de incorporar a su sistema operativo a Internet Explorer como navegador por defecto, cosa que por cierto no gustó al público.

En julio del 2002 Apple contrató a Dave Hyatt. Éste era una eminencia en el mundo de los navegadores web, por crear Chimera, también conocido como Camino. Un navegador web para Mac basado en el motor de Mozilla Gecko. Hyatt también fue el co-creador del proyecto que dio vida a Firefox.

Como iba diciendo, cuando Apple fichó a Hyatt, las especulaciones no se dejaron esperar. Muchos apuntaban que Hyatt iba a migrar Chimera a Mac, pero no eso no hacía falta porque éste ya corría sobre Mac y otros apuntaban a que Apple estaría trabajando en su propio navegador web basado en Gecko, con el que Hyatt ya tenía bastante experiencia.

Según cuenta Don Melton, el nombre con el que se conocía internamente a dicho navegador era “Alexander”, aunque muchos hacían referencia a él como “iBrowse”. Después de varias reuniones para bautizar al navegador se llegó a la conclusión de que se llamaría: Safari.

Melton, como responsable del proyecto, una de sus mayores preocupaciones era que se filtrara. Por suerte para él, por aquel entonces no existían ni Facebook ni Twitter. Y todo y cada uno de los miembros del equipo tanto desarrolladores como beta-testers, se les requería bajo juramento, el no filtrar absolutamente nada del proyecto, ni siquiera el proyecto en sí.

Para guardar el secretismo, otra de las precauciones que dicho equipo tuvo que tomar era el no revelar ningún tipo de pista a los servidores web. Como la cadena del User-Agent o las IPs, para no dar ningún tipo de pistas a ningún administrador que le diera por mirar los logs de su servidor.

Como hemos visto antes Apple, en 1997 llegó a un acuerdo como Microsoft para incorporar Internet Explorar en su sistema, con lo que el objetivo para despistar a avispados administradores, para ello simularían la presencia de IE. Para hacer ciertas pruebas, necesitaban poder usar el User-Agent que Safari llevaría cuando éste fuera lanzado. El plan fue usar la cadena User-Agent de Safari sólo cuando se encontraran fuera del campus de Apple o fuera del rango de IPs que pertenecían a éste, para que nadie pudiera relacionar dicho User-Agent con una IP de Apple. Quien por cierto, por aquel entonces poseía toda una red del tipo A, cualquier dirección IP que empezará por “17” pertenecía a Apple.

Safari no fue creado desde cero y se basó en uno de los motores de renderizado web Open Source, pero no fue Gecko como algunos suponían, sino KHTML y KJS, el motor de Konqueror, navegador web de KDE.

En el siguiente vídeo de apertura de la Macworld 2003, 7 de enero, vemos la presentación en primicia de Safari. Podéis escuchar al público muy emocionado con el anuncio del navegadores, la comparación de velocidad con otros navegadores para Mac, los marcadores (bookmarks), incluso cuando Steve Jobs dijo que lo habían basado en código Open Source, pero cuando dijo que estaba basado en KHTML la gente se quedó muda. El vídeo empieza en el minuto 54:50

… Some people have a problem with Open Source, we think it's great, we think it is great.

Steve Jobs

• Facebook
• Twitter
• Reddit
• LinkedIn

En ocasiones anteriores hemos hablado sobre Raspberry Pi, un ordenador del tamaño de una tarjeta de crédito totalmente funcional y muy barato. En esta entrada vamos a ver un poco de historia sobre los inicios de este dispositivo.

Inicialmente la idea de la creación de Raspberry Pi era muy incierta. La reputación de los diseñadores, no conocidos, y los precios que tenían en mente apuntaba a que las ilusiones del proyecto se desvanecerían.

El plan inicial era el de construir 1.000 unidades para estudiantes de la Universidad de Cambridge. El precio de venta serían de 35 dólares, incluso sabiendo que el coste de fabricación de estos dispositivos sería de 36 dólares. Haciendo números no es difícil darse cuenta que este movimiento les llevaría a unas pérdidas iniciales de 1.000 dólares. Coste que estaban dispuestos a asumir como parte del marketing de este dispositivo. Los diseñadores esperaban que los estudiantes universitarios sirvieran de “conejillos de indias” para depurar, documentar y mejorar el dispositivo. Visto de esta forma 1.000 dólares parecen más una gran inversión que un gasto.

Pero lo que empezó como un pequeño proyecto (de 1.000 unidades) se convertiría en un éxito de terror. Tres semanas antes del lanzamiento del Raspberry Pi, se produjo un incremento en la demanda del mismo de 200.000 unidades. Si nos basamos en los números anteriores, estaríamos hablando de unas pérdidas iniciales de 200.000 dólares, pero como consecuencia del incremento del número de dispositivos, el coste de fabricación disminuiría. El gran problema era que estaban a tres semanas del lanzamiento y era imposible producir tal cantidad de dispositivos en dicho periodo de tiempo. Esto no sólo hizo que tuvieran que renegociar el contrato de producción sino que además tenían que encontrar un fabricante que fuera capaz de poder manejar tal volumen de producción.

La decisión parecía clara: China. Mano de obra barata y producción masiva. Pero los integrantes del proyecto querían mantener la producción en Reino Unido, dónde al menos, la mano de obra para la producción la placa impresa era permisible y se encontraba dentro de un precio razonable de producción. Eso sí, el resto de los componentes tendrían que ser importados de países más baratos. Para ello se asociaron con Premier Farrell y RS/Allied. Dos empresas capacitadas para hacer frente a las necesidades del proyecto a nivel mundial.

El siguiente paso era como iban a publicar información sobre el dispositivo y a la vez evitar que alguien copiara el proyecto y sacara un dispositivo igual o parecido, pero más barato, ya que se ahorrarían el coste del diseño. Esto era más una preocupación de los socios, que al fin y al cabo eran los que iban a arriesgar el capital. La solución fue el de publicar el esquema del dispositivo, pero sin dar detalles de los componentes que llevaría el mismo. Esto haría que el copiarlo fuera casi tan costoso como hacer el diseño desde cero.

Por último, tenían que decidirse a que segmento de la población enfocarían el producto y por lo tanto que funcionalidades desde el punto de vista del hardware deberían incorporar en el Raspberry Pi. Del cual hablaremos en una nueva entrada.