0  0

0  0

0  0

0  0

0  0

0  0

0  0

0  0

evitar los problemas de inestabilidad del SO que genera la existencia de aplicaciones de terceros con acceso nativo, que salía del control del SO.

Ningun sistema operativo moderno, incluyendo Windows desde NT, permite acceso nativo. Todo el acceso está supervisado por el sistema operativo a través de mecanismos provistos por el hardware.

Plataformas “managed” como .NET y Java apuntan a otro tipo de problemas : gestión de memoria, seguridad de las aplicaciones (sin comprometer al sistema operativo), etc.

Lectura recomendada:
http://en.wikipedia.org/wiki/Protected_mode

0  0

Pero no les va a funcionar por que la razón por la que en Linux se pueden usar paquetes es por que Linux es modular y los paquetes y librerias son abiertos, no asi en Windows donde el código de las librerias que usa Windows están cerradas…

Nuevamente… esto se está haciendo para paquetes de código abierto en Windows. cOapp O = Open.

0  0

0  0

El sistema de repositorios es muy cómodo y eficiente.

Nadie niega que a veces hay conflictos con dependencias estilo

“se ha retenido el siguiente paquete”

Pero en mi caso la solución siempre ha sido simple.

Muchas veces actualizan un paquete pero no su dependencia, y queda retenido por un tiempo, el sistema se corrige solo a medida que se va actualizando.

En otros casos, me ha pasado que queda la grande, unos 5 paquetes retenidos, paquetes rotos, y demás etcéteras. Pero la solución nunca ha sido un dolor de cabeza. Casi siempre es abrir Synaptic, Marcar todas las actualizaciones, aplicar, o bien, filtros, paquetes rotos, reinstalar.

0  0

0  0

0  0

0  0

0  0

Pero como leo en el blog del impulsor de la idea, el tema es portar el sistema de paquetería de linux a windows para poder facilitar el trabajo de porteo de aplicaciones linux a windows, sin tener que buscar a mano cada paquete y resolver dependencias a mano, que es lo que usualmente hacen los programadores cuando se porta un paquete a windows (piensen en el GIMP, por ejemplo, que tiene varias dependencias y cada version cambia las versiones de las dependencias.). El usuario final simplemente instala un archivo MSI, siguiente, siguiente, instalar ahora, finalizar, disfrutar.

Al parecer la idea es simplemente facilitarles la vida a los programadores que portan código de linux a windows. No es malo para los programadores y probablemente sea transparente para los usuarios.

0  0

0  0

0  0

0  0

0  0

Ese es un problema de quien hizo el paquete, no del sistema de paquetes. En distribuciones bien coordinadas no encuentras ese tipo de problemas.

Recuerdo que hace muchos años, cuando no existía Fedora y RedHat solo tenía RPM, sin yum, era un problema bastante común.

0  0

Ademas que en tu ejemplo olvidas que de antemano debes saber el nombre del paquete, y eso no es trivial muchas veces asi que tienes que recurrir a un apt-cache search etc etc.

Para eso existen aplicaciones como el Centro de Software de Ubuntu. Perfectamente podrían hacer lo mismo en Windows.

También existen mecanismos como Apturl, en donde un sitio web publica una link que gatilla al sistema de instalación de la distribución para que se instale el paquete desde los repositorios, ni siquiera necesitas alojar el paquete en el sitio web.

Por ejemplo un usuario de Ubuntu puede instalar Cairo Clock simplemente haciendo click sobre ese enlace.

0  0

¿Ademas quien va a diseñar paquetes para el software que tengo instalado? es decir, ¿Como saben que es lo que ya tengo instalado para estructurar un paquete con actualizaciones para ese software? y sin meterme otras pendejadas que no quiero ni necesito.

Los paquetes los podría hacer cualquiera, es un proceso abierto (y público) así como está planteado.
La estructuración de los paquetes se define mediante coordinación, piensa que en distribuciones como Debian se coordina el versionamiento y estructura de más de 15.000 paquetes. Hoy en día los paquetes construibles para Windows son una pequeña fracción.

