Amiga a1200 y su monitor 1084S

Justo este Lunes, he echado mano a un Amiga a1200 con su monitor, fuente, ratón original y una capturadora de video, a un precio baratisimo! Obviamente quien me lo vendio, en un mercadillo, no tenia ni idea de que era. El muy pobre pensaba que era un teclado y un monitor viejos sin valor alguno. En fin, así que lo pille sin pensármelo dos veces y ahora tengo en mis mano una pieza de museo en un estado de conservación impecable.

Para quienes no lo sepáis un Amiga era un ordenador personal fabricado por Commodore, a finales de los 80 y principios de los 90. Dichos ordenadores eran capaces de dejar en la estacada a un PC de la época  De hecho, los PCs no se les pusieron de tu a tu, hasta que aparecieron los 386 y las gráficas SVGA. Para que os hagáis una idea, este a1200 del 93 era capaz de capturar y hacer edición de vídeo básica !!

Bueno, así que una vez conseguido esta ganga y verificado que funciona, ahora me toca cacharear y descubrir sus entresijos.

Disco duro del Amiga, de 127MiB

En fin, después de conseguir ponerlo en ingles, ya que venia puesto en italiano y ver que el disco duro estaba casi lleno (al 90%), me toco limpiarlo un poco, aunque la verdad casi no le hacia falta. Solo tenia unas pocas manchas rojas en una parte de la rejilla.

Luego, ya por la tarde/noche, lo abrí para darle un vistazo rápido. Así descubrí que el disco duro es de 127MiB (un Seagate ST9145AG).

También observe la versión del Kickstart, siendo la 3.0. El Kickstart seria el semejante a la BIOS de un PC, pero llevaba más funciones integradas, incluyendo funciones gráficas usadas por el entorno grafico. Desde luego algo bastante curioso.

Kickstart 3.0

Luego, vi unas ranuras de expansión de RAM, que creí que eran del diseño original de la maquina. Pues resulta ser que realmente es una tarjeta de expansión del a1200, que le añade un reloj con batería, dos ranuras para expandir la RAM hasta 8 MiB, y la posibilidad de añadirle un coprocesador matemático. Dicha tarjeta de expansión se une a la placa principal por un bus llamado Zorro II, y que normalmente es accesible por debajo de la maquina vía una trampilla de acceso.
Lo más curioso de esta placa de expansión, es que por un casual tengo un modulo de 4Mib FPG 70ns SIMM de 72 pines que le debería de valer y por lo tanto me permitiría ampliar el Amiga a 8Mib de RAM, lo cual es una ganancia muy buena para este ordenador.

Tarjeta de expansión DKB 1202

Trampilla de acceso para el bus de expansión

Bien ! Si eres un usuario de una gráfica ATI y por alguna razón necesitas usar el driver propietario (en mi caso, tener bajo consumo en el portátil), entonces habrás tenido que lidiar con el fglrx y catalyst de ATI. Resulta que si intentáis usarlo con varias pantallas normalmente va a tratar de forzaros a tener la pantalla clonada, en vez de poder colocarla a un lado, encima, etc… La razón es que al parecer fglrx cuando se instala en Ubuntu  & cia, configura las X con un escritorio virtual apenas más grande que la máxima resolución de la pantalla, lo cual hace imposible colocar la segunda pantalla a un lado de la principal.

La solución, es editar el fichero /etc/X11/xorg.conf y buscar la linea “Virtual  X Y“, para cambiar los valores de X e Y por unos que os permitan colocar la pantalla de forma contigua verticalmente o lateralmente, en mi caso uso los valores de 2560 y 2048. Encontrar dicha linea no tiene dificultad ya que en el xorg.conf de Ubuntu y derivadas, suele ser 4 lineas.

Los valores de X e Y deben ser tales que os permitan tener la resolución máxima de ambas pantallas, de forma contigua. Por ejemplo, tengamos dos monitores, uno de 1680×1050 y otro de 1280×720 . Si queréis poder poner la imagen de uno al lado de otro (lo típico), entonces X >= 1680+1280 = 2930 e Y >= 1050. Si queréis poder poner la imagen de uno encima de la del otro (muy útil para portátiles), entonces X >= 1680 e Y >= 1050 +720 = 1770 . Sencillo¿ no ?

Fuente : Ask Ubuntu

