Un script de Bash que “tiñe” la pantalla de tu equipo de rojo por si tienes que realizar tareas en tu equipo y mantener tu visión nocturna

Imagen: Alan Formy-Duval

Entre las personas que utilizan sistemas GNU/Linux hay apasionados a la astronomía, que se deleitan con sus equipos observando el cielo por la noche mientras contemplan los cuerpos celestes brillando en el espacio oscuro.

Esas personas utilizan aplicaciones como Kstars, Skychart u otras aplicaciones de control de telescopios en sus sitemas GNU/Linux en la oscuridad de la noche.

Pero si estás a oscuras, la luz que emite la pantalla de tu equipo, puede cegar momentáneamente al astrónomo y provocarle fatiga visual, o dañarle la vista por cambios bruscos de luz.

Para eso está este pequeño script de Bash que lo que hace es “teñir” de rojo toda la imagen gestionada por el servidor X11, es decir, no una aplicación si no toda la pantalla y todas las aplicaciones.

Con este tono, podremos consultar la aplicación en nuestro equipo, el correo o consultar internet y mantener “la visión nocturna” a la que nos habíamos acostumbrado y sin exponer a cambios bruscos de luz a nuestros ojos.

Este script para bash es una adaptación realizada por Alan Formy-Duval que ha compartido en la web opensource.com y que he subido a GitHub para que este disponible para quien quiera utilizarla y probar.

Este script es una adaptación para bash de otro script llamado Redscreen, que estaba escrito para csh. Ambos utilizan xcalib para dar ese tono rojizo a nuestra pantalla. Así que deberás instalar esta aplicación en tu sistema si quieres utilizarla

Solo funciona para sistemas GNU/Linux que utilicen X11, por lo que en sistemas que utilicen Wayland como servidor gráfico no funcionará.

En el repositorio de GitHub están las instrucciones. En definitiva, nos descargamos el script (GPL v3.0), le damos permisos, y lo ejecutamos.

wget https://raw.githubusercontent.com/victorhck/stargazing/master/stargazing
chmod +x stargazing

Tenemos varias opciones:

• ./stargazing * → Muestra las opciones que tiene el script
• ./stargazing on → Tiñe de rojo nuestra pantalla
• ./stargazing off → Vuelve a dejar todo como estaba
• ./stargazing dim → Baja el nivel de luminosidad de nuestro equipo. (por si queremos quitar el tono rojizo, pero aún así no dañar nuestra vista con un nivel alto de luz de la pantalla)
• ./stargazing inv → Invierte los colores de nuestra pantalla

Quizás si eres una persona aficionada a la astronomía, este script para tu sistema GNU/Linux te resulte de utilidad y sirva para proteger un poco más tus preciados ojos, para que puedas seguir leyendo este blog!!

Enlaces de interés

• https://opensource.com/article/20/4/linux-astronomy
• https://github.com/victorhck/stargazing

El mundo del Software Libre es dinámico, en ocasiones esto es positivo y en otras no tanto. A raiz de unas noticias acaecidas estos días tengo el placer de presentar un artículo de Rubén Gómez, Vocal de KDE España y miembro muy activo de HackLab Almería (entre otras cargos) que ha elaborado un buen texto explicativo del «affair» entre la Comnidad KDE y Qt que ha titulado «KDE Free Qt Foundation, pieza clave del futuro de Qt» en el que explica, de forma que la mayoría de los mortales lo entandamos (entre los que me incluyo) qué esta pasando entre estos dos entes del mundo del Software Libre. Quisiera remarcar que la idea del texto no es entrar en todos los detalles del tema pero si dar una pincelada para que sepamos qué está pasando. Gracias Rubén por colaborar en el blog.

KDE Free Qt Foundation, pieza clave del futuro de Qt

El pasado 8 de abril de 2020 se ha hecho público a través de la lista KDE-community que The Qt Company está planeando cambios sobre el futuro de Qt, las bibliotecas y herramientas que son la base de KDE y otros muchos proyectos.

