miércoles, 6 de enero de 2016

Teorias del secesionismo


Factores:

  • V: Variabilidad del voto ciudadano. Hemos visto como a raíz de las diferentes situaciones socio-económicas, aplastantes mayorías en unos comicios, dejan de ser primera fuerza política en los siguientes. Manipulación política, y de medios de comunicación, pueden artificialmente afectar a este hecho. 
  • H: Derecho a decidir hereditario. Cuando un pueblo consigue su independencia por algún resquicio o derecho constitucional que le permita a él mismo decidir su soberanía, tiene sentido que ese resquicio o derecho siga presente en el nuevo país constituido.

Escenario:

  • Imaginemos un teórico país P(rosa+amarillo+naranja):
    • Dentro del cual hay una región R)(amarillo+naranja), y dentro de ésta una subregión S(naranja).
    • Propongamos una ciudad C(naranja) dentro de la región R.


  • Asumamos que R consigue su independencia vía referéndum, por las vías comentadas en el factor H.

Problemas:

Problema de una Pseudomayoría(M):

En el caso que ese referéndum hubiera sido ganado por una estrecha mayoría(<55%), el factor V(ese <55% se haya podido convertir en un >45%), y la opción legal H, podría llevar al pueblo demandar otro referéndum de anexión al cabo de un cierto periodo de tiempo. Volviendo así a la situación inicial.

Se presenta el hecho paradójico en que si la independencia se obtiene con menos del 50% de los votos, ese periodo en el que ese demandado referéndum de reanexión resultaría ganador, podría ser muy corto o inmediato.

Problema de Localidad o de Zoom(Z):

Este problema puede darse incluso sin la presencia del problema de la pseudomayoría. 

P ha sufrido una perdida territorial dado un problema socio-político interno localizado en su región R. 

De la misma forma podemos hacer un zoom sobre R y puede que exista una región S con un similar problema socio-político. Alimentado por el antecedente de la independencia de R y con el apoyo legal del factor H, estaríamos hablando de un tercer país que obtiene su independencia(e2) o una posible reanexión(e1).

Nótese, que este zoom puede hacerse en cualquier lugar del territorio, y en cualquier nivel de ampliación. Siendo quizás zonas limítrofes un ejemplo de zonas vulnerables al problema. 

Si a éste problema(Z) se le añade el problema M, puede provocar que el problema Z sea prácticamente inevitable. Las razones son matemáticas:

Si tenemos unos resultados de referéndum en que la balanza está ligeramente inclinada hacia un lado(M). Es muy fácil que pueda darse que en una subregion S o incluso ciudad C, esta balanza este inclinada hacia el otro lado. Dando total legitimidad por H a cualquier subregion o ciudad a reclamar su independencia sobre R.


Ejemplos:

Aunque los ejemplos que se van a comentar no son comparables a España, tengo la necesidad de exponerlos para demostrar que no son problemas utópicos y que incluso han sucedido recientemente en nuestro continente. Por lo tanto, aunque los ejemplos no sean aplicables a España, si lo es la teoría expuesta arriba.

El problema de la localidad lo hemos visto presente en Yugoslavia. En su totalidad, ya que una de estas regiones, Serbia, podemos decir que sufrió una segunda fase de desmembración con la independencia de Montenegro y Kosovo.

Otro más fresco temporalmente sería la independencia de Ucrania(R) sobre la URSS(P):
  • e1: La región de Crimea(S) ha acabado reanexionandose a Rusia(heredera de la URSS).
  • e2: Las regiones de Lugansk(S) y Donetsk(S) declaran su independencia de Ucrania.
Todas las decisiones fueron basadas en un referéndum similar al expuesto en H.


Conclusiones:

En este tipo de procesos debe haber una mayoría amplia y consolidada durante un periodo de tiempo suficientemente largo. De lo contrario pueden empezar a rodar engranajes de difícil detención.

lunes, 5 de octubre de 2015

Pathguard, the ADAS appplication that started inside Haiku

Back in time it was called HAIA, it stand for Haiku for Automotive Infotainment applicationsThe intention was to build a framework using the BeAPI and app_Server to provide a comfortable playground to deploy Automotive(Graphic) Applications within Haiku. The idea was not crazy at that time, if Haiku ever would get ported to ARM platforms. Looking how QNX was turning to automotive market, I said myself, why not Haiku too? Somehow what GENIVI could stand for now, or the AGL (Automotive Grade Linux), but for Haiku.

HAIA was and is functional and I still keep that version of the Haiku code.


Unfortunately the slow down of Haiku, and the lack of hope made me move that framework to the popular OS of the moment. HAIA somehow changed its name to AAIA, got ported to Android in a couple of days and evolved since then a lot. My actual first code in Android was actually porting all this code from Haiku/C++ to Android/Java.

First version of the framework running in Android (Jan/2012):




Later on it could be seen in automotive industry that the Instrument Clusters of the cars stopped from being needles to become TFT screens, and now ADAS(Advance Driving Assistance System) is just first step in the path to reach the autonomous car. More & more complex Operating systems are inside our cars now. The framework also evolved to cope with these emerging automotive domains.

Out of that framework has born PathGuard, the project who has kept me occupied during these last 2/3 years. Available as well in Google Play, Take a look, it does not look like the first screenshot anymore.

PathGuard, tries to put together all information that the network, cloud and sensors in your Android device to provide all possible feedback to the driver. Using the camera and the increasing computer power of these devices, I believe everyone who can affoard a mobile devicem could affoard to have the protection of an ADAS system while driving.

miércoles, 30 de abril de 2014

Circle room or Square room