Últimamente he estado “experimentando” con GTK+2 en el lenguaje D, gracias a GtkD (bindings de GTK para D) y decidí probar hasta que punto era problemático que el programa fuese multi-plataforma. La verdad ,es que por la parte del código no he tenido problemas, por el momento. Lo único complicado fue establecer el environment para compilar y prepararme, inicialmente, unos scripts BAT para hacerlo, aunque actualmente lo he pasado a CMake para poder automatizar otras tareas.

Así que si más preámbulos, resumiré que he hecho para conseguir que pueda compilar programas que usan GTK en Windows.

1. Instalar MinGW. También es posible instalar la suite TDM-GCC que incluye MinGW y gcc de forma fácil de instalar, y es lo que hice yo.
2. Descargar GTK+ All-on-in-bundle y descomprimirlo en un directorio a tu elección (c:\gtk por ejemplo)
3. Añadir estas variables al entorno de windows (en W7-Vista: Panel de control->Sistema->Confg. Avanzada del sistema, variables de entorno ) :
1. GTK_BASEPATH = “Directorio donde has descomprimido gtk” (en nuestro ejemplo c:\gtk )
2. PKG_CONFIG = “Mismo Dir que antes“\lib\pkgconfig ( c:\gtk\lib\pkgconfig )
3. PATH = Añadir “Mismo Dir que antes“\bin ( c:\gtk\bin )

Y partir de aquí ya depende de que lenguaje estés usando, etc… pero ya dispones de un make (mingw32-make), pkg-config , las librerías y los includes de GTK+2 en Windows. Si lo hicisteis por la via de TDM-GCC, y el proyecto esta en C, ya deberías de poder directamente compilar.

Y siguiendo con que tengo que estar enfermo, ayer en un rato hice un emulador sencillote del DCPU-16.
Es muy simplón y funciona step by step, ejecutando instrucciones cada vez que se presiona el enter.
Esta disponible en GitHub.

Tengo planeado darle un pequeño interprete para poder controlar la información en pantalla y poder visualizar trozos de la memoria ram de la CPU. Además de cambiar como se presenta la información para que sea más útil.

Actualmente creo que ya es una herramienta que puede ser util.

Creo que solo han pasado dos días desde que Noth anuncio 0x10c, su nuevo juego de ciencia ficción en que habrá que programar un microordenador con una CPU de 16 bits al mas puro estilo ochentero. La gracia es que en ese breve lapso de tiempo, ya han aparecido, ensambladores, compiladores, desensambladores, emuladores y hasta una IDE!

Yo por mi parte, hice mi propia especificación de una CPU basada en la original de Notch con un diseño RISC, a la cual la llamo RDCPU-16

RISC DCPU-16 variant

* Work with 16 bit unsigned words, but have basic 16 bit signed two complement arithmetic (not MUL / DIV / MOD for signed integers)

* 0×10000 word of RAM

* 11 general 16 bit registers (A, B, C, D, E, F, X, Y, Z, I, J)
* program counter (PC)
* base pointer (BP)
* stack pointer (SP)
* overflow (O)

In this document, anything within [brackets] is shorthand for “the value of the RAM at the location of the value inside the brackets”.
For example, SP means stack pointer, but [SP] means the value of the RAM at the location the stack pointer is pointing at.
Access to RAM memory for data are only by RAM I/O instructions.
Instructions are from 1 to 3 words of long and can handle a max of 1024 + 64 different instructions
Whenever the CPU needs to read a word, it reads [PC], then increases PC by one. Shorthand for this is [PC++].
In some cases, the CPU will modify a value before reading it, in this case the shorthand is [++PC].

General Format of Instructions:
bbbbbb aaaa oooooo

Where aaaa: (destination)
0×0 – 0xB : Registros (A,B,… Z, I ,J)
0xC : SP
0xD : BP
0xE : PC
0xF : O

Where bbbbbb: (source)
0×00 – 0x0B : Registros (A,B,… Z, I ,J)
0x0C : SP
0x0D : BP
0x0E : PC
0x0F : O
0×10 : next word is a 16 bit literal
0×11 – 0x3f : Literal value -1, 0×00-0x2D

Where oooooo are the basic OpCodes

Special opcodes:
0×00: non-basic instruction – see below
0x3F: JSR a – pushes the address of the next instruction to the stack, then sets PC to a (like STORE SP–, PC+1; SET PC, a)
0x3E: NOP – Not Operation (do nothing)
0x3D: SWP a, b – Swap two register values

