¿Por qué hay que evitar hacer uso de Java?

xatafi escribió:En varios sitios, incluido éste, he podido leer varias veces que hay que evitar el uso java, no ya por motivos técnicos como su "no" portabilidad o su "escaso" rendimiento, sino por argumentos que atentan contra la "libertad del software".

Si una aplicación es libre, pero está programada en java, ¿qué tiene de malo desde el punto de vista de la libertad del software?. ¿Alguien puede dar argumentos sólidos de forma breve?.

Gracias

No soy ningun expero en el tema, pero si la maquina virtual no es libre, y esta es necesaria para hacer funcionar el programa...
Supone ke tu programa Java, ke tu lo has hecho en GPL, depende totalmente de lo k al dueño de JRE (actualmente Sun, sino recuerdo mal) le salga de las pelotas hacer con su maquina virtual.

1) No existen máquinas virtuales libres que cumplan el estándar (es decir, que sean medianamente usables sin cambiar el código)

2) No hay garantías de que Java siga siendo gratis

Yo lo evito porque creo que no ofrece nada que no me ofrezcan otros lenguajes. Pero creo que es perfectamente legítimo e interesante hacer aplicaciones libres en java.

Saludos.Ferdy

------------ blah

No soy ningun expero en el tema, pero si la maquina virtual no es libre, y esta es necesaria para hacer funcionar el programa...

Hay máquinas virtuales libres y compiladores libres. Pero aún están un pelín verde; realmente el 'futuro' puede estar en sablevm, kaffe (primer tipo) y gcj+gnu classpath (segundo tipo).

Supone ke tu programa Java, ke tu lo has hecho en GPL, depende totalmente de lo k al dueño de JRE (actualmente Sun, sino recuerdo mal) le salga de las pelotas hacer con su maquina virtual.

No, hay máquinas virtuales que no son de Sun y son perfectamente utilizables, como la de IBM.

Saludos.Ferdy

Gracias a ambos

Coincido plenamente con Ferdy en que es perfectamente legítimo desarrollar aplicaciones libres con java, de ahí la duda que me surgió.

Con respecto a los argumentos 1) y 2), Windows también se encuentra en la misma situación y, "por lo que se puede leer", es casi "más legítimo" hacer una aplicación que funcione en bajo windows que no una que funcione con java bajo linux.

Gracias por la aclaración.

Mi opinión es que es mejor que exista una aplicación libre a que no exista; si puede estar escrita sobre una plataforma, lenguaje... libre, pues mejor, para que nos vamos a engañar. Pero tampoco rezo a San iGNUcius por las noches.

Saludos.Ferdy

De nuevo coincido plenamente contigo.

La verdad es que este tema siempre crea mucha controversia...

Hombre, a mi Java siempre me ha parecido un lenguaje completito y bastante versátil, y si digo la verdad, le tengo un cariño "especial" porque es con el que aprendí a programar. Que si es lento o no... que si poco rendimiento... pues no se, hasta ese nivel no llego, pero te puedo asegurar que lo he usado para bastantes cosas y siempre he llegado al resultado que quería.

Yo opino lo mismo que ha dicho ferdy, no tiene por qué haber ningún problema en usar Java como lenguaje para programas Open Source... si no parate a pensar, un programa con licencia GPL (digo GPL por poner un ejemplo) usado en windows ¿Deja de ser libre porque lo usamos en windows?

Ferdy escribió:Hay máquinas virtuales libres y compiladores libres. Pero aún están un pelín verde; realmente el 'futuro' puede estar en sablevm, kaffe (primer tipo) y gcj+gnu classpath (segundo tipo).

Y el proyecto Harmony de Apache? ¿Se sabe algo o quedó en vapor?
http://www.mackmo.com/apacheharmony/default/

Si no recuerdo mal creo que se llegó a especular incluso con que recibieran apoyo de la gente de GCJ y Classpath aunque desde que surgió la noticia (hace ya tiempecito) no se ha vuelto a saber nada más del tema.

