-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2008-12-10 a las 20:50 +0100, Camaleón escribió:

Sí, sólo eso.

He creado ese archivo (/home/test/.gtkrc-2.0), he reiniciado nautilus (killall nautilus) y listo.

text[NORMAL] = "#FFFFFF" para un texto de color blanco

...

¿Y de donde rayos sale eso, donde está documentado?

Debe estar por algún lado, en la documentación para desarrolladores, quizá... en mi búsqueda sólo encontré este documento:

GTK Theming Tutorial http://live.gnome.org/GnomeArt/Tutorials/GtkThemes

Pero poco más... y con eso sólo no me aclaraba :-(

Es lo que digo siempre, que el gnome no está hecho para ser ajustado al gusto. No por los usuarios. Lo hacen los desarrolladores, y o te comes las lentejas o las dejas. :-( - -- Saludos Carlos E.R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAklAH0AACgkQtTMYHG2NR9UwSgCcC5SI08bp36u5tVRNC116bNOK EKAAn0UV8tqArsvDJIZAvTXuFXRFcBHf =wFFs -----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Content-ID: El 2008-12-11 a las 08:29 -0200, Juan Erbes escribió:

...

¡¡ Yuuuhuuu !! 8-)

Ahora sí... funciona, y no veo "efectos secundarios".

:_) << lagrimón

Curiosidad:

Porque usas Gnome, y no KDE?

¿Y tu porqué usas kde, y no gnome? >:-P - -- Saludos Carlos E.R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAklA9XMACgkQtTMYHG2NR9VWOACePuGNLP8+OQcAJ6Q/sLoRzMsg EbkAniRu0YgdArIyOdnHSbwn9Z3YQmih =CHrk -----END PGP SIGNATURE-----

El 11/12/08, Alberto Vicat escribió:

Ey Carlos, ¿no sabes cuál es la inicial del apellido de nuestros dos últimos presidentes?

Ya veremos de usar Gnome cuando tengamos un presidente Gómez, Gutiérrez, González, etc.

X-DDD

Entonces en España tendríamos que estar utilizando "windoZ" X-) Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org

2008/12/11 Carlos E. R. :

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

Content-ID:

El 2008-12-11 a las 08:29 -0200, Juan Erbes escribió:

...

...

¡¡ Yuuuhuuu !! 8-)

Ahora sí... funciona, y no veo "efectos secundarios".

:_) << lagrimón

Curiosidad:

Porque usas Gnome, y no KDE?

¿Y tu porqué usas kde, y no gnome? >:-P

Empezando, porque fue el primer entorno grafico amigable que utilizó SuSE. Segundo, porque a nivel programación estaba programado en C++, mientras el Gnome en Ansi C. Tercero, el favorito de Linus Torvalds, era el KDE, y no el Gnome. Cuarto, en genearl, para instalar una aplicación Gnome, hay mas problemas de dependencias que para una aplicación KDE, que requiere de menos librerias o paquetes adicionales. Realmente, nunca me tomé el tiempo para hacer una evaluación comparativa en los ultimos tiempos, y por innercia sigo con KDE. Salu2 -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org

El día 11 de diciembre de 2008 14:32, Carlos E. R. escribió:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

El 2008-12-11 a las 13:26 -0200, Juan Erbes escribió:

...

...

...

Curiosidad:

Porque usas Gnome, y no KDE?

¿Y tu porqué usas kde, y no gnome? >:-P

Empezando, porque fue el primer entorno grafico amigable que utilizó SuSE.

No era una pregunta en serio.

¿El primer entorno amigable que usaron? No, antes hubo otros. Es del año 96.

...

Segundo, porque a nivel programación estaba programado en C++, mientras el Gnome en Ansi C.

A lo mejor por eso el Gnome era capaz de funcionar en una máquina de 32 megas de hace 10 años, y el kde se arrastraba - todo el mundo sabe que programar en C++ es una desperdicio de recursos :-P

En la actualidad, cual consume mas recursos?

...

Tercero, el favorito de Linus Torvalds, era el KDE, y no el Gnome.

Bueno... eso no quiere decir nada. Tendrías que entrar en ver porqué lo ha dicho: y no es porque piense que sea malo, sino porque no hace lo que el quiere hacer. Es decir, porque oculta y quita de en medio la posibilidad de ajustar esto o lo otro... y eso es apropósito, es por diseño.

Si quieres un entorno que te permita ajustarlo todo, el gnome no es para ti. Si todo eso te da igual, buscas simplicidad de manejo, entonces si es para ti. Va en gustos.

...

Cuarto, en genearl, para instalar una aplicación Gnome, hay mas problemas de dependencias que para una aplicación KDE, que requiere de menos librerias o paquetes adicionales.

¡Que dices! Es al revés. Yo he compilado aplicaciones para ambos entornos, y me ha sido más fácil satisfacer las necesidades del gnome que las del kde.

Parece que nuca compilaste una aplicacion gtk para kde! Salu2 -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org

El jue, 11-12-2008 a las 17:32 +0100, Carlos E. R. escribió:

A lo mejor por eso el Gnome era capaz de funcionar en una máquina de 32 megas de hace 10 años, y el kde se arrastraba - todo el mundo sabe que programar en C++ es una desperdicio de recursos :-P

Y dale, lo del C++ NO es verdad.

-- Saludos Lluis

El día 11 de diciembre de 2008 17:46, Carlos E. R. escribió:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

El 2008-12-11 a las 19:54 +0100, lluis escribió:

...

El jue, 11-12-2008 a las 17:32 +0100, Carlos E. R. escribió:

...

A lo mejor por eso el Gnome era capaz de funcionar en una máquina de 32 megas de hace 10 años, y el kde se arrastraba - todo el mundo sabe que programar en C++ es una desperdicio de recursos :-P

Y dale, lo del C++ NO es verdad.

X'-)

Que si, que es verdad. Si se pasa Rafa por aquí preguntale: la gente del compilador GCC ha tenido que meter tremedos cambios y optimizaciones en el compilador porque el código que generaba para C++ era ineficiente y estaba perjudicando grandemente el desarrollo del KDE. A partir de esos cambios el rendimiento del KDE ha mejorado considerablemente.