Math OpCodes:
0×01: SET a, b – sets a to b
0×02: ADD a, b – sets a to a+b, sets O to 0×0001 if there’s an overflow, 0×0 otherwise
0×03: SUB a, b – sets a to a-b, sets O to 0xffff if there’s an underflow, 0×0 otherwise
0×04: MUL a, b – sets a to a*b, sets O to ((a*b)>>16)&0xffff
0×05: DIV a, b – sets a to a/b, sets O to ((a<<16)/b)&0xffff. if b==0, sets a and O to 0 instead.
0×06: MOD a, b – sets a to a%b. if b==0, sets a to 0 instead.
0×11: NEG a, b – sets a to -b (!b +1 & 0xffff)

Logical OpCodes
0×07: SHL a, b – sets a to a<<b, sets O to ((a<<b)>>16)&0xffff
0×08: SHR a, b – sets a to a>>b, sets O to ((a<<16)>>b)&0xffff
0×09: AND a, b – sets a to a&b
0x0a: BOR a, b – sets a to a|b
0x0b: XOR a, b – sets a to a^b
0×10: NOT a, b – sets a to !b

Branch/Jump OpCodes
0x0c: IFE a, b – performs next instruction only if a==b
0x0d: IFN a, b – performs next instruction only if a!=b
0x0e: IFG a, b – performs next instruction only if a>b (unsigned)
0x0f: IFB a, b – performs next instruction only if (a&b)!=0
0×12: IFSG a, b – performs next instruction only if a>b (signed two complement)

RAM OpCodes :
0x3B: READ a, b – Read the address in b and stores his value in a
0x3C: WRT b, a – Get the value of a and write in the address b

From 0×12 to 1x3A OpCodes, are reserver for future instructions (28 OpCodes)

Non-basic OpCodes always have their lower six bits unset.
In additon the next word uses this structure:
oooooo oooo 000000
That allow to use 10 bits OpCodes (1024 extra OpCodes!!)
This extra OpCodes are reserver for future instructions

In the case that bbbbb was 0×10, then the 16 bit literal is the next word to the non-basic OpCode.

* SET, AND, BOR, XOR, NOT, ADD, SUB, SHR, SHL take 1 cycle, plus the cost of b
* MUL take 2 cycles, plus the cost of b
* NEG, DIV and MOD take 3 cycles, plus the cost of  b
* IFE, IFN, IFG, IFB, IFSG take 2 cycles, plus the cost of  b, plus 1 if the test fails
* JSR takes 3 cycles.
* READ and WRT takes 2 cyles to perform the operation, plus the cost of b.

The FAQ are nearly equal that DCPU-16 v1.1
Except for ….

Change SET [0x1000], 0×20 for:
SET I, 0×20
WRT 0×1000, I

Change SUB A, [0x1000] for :
READ I, 0×1000
SUB A, I

Change :loop SET [0x2000+I], [A] for :
ADD I, 0×2000
loop:  READ J, A
WRITE I, J

Conventions about the use of the registers:
BP It’s Base Pointer, used to store SP when a subroutine needs to read parameters and use local vars in stack.
I and J are used mainly like auxiliary registers to work with the RAM (set a literal value to be writes to RAM, etc…)

Bueno, despues de debanarme los sesos día y medio con este error :

Bien… despues de indagar, encontre como solucionarlo en StackOverflow. Segun pude entender, hay un conflicto en Glashfish, con uno de sus modelos. Desisntalando dicho modulo tanto en la maquina que ofrece el webservice, como la maquina cliente del webservice, se soluciona el toston :

/opt/glassfish3/bin$ sudo ./pkg uninstall sun-javaee-engine
$ asadmin stop-domain
$ asadmin start-domain

Y ya tira asi…

Fuente :

http://stackoverflow.com/questions/4935226/deploying-war-with-cxf-in-glassfish-v3

Bueno, últimamente me ha dado por enjaular un servidor web que tenemos en Antares, y me topado con algunas cosas que los how-to’s que hay por ahí no comentan.

Enjaular (chrootear) el servidor web, sirve para que si de alguna forma alguien rompe / hackea el servidor web, no pueda acceder al resto del servidor. Se queda encerrado dentro de lo que es el servidor web. Para ello se ejecuta el servidor web dentro de una estructura de directorios aparte y sin capacidad de ver el resto del entorno del servidor.

Obviamente, no recomiendo seguir este proceso si solo necesitas el servidor web para hacer chorradas / pruebas. Esto es más si va a dejar un servidor web medio serio y la maquina tiene algún otro servicio aparte de la web que no quieras que te tiren.