Por cierto... si estás pensando en aprender algún lenguaje echale un ojo a Ruby, yo llevo muy poco con él y lo poquísimo que he visto me ha parecido la leche (con perdón de la expresión)

(Joer... menuda parrafada me ha quedado...)

Saludos!!!!

flamel escribió:si no parate a pensar, un programa con licencia GPL (digo GPL por poner un ejemplo) usado en windows ¿Deja de ser libre porque lo usamos en windows?

Está claro que no.

El caso es que tenia mis dudas porque no encontraba nada "extraño" en programar aplicaciones con java, pero ya habia leido varias veces que se recomendaba no programar aplicaciones libres con java y no sabia por qué. Los motivos de Ferdy me lo han dejado mas claro pero tampoco veo el "gran drama".

He sido víctima del ruido y de los loros, que me han hecho dudar.

Un saludo a todos.

Y el proyecto Harmony de Apache? ¿Se sabe algo o quedó en vapor?
http://www.mackmo.com/apacheharmony/default/

Ni idea

Como he dicho antes, "el gran drama" es que si puedes elegir el lenguaje es mucho mejor usar ruby, python... (el que mas te guste), que java por aquello de que el propio lenguaje es libre y tienes la garantía de que tiene una comunidad que siempre lo mantendrá libre.

Saludos.Ferdy

Lo del "gran drama" no iba por tí , y de nuevo te doy la razón.

Puedes usar java pero siempre que pueda ser compilado con el compilador de GNU, creo que el GCC 4 soporta archivos java de un tamaño intermedio.

Puedes usar java pero siempre que pueda ser compilado con el compilador de GNU, creo que el GCC 4 soporta archivos java de un tamaño intermedio

¿Por qué? Me parece una chorrada

lo que una chorrada?

Por lo que hemos comentado antes un desarrollo hecho en java es tan libre como uno hecho en python, solo que java tiene un par de peculiaridades que lo hacen "un poco diferente".

El compilador de Sun no es libre y la maquina virtual tampoco.

¿Y?

Pues que estamos en el subforo de software libre, un programa no es libre si las herramientas de ejecución/compilación no son libres. A esos se les llama contrib y van en una carpeta diferente en los repositorios.

Pero si puedes ver el codigo fuente, modificarlo y demás, ¿por qué no es libre?.

¿Una aplicación no es libre porque el IDE con el que se hace, la plataforma en la que se ejecuta, o la máquina vitual que hay por debajo no lo es?

Pues basicamente es asi. Tu imaginate que haces un programa en Visual Basic con licencia GPL, pero para compilarlo necesitas el visual studio. Lo bueno es que siempre queda la esperanza de que lo que ahora no es GPL en el futuro lo sea.

paloseco escribió:Pues basicamente es asi. Tu imaginate que haces un programa en Visual Basic con licencia GPL, pero para compilarlo necesitas el visual studio.

Y?¿

Osea, que según esa misma filosofía open office en versión windows deja de ser open source (porque necesitas windows para ejecutarlo) y mozilla firefox en versión windows (idem de antes).

A mi entender (y que conste que es solo una opinión) una pieza de software es libre cuando te permite ver el código, modificarlo y distribuirlo a tu voluntad (respetando la autoría original)

Y si no te sirve mi opinión mira la de la OSI (Open Source Iniciative)

OSI escribió:The basic idea behind open source is very simple: When programmers can read, redistribute, and modify the source code for a piece of software, the software evolves.

Que viene a decir más o menos lo que yo he dicho antes pero en inglés...

paloseco escribió: Lo bueno es que siempre queda la esperanza de que lo que ahora no es GPL en el futuro lo sea.

Aaaaaamen hermano , aunque no hay que olvidar que hay muchas otras licencias libres (bueno... las de Microsoft no cuentan xD )

Saludos!!!

Pero aunque sea GPL el programita sigue sin ser libre, hay que marcar la diferencia entre los programas que puedes usar unica y exclusivamente con sistemas libres y los que a pesar de ser el codigo libre su uso y creacion estan restringidos. No podemos meter a todos en el mismo paquete cuando hay diferencias muy marcadas entre ellos.