Ya hemos visto este año como esta misma empresa ha adoptado unas nuevas políticas que, de una forma u otra iban a afectar a los proyectos que la usaban. Desarrolladores varios comentaron en sus blogs que, aunque podrían suponer ciertos inconvenientes, esto no afectaba en profundidad a proyectos como el KDEero.

Sin embargo la llegada del Coronavirus SARS-CoV-2 y la pandemia que ha ocasionado está forzando más cambios dentro de The Qt company.

Según informa Olaf Schmidt-Wischhöfer en el correo enviado a la lista KDE-community, The Qt company está pensando en lanzar distintas versiones solo con licencias comerciales y la necesidad de tener una cuenta Qt para la utilización de binarios.

KDE e.V se ha visto en la obligación de pronunciarse (artículo traducido al castellano en la página oficial de KDE España) destacando el papel de la KDE Free Qt Foundation (KFQF) como garante de los intereses no solo de la comunidad KDE sino del resto de proyectos libres que utilizan Qt como marco de trabajo.

Aunque es evidente que la posibilidad de una bifurcación (del inglés *fork*) del proyecto Qt es posible -existe un contrato vigente entre The Qt company y la KFQF que garantiza este punto-, es necesario resaltar que ninguno de los autores implicados desea tal cosa por no acarrear ningún beneficio para las partes, al revés. Y, no obstante, la Comunidad está debatiendo como prepararse para el (improbable) caso en que este peor de los escenario se cumpliera.

Es importante aclarar varios puntos clave sobre esta posibilidad de bifurcación
y lo que significaría para cada parte.

La bifurcación se podría realizar en cualquier caso, la licencia libre de Qt lo permite, pero, además, existe otro mecanismo que asegura la disponibilidad de Qt libre, si bien sujetas a condicionantes: un contrato firmado entre The Qt company y KFQF.

Este contrato obliga a The Qt company a publicar una versión libre de Qt en un  tiempo limitado a un año, si no se hace así se entiende incumplimiento de contrato y da vía libre a la KFQF a publicar, bajo licencia BSD, la última versión disponible de Qt libre. Esta publicación, evidentemente, no favorece a The Qt company, pero la publicación con un año de retraso de las versiones de Qt
(para hacer cumplir el contrato) no favorecen a la comunidad del SL. Este es el punto en discordia porque, si se realizase la bifurcación, todos los proyectos y empresas que utilizan Qt tendrían tres posibilidades: usar y colaborar con el nuevo proyecto, pagar por usar Qt o dejar de usar Qt.

La KDE Free Qt Foundation esta peleando, con Olaf y Martin Konold como representantes de la comunidad, para impedir ese escenario y hacer recapacitar a The Qt company en los pocos beneficios que le acarrearía tomar las decisiones arriba comentadas.

No son pocos los que han comentado que hay muchos otros proyectos y empresas que utilizan la versión libre de las bibliotecas Qt; empresas nada pequeñas como Autodesk o Pixar, y otras como KDAB -que ya se ha expresado a favor de la comunidad del software libre-.

Mientras Qt se mantenga libre -y actualizada-, para KDE y el resto de usuarios de Qt no tiene sentido la realización de una bifuración.

Es de suponer, y de esperar, que The Qt company va a tomar una decisión muy pensada y que, seguramente, no dé el paso de cerrar esas versiones y obligar al uso de una cuenta. Perder el apoyo de una comunidad tan enorme como KDE, además de otros muchos proyectos y, seguramente, perder a empresas como las anteriormente nombradas no es plato de buen gusto para nadie.

No obstante, es cierto que deben buscar una solución para los problemas económicos que afrontan en estos momentos (problemas que, sin duda, van a ser compartidos por muchas otras empresas) y, precisamente, la KDE Free Qt Foundation, también quiere ayudar ahí aportando ideas y caminos.

¿Estamos, entonces, ante un problema para KDE y otros proyectos libres? Si, sin duda estamos en una situación seria, bastante seria. No es un peligro de muerte de la comunidad pero, perder a The Qt company supondría la necesidad de realizar un gran esfuerzo para soportar la base sobre la que se sustenta KDE.

No es seguro, pero si muy probable, que se recibiría mucha ayuda para soportar esa base pero, aún así, no es algo que nadie desee.