Paso 1: Instalar lighttpd y php5

Habiendo logeado en la maquina y habiendo ejecutdo su root para entrar en modo superusuario, hay que instalar los paquetes lighttpd php5 php5-cgi php5-cli :

# apt-get install lighttpd php5-cgi php5-cli 

Nota: Si necesitas otros módulos php como php-gd, php-mysql, php-psql , etc… Se instalan igual

Paso 2:Preparar el sistema de ficheros

Creamos un directorio llamado /webroot:

# mkdir /webroot

Creamos un subdirectoio tmp :

# mkdir /webroot/tmp/
# chmod 1777 /webroot/tmp/

Creamos un directorio /etc para almacenar los ficheros de configuración necesarios:

# mkdir /webroot/etc

Crear un directorio de logs para lighttpd:

# mkdir -p /webroot/var/log/lighttpd
# chown www-data:www-data /webroot/var/log/lighttpd

Crear el directorio de cahce para lighttpd:

# mkdir -p /webroot/var/cache/lighttpd/compress/
# chown www-data:www-data /webroot/var/cache/lighttpd/compress/


Crear un directorio home para lighttpd:
# mkdir -p /webroot/home/lighttpd
# chown www-data:www-data /webroot/home/lighttpd
# chmod 0700 /webroot/home/lighttpd
# ls -dl /webroot/home/lighttpd
Debería de salir algo como t:

drwx------  2 www-data www-data 4096 Oct  5 23:15 /webroot/home/lighttpd

Este script (l2chroot) es útil para copiar las librerías compartidas del sistema a la jaula:

# wget http://www.cyberciti.biz/files/lighttpd/l2chroot.txt
# mv l2chroot.txt l2chroot
# cp l2chroot /bin # chmod +x /bin/l2chroot

Paso 3: Enjaulando PHP

Ahora toca copiar los ejecutables de PHP, extensiones y los ficheros que necestian (php-gd, php-psql, etc…) al directorio /webroot :

# mkdir -p /webroot/usr/bin
# cp /usr/bin/php5-cgi /webroot/usr/bin/
# cp /usr/bin/php5 /webroot/usr/bin/

Copiamos /etc/php5/cgi/php.ini al directorio /webroot/etc/  :

# cd /webroot/etc/
# cp -avr /etc/php5 .

Ahora copiamos otros ficheros de configuración a la jaula:

# cp /etc/hosts /webroot/etc/
# cp /etc/nsswitch.conf /webroot/etc/
# cp /etc/resolv.conf /webroot/etc/
# cp /etc/services /webroot/etc/
# cp /etc/localtime /webroot/etc/

Copiamos las librerías compartidas de PHP con el script de antes :
# /bin/l2chroot /usr/bin/php5
# /bin/l2chroot /usr/bin/php5-cgi

Ahora tenemos todas las librerias compartidas necesarias para PHP en el directorio de la jaula. Podemos verificar esto usando el comando ls. Peero aun así, es necesario copiar otro fichero mas de forma manual  – /lib/ld-linux.so.2:
# cp /lib/ld-linux.so.2 /webroot/lib

Paso 4: Metiendo las extensiones de PHP en la jaula

Para ver los ficheros que contiene una extensión, usamos dpkg para listar los ficheros del paquete que los instalo.
Copy php mysql extension from /usr/lib/php4/20050606 directory, use following command to determine exact location of mysql.so file:

# dpkg -L php5-gd
/.
/etc
/etc/php5
/etc/php5/conf.d
/etc/php5/conf.d/gd.ini
/usr
/usr/lib
/usr/lib/php5
/usr/lib/php5/20090626+lfs
/usr/lib/php5/20090626+lfs/gd.so
/usr/share
/usr/share/doc
/usr/share/doc/php5-gd

Copiamos los ficheros *.so de las extensiones de /usr/lib/php5/un_numero/loquesea.so a /webroot/usr/lib/php5/el_mismo_numero/loquesea.so y ficheros relacionasdo con el script l2chroot:

# mkdir -p /webroot/usr/lib/php5/20090626+lfs
# cp /usr/lib/php5/20090626+lfs/gd.so /webroot/usr/lib/php5/20090626+lfs/
# /bin/l2chroot /usr/lib/php5/20090626+lfs/gd.so

Repetimos el proceso con todas los módulos de PHP que queramos.

Paso 5: Configurar lighttpd para que se ejecute en la jaula