Eso es lo que le paso a linux tolvards al usar BitKeeper: el codigo del kernel era libre pero la herramienta usada no:

https://drupal.gulic.org/node/262

Así pues, en Debian los paquetes se organizan en las siguientes secciones:

1. Main (principal): Esta es la sección más grande en Debian y la que más nos interesa, todo su software debe cumplir las normas DFSG. En resumen: debe ser libre. Además, no deberá tener ninguna dependencia de otro paquete que no esté en esta sección ni para compilarse, ni para ejecutarse.

2.Contrib (contribuciones): Son paquetes que cumplen las DFSG, pero pueden depender para ejecutarse o compilarse de software no libre.

3.non-free (No libres): Son paquetes que no cumplen las DFSG, es decir, no son libres según las definiciones acordadas en el proyecto Debian.

flamel escribió:aunque no hay que olvidar que hay muchas otras licencias libres (bueno... las de Microsoft no cuentan xD )

¿Y? ¿Por estar hechas con MS Office ya dejan de ser libres? . Que es coooooña!XD.

Paloseco... claro que hay diferencias. A uno lo puedes llamar programa libre (que es lo que está acordado según definición), y a lo otro, si quieres, lo puedes llamar algo así como... "programa y sustentación libre". Lo sé... queda feo pero es lo primero que se me ha ocurrido.

Un saludo![oki]

A esos se les llama contrib y van en una carpeta diferente en los repositorios.

A eso le llamará contrib debian o stallman o alguno de vosotros sus cachorros. En gentoo están en el mismo repositorio.

https://drupal.gulic.org/node/262

Ese enlace miente, Linus no escribió y sigue programando git de mala gana. Y se llama Linus y no linux.

---

Si quieres tener una discusión normal, deja de trollear con pancartas de la FSF.

Saludos.Ferdy

A veces no se puede evitar escribir en Java. Si tienes que trabajar en una plataforma que usa Java, te toca tragar te guste o no. Otra cosa es cuando empiezas un proyecto desde cero, lo que ocurre muy pocas veces.

Creo que Paloseco está confudiendo la filosofía de Debian con la del software libre en general. Si Debian quiere separar el software en ramas contrib, main o lo que sea me parece muy respetable, pero el software libre sigue siendo libre por mucha maquina virtual o librerias externas no libres q necesite.

Viendo lo que le ha pasado a Solaris, no me extrañaria que Sun liberase algun dia alguna version del JDK.

Digan lo que digan los de la FSF o quien sea, para mi aunque un lenguaje permita escribir código libre, si éste va a estar de alguna forma sujeto a algo no libre entonces ese lenguaje es descartable en favor de otras opciones (siempre que sea posible).

No tengo nada en contra del java, pero una cosa es usarlo por necesidad o porque resulte ser la mejor opción, y otra es meterlo por todas partes.
Por ejemplo: portagemaster. Un frontend de portage en java? que sentido tiene?

Hola a todos,

no me he leido el hilo entero, no se si habreis comentado tal o cual pero mi opinión es la siguiente:

¿Es lícito utilizar una tecnología no-libre para crear software libre?
Es lícito, pero no es lo más recomendable. Basar nuestros programas en lenguajes propietarios nos ata de forma prácticamente irremediable a una sola opción, por muy gratis que sea. Esa sola opción puede ser desde el sistema operativo hasta la compañía que desarrolla dicho lenguaje.

Para realizar una máquina virtual JAVA hay que leerse muy bien las licencias del propietario del lenguaje, Sun Microsystems. En este caso nos encontramos con sorpresas desagradables. Una de ellas es que se deben cumplir ciertas normas (especificaciones), de las cuales no se conocen todas... aunque no es del todo cierto: hay libros en las que estan escritas y descritas, aunque por gente que las ha "investigado", no por la propia Sun. Pero ahí no acaba todo: Sun puede hacer en cualquier momento que tu implementación sea "ilegal", alegando copia o plagio... y el motivo da igual. Inmediatamente debes dejar el proyecto de lado, o te cae un puro bastante hermoso.