Confiemos, por tanto, en la buena gestión de la KDE Free Qt Foundation y en la  buena cabeza de los dirigentes de The Qt company para conseguir encontrar la mejor solución para todas las partes involucradas. En sus manos queda.

Postdata: Un agradecimiento especial a José Millán por sus correcciones e indicaciones para el correcto enfoque de esté artículo.

Rubén Gómez, Vocal de KDE España y miembro de HackLab Almería

Sigo con el repaso de los programas de los podcast de Juan Febles. En esta ocasión me he saltado un par de ellos ya que se ha publicado el episodio número 100 de este gran Podcast «Especial Preguntas y Respuestas Podcast Linux», con lo que toca felicitar a Juan Febles por su gran labor en la promoción y difusión de los múltiples proyectos que forman el ecosistema del Software Libre.

Especial Preguntas y Respuestas Podcast Linux #100

«Bienvenido al primer episodio de Podcast Linux, tu podcast de GNU Linux.

Un podcast para acercar al usuario de a pie el mundo del sistema operativo del pingüino.

En todos los episodios tendremos estas secciones:

• Gestor de Arranque: Resumen del programa
• Núcleo Kernel: Parte central.
• Gestor de Paquetes: Analizo una aplicación Libre
• Comunidad Linux: Sección para dar a conocer linuxeros, comunidades, blogs,….
• Área de Notificaciones: Espacio para los mensajes de los oyentes.»

Este fue el texto de la introducción con la que se presentó a la sociedad Podcast Linux en su espisodio número 1, un proyecto podcastil que llegó para acercar el mundo del Software Libre al mundo general.

Con un estilo pausado pero constante, con una voz dulce y característica de las islas que habita y con una forma lúdica, respetuosa y muy sistemática, la labor de Juan Febles en Podcast Linux ha sido impresionante y ha conseguido llegar a los 100 capítulos, una gesta al alcance de pocos.

Desde aquí quisiera felicitar a Juan por el logro y desearle toda la felicidad en su vida para él y para los suyos, porque el éxito en el mundo de la promoción del Software Libre ya está logrado.

¡Muchas gracias Juan!

Como era de esperar, Juan ha publicado un episodio especial, que en sus propias palabras:

¡¡¡Muy buenas amante del Software Libre!!!
Hoy estamos de celebración. Hemos llegado al episodio 100. Para celebrar este momento realizaremos un episodio muy especial.
Ya estés en trayecto, haciendo deporte o tareas del hogar, paseando o en tu casa, te doy la bienvenida al episodio 100, Especial Preguntas y respuestas.»

No pude colaborar en la realización de este episodio, pero como siempre, os dejo el audio para que los podáis escuchar:

Yo, si puedo, estaré online a esa hora.

• Twitter: @podcastlinux
• Mastodon: @podcastlinux
• Telegram Juan Febles: @juanfebles
• Correo: podcastlinux@avpodcast.net
• Web: avpodcast.net/podcastlinux
• Blog: https://podcastlinux.com

Podcast Linux forma parte de la red de podcasting Avpodcast y esta alojado en Neodigit.net, un proveedor de confianza con instalaciones en España.

Los eventos están en un proceso de reconversión. Evidentemente no se pueden realizar de forma física, así que se estan virtualizando. Es el caso de la charla en directo «Vigilando al virus desde la privacidad ciudadana»organizada por VLCTechHub y fomentada por GNU/Linux València. ¿Te interesa? Sigue leyendo.

Charla en directo Vigilando al virus desde la privacidad ciudadana

Es evidente que estamos en un momento de crisis detonada por pandemia provocada por el virusCOVID19 que ha supuesto el fin de todos los eventos programados para el primer semestre de este 2020. No obstante, las Comunidades de Software Libre, punteras en lo que al uso de la tecnología se refiere, está buscando como seguir con sus actividades.

Es el caso de VLCTechHub, que de la mano Emma López (@hell03610), tecnóloga y una de sus fundadoras, ha organizado las charla en directo «Vigilando al virus desde la privacidad ciudadana» y que la Asociación GNU/Linux València se está preocupando en promocionar.