Primeros nos aseguramos que el modulo fastcgi este funcionando con:

# lighty-enable-mod fastcgi

Mostrando:

Available modules: auth cgi cml fastcgi proxy simple-vhost ssi ssl trigger-b4-dl userdir
Already enabled modules:
Enabling fastcgi: ok
Run /etc/init.d/lighttpd force-reload to enable changes

Configuramos lighttpd editando /etc/lighttpd/lighttpd.conf file:
# vim /etc/lighttpd/lighttpd.conf

The most importat part is server.chroot directive. Open config file:
# vim /etc/lighttpd/lighttpd.conf
Descomentamos / editamos la linea con server.chroot :
server.chroot = "/webroot"

Y además descomentamos o editamos la linea con server-document-root a :
server.document-root       = "/home/lighttpd"

Con la directiva server.chroot , hacemos que ningún usuario (exceptuando el root claro) ejecutando lighttpd dentro de webroot, pueda acceder a directorios fuera, ergo, efectivamente enjaulando el servidor web y el php.

Finalmente editamos un script del sistema para que lanze el modulo fastcgi correctamente. Editamos el fichero /etc/lighttpd/conf-enabled/10-fastcgi.conf y añadimos estas lineas  :

## Start an FastCGI server for php5 (needs the php5-cgi package)
fastcgi.server    = ( ".php" =>
((
"bin-path" => "/usr/bin/php5-cgi",
"socket" => "/tmp/php.socket",
"max-procs" => 2,
"idle-timeout" => 20,
"bin-environment" => (
"PHP_FCGI_CHILDREN" => "4",
"PHP_FCGI_MAX_REQUESTS" => "10000"
),
"bin-copy-environment" => (
"PATH", "SHELL", "USER"
),
"broken-scriptfilename" => "enable"
))
)

Ahora para iniciar el servidor web hacemos :

# /etc/init.d/lighttpd start   (o restart si ya estaba funcionando previamente)

Finalmente para testear que todo va bien, dentro de /webroot/home/lighttpd/, creamos un fichero llamado test.php y copiamos dentro :

<?php
phpinfo();
?>

Ahora desde el navegador, accedemos a nuestra dirección y si todo va bien, deberíamos de tener una típica pagina de información sobre la configuración de PHP en nuestra maquina.

Si se tiene algún problema, o no funciona el servidor, se puede consultar los logs con tail /webroot/var/log/lighttpd/error.log . Si la información mostrada no es suficiente, se puede ejecutar el servidor a mano con #lighttpd -f /etc/lighttpd/lighttpd.conf -D para que muestre más información.

Fuentes :

• How-to antiguo para Debian
• How-to para Ubuntu x64

Alguna vez nos ocurre esto. Reinstalas Windoor que se ha embotado de tanta mierda acumulada, y te encuentras que el selector de arranque ha desaparecido y solo arranca en Windows. Muy tipico. Por suerte la solución es sencilla, se arranca desde un pendrive / cd-rom con alguna versión reciente de Ubuntu y se selecciona el modo de Probar Ubuntu. Una vez en el modo LIVE , abrimos una terminal y procedemos a listar las particiones del disco duro con sudo fdisk -l (si tuvieses más disco duros, se puede seleccionar añadiendo /dev/sdX)

Una vez vista la particion , la montamos con mount /dev/sdaN /mnt/ Si no nos hemos equivocado de particion dentro de la carpeta /mnt, deberia de haber un arbol de directorios que entre otras carpetas apareza una llamada /boot y dentro de eta varios ficheros y una carpeta llamada grub . Procedemos a reinstalar grub con sudo grub-install --root-directory=/mnt /dev/sda

Nos debería de salir que todo esta OK. Una vez hecho esto, desmontamos el disco duro ( sudo umount /mnt) y reiniciamos el PC. Ya volvemos a tener metido Grub para seleccionar el SO.

KDE a la unity

En primer lugar, le damos al símbolo de plasma en el panel, para entrar en el modo de configuración del panel principal. Pinchamos en “Borde de la Pantalla” y arrastramos hasta colocarlo en la parte superior. Luego se quita el Lanzador de Aplicaciones, el gestor de tareas, el botón de Acceso rápido,el paginador y el botón de mostrar escritorio (estos dos últimos a gusto del consumidor).