Tu lo has dicho. La clave del problema, es que en los comienzos de KDE, el GCC, era un pésimo compilador para C++, por eso generaba codigo ineficiente.

Y eso se notaba empíricamente: en mi antiguo ordenador, que sólo tenía 32 megas, el KDE era insufriblemente lento, mientras que el Gnome, aun siendo lento también, era más rápido, una velocidad aceptable (en realidad en esa máquina no uso ninguno de los dos, sino el fvwm). El motivo principal de la diferencia de velocidad era la huella de memoria: el KDE usaba bastante más, necesitando más swap.

Actualmente, como dijiste que usas KDE y Gnome, cual es mas pesado y tarda mas en cargar? Salu2 -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org

El día 11 de diciembre de 2008 16:54, lluis escribió:

El jue, 11-12-2008 a las 17:32 +0100, Carlos E. R. escribió:

...

A lo mejor por eso el Gnome era capaz de funcionar en una máquina de 32 megas de hace 10 años, y el kde se arrastraba - todo el mundo sabe que programar en C++ es una desperdicio de recursos :-P

Y dale, lo del C++ NO es verdad.

...

Seguramente se referia a TODO EL MUNDO QUE NO SABE PROGRAMAR.: http://unthought.net/c++/c_vs_c++.html http://www.cs.utk.edu/~huangj/CS302S04/notes/c_versus_c++.html http://www.eventhelix.com/RealTimeMantra/basics/ComparingCPPAndCPerformance2... Del primer link: So, what's the deal with C++? I'm assuming that you know C already. If you do not, then this article really isn't for you. For the vast majority of problems out there, I state that C++ provides no significant downsides and a number of significant improvements. Bold? Some people seem to think so, but it's really the case. Let's start out by clearing up a few very common C++ misunderstandings: * C++ is slower than C Wrong! Many C programs are valid C++ programs as well - and such a C program should run at identical speed when translated with either the C and with the C++ compiler. * C++ specific features give overhead Wrong! The so-called overhead introduced by certain C++ specific features (such as virtual function calls or exceptions), is comparable to the overhead you yourself would introduce should you choose to go thru the pain it would be to implement a similar feature in C. * C++ is object oriented Wrong! The C++ language contains some language extentions over C, that make object oriented programming and generic programming more convenient. C++ does not force object oriented design anywhere - it merely allows for it if the programmer deems OO feasible. C allows for object oriented programming as well, C++ only makes it simpler and less error prone. So, if you believe me, we have established that "C++ is not significantly worse than C". Let's have a look at what it is that makes C++ a better C: * Stronger typing The type system in C++ is stronger than in C. This prevents many common programming errors - coupled with the next very important feature, the stronger type system even manages not to be an inconvenience. * Parameterized types The template keyword allows the programmer to write generic (type-agnostic) implementations of algorithms. Where in C, one could write a generic list implementation with an element like: struct element_t { struct element_t *next, *prev; void *element; }; C++ allows one to write something like: template <typename T> struct element_t { element_t<T> *next, *prev; T element; }; Not only does the C++ implementation prevent common programming errors (like putting an element of the wrong type on the list), it also allows better optimization by the compiler! For example, a generic sort implementation is available in both C and C++ - the C routine is defined as: void qsort(void *base, size_t nmemb, size_t size, int(*compar)(const void *, const void *)); whereas the C++ routine is defined as template void sort(RandomAccessIterator first, RandomAccessIterator last); The difference being, that for example sorting an array of integers, would, in the C case, require a function call for every single compare, whereas the C++ implementation would allow the compiler to inline the integer comparison calls, as the actual sort routine is instantiated at compile time, automatically by the compiler, with the correct types inserted in the template arguments. * A bigger standard library C++ allows the full use of the C standard library. This is very important of course, as the C standard library is an invaluable resource when writing real world programs. However, C++ includes the Standard Template Library. The STL contains a number of useful templates, like the sort routine above. It includes useful common data structures such as lists, maps, sets, etc. Like the sort routine, the other STL routines and data structures are "tailored" to the specific needs the programmer has - all the programmer has to do is fill in the types. Of course, the STL is no silver bullet - but it does provide a great help very often, when solving general problems. How often have you implemented a list in C? How often would an RB-tree have been a better solution, if only you had had the time to do it? With the STL you do not need to make such compromises - use the tree if it's a better fit, it's as easy as using the list. Ok, so I've been telling about all the good parts. Are there no downsides? Of course there is. Howver, they are shrinking day by day. Let me explain: * There are no good C++ compilers It's been like this for a long time. But you must remember, that the language was standardized in 1998 - it is a complex language, more complex than C. It has taken a long time for compilers to catch up to the standard. But as of this writing, there are good compilers available for the most widely used platforms out there; GCC in versions 3.X are generally very good, and it runs on GNU/Linux and most UNIX platforms. Intel has a good compiler for Win32 - it is also pretty good, but unfortunately it still relies on the MS STL which is sub-par. * People don't know good C++ This is not an often heard complaint, but it's something that I see a lot. C++ is a big and complex language - but it also used to be a language that was hyped a lot, especially back in the "OOP solves hunger, cures AIDS and cancer" days. The result seems to be that a lot of really poor C++ code, basically bad C with a few class statements here and there, is out there and is being used as learning material. This means, a lot of people who believe they know C++ actually write really crap code. That's too bad, and it's a problem, but I think it's unfair to blame C++ for this. So, the only two major problems with C++ are results of C++ being a young language. In time they will vanish. And for most problems out there, if you can get good programmers (or learn good C++ yourself), the problems are not really an issue today. Note, that I am not arguing that everything is rewritten in C++. There are many large projects out there which are written in C - I do not believe that it is a good idea to just "convert" them to C++. C++ allows for cleaner solutions than C does, for a great many problems. Doing a minimal conversion of a solution which is "as clean as it gets" in C, to C++, would convert "good C" code into "poor C++". That is not a change to the better! I have converted code from C to C++. But such a conversion has always ended up being a complete rewrite. From scratch. A redesign as such may not be necessary - after all, C++ does not force any new design principles down your throat, and if the original C code was well designed, there may not be a need to redo that. However, for new projects starting out today, I fail to see why anyone (who knows C++ or is willing to learn it) would use C rather than C++. Unless, of course, that one of the two problems stated earlier are important. The Challenge So, after a little back and forth on the Beowulf mailing list, where various people (myself included) argued for the pros and cons of their pet languages and other peoples (inferior of course) pet languages, I decided to put out a challenge; I presented a problem, and a small and clean solution for it, and challenged the list to come up with a better solution. The problem: Write a program that reads text from standard-input, and returns (prints) the total number of distinct words found in the text. In short, I presented a C++ solution to the problem, and challenged someone to do it in C. I even wrote: I still guarantee you two things: 1) Your code will be longer 2) Your program will be slower Hey, you gotta be bold to keep these things interesting! Initial solutions The small C++ solution The following is the solution I presented with my challenge. It is a total of 15 lines of C++. It uses the STL std::set template with an std::string as the template argument, to hold the words read from stdin. In non-C++ speak this means I use an RB-tree of strings. #include <set> #include <string> #include <iostream> int main(int argc, char **argv) { // Declare and Initialize some variables std::string word; std::setstd::string wordcount; // Read words and insert in rb-tree while (std::cin >> word) wordcount.insert(word); // Print the result std::cout << "Words: " << wordcount.size() << std::endl; return 0; } Personally, I think this is elegant. Anyone who knows C++ will be able to glance at the code and understand completely what it does, within a few tens of seconds. The code is short, and only extremely simple well-understood operations are performed on the data - it is quickly established that the code is correct. If the beholder understands the language, of course, but this is a problem with all languages. The faster C solution Of course, shortly after that post, someone replied with a faster implementation in C. I should have known that. I was happy to see, that the C implementation was indeed longer - this faster solution is 85 lines long. Note, the actual code presented here is not the exact suggestion sent to the list - I changed the printing of the result at the bottom of the code, so that the program prints out the number of distinct words - the original code was made to print out an unsorted list of word frequencies. This change only touches a few of the very last lines in the code, it touches nothing in the central parts of the program at all. Unlike my initial solution, this program uses a hash to store the distinct words. A hash can be faster than an RB-tree - a well dimensioned hash can exhibit O(1) complexity for insertions where an RB-tree exhibits O(log(n)) complexity. The change of algorithm is unfortunate for a language-performance comparison point of view - as the C implementation will exhibit different run-time performance than the C++ implementation, for reasons that are not related to the choice of language at all. However, I'm not going to bitch about it, I'm going to evaluate the suggestion and still prove my point; that C++ is a better language for solving general purpose programming problems. Let's have a look at the C code shall we; /* Copyright (C) 1999 Lucent Technologies */ /* From 'Programming Pearls' by Jon Bentley */ /* wordfreq.c -- list of words in file, with counts */ #include #include #include typedef struct node *nodeptr; typedef struct node { char *word; int count; nodeptr next; } node; #define NHASH 29989 #define MULT 31 nodeptr bin[NHASH]; unsigned int hash(char *p) { unsigned int h = 0; for ( ; *p; p++) h = MULT * h + *p; return h % NHASH; } #define NODEGROUP 1000 int nodesleft = 0; nodeptr freenode; nodeptr nmalloc() { if (nodesleft == 0) { freenode = malloc(NODEGROUP*sizeof(node)); nodesleft = NODEGROUP; } nodesleft--; return freenode++; } #define CHARGROUP 10000 int charsleft = 0; char *freechar; char *smalloc(int n) { if (charsleft < n) { freechar = malloc(n+CHARGROUP); charsleft = n+CHARGROUP; } charsleft -= n; freechar += n; return freechar - n; } void incword(char *s) { nodeptr p; int h = hash(s); for (p = bin[h]; p != NULL; p = p->next) if (strcmp(s, p->word) == 0) { (p->count)++; return; } p = nmalloc(); p->count = 1; p->word = smalloc(strlen(s)+1); strcpy(p->word, s); p->next = bin[h]; bin[h] = p; } int main() { int i; nodeptr p; char buf[16384]; unsigned total = 0; for (i = 0; i < NHASH; i++) bin[i] = NULL; while (scanf("%s", buf) != EOF) incword(buf); for (i = 0; i < NHASH; i++) for (p = bin[i]; p != NULL; p = p->next) total += p->count ? 1 : 0; printf("Words: %d\n", total); return 0; } Well there you have it. An interesting exchange happened on the list after this was posted:

As in maybe it's just me, but when I look at Jakob's code I have no idea how it works. What are these routines? What do they do? Where's the logic? Oh, I can read the comments and see the keywords and sort of guess that all sorts of dark magic is being done; I just have no idea how it does it, any more than I would if one took Jakob's code or my code or anybody's code for the same task and wrapped it up in a single routine:

And here I argue that this is where C++'s strength becomes evident. STL is _standard_ (hence its name). Thus, for a C++ programmer, Jakob's code is comprehensible in one 15second long glimpse and this programmer can immediately use (trust?) the code. With the equivalent C code from the posted link, I personally have the problem that I need at least 15 minutes to read and understand it, and even then, I can't be sure I identified all gotchas and thus I can use it without major crashes and problems. I argue that the biggest problem with C up until glib and gsl (thus very recently) was exactly the lack of high level routines collected in a ubiquous library. -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org

El día 12 de diciembre de 2008 11:00, Carlos E. R.

No estoy diciendo que sea peor. C++ es mejor. Pero un programa hecho en C++, que usa las cosas especiales que añade, es más lento por narices. Y encima, como el compilador GCC de hace unos años no generaba código bien optimizado para C++, pues teníamos una rémora considerable, que afectaba al KDE. La gente de KDE estuvo dando la lata a la gente del GCC para que corrigieran ese problema, y estuvieron trabajando mucho en eso. Supongo que ya lo habrán conseguido.

Esto lo explicó Rafa en su dia.