Ever wondered how can you get more surface wasting the same amount of bricks or material. This is a demonstration in fact with the same amount of material if you build a circle room you will have exactly a factor of 4 / П extra surface... Another thing is what you do with the space outside... and if ikea sells rounded furniture...


viernes, 18 de abril de 2014

Arch Linux suspending sleeping each 30 seconds

This was the situation for a non Linux expert after installing for first time the lightweight distribution.
The system was going unconditionally to sleep after 3 minutes after the power on, and afterwards sleeping each 30 seconds.

Google did not show anyone with this situation therefore here is the post for the next one. As not being a Linux expert I was out of clue who is triggering the action.

Hint: as in the base installation there are not so many processes so a top commands shows some useful information. Certainly yes, each time the suspend happened a new process looked get the CPU. Anyway the time between top acknowledging the process and showing it, and the system suspending was in the order of milliseconds my eyes could not see it.

Hint2: Waste cpu in a paralel process so that my eyes, or a camera could see it:
dd if=/dev/zero of=/dev/null

This would work for a single core CPU, the next item would be setting top to update as fast as possible, and the third recording it with your smartphone video camera.


Video

The process to blame was systemd-logind. It is a service inside systemd which can be configured in /etc/systemd/logind.conf check here for details.

Somehow some of the suspend/hibernate buttons of the laptop were detected as pressed. Where the system(Compaq Evo laptop) had no such keys. Therefore I recommend to look at which keys you really want to have functional and ignore the rest:


[Login]
#NAutoVTs=6
#ReserveVT=6
#KillUserProcesses=no
#KillOnlyUsers=
#KillExcludeUsers=root
#Controllers=
#ResetControllers=cpu
#InhibitDelayMaxSec=5
HandlePowerKey=poweroff
HandleSuspendKey=ignore
HandleHibernateKey=ignore
HandleLidSwitch=ignore
PowerKeyIgnoreInhibited=yes
SuspendKeyIgnoreInhibited=yes
HibernateKeyIgnoreInhibited=yes
LidSwitchIgnoreInhibited=yes
#IdleAction=ignore
 #IdleActionSec=30min 

miércoles, 11 de julio de 2012

Bluetooth Documentation

In the past I got to know that motivation comes by streams, I did not worry too much, and said to myself that it was just a matter of waiting for the next stream. The problem is that it has been near 2 years of non activity, awaiting for one of those streams to come.

Real life temptations, and the increasing responsibilities during these years, have eclipsed the free time. I always had backup plan, but the Economical situation in my country has made think about having another back-up plan, of the backup plan.
And a third reason is some property I just acquired to accomplish a life dream, which is taking all of the creativity remaining on me. It is a piece of land in the mountain, with a ruin house where I am trying to build my little own paradise. Much in the style of Frank Herbert (Dune writer), coexisting with nature and environment converting a dry and abandoned place in such little paradise. This is also explanation why this blog might change radically its topic.

Back in third quarter of 2006 after leaving yellowTAB and Germany, kind of decided to leave the BeOS scene, but then I was back 1 year later in 2007, writing a Bluetooth Stack. So it could happen again, I have been and I will keep subscribed in mail lists, follow the news, reply questions and offer all support I can. I’ll be around as I was up to now, just not likely developing.

So here is a piece of overview documentation of all I have been doing these years(dia format):


L2cap under network/protocols/l2cap:  Provides socket interface to have l2cap channels. L2CAP offers connection oriented and connectionless sockets. But bluetooth stack as this point has no interchangeability with TCP/IP, A Higher level Bluetooth profile must be implemented

HCI under  src/add-ons/kernel/bluetooth : Here we have 2 modules, one for handling global bluetooth data structures such as connection handles and L2cap channels, and frames


H2generic under src/add-ons/kernel/drivers/bluetoothThe USB driver, implementing the H2 transport

Bluetooth kit under src/kit/bluetoothC++ implementation based on JSR82 api

Bluetooth Server under src/servers/bluetoothBasically handling opened devices (local connected fisically in our system) and forwaring kit calls to them



Bluetooth Preferences under src/preferences/bluetooth
Configuration using the kit


Test applications under src/tests/kits/bluetooth


There is a small prototype component which is not here documented below  src/add-ons/bluetooth/ResetLocalDevice. Its intention was to be an add-on of bluetooth preferences, So that new HCI commands could be customized by users or external developers. I did not like at the end the idea, I did not find the flexibility I wanted.



Whoever is interested can contact me and I can share more documentation such as roadmaps and TODOs.



Thank you all

sábado, 28 de agosto de 2010

L2CAP next steps

Summer is still here, productivity in code is one of the lowest ones since I remember. Summer is to blame, hardly remember which update i need to give now.

Related my development I did a small incrusion in Caya development, implementing some features I needed to feel comfortable regarding the chat windows behaviour. BTW last release with MSN support!

But focusing on bluetooth L2CAP and its sockets interface has been a bit improved. As we said in the previous post, Haiku could initiate a pairing process and establish a communication link.

The next step was to allow Haiku act as a client to request opening a channel in the given communication link to finally interchange real user information from node to node.

There has been implemented a test application in src/test/kits/bluetooth/l2capClient. I was able to request pairing with a device (a Motorola V5), open a communication channel and send dummy data to him. the phone obviously did not understand information, and closed the communication.

Still unmature and some configuration parameters are unsupported, but if both nodes are Haiku, they could send information that each other understand. Therefore with that implemented some small applications could be implemented to have 2 haiku nodes interchanging normal user data wireless through bluetooth. This opens possibilities to implement small custom and non standard applications to:
  • Chat between 2 nodes.
  • Send flattened BMessages
  • File exchanges
between 2 Haiku nodes.

miércoles, 14 de julio de 2010

Por fin!