Ahora toca colocar el  menú global estilo Mac. Yo antes usaba XBar que por el momento solo se  puede usar con el motor QT Bespin y QTCurve (ni de coña los programas que usan GTK+), pero he decidido mandarlo a paseo y poner el  teóricamente más universal ”Barra de menu ventana“, que traducción más horrible… su nombre original en ingles es “Window MenuBar”. Según tengo entendido, debería de soportar aplicar la barra de  menús global a aplicaciones GTK+ … al menos aplicando un parche a las QT. Por desgracia yo no he visto que funcione a pelo ese detalle en Ubuntu Maverick. Lo único que hecho de menos de XBar vs MenuBar, es que  podías cambiar de  menú de aplicación con la rueda y que  podías hacerte tu menú personalizado cuando no hay aplicación abierta, aunque  últimamente ha venido dando un poco por saco al no poner el menú de algunos programas como Okular. Si lo carga, pero hay que ir con la rueda del  ratón  para que sea visible o maximizar la ventana; un bug un tanto peculiar. Con MenuBar el  menú que aparece siempre es de la ventana con el foco (incluido escritorio). Lo colocamos a la izquierda del todo.

Volviendo al tema, el  siguiente paso es instalar  el plasmoide “KWin Buttons” que permite tener los  botones de Maximizar/Restaurar, Minimizar, Cerrar y WindowMenu como  botones de plasma, pudiendose colocar en el panel. Una vez instalado, se coloca 4 instancias de plasmoide en el panel. Uno a la izquierda del todo, y los otros 3 a la derecha del MenuBar (o la XBar). Haciendo click derecho en plasmoides, se les configura para que el de la izquierda sea “Show window menu“, y los otros sean “Maximice/restore” , “Iconify” y “Close“. Ademas hay una  opción de apariencia que deja designar el icono a usar, si el del tema de escritorio/dolphin, el de tema de plasma, o uno a elección. Yo he usado el de escritorio para el  menú de aplicación y para el resto el de plasma. Adicionalmente podeis colocar un espaciador a la derecha de los 3 botones para separarlos un poco de notificador (System tray). Y para terminar con esta barra, añado a la derecha el plasma de “Bloquear/Terminar“, para poder apagar el PC rápido.

Haciendo click derecho en el escritorio, le damos a Añadir panel -> panel vacio y movemos el nuevo panel a la izquierda, ajustamos la anchura al gusto, y reajustamos su tamaño para que no tape el panel de arriba. Dandolé a “Más opciones“, le damos a “Alieación abajo” y “Ocultar automaticamente“. Ya tenemos casi logrado el comportamiento de unity en el lateral. Solo queda añadir el Lanzador de aplicaciones, un gestor de tareas como “Fancy Tasks” o “Smooth Tasks” (disponibles en los paquetes de Ubuntu Maverick y más modernos, y si no en KDE-Looks), el plasmoide de “Acceso rápido” (yo lo configuro solo par que muestre carpetas), la Palera en la parte inferior, y las aplicaciones que quieras en el panel.

Una aplicación maximizada

Reiniciamos kwin ejecutando en KRunner (Alt+F2) “kwin –replace“. Ahora cuando maximiceis una ventana se le quitara el borde, dando una utilidad inmensa al KWin Buttons y aprovechando al  máximo toda la pantalla.

Ya solo queda los detalles estéticos. Un detalle curioso es que el WindowMenu, como color del texto de los  menús, usa la misma tinta que usaría el  menú si fuese un  menú normal, y no el color que da al texto  el tema de plasma. Esto puede ser problemático si usáis un tema de plasma transparente y el fondo tiene un color que sea parecido, haciendo que todo plasma se vea bien, excepto el  menú que es casi ilegible. La solución es jugar con los temas de plasma y de colores de KDE para evitar esto. Ademas yo utilizo un tema de plasma opaco.

Como tema de plasma, es escogido “Ambience” que evidentemente imita el estilo de Ambience de Unity. Es agradable, pero por lo que he comentado antes, hay que escoger un esquema de colores para KDE a juego, oscuro. En mi caso, seleccione el tema “Oxygen Dark“, aunque otros temas como “Green-Purple-Black” o “Obsidian Coast” dan un resultado muy bueno.

Para colocar los botones de maximizar /minimizar, etc.. de la ventana en si, en “Preferencias del sistema->Apariencia del espacio de trabajo-> Decoración de ventanas” y le dais al  botón de configurar botones. Hay tenis una libertad total de colocar los botones como os de la real gana. Si estilo Windows, o Mac, o inventado.