Ahí tenemos el kernel, que está hecho en C, no C++. Cuando cuenta la velocidad y la optimización y el control, no se usa C++. Por muy bueno que sea, cada lenguaje tiene sus usos optimos y los que no o son. Como todo lo que hacemos las personas.

Vuelvo a citar el texto original, sin recortes: For the vast majority of problems out there, I state that C++ provides no significant downsides and a number of significant improvements. Bold? Some people seem to think so, but it's really the case. Let's start out by clearing up a few very common C++ misunderstandings: * C++ is slower than C Wrong! Many C programs are valid C++ programs as well - and such a C program should run at identical speed when translated with either the C and with the C++ compiler. * C++ specific features give overhead Wrong! The so-called overhead introduced by certain C++ specific features (such as virtual function calls or exceptions), is comparable to the overhead you yourself would introduce should you choose to go thru the pain it would be to implement a similar feature in C. * C++ is object oriented Wrong! The C++ language contains some language extentions over C, that make object oriented programming and generic programming more convenient. C++ does not force object oriented design anywhere - it merely allows for it if the programmer deems OO feasible. C allows for object oriented programming as well, C++ only makes it simpler and less error prone. So, if you believe me, we have established that "C++ is not significantly worse than C". Let's have a look at what it is that makes C++ a better C: * Stronger typing The type system in C++ is stronger than in C. This prevents many common programming errors - coupled with the next very important feature, the stronger type system even manages not to be an inconvenience. * Parameterized types The template keyword allows the programmer to write generic (type-agnostic) implementations of algorithms. En los primeros años del desarrollo del kernel Linux, no había ningun compilador C++ de GNU, así que forzosamente debían hacerlo en C. Hoy en dia la situación ha cambiado en cuanto a compiladores para C++, pero por inercia, continuan con C a secas. No se si realmente los craneos del kernel Linux, se habran tomado la molestia de estudiar el C++, y hacer las evaluaciones correspondientes. Por otro lado, con la cantidad de lineas de codigo que tiene el kernel linux, ponerse a reescribirlo, sería como desarrollar un kernel nuevo desde cero. Y eso solamente lo puede hacer alguien que conozca al dedillo los fuentes del kernel, al igual que la programación en C++, y le sobre mucho tiempo. Podras ver, de acuerdo con las lineas anteriores, que el kernel Linux no está escrito en C, porque el ejecutable sea mas rapido que el escrito en C++, sino por otras razones completamente ajenas a eso. Por otro lado, pasate por alto el hecho de que algunos programas (o kernel) hechos en C, si no estan bien depurados, tienden a tener problemas con el uso de memoria, ya que no limpian la memoria una vez que ha sido usada, cosa que rara vez sucede en C++, y que ademas el codigo escrito en C++, ademas de tener la tercera parte de la cantidad de lineas, se presta menos a los errores de tipeo. Slau2 -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org

On Saturday 13 December 2008 09:17:10 Carlos E. R. wrote:

El 2008-12-13 a las 01:37 -0200, Juan Erbes escribió:

...

El día 12 de diciembre de 2008 11:00, Carlos E. R.

...

No estoy diciendo que sea peor. C++ es mejor. Pero un programa hecho en C++, que usa las cosas especiales que añade, es más lento por narices. Y encima, como el compilador GCC de hace unos años no generaba código bien optimizado para C++, pues teníamos una rémora considerable, que afectaba al KDE. La gente de KDE estuvo dando la lata a la gente del GCC para que corrigieran ese problema, y estuvieron trabajando mucho en eso. Supongo que ya lo habrán conseguido.

Esto lo explicó Rafa en su dia.

Ahí tenemos el kernel, que está hecho en C, no C++. Cuando cuenta la velocidad y la optimización y el control, no se usa C++. Por muy bueno que sea, cada lenguaje tiene sus usos optimos y los que no o son. Como todo lo que hacemos las personas.

Vuelvo a citar el texto original, sin recortes: For the vast majority of problems out there, I state that C++ provides

Y yo vuelvo a cortarlo. Quien lo queira leer, lo tiene en los correos anteriores.

...

...

So, if you believe me, we have established that "C++ is not significantly worse than C". Let's have a look at what it is that makes C++ a better C:

Pues como ya he explicado, no le creo. Que sea mejor, si. Que ha establecido esos puntos anteriores, no. Los niego.

...

En los primeros años del desarrollo del kernel Linux, no había ningun compilador C++ de GNU, así que forzosamente debían hacerlo en C. Hoy en dia la situación ha cambiado en cuanto a compiladores para C++, pero por inercia, continuan con C a secas. No se si realmente los craneos del kernel Linux, se habran tomado la molestia de estudiar el C++, y hacer las evaluaciones correspondientes.

Dudo muchísimo que digas en serio que el señor Torvalds no conozca C++.

...

Por otro lado, con la cantidad de lineas de codigo que tiene el kernel linux, ponerse a reescribirlo, sería como desarrollar un kernel nuevo desde cero. Y eso solamente lo puede hacer alguien que conozca al dedillo los fuentes del kernel, al igual que la programación en C++, y le sobre mucho tiempo.

Podras ver, de acuerdo con las lineas anteriores, que el kernel Linux no está escrito en C, porque el ejecutable sea mas rapido que el escrito en C++, sino por otras razones completamente ajenas a eso.

Está escrito en C por muchas razones, incluyendo la velocidad.

...

Por otro lado, pasate por alto el hecho de que algunos programas (o kernel) hechos en C, si no estan bien depurados, tienden a tener problemas con el uso de memoria, ya que no limpian la memoria una vez que ha sido usada, cosa que rara vez sucede en C++, y que ademas el codigo escrito en C++, ademas de tener la tercera parte de la cantidad de lineas, se presta menos a los errores de tipeo.

¿Y porqué lo voy a pasar por alto? Ya he dicho que el C++ es mejor. Simplemnte niego que sea más rápido el C++. No lo es.

Tienes la manía de cerrarte en redondo con una idea y no querer comprender que las cosas no son blancas y negras: hay matices y multitud de motivaciones.