0  0

¿Instalar aplicaciones puede ser un infierno en windows? Pues solo que tengas retraso mental para no poder instalar algo en windows.

Lee bien el artículo. No se refiere a aplicaciones como uTorrent o MS MSN (o Live), sino que a las aplicaciones del ecosistema de código abierto que a estas alturas es bastante grande.

¿Los malditos repositorios no instalan también un montón de mierda que no voy a necesitar?

No, porque los repositorios los podría proveer Microsoft, y así se puede asegurar de que no se abusen. Hoy en día no tienes nada de eso para aplicaciones de terceros. Si descargas aplicaciones en Windows te pueden meter cualquier backdoor, adware o spyware, es justamente uno de los grandes problemas de instalar aplicaciones de internet para Windows hoy en día.

Bueno si no pueden con algo tan simple no es nuestra culpa, orgasmeados linuxeros de caca.

Trata de instalara algo similar a lo que incluye Linux en Windows y después conversamos.

0  0

Uso Lenny estable, para arm, y creeme de vez en cuando sigo teniendo problemas tontos para instalar algunos programas, pero lejos lo peor es cuando el sistema me obliga a instalar 50 o 60 megas en “dependencias” para un programa de 300 kilos, como por ejemplo la sarta de software para instalar el convert de image magick. Si esta bibliotecas de X.org me obliga a instalar cuando yo no tengo x en mi maquinita arm!!!. Al final de suerte encontre un binario estatico por ahi con todo lo necesario y me ahorre 50 megas en cosas que jamas iba a utilizar.

Pero ese no es un problema del sistema de paquetes, es un problema del personaje que hizo el paquete. Problema que perfectamente podrías reportar.

Sin usar un sistema basado en dependencias, la mayoría de los usuarios no bajaría 300k sino que tendría que bajar los 50 megas completitos aunque ya tuviera las bibliotecas instaladas, ya que sin esas bibliotecas, ese programa no funcionaría como fue compilado originalmente.

Lo que hiciste al final fue bajar otro paquete en donde estaban planeadas las dependencias de otra forma, generalmente recortando funcionalidad de la aplicación, pero como dije al principio, definir las dependencias no es un problema que resuelve el sistema de paquetes, sino el desarrollador del paquete.

0  0

No veo la incompatibilidad técnica. Si bien CoApp es solo para aplicaciones de código abierto, perfectamente podrian tener repositorios de software restringido, tal como hoy lo hacen en Linux.

Por otro lado, estas interacciones podrían tener problemas de licencias. Muchas licencias de software de código abierto permiten interacción con software cerrado sin problemas (BSD, MIT), pero en otros casos es más complejo (GPL con Copyleft) en tanto el software que utilice partes del software con copyleft debe ser distribuido a su vez como copylef

Las restricciones de distribución no van a cambiar si descargas el programa a mano o lo baja un sistema automático.

0  0

Creo que el mejor de los Administradores de paquetes en linux, hoy por hoy, es pacman de Archlinux, el mismo busca el paquete y dependencias, si éstas ya están instaladas, entonces perfecto si no entonces el mismo las busca y las instala, la verdad es una maravilla y por eso uso esa distro

Y cual sería la diferencia con lo que ya hace Fedora, RedHat, CentOs, Debian, Ubuntu, OpenSUSE, etc? con apt, zipper y yum?

0  0

Por el momento es sólo para aplicaciones de código abierto, pero no sería extraño que otras aplicaciones les interese usar el mismo mecanismo, por ejemplo así no tendrían que preocuparse de escribir o mantener sus propios sistemas de actualización.

0  0

El ejemplo de las DLL es malo: Las DLL no siempre son compartidas, justamente por lo que cuesta asegurar que una aplicación funcione bien con las DLL que ya están instaladas (alguien dijo DLL hell?). Por eso preferí el ejemplo de DirectX en donde si se instala y comparte en una forma similar a las bibliotecas de Linux.

http://es.wikipedia.org/wiki/DLL_Hell

0  0