La motivación de esta charla nace de la siguiente idea sobre el fin del confinamiento y las medidas que se quieren implementar para que este hecho no sea el precursor de otra oleada de casos. Y es que la medida más potente que se ha puesto en marcha para poder frenar la propagación de sus efectos ha sido el confinamiento máximo, pero ya se están pensando otras medidas más tecnológicas que ayuden que el fin del confinamiento sea la salida del confinamiento.

La charla se realizaŕa eldDomingo 12 de abril, 11:30h

En palabras de sus organizadores:

[…] Para poder paliar sus efectos y retrasar las infecciones se están planteando medidas tecnológicas que ayuden a gestionar la salida del confinamiento.

«¿En que consisten estas medidas tecnológicas o apps? En todas ellas tú, yo, todos, volcaremos nuestros datos. ¿Tendremos que afrontar la disyuntiva de ceder nuestros datos y privacidad para preservar nuestra salud? ¿Cederlos a quién? ¿Con qué propósito? ¿Por cuánto tiempo? ¿Qué se está haciendo en España y en otras regiones a este respecto?

Hablaremos de tecnología, ética, derecho y Open Data. Para ello contamos con Gemma Galdon (@gemmagaldon), analista de políticas públicas especializada en la vigilancia, el impacto social, legal y ético de la tecnología, Jorge Morell (@Jorge_Morell), jurista especializado en nuevas tecnologías y Bárbara Román (@NoLegalTech) experta abogada tecnológica. Modera la charla Emma López (@hell03610), tecnóloga y fundadora de VLCTechHub.

Queremos que tú también participes en la conversación. La charla se podrá seguir en directo, desde el reproductor que aparece a continuación, y podrás lanzar preguntas a los ponentes y debatir mediante el siguiente Chat en Telegram: https://t.me/Covid19yPrivacidad y #Covid19yPrivacidad en Mastodon, Diaspora y Twitter.»

Para asistir a ella os emplazo dirigirse a la página oficial del anuncio de  GNU/Linux Valencia

SUSE has sent a proposal to the openSUSE community about bringing the code streams of both SUSE Linux Enterprise and openSUSE Leap closer together. The proposal includes SLE binaries for the community version.

Bringing the code streams closer together to provide full compatibility provides several advantages to the community going forward such as the use of higher-quality code due to the clean-up of spec-files, an improved relationship between the two distributions, easier bug reporting, less code streams to maintain, extensively tested packages and the inclusion of SLE supported architectures like s390x.

“With this change, we can make better use of our resources as one code base converge, so one build target less to consider,” expressed openSUSE board member Axel Braun in an email sent out to the community about the proposal. “Everyone who packages for Leap and for Package Hub will immediately benefit from this.”

The proposal provided a staged approach to implementing the vision. The email listed the following options: • Merge the code bases for the intersection of openSUSE Leap 15.2 and SUSE Linux Enterprise 15 SP2 as much as possible without loss of stability or functionality. (SUSE has actually started merging from Leap into SUSE Linux Enterprise.) • Create an intermediate openSUSE Leap flavor where SLE binaries are used inside (October 2020 time frame) in parallel to classic Leap 15.2. • Build openSUSE Leap 15.3 with SLE binaries included by default (assuming community agreement).

The Leap distribution already shares a significant amount of core source code with SLE. Leap 15.2 will be based on the sources from SLE 15 SP 2, but not the binaries.

The community is likely to discuss the proposal on how to bring the SLE binaries into a to new build setup for Leap and would help to identify any issues that might change processes or workflows. The intermediate project build in OBS is likely to come in May. The build should give openSUSE contributors and developers an opportunity to better understand SUSE’s proposal.

“We have an idea about the setup in build.opensuse.org,” responded Adrian Schröter from the OBS team. “I anticipate to have a first prototype of the build setup in next three weeks. We must keep in mind that this is really an entire new way to develop a distribution.”

The release team has evaluated all the packages and technical implications for integrating the additional SLE packages, so they could provides some clarity to the community on how a technical implementations might work best.