Me puse a indagar, y encontré esto: http://www.linuxquestions.org/questions/programming-9/c-or-pure-c-for-linux- kernel-module-linux-device-driver-development.-what-to-use-353924/ Son algo claros... o al menos entiendo la mitad de lo que hablan e indican que C++ no es lo apropiado para el kernel, que C++ tiene otras ventajas, pero no lo hacen una opción a considerar para el kernel. Por favor lean todo el hilo. El termino de búsqueda fue: kernel +c++ -- Carlos A. -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org

El día 13 de diciembre de 2008 14:54, Shinji Ikari escribió:

On Saturday 13 December 2008 09:17:10 Carlos E. R. wrote:

...

El 2008-12-13 a las 01:37 -0200, Juan Erbes escribió:

...

El día 12 de diciembre de 2008 11:00, Carlos E. R.

...

No estoy diciendo que sea peor. C++ es mejor. Pero un programa hecho en C++, que usa las cosas especiales que añade, es más lento por narices. Y encima, como el compilador GCC de hace unos años no generaba código bien optimizado para C++, pues teníamos una rémora considerable, que afectaba al KDE. La gente de KDE estuvo dando la lata a la gente del GCC para que corrigieran ese problema, y estuvieron trabajando mucho en eso. Supongo que ya lo habrán conseguido.

Esto lo explicó Rafa en su dia.

Ahí tenemos el kernel, que está hecho en C, no C++. Cuando cuenta la velocidad y la optimización y el control, no se usa C++. Por muy bueno que sea, cada lenguaje tiene sus usos optimos y los que no o son. Como todo lo que hacemos las personas.

Vuelvo a citar el texto original, sin recortes: For the vast majority of problems out there, I state that C++ provides

Y yo vuelvo a cortarlo. Quien lo queira leer, lo tiene en los correos anteriores.

...

...

So, if you believe me, we have established that "C++ is not significantly worse than C". Let's have a look at what it is that makes C++ a better C:

Pues como ya he explicado, no le creo. Que sea mejor, si. Que ha establecido esos puntos anteriores, no. Los niego.

...

En los primeros años del desarrollo del kernel Linux, no había ningun compilador C++ de GNU, así que forzosamente debían hacerlo en C. Hoy en dia la situación ha cambiado en cuanto a compiladores para C++, pero por inercia, continuan con C a secas. No se si realmente los craneos del kernel Linux, se habran tomado la molestia de estudiar el C++, y hacer las evaluaciones correspondientes.

Dudo muchísimo que digas en serio que el señor Torvalds no conozca C++.

...

Por otro lado, con la cantidad de lineas de codigo que tiene el kernel linux, ponerse a reescribirlo, sería como desarrollar un kernel nuevo desde cero. Y eso solamente lo puede hacer alguien que conozca al dedillo los fuentes del kernel, al igual que la programación en C++, y le sobre mucho tiempo.

Podras ver, de acuerdo con las lineas anteriores, que el kernel Linux no está escrito en C, porque el ejecutable sea mas rapido que el escrito en C++, sino por otras razones completamente ajenas a eso.

Está escrito en C por muchas razones, incluyendo la velocidad.

...

Por otro lado, pasate por alto el hecho de que algunos programas (o kernel) hechos en C, si no estan bien depurados, tienden a tener problemas con el uso de memoria, ya que no limpian la memoria una vez que ha sido usada, cosa que rara vez sucede en C++, y que ademas el codigo escrito en C++, ademas de tener la tercera parte de la cantidad de lineas, se presta menos a los errores de tipeo.

¿Y porqué lo voy a pasar por alto? Ya he dicho que el C++ es mejor. Simplemnte niego que sea más rápido el C++. No lo es.

Tienes la manía de cerrarte en redondo con una idea y no querer comprender que las cosas no son blancas y negras: hay matices y multitud de motivaciones.

Sobre el enlace que pase: http://www.linuxquestions.org/questions/programming-9/c-or-pure-c-for-linux- kernel-module-linux-device-driver-development.-what-to-use-353924/

estoy.. intentando acabar con el post pero.... estoy mas perdido que en las clases de computación gráfica. Si es que pueden entender lo que describen allí vale. =P

De los links que posteaste, hay uno que apunta a: http://netlab.ru.is/exception/LinuxCXX.shtml C++ in the Linux Kernel We have implemented a complete kernel level run-time support for C++ in the Linux kernel. In particular our run-time support enables the full use of C++ exceptions in the Linux kernel, but notably also includes support for global constructors and destructors, and dynamic type checking. Our kernel level support is based on open source commodity components, specifically the GNU gcc/g++ compiler and its exception implementation, the C++ ABI version independent standard interface. Currently only the i386 architecture is supported. Furthermore the kernel patch has only been tested with gcc version 3.3.3, and (with the 0.0.3 release) 3.4.3 Release Notes for version 0.0.3 C++ runtime support for 2.6.6, version 0.0.3 (Last update 26 January 2005) C++ runtime support for 2.6.9, version 0.0.3 (Last update 26 January 2005) C++ runtime support for 2.6.10, version 0.0.3 (Last update 26 January 2005) Using the C++ runtime support for Linux Installing the C++ runtime support for Linux The code is installed by applying a patch to the Linux kernel and enables the full use of C++ using the GNU g++ compiler. Programmers that have used C++ in Linux kernel modules have primarily been using classes and virtual functions, but not global constructors. dynamic type checking and exceptions. Using even this small part of C++ requires each programmer to write some supporting routines. Using the rest of C++ includes porting the C++ ABI that accompanies GNU g++ to the Linux kernel, and to enable global constructors and destructors. The implementation of the C++ ABI is based on the implementation provided with the source of the GNU g++ compiler. We modified it to run in kernel space, and performed optimizations that reduces the cost of exceptions and dynamic cast considerably. Our paper contains thorough explanations of these optimizations. The cost of throwing an exception one level on a 990 MHz Intel Pentium is around 12-13 micro seconds in the plain GNU g++ implementation, which we reduced to 2.1 micro seconds by modifying the runtime library, including unwinding the stack in one phase, and caching information on exception paths. In contrast the cost of a trivial printk operation -- printk("Error\n") -- is 18 micro seconds. In addition, we modified the linux kernel module loader to handle C++ weak symbols correctly. GNU g++ associates with each class a type information object that encodes the type of the class as a mangled string and puts a pointer to this object in the virtual table for the class. GNU g++ uses weak symbols to reduce the dynamic type checking to a pointer comparison, thus avoiding the more expensive string comparison. Each time a class, containing virtual functions, is used in a source file, GNU g++ generates the virtual table, type information object and type name string as weak symbols and the user space linker ensures that there is only one copy of this object, which renders the simple pointer comparison sufficient. However, the kernel module loader, which in the 2.6 versions of the kernel is exclusively in kernel space, does not handle these weak symbols correctly and always relocates references to weak symbols to the weak definition within each object file that is being loaded. Therefore multiple type information objects may exist for the same class and pointer comparison becomes insufficient when doing dynamic type check across kernel modules. To avoid this overhead we have modified the kernel module loader to handle these weak symbols; the first time a weak symbol is encountered it is added to the symbol map, and on subsequent encounters the relocation is done to the first symbol. Paper: Exceptional Kernel: Using C++ exceptions in the Linux kernel Halldor Isak Gylfason, Gisli Hjalmtysson Submitted for publication October 2004 Abstract Full version