Otro tema sobre las MV de JAVA que te puedas hacer tu, es que no puedes implementarlo como te dé la gana. Esto es bueno y malo. Microsoft hizo una implementación de JAVA en la que incluia cosas que sólo funcionaban con la MV de MS y, obviamente, únicamente bajo Windows. Esto es una mala jugada: rompes el estándard de facto creado por Sun y pierdes portabilidad. Esto hizo que Sun denunciara a MS... ganando los primeros y obligando a MS retirar de todos sus Windows dicha máquina virtual (que venía de serie en Win98, por cierto). Si os fijáis, los primeros que vieron el gran potencial de "encerrar" a todos los desarrolladores en un sistema operativo mediante el lenguaje fué MS, como no. De esta última idea salió .NET, no me extenderé, que fué creado diciendo "os dejaré que lo implementeis donde querais", pero luego no suelta prenda de la parte más importante, las Windows.Forms, atando a todo el mundo a un único sistema operativo. Ya lo dijo Tolkien, Uno Para Dominarlos a Todos.

Tu máquina virtual puede incorporar propiedades que no estén en la de Sun, siempre y cuando sea compatible con esta a nivel de Bytecode mientras no hacemos uso de estas caracterísiticas nuevas y mientras las marquemos muy bien (con neones de colores prácticamente). Por lo general la gente no implementa nada que se salga del estándard de facto creado por Sun, debido a la gran presión que suelen sufrir.

El lenguaje como tal está bastante bien pensado, es ágil y funciona sin volver a compilar en todas las máquinas que tengan una máquina virtual... y encima gratis. Pero, ligar nuestro software a algo que depende de una sola empresa y que encima no podamos hacer nada nosotros en caso de "quiebro", o en caso de que esta decida cobrar por JDK (Java Development Kit), o en... miles de hipotéticos "o", nuestro software quedará cerrado en la inopia del software y ya nos podemos despedir. No creais que es tan "paranoico-cospiratorio"... he ido a muchos bancos (a pedir, pero no... nunca me dan ) y muchos de estos tienen su gestión en JAVA (únicamente hay que ver la interfaz tan alien de JAVA), no creo que todos estos no paguen las licencias que hagan falta (seguro que les sale más barato que migrar a otros lenguajes). Pero... ¿que pasará con el software gratuito o libre? No es muy lógico desde este punto de vista, entonces, utilizar un lenguaje propietario.