There are about a couple dozen packages that are technically difficult to implement for full compatibility with the enterprise and community distributions.

“It took quite some effort to create a plan acceptable by all involved teams,” explained Leap release manager Lubos Kocman. “Splitting the work across the upcoming two releases seemed to be accepted well at least by involved parties so far. The idea of re-using should generally lower the effort on the Leap side. However, it comes with the price of increased complexity to bring all (the) pieces together.”

Feedback and technical discussions are an important part of any open-source project. The new intermediate project build will introduce the community to the sources and help with the handling of various code parts that are needed to implement schedulers, publishing and other elements of releases should the proposal be accepted by the community.

The release engineering team is interested in feedback from contributors and users once the intermediate project build becomes available.

Feedback is an important part of this process as the project looks to gain more SLE source code, Kocman emphasized.

A road map for the prototype build an proposed release would become available at https://en.opensuse.org/openSUSE:Roadmap.

Frequently Asked Questions about this topic are available at https://en.opensuse.org/Portal:Leap/FAQ/ClosingTheLeapGap.

Me congratula anunciar que la recién creada Asociación GNU/Linux Valencia ofrece servidor Jitsi libre y gratuito para todas aquellas personas que lo necesiten. Una gran iniciativa en estos tiempos en los que las necesidades de comunicación a distancia se han multiplicado por 10… o más.

La Asociación GNU/Linux Valencia ofrece servidor Jitsi libre y gratuito

En estos días de confinamiento y clases virtuales, estoy buscando soluciones al problema de comunicarme con mis alumnos de forma segura y nada intrusiva.

Como no podías ser de otra forma, la solución principal ha sido Jitsi.org, la cual funcionaba bien pero tenía algunos problemas de estabilidad. Evidentemente esas dificultades las achacaba al gran número de usuarios que estarían utilizando este servicio en estos días.

Es por ello que me congratula que algunas asociaciones estén tomando la iniciativa y que aprovechando las características de Jitsi empiecen a ofrecer sus servicios en otros servidores.

Es el caso de la Asociación GNU/Linux Valencia que ha anunciado lo siguiente:

«Desde la Asociación, queremos comunicaros que hemos decidido contratar un nuevo VPS en el que instalar varios algunos servicios que nos ayuden en estos tiempos de confinamiento.

De momento ofrecemos el servicio de videoconferencia Jitsi para descargar la saturación de los servidores públicos existentes. Por todo ello, hemos considerado un ejercicio de responsabilidad, ofrecer esta posibilidad a todo el mundo.

Las características técnicas del servidor son:

• 4 Cores
• 8 Gb de Ram
• 200 Mbits/seg
• Disco SSD

Todo montado sobre Debian 10

El enlace a nuestro servicio, es:

https://jitsi.gnulinuxvalencia.org«

Debo decir que lo he probado de forma intensiva, durante unas horas y con bastantes alumnos, y funciona muy bien. Os animo a utilizarlo con moderación ya que el objetivo es cubrir necesidades.

Aprovecho la ocasión para animaros a asociaros a esta Asociación ya que para realizar este tipo de proyectos se necesitan recursos técnicos, ideas y gente que trabaje en bien de la Comunidad.

Y por supuesto, unos recursos económicos que entre muchos es poco. De hecho, la cuota de inscripción anual es de 20€ para personas físicas, y 40€ para empresas o personas jurídicas, y ambas garantizan la promoción de forma más eficiente el Software Libre y ayudarán a los gastos económicos inherentes a cualquier asociación (sí, aún siendo sin ánimo de lucro las asociaciones tienen gastos).

Yo ya lo he hecho, y estoy esperando que me quieran como miembro. Ya os cuento.

Bagaimana kalau mau belajar pemasangan shinobi namun tidak memiliki IP Cam? ada caranya kah?

Ada. Pasti Ada

Salah satu caranya adalah dengan menggunakan IP Cam publik yang berada di beberapa wilayah/negara. Daftarnya bisa didapat di http://www.insecam.org/. Tidak semua bisa digunakan, namun tentu saja ada yang bisa. Saya sendiri menemukan satu yang sukses digunakan. Tahapannya kurang lebih seperti ini:

1. Cari salah satu kamera. Saya menemukan yang berada di Jepang. http://www.insecam.org/en/view/534370/.
2. Ambil IP Addressnya, investigasi url-urlnya dengan iSpy agar bisa mendapat informasi lebih detil.
3. Jika tanpa nomor 2, juga bisa, kebetulan kameranya support ONVIF, tinggal masukin alamat IP dan atur-atur dan coba-coba sampai pas
4. Khusus ini, saya menemukan bahwa konfigurasi yang pas itu MJPEG.

Selamat mencoba dan latihan untuk kamera yang lain. Banyak spot-spot bagus juga lho.

PS: CCTV Xiaomi Yi Max 02 1080p Outdoor Smart IP Cam ini ndak support ONVIF gak bisa diakses via rtsp jadinya.

Pemasangan Shinobi cukup mudah sekali, cukup menjalankan sebaris perintah dari root:

bash <(curl -s https://gitlab.com/Shinobi-Systems/Shinobi-Installer/raw/master/shinobi-install.sh)


Selanjutnya tinggal mengikuti langkah-langkah yang ada di layar. Saya memilih mengambil dari branch development agar mendapatkan fitur-fitur terbaru sekaligus testing. Dokumentasi pemasangan secara lengkap bisa dibaca di sini.

Berikut hal-hal utama yang perlu dilakukan setelah pemasangan:

Peramban Firefox

Gunakan peramban Firefox. Karena peramban Chrome tidak mau bila ada https dan self sign. Juka untuk streaming beberapa video cctv. Firefox bekerja lebih benar dari pada Chrome. Enggak tau kenapa.

Masuk sebagai admin dan buat user

Kita perlu memasukkan url http://alamat-ip-shinobi-server:8080/super. User / Pass bakunya adalah admin@shinobi.video / admin. Dari halaman ini kita bisa membuat user baru untuk masuk ke dashboard shinobi server. Juga untuk mengganti password akun admin tersebut.

Shinobi Dashboard

Untuk masuk ke dashboard, buka peramban dan arahkan ke http://alamat-ip-shinobi-server:8080/ lalu masukkan username/password yang sudah dibuat tadi.

Menambahkan Kamera

Klik tombol + (Add Monitor). Di sini kamera disebut monitor. Lalu tinggal isikan parameter-parameter yang sesuai kamera. Saya mencoba sendiri dan ribet. Setelah beberapa kali percobaan, baru berhasil.

Ada cara gampangnya, melalui menu pojok kiri atas – ONVIF. Lalu isikan alamat ip dan klik tombol search. Secara pintar, shinobi bisa mendeteksi kamera dalam jaringan yang kombatibel ONVIF. Jika ketemu, akan ditampilkan deskripsi kamera, bahkan bisa tahu merek/modelnya. Lalu tinggal klik tombol bergambar 2 dokumen (seperti ikon duplicate).

Selanjutnya tinggal melengkapi/mengganti isian yang ditampilkan (sama dengan jendela Add Monitor). Tinggal disesuaikan saja atau langsung Save. Secara baku, kamera akan memiliki mode View Only. Kita bisa mengatur/mengganti modenya menjadi Record.

Power Video Viewer

Digunakan untuk melihat video yang sudah tersimpan terekam. Tombol ikonnya mirip seperti tag/point pada peta.

Seingat saya, Power Video Viewer ini yang tidak bisa di Chrome.

Dah itu dulu tulisan kali ini. Tulisan berikutnya saya akan jelaskan cara optimasinya.

*Featured image diambil dari http://getwallpapers.com/collection/hidden-leaf-village-wallpaper

A build 19603 do Windows 10 permitirá acessar os arquivos da partição Linux de forma nativa e dentro do Explorador de Arquivos. Como não uso Windows, este recurso não faz diferença alguma. Mas de agora em diante, posso formatar meu pendrive em ext4 e usar em maquina de usuários Windows.

https://tecnoblog.net/333418/windows-10-integra-acesso-ao-linux-no-explorador-de-arquivos/