El 12/12/08, Carlos E. R. escribió:

No estoy diciendo que sea peor. C++ es mejor. Pero un programa hecho en C++, que usa las cosas especiales que añade, es más lento por narices. Y encima, como el compilador GCC de hace unos años no generaba código bien optimizado para C++, pues teníamos una rémora considerable, que afectaba al KDE. La gente de KDE estuvo dando la lata a la gente del GCC para que corrigieran ese problema, y estuvieron trabajando mucho en eso. Supongo que ya lo habrán conseguido.

Esto lo explicó Rafa en su dia.

Leyendo este hilo del 2001, desde luego parece que algún problema serio que tenían en KDE con el C++: Prelinking of shared libraries http://sources.redhat.com/ml/libc-alpha/2001-05/msg00025.html Y en este otro artículo, ponían en duda el uso de C++ (en lugar de C) para los sistemas integrados donde, obviamente, la gestión óptima de los recursos es importante: C vs. C++ on Embedded Devices http://www.linuxdevices.com/eljonline/issue07/4870s1.html Lo cual, cuanto menos, hace pensar sobre la idoneidad de uno u otro según para qué... no siempre lo más nuevo es lo mejor "siempre y para todo". C (1972) y C++ (1983) tienen 11 años de diferencia, así que parece lógico pensar que la misma situación que se da actualmente con las nuevas versiones de los sistemas operativos que necesitan más memoria y recursos, se dé (de forma análoga) con los lenguajes de programación: han sido desarrollados bajo circunstancias y con objetivos muy diferentes. Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org

El sáb, 13-12-2008 a las 15:22 +0100, Carlos E. R. escribió:

Efectivamente. El C++ es mejor, en general... pero todo tiene un coste. Tiene más comprobaciones, es más seguro... pero eso significa más código, mayor tamaño.

Esas comprobaciones forzosas, se efectuan en tiempo de compilación, no en tiempo de ejecución. Por lo tanto el programa puede ejecutarse igual de rapido aunque se tarde mas en compilar. Hay alguna comprobación, mas o menos opcional, como los dinamyc_cast que si se efectua en tiempo de ejecución. -- Saludos Lluis

El sáb, 13-12-2008 a las 13:37 +0100, Camaleón escribió:

Y en este otro artículo, ponían en duda el uso de C++ (en lugar de C) para los sistemas integrados donde, obviamente, la gestión óptima de los recursos es importante:

Volvemos a estar en un caso de programar bien o mal, hay que saber en los sistemas integrados, de lo que dispones y usar el lenguaje, sea el que sea, de forma adecuada. Si no se hace asi, llegaremos a la conclusion de que como el Assembler no hay nada. Y acordaros un mal programa en ensamblador puede necesitar mas recursos y funcionar peor que un programa en C++. -- Saludos Lluis

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2008-12-13 a las 20:03 +0100, Camaleón escribió:

El 13/12/08, lluis escribió:

...

Volvemos a estar en un caso de programar bien o mal, hay que saber en los sistemas integrados, de lo que dispones y usar el lenguaje, sea el que sea, de forma adecuada.

Si no se hace asi, llegaremos a la conclusion de que como el Assembler no hay nada.

Es el propio lenguaje quien "dirige" en cierta medida al programador (y a su mentalidad) y no al revés.

Por lo que que he leído de la wikipedia (tanto del C como del C++) pareciera que mientras el lenguaje C está enfocado a optimizar el rendimiento del "sistema", el C++ está enfocado a mejorar el rendimiento del "programador" (a hacerle la vida más fácil).

Correcto. O casi. El C está enfocado a obdecer ciegamente a lo que le mandan hacer, esté bien o mal. Te permite hacer cosas cercanas a la máquina que de otro modo no serían posibles.

Tengo la impresión de que, en igualdad de condiciones, el C necesita menos memoria y menos recursos que C++, sencillamente por la época en la que se desarrolló.

Bueno, no exactamente... es que usa maneras más simples, por decirlo así.

...

Y acordaros un mal programa en ensamblador puede necesitar mas recursos y funcionar peor que un programa en C++.

No me cabe la menor duda de que un buen programa en javascript puede hacer también maravillas :-P

A ver, lo que quiero decir es que cuando se mezclan sistemas híbridos (C con C++) los resultados no son siempre los esperados. Estoy casi segura de que un kernel desarrollado desde cero en C++ "puro" hoy en día sería más rápido y más eficiente que el kernel actual, desarrollado en C.

Huy, lo dudo. También hay quien hace kernels en Java: si tienes máquina de sobra, ¿que más da? Se gana tiempo al desarrollarlo, sale más barato, y posiblemente, más seguro, más fiable. Al hacerlo en C++, no en java :-)

Ojo, que yo he tocado muy poco de programación: estructuras y funciones básicas -lo que llamaban "metodología de programación"- basic, visual basic, lingo... un poco de javascipt, actionscript, php, perl y poco más O:-).

