#26
> Lo que la Agencia Tributaria no sabe es si el inmueble ha sido alquilado o no porque empresas como AirBnB no están obligadas a comunicarlo.
Que yo sepa AirBnB ingresa al propietario lo que cobra a quien se hospeda mediante transferencia bancaria, así que no debería ser muy difícil para hacienda tener un listado de la gente que ha recibido más de una determinada cantidad procedente de AirBnB.
#42 No tengo ni idea de hasta qué punto la Agencia Tributaria puede husmear en las cuentas bancarias (que si ingresos de más de 3000 euros, etc.), pero esa no es una solución porque el propietario podría pedir que le paguen en Bitcoins, a una VISA emitida en la city londinense, etc.
Yo creo que la solución es que el Estado regule y obligue a que empresas tipo de AirBnb comuniquen los datos de alquiler identificando propietarios, inmuebles y fechas para que puedan operar en España. Imagino que habrá una mezcla de anacronía legislativa, retraso burocrático y poca colaboración por parte de algún partido político que otro
#42 Airbnb te ingresa en cuenta bancaria o en tu cuenta de PayPal. Lo primero es fácil de rastrear, pero lo segundo de momento no pueden saberlo (de momento).
Otra cosa es que la gente luego saque la pasta de PayPal a su cuenta corriente y eso llame la atención, pero en principio, si PayPal y AirBnB se callan y vas utilizando el dinero de PayPal a base de hacer compras, pagar Netflix, y cosas por el estilo, no hay forma de que hacienda se entere (en #74 explico que tampoco saben quien está detrás de la vivienda).
#7 Umm, yo acabo de ver el artículo y lo que explica es otra interfaz para configurar exactamente la misma funcionalidad que KDE Connect (ya que usa el mismo protocolo), así que no veo por qué comentaas que es muy mejorado.
#8 Pruébalo y me comentas
#28 Sí, pero depende del Consejo de Europa, no de la Unión Europea: https://es.wikipedia.org/wiki/Consejo_de_Europa
#13 No era ilegar usarlos por ser considerados armas, era ilegal sacarlos de EEUU por ser considerados armas. Introducirlos en EEUU sí se podía. Por ese motivo las implementaciones de software criptográfico se hacía de forma aislada en EEUU y en el resto del mundo: algunos navegadores desarrollados en EEUU tenían dos versiones, una con SSL completo y otra con SSL de 48 bits (creo); y por ejemplo Debian tenía el software criptográfico en unos repositorios que no se copiaban en los mirrors en EEUU.
#14 No darse cuenta de que diversos inputs pueden contener comandos embebidos y no "escaparlos" es un error bastante común. Ese fue el error del desarrollador original y puedes ver la corrección aquí:
https://cgit.kde.org/plasma-workspace.git/commit/?id=f32002ce50edc3891f1fa41173132c820b917d57
Es algo parecido a un error por SQL injection o a XSS.
#7 Para que se active tienes que montar el dispositivo, no solo insertarlo. Si lo pruebas (puedes hacerlo con un simple "touch a" que no va a causar ningún daño) y aún así no pasa nada es posible que tu distri bución ya haya incorporado la corrección.
El parche se publicó el 5 de febrero; por lo que supongo que casi todas las distribuciones lo habrán incorporado ya.
Umm, tal y como está escrita es errónea. En la noticia se afirma que pueden ser infectados únicamente insertando una unidad sin necesidad de interacción del usuario. Sin embargo es necesario que el usuario abra la unidad después de insertar el disco USB.
Anuncio oficial: https://www.kde.org/info/security/advisory-20180208-2.txt
"When a vfat thumbdrive which contains `` or $() in its volume label is plugged
and mounted trough the device notifier, it's interpreted as a shell command"
#17 Así lo que estás haciendo es iniciar una sesión de dbus manualmente. Para eso sería mejor asignar la variable DBUS_SESSION_BUS_ADDRESS a una sesión DBUS que ya estuviese activa.
No tiene que ver con no poder dolphin como root. En este caso dolphin simplemente comprueba si el usuario es root y en caso afirmativo se cierra. Si puedes ejecutar dolphin como root es que tu distribución (muchas lo han hecho) considera que tal grado de prevenir problemas de seguridad es excesivo y han aplicado un parche que no realiza esa comprobación.
#9 #15 No tiene realmente que ver DBUS.
Si solo haces "su" se inicia una nueva sesión con unas nuevas variables de entorno. Si no se configura la variable de entorno DISPLAY la aplicación no sabe en qué pantalla debe mostrarse. Para poder ejecutar una aplicación X11 debe configurarse la varible de entorno DISPLAY a la pantalla en la que se desee que se ejecute la aplicación (normalmente ":0" ), y ejecutar antes como usuario "xhost +" para autorizar la ejecución de aplicaciones de otros usuarios. Las herramientas gráficas que permiten ejecutar aplicaciones gráficas como root ya lo hacen automáticamente.
#14 Relativo al enlace que comentas, ahí se habla de otro tema diferente (ejecución de dolphin como root). Los desarrolladores de dolphin decidieron impedir la ejecución de dolphin como root para prevenir que si alguien diseñaba un programa que se ejecutase y estuviese en espera hasta que detectase que se ejecutaba una aplicación como root y en ese momento empezar a mandar teclas al servidor X11 (por ejemplo esperar hasta que arranque el dolphin como root, y cuando este arrancado pulsar F4 para lanzar una consola y pulsar "rm -rf /" e INTRO).
Algunas distribuciones (como por ejemplo OpenSUSE) opinaron que esa prevención era excesiva y no aplicaron el parche.
#16 No se si tendría que ver con lo del dolphin, pero puse ese enlace porque la solución para el problema (el que yo tuve, me refiero) fué exactamente esa que pone ahí:
export $(dbus-launch) (hit the enter key) type: dolphin to open it
Esto me pasaba con varias aplicaciones, no sólo dolphin, y al añadir el export manualmente funcionaban sin problema. Eso sí, solo en consolas de root. Supongo que estará relacionado.
#17 Así lo que estás haciendo es iniciar una sesión de dbus manualmente. Para eso sería mejor asignar la variable DBUS_SESSION_BUS_ADDRESS a una sesión DBUS que ya estuviese activa.
No tiene que ver con no poder dolphin como root. En este caso dolphin simplemente comprueba si el usuario es root y en caso afirmativo se cierra. Si puedes ejecutar dolphin como root es que tu distribución (muchas lo han hecho) considera que tal grado de prevenir problemas de seguridad es excesivo y han aplicado un parche que no realiza esa comprobación.
#5 Además de eso incluye únicamente las reclamaciones tramitadas a través de una web específica.
Linus Torvalds vuelve a la carga: dice que los parches de Intel son una "absoluta y completa basura"
#52 El problema no es la prelectura de operaciones. El problema es que en esa prelectura el procesador no comprobaba que las direcciones de memoria a las que se intentaba acceder fueran direcciones de memoria a las que se pudiese acceder en el modo de ejecución (usuario, sistema). Es decir, hasta que se descubrió el problema todo el mundo (desarrolladores de SOs, de sistemas de virtualización, etc) daba por hecho que siempre y en todos los casos (incluyendo ejecución especulativa) se comprobaba que el acceso a memoria fuese correcto.
No es comparable a usar dos cifras para fechas. En el momento de usar dos cifras para fechas sabían que sería un problema en veinte años. En el momento en el que se hicieron estos procesadores que no comprobaban las direcciones de memoria, si se supiese que los procesadores estaban mal diseñados el problema sería instantáneo.
#3 No es lo mismo. En primer lugar, puedes configurar un certificado SSL en el servidor y que la información viaje cifrada entre cliente y servidor. En el caso de usar Telegram, por defecto la comunicación entre usuarios se cifra únicamente entre el cliente y el servidor Telegram; es decir, es imposible verificar para qué usa Telegram esa información.
En cualquier caso incluso aunque configurases el servidor sin cifrado seguiría sin ser lo mismo ya que aquí la noticia es que esto permite crear tu propio servidor. También existen otras alternativas para crear servidores para mensajería cifrados como Matrix, XMPP, etc; y esta herramienta sí puede considerarse similar a esas opciones, pero a Telegram no.
#1 No es lo mismo.
Telegram es un cliente de mensajería para su servidor. Es decir, con Telegram únicamente puedes comunicarte usando el servidor de Telegram.
En este caso es un módulo de nextcloud que te permite contar con un servicio de mensajería en tu servidor. Es decir, lo instalas en tu servidor y luego el cliente se conecta a tú servidor. Dudo que tenga mucho éxito entre clientes particulares porque nadie va a querer configurar un servidor para usar una herramienta de mensajería, supongo que su desarrollo se orientará a chats internos para empresas y/o entidades que quieran tener un sistema de comunicación interno.
#2 Es lo mismo. Esa información viaja por Internet y por tanto es potencialmente insegura. No importa dónde esté el servidor.
#4 No necesariamente el servidor corporativo debe ser para comunicación interna. 
#3 No es lo mismo. En primer lugar, puedes configurar un certificado SSL en el servidor y que la información viaje cifrada entre cliente y servidor. En el caso de usar Telegram, por defecto la comunicación entre usuarios se cifra únicamente entre el cliente y el servidor Telegram; es decir, es imposible verificar para qué usa Telegram esa información.
En cualquier caso incluso aunque configurases el servidor sin cifrado seguiría sin ser lo mismo ya que aquí la noticia es que esto permite crear tu propio servidor. También existen otras alternativas para crear servidores para mensajería cifrados como Matrix, XMPP, etc; y esta herramienta sí puede considerarse similar a esas opciones, pero a Telegram no.
Justo después de la Akademy-es comenzará la Akademy.
Si alguien quiere revisar el programa: https://akademy.kde.org/2017/program
#20 ¿Con qué distro tienes problemas?
La diferencia entre este portátil y un portátil genérico con una distro instalada por defecto es que en este caso los propios desarrolladores de KDE han probado y optimizado para ese dispositivo el software preinstalado.
Hoy hay fiestas de aniversario en varias ciudades, incluyendo Barcelona, Madrid, Oviedo y Santiago de Compostela.
https://community.kde.org/Promo/Events/Parties/KDE_20_Anniversary
#9 Si revisas el presupuesto del evento (disponible en http://www.kde.org/fundraisers/randameetings2014/ ), verás que la inmensa mayoría de los gastos son en desplazamiento, que no variaría mucho aunque se hiciese en otro sitio.
Los otros gastos previstos no me parecen excesivos para una reunión de 45 personas durante una semana.
Por lo que parece viendo la página del OPW, el problema no son los gastos del OPW en sí, que deberían estar cubiertos de patrocinadores, si no la falta de liquidez. Es decir, una vez los patrocinadores del OPW paguen, GNOME debería incluso tener beneficios.
Posiblemente el verdadero origen del problema venga de que parece que el año pasado GNOME Asia no consiguió los patrocinadores necesarios ( http://2013.gnome.asia/sponsor/ ).
#6 Sí, pero precisamente la mayoría de las licencias Open Source no son '...mira pero no toques...' ni '...distribuye pero no modifiques...'.
De hecho una licencia que no permitiese modificar el software no sería considerada Open Source: https://opensource.org/docs/osd
La principal diferencia entre los dos movimientos es la motivación, pero la inmensa mayoría del software libre es open source y la inmensa mayoría del software libre es open source.