Hay gente que opina que si una tecnología software la crea una empresa, por definición es "malo" (éticamente hablando). Esto es un extremismo muy grande... pero que tiene algo de cierto: si ese software es propietario, estas a su merced. No hay nada de malo en utilizar software propietario, siempre y cuando el formato de salida sea estándard o libre. Si el lenguaje de desarrollo es propiertario y no es ni estándard (recordemos que JAVA no forma parte de ningún estándard y que C# desde poco después de su creación fué ECMA), no es ético ni, en cuanto a hacer programas con él, práctico a la larga.

A favor de estas tecnologías diré: tienen un momento y un lugar. Por ejemplo, la tecnología derivada de JAVA que más provecho le podemos sacar (aunque me parece anticuada y tosca) es J2ME... JAVA para dispositivos empotrados (móviles, por ejemplo). Yo desarrollo juegos en J2ME... están destinados a un cierto tipo de móviles y para remunerarse inmediatamente. Ahora es su momento, y los móviles de la generación actual son su lugar. Mañana esos juegos/programas estarán desfasados y no se utilizarán, y habrán dado el rendimiento económico que debieron dar.

Si queremos desarrollar algo que nos dure "toda la vida", con espectativas a poder mejorarlo durante tiempo indeterminado y lograr que llegue al mayor número de sistemas y personas posibles y sin restricciones... no debemos utilizar tecnologías propietarias.

A mi me gusta mucho lo que han hecho con un programa que utilizo muy amenudo: iPodder Lemon, un gestor de podcasts programado en JAVA... pero que en su versión para Linux utilizan Python. Obviamente, las dos versiones son distintas en cuanto a fondo, pero en cuanto a las features son lo mismo. El Look'n'Feel es muy similar entre ellas... pero la velocidad es mucho más alta en Linux... y lo he comprobado yo mismo sorprendiéndome gratamente. A decir verdad, no se si es por Linux o por Python... pero fué lo que me hizo mirar de forma muy distinta este último lenguaje como substituto del JAVA para aplicaciones de escritorio y varios.

Como he dicho JAVA es un lenguaje muy potente, pero últimamente las mejoras son sólo parches sobre estructuras antiguas... y estas mejoras no dejan de ser remiendos para que .NET no le coma terreno, cosa que Sun no está logrando porque se nota que son arreglos. Con mono y python yo creo que se pueden crear aplicaciones más que buenas para substituir a JAVA... teniéndolo libre, para que ir a soluciones privativa.

Recuerdo que con mono y Python pueden crear aplicaciones propietarias si se quiere... no sólo software libre.

Un saludo!


Links

http://www.java.com/en/download/license.jsp
Licencia de usuario final (no para desarrollar MV compatibles)

http://ipodder.sourceforge.net/index.php
Ipodder Lemon

Gracias por el comentario Rurouni.

xatafi escribió:Gracias por el comentario Rurouni.

De nada!

Lo he actualizado un poco porque lo he releido y se me cruzaban los ojos mientras lo leía de la cantidad de errores tipográficos y cosas poco claras que he hecho... pero bueno. Siento el rollazo por eso...

Saludos!

Un texto muy interesante e instructivo. Gracias.

Uf que comentario más largo ruro, me está gustando mucho, pero creo que toy cayendo malo.. pero como decían en otro post, a ver si sakas un libro ke yo tb me lo compraré .


En fín, yo lo que pienso de este tema es que el único lenguaje de programación que existe es el C (no, el ensamblador tp xD ) así que sólo se puede usar el gcc... (aunque he oido de un pavo que desarrolla soft-libre con el Vstudio xD ).


(Bueno, tp opino como todos, que el caso es hacer soft libre, sea como sea... aunke siempre mejor con el gcc x'D )


Saludos

dykstra escribió:En fín, yo lo que pienso de este tema es que el único lenguaje de programación que existe es el C

Te respondo con una cita de Miguel de Icaza:

Miguel de Icaza escribió:Programar en C es demencial

Yo hace tiempo pasé a hacer proyectos propios de C a Java/C++ porque no puedo estar más de acuerdo en esa afirmación. También desarrollo con C pero es algo que sencillamente detesto.

La cuestión que me viene a la mente ahora es, .¿es preferible programar aplicaciones libres en C# a hacerlo en Java?

Ferdy escribió:Pero tampoco rezo a San iGNUcius por las noches.

Dios!!! Ferdy, no mientas todos sabemos que lo haces

Rurouni escribió:Siento el rollazo por eso...

. Ni sientes ni leches, eso son explicaiciones y lo demas son tonterias

Salu2!!

Para mi, mas que un cuestion tecnica es una cuestion de gustos, vaya con el tema, si que ha levantado polvo...


En cuanto a Ferdy y la FSF, que tienes en contra de ellos?

Lo malo de Java desde el principio es que no han sacado un compilador directo a ensamblador. Con lo cual te encuentras con la paradoja de que Java es, en general, más lento que el caballo del malo.

Comentáis que lo malo es que Sun tenga a todos los demás pillados por los cataplines, la verdad es que en el fondo en este caso es cierto. Porque Sun no vive de Java, Sun vive de vender servidores con solaris capaces de tragarse un megaportal jsp funcionando en la elefántica máquina virtual de java, que desde luego no es lo mismo. Si sacan un compilador directo, de qué valen sus servidores?

Para todo lo demás, como dice el anuncio: php, rails, o cualquier cosa que no pese 20 toneladas. Ahora, con proyectos como gcj, quizá Java viva una segunda existencia, pero desde luego como está ahora no.

Utilizar una VM va bien si el programa no sabes en qué arquitectura ni sistema operativo se ejecutará. Es decir, J2ME como comenta Rurouni, y applets para páginas web.

Pero desperdiciar un kilo de silicio para ejecutar Eclipse, o un servidor web, que son programas "estáticos" que tienen que ir lo más rápido posible y van a funcionar una y otra vez, no tiene ni pies ni cabeza. Imaginaos que programan el Quake IV en Java "para que sea multiplataforma". Lo mismo.

Todo esto, claro está, licencias oscuras a parte.

salu2

Amén Rurouni

Java fue diseñado expresamente para que fuera portable y no dependiera de ninguna arquitectura hardware. Eso es imposible con lenguaje ensamblador.

Creo que hay que situarse un poco: Breve historia de la tecnología Java. Alguno se sorprenderia de la cantidad de chismes que llevan Java.

Actualmente estoy desarrollando en Java sobre Oscar, un framework libre del estandar OSGi. Hay una enorme cantidad de "bundles", que son como programitas que corren sobre Oscar, que son software libre y están a disposicion de todo el mundo.

Briareos_H escribió:desperdiciar un kilo de silicio

Lo siento, me ha hecho gracia la frase.

Gran explicación Rurouni.

Saludos

Y, ¿Mono no pasa código Java a nativo?
Lo digo porque sé que corre Java, pero no sé si sólo lo corre, o forma tambíen parte del conjunto de lenguajes soportados para programar.

Salu2!

Gentoo no innova mucho de unas versiones a otras, simplemente actualiza los programas, y la documentacion incluida en los cds es muy escasa. Un simple doc con los pasos basicos. Por espacio no será. Además gentoo no es apropiado para principiantes y ha perdido mucho ultimamente. Aun asi cada distribucion distribuye sus programas como le da la gana mas o menos.

Gentoo no innova mucho de unas versiones a otras, simplemente actualiza los programas, y la documentacion incluida en los cds es muy escasa. Un simple doc con los pasos basicos. Por espacio no será. Además gentoo no es apropiado para principiantes y ha perdido mucho ultimamente. Aun asi cada distribucion distribuye sus programas como le da la gana mas o menos.

No eres capaz de tenerla a tu gusto y culpas a la distribución una vez más... por otro lado ¿a qué viene esto? Quizá a que no sabes qué decir, has visto que te has equivocado y has dicho "pues voy a trollear para que se den cuenta de que no fui capaz de configurar Gentoo". ¿Verdad?

Saludos.Ferdy

En gentoo tengo exactamente lo mismo que enlas otras distribuciones, hace unos dias le meti aceleracion grafica y recompilando el kernel con oss ya me va el sonido, pero eso es dificil de hacer para un novato en linux. Ademas el sistema emerge no es tan transparente como el sistema de debian, y puede dar problemas con las dependencias al desinstalar.

Define transparente

el_Salmon escribió:Java fue diseñado expresamente para que fuera portable y no dependiera de ninguna arquitectura hardware. Eso es imposible con lenguaje ensamblador.

La misma postura (aunque más desarrollada) tiene Mono, y me parece una solución bastante más eficiente. Puedes utilizar la máquina ó compilarlo a nativo. Incluso tiene un ensamblador un poco enriquecido.

Paloseco escribió: Gentoo no innova mucho de unas versiones a otras, simplemente actualiza los programas, y la documentacion incluida en los cds es muy escasa. Un simple doc con los pasos basicos. Por espacio no será. Además gentoo no es apropiado para principiantes y ha perdido mucho ultimamente. Aun asi cada distribucion distribuye sus programas como le da la gana mas o menos.

Esto... ¿me he perdido algo? Hasta donde yo había leído estábamos hablando de Java y estas cosas... No sé muy bien a qué viene esto, pero me has tocado la fibra sensible... .

Gentoo no innova mucho de unas versiones a otras, simplemente actualiza los programas, y la documentacion incluida en los cds es muy escasa

Curioso, a mi entender es de las comunidades más inquietas e innovadoras. La documentación en los CDs no sé, porque para ser sincero en CD no he mirado más que el manual de instalación. Pero es curioso que para cosas que pregunta aquí gente de Ubuntu, Mandriva, etc... no tienen una guía, y en cambio entre los foros de Gentoo y sus wikis casi siempre he logrado un manual para hacer lo que quería.

Paloseco escribió:Además gentoo no es apropiado para principiantes

Claro, ni lo pretende. No se me entienda mal... adoro que haya distribuciones como Ubuntu, pero precisamente lo bueno del SL, como tantas veces se ha comentado, es la diversidad. ¿El que no sea apta para principiantes (yo empecé con ella y sigo con ella) la hace peor?

Paloseco escribió:y ha perdido mucho ultimamente

No sé si fuiste tú el que puso lo mismo en un post hace tiempo. A ver si nos puedes explicar las razones que tienes para opinarlo.

Paloseco escribió: En gentoo tengo exactamente lo mismo que enlas otras distribuciones, hace unos dias le meti aceleracion grafica y recompilando el kernel con oss ya me va el sonido, pero eso es dificil de hacer para un novato en linux

Te repito, ¿por qué lo dices como algo negativo eso de "es difícil para un novato"? Es que no es el objetivo de Gentoo. Para eso hay otras distribuciones, y es bueno que haya de todo!

Paloseco escribió:Ademas el sistema emerge no es tan transparente como el sistema de debian, y puede dar problemas con las dependencias al desinstalar.

Tampoco entiendo muy bien lo de transparente... y no sé si te referirás a facilidad de uso. Por otra parte, se sabe que depclean y revdep-rebuild son paquetes que fallan y comentó Ferdy que se estaban rehaciendo. Es lo "malo" de intentar ir siempre tan para delante, que estás más expuesto a estas cosas. Pero es lo que tiene la innovación... esa misma que tú no ves. Y es que, aún así, hay soluciones reales para lo que has propuesto. Vale, tienes que mirarte un poco los foros y no es tan fácil como en OpenSuSE ó Ubuntu ó Mandriva ó Fedora ó.... pero volvemos a lo de antes, no es el objetivo de Gentoo.
Es que es como si criticas a un fórmula uno por no poder ir sentado cómodamente en una limusina... ¿Ambos son buenos? Por supuesto. ¿Ambos están destinado a lo mismo? Ni de lejos.

Un saludo!

Veremos que hace la nueva version de gentoo. Tambien le eché en falta que no trajese bt, aunque ya se que se puede conseguir aparte.

bt es... bittorrent?
Porque si es así, no lo entiendo... No hay que conseguirlo aparte ni nada. En portage está desde el cliente oficial hasta un montón de otros clientes.
Después de todo... ¿es lo que te queda? Decir "veremos que hace la nueva version de gentoo". En fin, no te digo que no pueda haber opiniones contrarias contra gentoo ni nada de eso, porque de hecho las hay. Pero es que al final el argumento más "sólido" que has dado es que gentoo no es fácil; algo que ya sabe todo el mundo y que no es lo que tiene como objetivo esta distribución.

Sólo me gustaría que cuando se criticasen las cosas, se hicieran con datos/pruebas. Si no, con decir que A TI gentoo ó cualquier otra distribución/cosa no te gusta, pues ya queda bien.

Un saludo!

Bah... su distribución (la que hace él) funciona mucho mejor; fijo.

Saludos.Ferdy

A mí lo que me gustaría que mejorasen de gentoo es la velocidad al haacer un emerge --sync (el updating portage cache) que ya he visto que hay algún proyecto dedicado a eso. Ah, y que me regalasen un procesador más potente.

Lo que sí he visto que algunos paquetes siguen en masked cuando en otras distros (p.ej. monodevelop y ubuntu) ya están en su versión estable. Que sus motivos tendrán, pero yo quiero! Y me da no se qué empezar a meter paquetes de masked (que si fuese sólo un paquete bueno, pero empieza a pedir dependencias y me da yuyu).

PD: Paloseco, tus argumentos son un poco... flojos. Sabemos que Debian de una distro a otra mejora un montón (mira de debian a sarge, uff nuevo kernel, kde, gnome,XFree,...) pero tampoco veo que Debian innove en nada. Vale que apt está muy bien y tal. Pero emerge/portage también.

Un saludo.

A mí lo que me gustaría que mejorasen de gentoo es la velocidad al haacer un emerge --sync (el updating portage cache) que ya he visto que hay algún proyecto dedicado a eso

Está solucionado en las nuevas versiones de Portage y se está trabajando en un parche para las versiones estables. Tampoco creo que sea un problemón... no hay que hacer --sync todas las horas ni siquiera todos los dias.

Ah, y que me regalasen un procesador más potente.

Al revés te lo digo para que me entiendas

Lo que sí he visto que algunos paquetes siguen en masked cuando en otras distros (p.ej. monodevelop y ubuntu) ya están en su versión estable. Que sus motivos tendrán, pero yo quiero! Y me da no se qué empezar a meter paquetes de masked (que si fuese sólo un paquete bueno, pero empieza a pedir dependencias y me da yuyu).

Hasta donde yo se, están en ~arch, lo cual no es peligroso para nada.

Saludos.Ferdy

Ferdy escribió:
Está solucionado en las nuevas versiones de Portage y se está trabajando en un parche para las versiones estables. Tampoco creo que sea un problemón... no hay que hacer --sync todas las horas ni siquiera todos los dias.

Lo sé, era por criticar algo. Es lo único que creo que le puedo reprochar, y fíjate.

Ferdy escribió:Al revés te lo digo para que me entiendas

.etnetop sám rodasecorp nu nesalager em euq y ,hA ?
Pues ahora sí que sí.

Ferdy escribió:Hasta donde yo se, están en ~arch, lo cual no es peligroso para nada.

El que estén en ~arch entonces sólo significa que el programa puede cascar y ya? ¿Y si quiero instalar (no actualizar) otro paquete que me piden las dependencias que también está en ~arch sin que me quite el estable, como se hace, usando slots?

Un saludo.

Lo sé, era por criticar algo. Es lo único que creo que le puedo reprochar, y fíjate.

Entonces es una buena señal, parece que no estamos haciendo tan mal trabajo a fin de cuentas

.etnetop sám rodasecorp nu nesalager em euq y ,hA ?
Pues ahora sí que sí.

Me refiero a que quien realmente necesita más hardware son los desarrolladores; para construir los stages y los paquetes y probar más y más cosas; no tu jeje.

El que estén en ~arch entonces sólo significa que el programa puede cascar y ya? ¿Y si quiero instalar (no actualizar) otro paquete que me piden las dependencias que también está en ~arch sin que me quite el estable, como se hace, usando slots?

Un ebuild en ~arch significa que está preparado para ir a arch pero no ha pasado el suficiente tiempo en ~arch. Y la segunda preguna sinceramente... no la he entendido Pero vamos que los slots no es algo que usen los usuarios, si no los desarrolladores.

Saludos.Ferdy

bastian escribió:El que estén en ~arch entonces sólo significa que el programa puede cascar y ya? ¿Y si quiero instalar (no actualizar) otro paquete que me piden las dependencias que también está en ~arch sin que me quite el estable, como se hace, usando slots?

Un saludo.

Bastian, si quieres programar bajo mono es facil, te instalas las librerias *-sharp estables que son la version 1.0.10, luego metes monodevelop 0.8, mono 1.1.9.2 (en espera de que salga la 1.1.10 en portage), e instalas las librerias *-sharp 2.4 que estaran en otro slot a la 1.0.10, asi que podras trabajar con la version 1 o la version 2 de las librerias cuando quieras. Yo lo tengo asi, ambas versiones de cada libreria (excepto algunas que tienen nomenclatura diferente como gtksourceview) y mono ultima version y monodevelop tb, y perfecto, sin problemas de nada.

Un saludo