Pues en número de lenguajes has visto más que yo :-P Oficialmente: assembler, pascal, y C. En cursos posteriores o anteriores, algunas cosas más, como basic o C++. O sin cursos, como "labview". Oficialmente, no soy programador, soy electrónico. Mi idea era dedicarme a los cacharros embebidos con 68miles. - -- Saludos Carlos E.R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAklEINkACgkQtTMYHG2NR9W57wCfWlmpMdkgIQty1jXebzLtO7JM d9cAnjJm0zvn7FTmYTM6HqOSxteUTCMX =Fwxz -----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Content-ID: El 2008-12-13 a las 22:57 +0100, Camaleón escribió:

El 13/12/08, Carlos E. R. escribió:

...

Huy, lo dudo. También hay quien hace kernels en Java: si tienes máquina de sobra, ¿que más da? Se gana tiempo al desarrollarlo, sale más barato, y posiblemente, más seguro, más fiable. Al hacerlo en C++, no en java :-)

¡Shhh! Calla, hombre, que estaba intentando conciliar posturas y me lo vas a estropear >:-)

¡JUASSS! X'-)

...

Mi idea era dedicarme a los cacharros embebidos con 68miles.

¿CISC? :-?

No me lo había planteado, pero sí, es CISC (Complex Instruction Set Computing). Eso dice la wikipedia. La belleza del 68000 es que es memoria lineal y registros multipropósito, no como el 8086 que la memoria está segmentada y hay instrucciones que hay que hacer en ciertos registros (ver al final). Lógicamente no vas a hacer una lavadora con un 68000; pero por ejemplo, los vagones de metro de la linea 6 de Madrid (o sea, los de vía "ancha" o Española) llevan uno como "copiloto". Otro sitio donde se emplea es en las centrales telefónicas 5ESS: el procesador central de los módulos SM es un 68000 también (o de la familia); me sorprendió cuando me enteré, estoy hablando de un módulo que son varios armarios.

A mi me hubiera gustado aprender (bueno, "tocarlo" al menos) código máquina :-}

Es un código máquina muy agradecido. Y como hardware también es agradecido. Y no te hablo de enchufar tarjetas, sino de mirar las señales con un osciloscopio para ver porqué no funciona el puerto serie, por decirte un ejemplo. A eso es a lo que yo quisiera haberme dedicado, pero la vida da muchas vueltas... http://es.wikipedia.org/wiki/68000 Arquitectura El 68000 está basado en dos bancos de 8 registros de 32 bits. Un banco es de datos (Dn) y el otro de punteros (An). Además contiene un contador de programa de 32 bits y un registro de estado de 16 bits, Siendo su parte alta el "System Byte" y la parte baja el "User Byte". Los registros de datos (D0 a D7) se pueden usar como registros de 32 bits (.l), 16 bits (.w) y 8 bits (.b). Cualquiera de ellos puede usarse como acumulador, índice o puntero. Realizado en tecnología HMOS y posee 64 pines sin multiplexación de señales. Los registros de direcciones (punteros) son muy parecidos a los de datos, pero no pueden usarse como bytes y las operaciones con ellos no afectan al acarreo para poder efectuar cálculos con direcciones entre cálculos con datos. El registro A7 es el puntero de la pila (Stack Pointer) y está duplicado, habiendo un stack para el modo usuario y otro para el modo supervisor. Contiene dos ALUs diferentes, para operar con datos y direcciones independiente y simultáneamente. - -- Saludos Carlos E.R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAklESBcACgkQtTMYHG2NR9Wy8ACcDjj5aOGNYatNLHuAHDIg1khd PvwAoIk/oB2IP10h8qTiWoaoJ+dYCHwv =cNtr -----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2008-12-15 a las 11:29 +0100, lluis escribió:

Si te hace mucha "ilu" lo del codigo maquina, me parece que tengo por algun rincon la forma de programa y simular sobre PC para un hitachi SH2, tambien debo tener un simulador de 6809( este esta mas bien obsoleto).

Pero eso no tiene la misma gracia que ver como una plaquita que has programado tu enciende unas lamparitas en secuencia, por ejemplo. - -- Saludos Carlos E.R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAklGQ5wACgkQtTMYHG2NR9VEDACfTmkDmW7U89QKyf5i3f8OyBxR S6EAnRVOpAZxrPqrmLQG3c8y1n5NrH9k =IwB2 -----END PGP SIGNATURE-----

On Monday 15 December 2008 09:00:47 lluis wrote:

El lun, 15-12-2008 a las 12:46 +0100, Carlos E. R. escribió:

...

Pero eso no tiene la misma gracia que ver como una plaquita que has programado tu enciende unas lamparitas en secuencia, por ejemplo.

No, claro. Yo estaba hablando de cosas con coste cero.

Se pueden conseguir, a precios razonables, placas de evaluación de microprocesadores, desde muy pocas prestaciones a placas donde se puede correr un uClinux con conexion ethernet.

<http://www.renesas.com/fmwk.jsp?cnt=starterkits_evaluation_boards_mid_leve l_landing.jsp&fp=/products/tools/introductory_evaluation_tools/starterkits_e valuation_boards/>

http://microcontrollershop.com/product_info.php?products_id=803

No entiendo de esas cosas. =/ Pero si he estado leyendo algo del Arduino: http://en.wikipedia.org/wiki/Arduino Un tío (que no es mi tío) que lo usa para que su hijo no nato reporte en twitter. Parece interesante para jugar. Usa Java. -- Carlos A. PS: ¿Motorola 68k o.o? ¿los procesadores que usaba Apple antes de los PPC? -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org

El 15/12/08, lluis escribió:

Hace ya bastantes años que la mayoria de cacharros embebidos( excepto los muy pequeños y de muy alto numero de produccion) se programan en algun lenguaje de alto nivel.

Por eso ahora fallan más que antes :-P

Los 68miles hace unos 20 años ya se podian programar con un C de IAR( bastante malo y lleno de bugs, por cierto).

Si te hace mucha "ilu" lo del codigo maquina, me parece que tengo por algun rincon la forma de programa y simular sobre PC para un hitachi SH2, tambien debo tener un simulador de 6809( este esta mas bien obsoleto).

Je, no creo que me aclarara ni con el ensamblador, así que con binario menos O:-) Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org

El día 13 de diciembre de 2008 16:08, lluis escribió:

El sáb, 13-12-2008 a las 13:37 +0100, Camaleón escribió:

...

Y en este otro artículo, ponían en duda el uso de C++ (en lugar de C) para los sistemas integrados donde, obviamente, la gestión óptima de los recursos es importante:

Volvemos a estar en un caso de programar bien o mal, hay que saber en los sistemas integrados, de lo que dispones y usar el lenguaje, sea el que sea, de forma adecuada.

Si no se hace asi, llegaremos a la conclusion de que como el Assembler no hay nada.

Y acordaros un mal programa en ensamblador puede necesitar mas recursos y funcionar peor que un programa en C++. --

Ups! andube medio ocupado reparando un monitor apple vision, y me habia desconectado del hilo. Voy a reconocer, que el caso del kernel linux, quizas no sea la mejor opción reescribirlo en C++, aunque estaria programado de forma mas estructurada, pero esa estructuración le restaria libertad, cuando necesita dentro del codigo C, hacer algunas llamadas en assembler. Pero sin embargo hay kernels que se programan en C++, por ejemplo el caso de los microcontroladores AVR de Atmel, e incluso tenemos esas herramientas dentro de la distro. en el siguiente link, podran ver que uno de los archivos del paquete cross-avr-gcc-4.1.3_20070724-15.i586.rpm, cuenta con modulos C++: -rwxr-xr-x 2 root root 122640 Sep 22 01:46 /opt/cross/bin/avr-c++ -rwxr-xr-x 1 root root 122640 Sep 22 01:46 /opt/cross/bin/avr-cpp -rwxr-xr-x 2 root root 122640 Sep 22 01:46 /opt/cross/bin/avr-g++ -rwxr-xr-x 2 root root 122644 Sep 22 01:46 /opt/cross/bin/avr-gcc -rwxr-xr-x 2 root root 122644 Sep 22 01:46 /opt/cross/bin/avr-gcc-4.1.3 -rwxr-xr-x 1 root root 16312 Sep 22 01:46 /opt/cross/bin/avr-gccbug -rwxr-xr-x 1 root root 26596 Sep 22 01:46 /opt/cross/bin/avr-gcov http://www.novell.com/products/linuxpackages/opensuse/cross-avr-gcc.html Otros links: http://en.opensuse.org/Arduino http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1228866246/1#1 http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=69187 http://www.utpinux.org/index.php?option=com_content&view=article&id=170:microcontroladoresavr&catid=36:tutoriales Salu2 -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org

El 11/12/08, Juan Erbes escribió:

Curiosidad:

Porque usas Gnome, y no KDE?

¿De verdad lo quieres saber o es sólo para "meter baza"? >:-) Te diré, pues, el porqué... *** "Todo tiene su momento, y cada cosa su tiempo bajo el cielo: Su tiempo el nacer, y su tiempo el morir; su tiempo el plantar, y su tiempo el arrancar lo plantado. Su tiempo el matar, y su tiempo el sanar; su tiempo el destruir, y su tiempo el edificar. (...)" - Eclesiastés / Capítulo 3 / El Momento Oportuno *** Todo tiene su momento: hay un tiempo para KDE, y un tiempo para Gnome :-) Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org

El 11/12/08, Shinji Ikari escribió:

Hay que responder a la pregunta, pues no fue respondida.

Oh, sí fue respondida... ¿o acaso pones en duda la sabiduría del Eclesiastés? >:-)

El problema se mencionó hace lunas atrás, debido a la falta de alternativas que ofrece KDE4 (comparado con KDE 3.5), se decidió mudar a Gnome, pues las próximas versiones de openSuSE no iban a incluir KDE3.5.

Hay más, no creas... Konqueror (aplicación estrella) ya casi no lo puedo utilizar porque: a) Si activo el plugin de flash, tiene una extraña tendencia a quedarse colgado por completo, es decir, que si quiero entrar a Youtube tengo que iniciar Firefox porque lo tengo desactivado en konqui b) Hay páginas que lo matan (literalmente hablando). No sé qué le pasa a konqui pero está herido de muerte y ya me da miedo entrar con él en páginas donde se utilizan pasarelas de pago en línea por si algún javascript lo deja tieso en mitad de la transacción :-( Ojo, hablo de la versión 3.5.x Otro de los motivos es que las aplicaciones de KDE se cierran solas (mueren) o no se abren. Con kontact (aplicación estrella nº 2) me pasa demasiado a menudo... Kmail, en esta versión (y creo que en la 4.x también) tiene un soporte muy pobre del formato html. K3b ya ni lo uso porque sé que me va a destrozar el CD o DVD de turno. Y alguna cosa más habrá que se me olvida, seguro... :-)

Aunque según veo, va a ser un cambio difícil, considerando que va a pasar de un escritorio configurable a uno más simplificado (lógicamente sería cambiar de un escritorio configurable por otro simplificado, por que la nueva versión es muy simple; bueno al menos yo lo entiendo así) =P~ y actualmente está mostrando síntomas de adicción al KDE (la razón de este post).

Bueno, verás, kde no me gusta porque sea personalizable "estéticamente" (el entorno) sino porque las opciones de configuración de sus aplicaciones son muy elevadas. Estéticamente hablando, al kde que viene de serie en suse le tengo que hacer un lavado de cara para dejarlo como me gusta (le cambio todo: colores, tipos de letra, ventanas, efectos, sombras de texto en el escritorio...) y me lleva mucho tiempo :-( Algo que con el Gnome no me ha pasado: sólo he cambiado un par de cosas, porque estéticamente me resulta más atractivo, me gusta como es "de serie".

Aunque pocos años durará el cambio pues gnome también está planeando un salto. =P

Si les da a los de Gnome por poner un reloj tan grande como el del kde4 y a poner "contenedores" por el escritorio... me paso al xfce

:-)

... "Todo tiene un tiempo..." Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org