Social engineering scam ALERT: "Subject: Hackers have access to your device. Check details ASAP!"

Spoofed email bitcoin scam
Spoofed email bitcoin scam

Not in our name, Mofos!



Social engineering mass email campaign(s) where spoofed email addresses -- including at least one of ours -- have been used by Internet scum mofos targeting the hard earned finances of unsuspecting users. Below is one of two identical ones that we came across.

'Hello there
Let me introduce myself first - I am a professional programmer, who specializes in hacking during my free time.
This time you were unlucky to become my next victim and I have just hacked the Operating System and your device.

I have been observing you for several months.
To put things in a simple way, I have infected your device with my virus while you were visiting your favorite adult website.

I will try to explain the situation in more details, if you are not really familiar with this kind of situations.
Trojan virus grants me with full access as well as control of your device.
Hence, I can see and access anything on your screen, switch on the camera and microphone and do other stuff, while you don't even know that.

In addition, I also accessed your whole contacts list at social networks and your device too.

You may be questioning yourself - why didn't your antivirus detect any malicious software until now?

- Well, my spyware uses a special driver, which has a signature that is updated on a frequent basis, hereby your antivirus simply cannot catch it.

I have created a videoclip exposing the way you are playing with yourself on the left screen section, while the right section shows the porn video that you were watching at that point of time.
Few clicks of my mouse would be sufficient to forward this video to all your contacts list and social media friends.
You will be surprised to discover that I can even upload it to online platforms for public access.

The good news is that you can still prevent this from happening:
All you need to do is transfer $1350 (USD) of bitcoin equivalent to my BTC wallet (if you don't know how to get it done,
do some search online - there are plenty of articles describing the step-by-step process).

My bitcoin wallet is (BTC Wallet): 1NToziZKcJfyxHpwkcxbafwghGasme4NUf

Once I receive your payment, I will delete your kinky video right away, and can promise that is the last time you hear from.
You have 48 hours (2 days exactly) to complete the payment.
The read notification will be automatically sent to me, once you open this email, so the timer will start automatically from that moment.

Don't bother trying to reply my email, because it won't change anything (the sender's email address has been generated automatically and taken from internet).
Don't try to complain or report me either, because all my personal information and my bitcoin address are encrypted as part of blockchain system.
I have done my homework.

If I discover that you have tried forwarding this email to anyone, I will right away share your kinky video to public.

Let's be reasonable and don't make any stupid mistakes anymore. I have provided a clear step-by-step guide for you.
All you need to do is simply follow the steps and get rid of this uncomfortable situation once and for all.

Best regards and good luck.
'

The above is copied verbatium from two identical emails from two(2) different email address senders of which one of them is spoofed from at least one of our legit email addresses used by our organization. We did not email the above crap!

Hacking a Reiser4/Zstd (SFRN 4.0.2) -patched Build of Debian Linux 4.14.Cempohualli-Ce for AMD64.

(Use your right mouse pointer on image to show video controls and/or to Open video in new tab -- recommended)


Official 4.14.x iterations of Debian kernel packaging for Unstable (Sid) ended with 4.14.17-1. Accordingly, there is no Debian kernel packaging for current upstream release Linux 4.14.20 and much less named its Nahuatl equivalent: Cempohualli: twenty and Ce: one. Moreover, the currently available Reiser4 patch is for kernel 4.14.1+; thus I had to find a way to debianize last kernel packaging if it was to successfully wrap around pristine kernel.org's Linux 4.14.20. The latter, i.e., Cempohualli, is a beautiful number; full of symbolism for existing Nahuatl speaking real Mexicah. What follows are my annotations to carry out the somewhat involved build procedure.

First oddity. Beginning with upstream kernel 4.14.18, Debian kernel packaging for 4.14.17-1 will fail to build:

LD vmlinux.o
MODPOST vmlinux.o
arch/x86/entry/syscall_64.o: In function `x32_enable':
syscall_64.c:(.init.text+0x8): undefined reference to `system_call_fast_compare_end'
syscall_64.c:(.init.text+0xe): undefined reference to `system_call_fast_compare'
syscall_64.c:(.init.text+0x19): undefined reference to `system_call_mask_compare_end'
syscall_64.c:(.init.text+0x1f): undefined reference to `system_call_mask_compare'
syscall_64.c:(.init.text+0x33): undefined reference to `system_call_fast_compare'
syscall_64.c:(.init.text+0x3f): undefined reference to `system_call_mask_compare'
make[5]: *** [vmlinux] Error 1
[]/build/kernel/tekitl-4.14.18/linux/Makefile:998: recipe for target 'vmlinux' failed
make[4]: *** [sub-make] Error 2
Makefile:146: recipe for target 'sub-make' failed
make[3]: *** [__sub-make] Error 2
Makefile:24: recipe for target '__sub-make' failed
make[3]: Leaving directory '[]/build/kernel/tekitl-4.14.18/linux/debian/build/build_amd64_none_amd64
make[2]: *** [debian/stamps/build_amd64_none_amd64] Error 2
debian/rules.real:190: recipe for target 'debian/stamps/build_amd64_none_amd64' failed
make[2]: Leaving directory '[]/build/kernel/tekitl-4.14.18/linux'
make[1]: *** [binary-arch_amd64_none_amd64_real] Error 2
debian/rules.gen:24: recipe for target 'binary-arch_amd64_none_amd64_real' failed
make[1]: Leaving directory '[]/build/kernel/tekitl-4.14.18/linux'
make: *** [binary-arch] Error 2
debian/rules:50: recipe for target 'binary-arch' failed
dpkg-buildpackage: error: fakeroot debian/rules binary-arch gave error exit status 2

Accordingly, if I wanted to build current upstream Linux 4.14.20 'the Debian way', i.e., to generate DEBs as well as UDEBs suitable for Metztli-Reiser4 netboot Debian-Installer (d-i), I had to figure out the issue above.

After considerable effort I found there are a few updated patches we must apply from current Debian kernel packaging master 4.15.4-1 git repository to our Debian kernel packaging unstable (Sid) 4.14.17-1 for this latter to build my downloaded Linux 4.14.20 from upstream:

debian/patches/debian/gitignore.patch
debian/patches/features/x86/x86-make-x32-syscall-support-conditional.patch

Additionally, I modified 4.14.17-1 packaging
debian/patches/series

because 4.14.20 newer kernel already had these security fixes applied.

Now, assuming the Debian kernel packaging default , i.e., to build the real-time (RT) kernel and headers, we get second oddity.

Although the first set of patches for the Debian 'vanilla' kernel applied smoothly, if the developer desired to build the real-time (RT) kernel and headers to subsequently patch all with reiser4 -- which I did -- I had to implement another small hack to fix the following issue:

Applying patch features/all/rt/preempt-lazy-support.patch
Applying patch features/all/rt/ftrace-Fix-trace-header-alignment.patch
Applying patch features/all/rt/x86-preempt-lazy.patch
1 out of 5 hunks FAILED
Patch features/all/rt/x86-preempt-lazy.patch does not apply (enforce with -f)
debian/rules.real:145: recipe for target 'debian/stamps/source_rt' failed
make[2]: *** [debian/stamps/source_rt] Error 1
make[2]: Leaving directory '/[]/build/kernel/nahui.matlactetl_onnahui.cempohualli/linux'
debian/rules.gen:989: recipe for target 'source_rt_real' failed
make[1]: *** [source_rt_real] Error 2
make[1]: Leaving directory '/[]/build/kernel/nahui.matlactetl_onnahui.cempohualli/linux'
debian/rules:26: recipe for target 'source' failed
make: *** [source] Error 2

Evidently debian/patches/features/all/rt/x86-preempt-lazy.patch applied by quilt with fuzz=0 fails at arch/x86/include/asm/thread_info.h since the latter has an extra line of code in the Linux 4.14.20 source tree:
u32 status; /* thread synchronous flags */

which quilt attempted to patch thread_info.h to be subsequently copied over into RT kernel build directory:
debian/build/source_rt/arch/x86/include/asm/thread_info.h

thus I modified slightly debian/patches/features/all/rt/x86-preempt-lazy.patch 1 so it could apply after the above referenced line of code.

It worked...

Otherwise, if you do not want to build the real-time (RT) kernel and headers, edit with a text editor (like xvi &#59;)
xvi debian/config/defines

and locate the lines:

[featureset-rt_base]
enabled: true

and change 'true' text string to false, i.e.,

[featureset-rt_base]
enabled: false

save your changes and close debian/config/defines

In summary. I used last 'official' Debian kernel packaging 4.14.17-1 for Unstable (Sid) as base. I then applied the above operations plus other reiser4 hacks for Stretch elaborated in previous post(s); thus generating a Metztli Reiser4 Debian kernel packaging for 4.14.Cempohualli...er, 20, suitable to build a stretch-backports kernel and which resulting source code I subsequently uploaded to Github.

Hacking a Reiser4/Zstd (SFRN 4.0.2) -patched Build of Debian Linux 4.14.Cempohualli-Ce for AMD64.
Real Mexicah used a base Cempohualli, i.e., twenty, for their number theory and cherished the expressiveness, non-linearity, of their language: Nahuatl. Those characteristics enhanced their mathematical acumen to apprehend, appreciate, and imitate, nature and Nehnencacitlalli ['the cosmos']. In stark contrast, pseudo-'Mexicans' from 1821 onward, i.e., descendants of Spanish scum invaders who -- like their mother country Spain -- lag several centuries behind in science and technology[1], only have tainted their colonized masses with infinite ignorance.

[1] Kant.

Building Reiser4/Zstd (SFRN 4.0.2) stretch-backports Linux 4.14.Cempohualli-Ce for AMD64

Assuming a proper development environment to build our kernel 'the Debian way' as elaborated a priori in other post(s), we can build upstream Linux kernel 4.14.20, thus:

mkdir --verbose nahui.matlactetl_onnahui.cempohualli
...er, well that's Nahuatl for 4.14.20 -- which you could name your working directory. I will just make a symbolic link:

ln -s nahui.matlactetl_onnahui.cempohualli 4.14.20

cd nahui.matlactetl_onnahui.cempohualli

Download Debian kernel packaging hacked for Linux 4.14.20 from GitHub:
git clone https://github.com/Metztli/reiser4-debian-kernel-packaging-4.14.20.git linux

(Do something while it downloads as it approaches 1Gb of data)

After the cloning procedure finishes, we make a linux sym link:

ln -s reiser4-debian-kernel-packaging-4.14.20 linux

then download kernel 4.14.20 from upstream:
wget https://cdn.kernel.org/pub/linux/kernel/v4.x/linux-4.14.20.tar.xz

Let's create a symbolic link in the format that Debian kernel packaging expects:
ln -s linux-4.14.20.tar.xz linux_4.14.20.orig.tar.xz

and change into linux directory
cd linux

Edit debian/changelog:
xvi debian/changelog

Locate the text string:

linux (4.14.17-1) unstable; urgency=medium

and remove the number 17 and insert 20, instead, i.e.,

linux (4.14.20-1) unstable; urgency=medium

save your changes.

Now we are ready to build the kernel 'the Debian way' as we did in previous post(s).

Added bonus &#59;)
Likely fix for Bug#885166: instability with 4.14 regarding KVM virtualization
https://lists.debian.org/debian-kernel/2017/12/msg00374.html

since referenced commit:
https://lists.debian.org/debian-kernel/2018/02/msg00173.html seems to be already applied to Linux kernel source tree 4.14.20.

YES! Bug#885166 has been fixed in 4.14.20!...
"If I used git correctly, then 4.14.20 already has 2a266f23550be997d783f27e704b9b40c4010292, so I tried 4.14.19. 4.14.19 on the one virt host that had the most violent failures failed in the first hour of operation, but with a slightly different error behavior that I was used to. I am therefore not sure whether we are not talking about multiple issues, one of them having been fixed somewhere in between 4.14.13 and 4.14.19."
...
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=885166


1 RE: x86: Support for lazy preemption in Debian Linux 4.14.20 AMD64

DISCLAIMER:P although due diligence has been applied, this resource is made available for testing/evaluation purposes on an AS IS basis. The procedure only reflects my own modifications, my limited testing, and the potential user who executes the procedures assumes all risks.

Please do not hold me or Metztli Information Technology responsible if the information provided here does not achieve the desired result. The information is provided AS IS and with the hope that it may be useful to the Internet community --especially those who desire reiser4 on GNU/Linux Debian.

Nevertheless, there is no implicit or explicit guarantee that the information presented here is accurate --even though due diligence was exercised during the procedure. Accordingly, if an user(s) decide to download and/or implement the procedure and/or shell commands described here s/he or them, do so at her, his, or their own risk. You have been forewarned.

Jose   ,   Feb 25 / 06:23
Categories: reiser4

From Ксения [Xenia] to Мария [Maria] With ffmpeg, gnome-subtitles, and mencoder


08-03-2021 update:
T̶h̶i̶s̶ ̶v̶i̶d̶e̶o̶ ̶i̶s̶ ̶a̶g̶e̶-̶r̶e̶s̶t̶r̶i̶c̶t̶e̶d̶ ̶a̶n̶d̶ ̶o̶n̶l̶y̶ ̶a̶v̶a̶i̶l̶a̶b̶l̶e̶ ̶o̶n̶ ̶Y̶o̶u̶T̶u̶b̶e̶ Fuck Youtube CEO Polish CENSOR and ex-sister-in-law to Google's co-founder1!




I used Mplayer's mencoder (built from source) to render the English/Russian subtitles in the PoC video above -- as I was trying out the upcoming GNU/Linux Debian Jessie distribution encapsulated inside a KVM virtual machine.

Debian: virt-manager managed KVM Jessie instance



In the past I had used mencoder to add Spanish subtitles to a video, but this time I was challenged with Russian subtitles, as those initially would not render properly in the resulting video. As a matter of fact, I was not even able to install mencoder from the Debian Jessie and Sid repositories due to libdvdnav4 dependency issue. Thus, the ephemeral viable option was to build mplayer's mencoder from source --which will skip support for DVD during the configure phase.

To solve the first issue, during Debian Jessie installation routine in the virtual machine I selected Russian as an additional language:

Debian Jessie installation: add ru_RU.UTF-8 locale during installation


I can verify the above action by examining /etc/locale.gen; I can see (scrolling to the bottom) that, in effect, I enabled 2 languages in addition to English: Russian and Mexico's Spanish dialect, all UTF-8.

Examining Debian Jessie /etc/locale.gen


For the record, at the top of the /etc/locale.gen file the user is advised to execute:

/usr/sbin/locale-gen

after manually enabling any locale (by removing the hash symbol from the beginning of the directive.)

Building mplayer -- defaults to building mencoder, too -- from source in Debian Jessie.

I update Debian repositories:

Shell

apt-get update

Since I am getting mplayer/mencoder code via Subversion:

Shell

apt-get install subversion

Then I get the mplayer/mencoder source code:

Shell

svn checkout svn://svn.mplayerhq.hu/mplayer/trunk mplayer

and directory mplayer will be created at my current directory location.

I change directory into mplayer:

Shell

cd mplayer

Since I am on Debian, and after scanning the README file, I can simply download a couple of DEBs:

Shell

apt-get install git devscripts

and then could simply execute the script under the debian directory to

"configure, compile and build a proper Debian .deb package with only one command:"

Shell

debian/daily-build.sh -b

But no. Since I am in a non-stable Debian, the resulting mencoder package may still refuse to install. Thus, I will download the relevant DEB packages manually:

Shell

apt-get install ffmpeg docbook-xsl ladspa-sdk libenca-dev libaa1-dev libasound2-dev libaudio-dev libcaca-dev libcdparanoia-dev libbluray-dev libdirectfb-dev libdts-dev libesd0-dev libfaad-dev libfontconfig1-dev libfreetype6-dev libfribidi-dev libgif-dev libgl1-mesa-dev libgtk2.0-dev libjack-dev libjpeg-dev liblircclient-dev liblivemedia-dev liblzo2-dev libmp3lame-dev libmpcdec-dev libncurses5-dev libopenal-dev libpng12-dev libpulse-dev libschroedinger-dev libsdl1.2-dev libsmbclient-dev libspeex-dev libsvga1-dev libswscale-dev libtheora-dev libvorbis-dev libvorbisidec-dev libx11-dev libx264-dev  libxext-dev libxinerama-dev libxv-dev libxvidcore-dev libxvmc-dev libxxf86dga-dev libxxf86vm-dev libvdpau-dev pkg-config vstream-client-dev x11proto-core-dev xsltproc yasm zlib1g-dev mpg123 libmpg123-dev

After the above operation completes, then we are ready to build mplayer/mencoder from our downloaded source snapshot. Since I am in the mplayer directory:

Shell

./configure --enable-gui

(sample partial output):

[...]
Creating config.mak
Creating config.h

Config files successfully generated by ./configure --enable-gui !

Install prefix: /usr/local
Data directory: /usr/local/share/mplayer
Config direct.: /usr/local/etc/mplayer

Byte order: little-endian
Optimizing for: native
[...]

Note: the default installation directory is /usr/local/ and the --enable-gui option is, well, optional. As usual we could change the installation directory and disable/enable options. Simply type ./configure --help for an overview.

Additionally, if you will be downloading codecs, make sure to place the extracted files ending in .so under the directory /usr/local/lib/codecs/
End of note.

In this particular case for this post, I follow a successfully completed ./configure operation with:

Shell

make
make install

You may be required to acquire root privilege to make install into /usr/local --as is usual any time you install software from repositories.

Cihuatl Archetype And The Human Subconsciousness.

Unless one is brainwashed by one of those three(3) major patriarchal strains spread by fanatics throughout the world imposing a misogynist attitude, the archetype of Cihuatl, Nahuatl -- Mexico's language par excellence -- which translates as женщина in Russian, Woman in English, and Mujer in Spanish, is fascinating. It beams down onto a man's subconsciousness when least expected.

I happen to add an extra feature supporting RuTube videos in b2evolution for Openshift PaaS cloud hosted at my Nepohualtzintzin GitHub repository. And during testing I came across Miss MAXIM 2013 (Ксения Кайгородова: Xenia Kaygorodova). Thus the seed of a proof of concept -- or PoC -- was generated as result of a Russian media video and my chance listening of a melody sung in Spanish: ¿Tú De Que Vas? -- loosely translated as, Do You Even Need To Ask?

Thus, I used youtube-dl utility -- available also from Debian repositories. If it does not exist in your system, all you have to do is:

Shell

apt-get install youtube-dl

and subsequently downloaded the video from RuTube with command:

Shell

youtube-dl -o nenetl.flv http://rutube.ru/video/cf126c6e54c8e30758fffe75503ca644

the option -o is just to assign a name to the file of interest; otherwise, you will end up with an unintelligeble alphanumeric-named file. As for the word nenetl, it is akin to a female image, ideal form, approaching an archetype.

Assuming current location is where the downloaded file resides, I create an ephemeral directory and change into it:

Shell

mkdir --verbose ephemeral
cd ephemeral

At this directory I will operate as follows:

used ffmpeg in order to extract the images from the nenetl.flv video, thus:

Shell

ffmpeg -../nenetl.flv -f image2 images%05d.png

The extracted images will occupy around 1.5 Gb of space. Now, by rough trial and error, I aimed to fit a relevant subset of the images into an interval equal to the length of the melody playing in the background. The final command -- referenced below -- outputs a nenetl_slideshow.mp4 which lasts approximately the length of the melody:

Shell

ffmpeg -r 6.2 -ss 00:00:03 -i images%05d.png -c:v libx264 -r 30 -pix_fmt yuv420p ../nenetl_slideshow.mp4

I had to decrease the intake of the images to 6.2 frames per second (fps) by using the -r option to ffmpeg; thus it gives the video somewhat of a slow motion :))

Also, by feeding the -ss to ffmpeg I advanced the resulting slideshow by hh:mm:03 seconds. Please type:

Shell

man ffmpeg

for additional information relevant to options specified.

Once we are satisfied with the outcome, we can erase all the extracted .png (picture) files at our current ephemeral directory and thus recover our disk space.

Subsequently, I merged the slideshow file with the .mp3 Franco de Vita audio file as follows:

Shell

ffmpeg -../nenetl_slideshow.mp4 -../Franco_De_Vita-Tu_De_Que_Vas.mp3 -map 0 -map 1 -codec copy -shortest ../nenetl.mp4

Cool! Now we have the length of the melody that is roughly equivalent to the most visually interesting media. We can verify it with the mplayer that was built above:

Shell

mplayer ../nenetl.mp4

Or, alternatively, since we enabled the graphical user interface (GUI) as an argument during ./configure
phase:

Shell

gmplayer ../nenetl.mp4
Using Hayraphon skin in GUI-enabled mplayer: gmplayer


Note: If you accepted the default installation path for the mplayer build, please make sure to install your skins under /usr/local/share/mplayer/skins/. For instance, the location for the Hayraphon skin in the above snapshot would be /usr/local/share/mplayer/skins/hayraphon End of note.

Adding Subtitles with GNOME Subtitles Editor

In Debian, we install the application as:

Shell

apt-get install gnome-subtitles

After it is completely installed, we start it from our shell:

Shell

gnome-subtitles

From topmost menu, we select Video, Open from the ensuing cascaded menu, and locate the nenetl.mp4 video/audio media we created before. The media file will be embedded in the upper section of the application.

gnome-subtitles: open video

We select the leftmost blank paper icon labeled New to start creating subtitles for our video -- as it is played using the controls under the embedded media. Further, as our embedded media is played, we can add another line of text by pressing the plus icon labeled Insert located in the upper row of icons -- just below the uppermost menu.

gnome-subtitles: new/open .srt file

From aforementioned row we also can save our newly created subtitles file by selecting the green arrow pointing down in a drawer icon, labeled as Save.

The named file will default to be saved with an extension .srt and UTF-8 locale.

Save dialog prompting format and location of subtitles file.

After we are satisfied assigning subtitles to relevant sections of the embedded audio/visual stream, we are ready to embed the subtitles file into the actual nenetl.mp4 media. For that we will use mencoder.

Assuming our location continues to be our ephemeral directory that we created for this set of tasks and we have a resulting xenia.srt subtitles file also here, we type next command:

Shell

mencoder ../nenetl.mp4 -oac mp3lame -ovc lavc -sub xenia.srt -subcp enca:ru:utf--subfont-outline 4 -of mpeg -o xenia.mp4

Alternatively, directive below will add extra font feature to your subtitles:

Shell

mencoder ../nenetl.mp4 -oac mp3lame -ovc lavc -sub xenia.srt -subcp enca:ru:utf--subfont-text-scale 4 -subfont-outline 6 -of mpeg -o Nenetl.mp4
Debian Jessie gmplayer



References:
1 "Her sister Anne is the founder of the genetic-testing company 23andMe and was married to Google co-founder Sergey Brin." via NeoMcCarthyism as a smoke screen to hide the crisis of neoliberalism

Useful FFmpeg Commands.

ffmpeg, how to add new audio (not mixing) in video

Past midway during the creation of this post -- researching sources -- I was surprised to find the RuTube source is also available from YouTube, albeit with a different cover:
Десятка финалисток Miss MAXIM 2013. Часть первая (Ксения Кайгородова)

How I got b2evolution to work in both English and Russian with UTF-8

Convert MPG to MP4


DISCLAIMER:P although due diligence has been applied, the above post is intended as a proof of concept for encoding Russian language subtitles in videos.

Please do not hold me or Metztli Information Technology, or its associates, responsible if the information provided here does not achieve the desired result. The information is provided AS IS and with the hope that it may be useful to the Internet community.

Notwithstanding, There is no implicit or explicit guarantee that the information presented here is accurate. Accordingly, if an user(s) decide to implement the procedure or shell commands described here she, he, or them, do so at her, his, or their own risk. You have been forewarned.

I reserve the right to modify the blog and even to delete it without further notice.

Debian: Patching Linux Kernel To Enable Aufs3 Module

Totonal ye
omotlatitzino,
totonal ye omixpoliuhtzino,

ihuan centlayohuayan
otechcahuili.

Mach ticmatih occeppa mohualhuiliz,
ma occeppa moquizaltiz

ihuan yancuican techtlahuililiquiuh.
                                                                Xonecuiltzin1

The Art of Toltecayotl



I happened to came across the need to enable advanced multi layered unification filesystem (Aufs) -- now at version 3.x (thus, Aufs3) -- module support into a GNU/Linux Debian deployment. It had been a while that I had done something similar by customizing the kernel to enable that feature. Well, surprise! Nothing has changed. Well, let me rephrase that, Aufs development continues; however, we still have to somehow hack the feature into the linux kernel tree version desired. Below I describe a procedure that worked on Debian and linux kernel 3.12.2, that is, the latest stable kernel source on this date.

Given the fact that cahuitl means the space of time in Nahuatl (Mexico's language par excellence), and a certain place, area, or surface in n-dimensional space is referred to as tlacauhtli, I was inspired to create a working directory appropriately named for the task at hand :P

mkdir -p --verbose /usr/src/tlacauhtli/build

Of course, prefixing sudo for the privilege to execute the above command (and similar others) is necessary if you are not already wielding root privilege; either way, the root (or super user) privilege is necessary to create directory(ies) at /usr/src directory since in Debian the default owner and group is root as shown with command:

ls -ld /usr/src
(sample output)...
drwxr-xr-x 8 root root 376 Nov 28 00:10 /usr/src/

We will not touch those default permissions but will manipulate those of the directories we initially created for our operations.

Now find out if your_username already belongs to Debian's src group:

groups your_username

Membership in the group src must be included in the output since, for security, we will want to operate as a non-root user. If the output does not show that your_user is a member of src group, then, wielding root privilege we should add the normal user who will be doing the Aufs3 and kernel build operations as a member of Debian's src group:

adduser your_username src

For the privileged permissions to take effect, your_username must logout and then login back again. Subsequently entering command again:

groups your_username

the output should show that your_username is a privileged member of Debian's src group (amongst others).

your_username should now be ready to begin her Aufs3 hack into the kernel tree.

But first root should grant and/or modify access permissions on our work area tlacauhtli and its subdirectory build, as below.

Still wielding root privilege, we subsequently grant src group ownership and writing privilege on the tlacauhtli directory where the operations will take place.

chmod -R g+w /usr/src/tlacauhtli

grants writing privilege to the group on directories tlacauhtli and its subdirectory build

chgrp -R src /usr/src/tlacauhtli

grants group ownership to the members of src group (which includes your_user) on directories tlacauhtli and its subdirectory build

Below is a rather verbose snapshot summary from bash shell on Debian:

Debian permissions on build directories

Now, we assume the identity of a normal non-root user, of course, you will assume your_username that we elaborately granted src group membership and privileges to operate on tlacauhtli and its subdirectory build directories. Now empowered, we change to tlacauhtli directory:

$ cd /usr/src/tlacauhtli

We start by downloading the latest stable kernel by visiting The Linux Kernel Archives. For security you are encouraged to check integrity of the files downloaded and scan them for malware.

For instance, if you have clamav, you may scan the uncompressed files as:

$clamscan downloaded_file

If you already uncompressed the files, you can recursively check the directory trees and only print out if infected files were found as:

$clamscan -ri uncompressed-file_directory

(Please do man clamscan and read for further information).

NOTE: If your Debian does not have the clamav anti-virus, wielding root privilege download and install as: apt-get install clamav

Verify Integrity Of Your Downloaded Kernel Releases By Verifying The Corresponding Signatures...

Linux kernel releases PGP signatures

Assuming we downloaded the compressed linux kernel tree linux-3.12.2.tar.xz and it is at our current location, we download its corresponding signature with wget utility (all in a single line directive)

NOTE: If your Debian does not have wget and/or bzip2, wielding root privilege download and install as: apt-get install wget bzip2 bc (indeed, you will need bc - An arbitrary precision calculator language - in your kernel building efforts.

$wget https://www.kernel.org/pub/linux/kernel/v3.0/linux-3.12.2.tar.sign

In order to be verified, linux-3.12.2.tar.xz should be decompressed and left in tar format (see Using GnuPG to verify kernel signatures ). As illustrated, the procedure can be accomplished step by step or in a one liner concatenation directive. I have decide to go with the latter:

$xz -dc linux-3.12.2.tar.xz | gpg --verify linux-3.12.2.tar.sign -

(sample output)...
gpg: Signature made Fri 29 Nov 2013 11:29:20 AM PST using RSA key ID 6092693E
gpg: Can't check signature: public key not found

I take as input the RSA key ID to download the public key from the PGP keyserver in order to verify the signature, thus:

$gpg --recv-keys 6092693E --keyserver subkeys.pgp.net

alternatively, if the above directive fails, try:

$gpg --keyserver pgp.mit.edu --recv-keys 6092693E
(sample output)...
gpg: requesting key 6092693E from hkp server subkeys.pgp.net
gpg: key 6092693E: public key "Greg Kroah-Hartman (Linux kernel stable release signing key) <greg@kroah.com>" imported
gpg: no ultimately trusted keys found
gpg: Total number processed: 1
gpg: imported: 1 (RSA: 1)

I rerun gpg --verify...:

$xz -dc linux-3.12.2.tar.xz | gpg --verify linux-3.12.2.tar.sign -
(sample output)...
gpg: Signature made Fri 29 Nov 2013 11:29:20 AM PST using RSA key ID 6092693E
gpg: Good signature from "Greg Kroah-Hartman (Linux kernel stable release signing key) <greg@kroah.com>"
gpg: WARNING: This key is not certified with a trusted signature!
gpg: There is no indication that the signature belongs to the owner.
Primary key fingerprint: 647F 2865 4894 E3BD 4571 99BE 38DB BDC8 6092 693E

Using GnuPG to verify kernel signatures

For this post, we will stop our verification process here. Nevertheless, you may decide to continue the procedure by following:

'You will now need to verify that the key used to sign the archive really does belong to the owner...'

I refresh my Debian repositories:

Shell

apt-get update



and download the necessary tools/utilities to build my kernel:

$apt-get install build-essential kernel-package patch fakeroot libncurses5 libncurses5-dev git


Now I change from my current tlacauhtli to subdirectory build

$cd build

and decompress my kernel, simultaneously untar'ing it:

$tar -xvJPf ../linux-3.12.2.tar.xz

"it becomes clear that 'Aufs was rejected. Let's give it up.' According to Christoph Hellwig, linux rejects all union-type filesystems but UnionMount."

Aufs at SourceForge

Since I am interested in building Aufs3 as a module, at this particular time the aufs3-standalone GIT tree enables that CONFIG_AUFS_FS=m option; hence, I download it:

git clone git://git.code.sf.net/p/aufs/aufs3-standalone aufs3-standalone.git

and change into the referenced directory:

$cd aufs3-standalone.git

and remember to specify the minor number of the kernel we are building. Thus, in our case, I have emphasized the minor number of the kernel 3.12 for inclusion in the next command:

$git checkout origin/aufs3.12

(sample output)...

Note: checking out 'origin/aufs3.12'.

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by performing another checkout.

If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -b with the checkout command again. Example:

git checkout -b new_branch_name

HEAD is now at 4a7364f... aufs3.12 20131111

and proceed to create a couple of directories to prepare a patch for the linux kernel tree:

$mkdir --verbose ../x ../y

How you name those remains at your discretion but I named them x and y. The following sequence of commands should operate on the directory ../y/.

Code

cp -rv Documentation ../y/.
cp -rv fs ../y/.
cp -rv include ../y/.



In the above commands, the verbosty (-v) is optional.

Make sure to remove Kbuild:

$rm -v ../y/include/uapi/linux/Kbuild

else you should specify 'no' when prompted by the patch utility whether it should replace Kbuild in your linux kernel tree.

We go back to our previous directory, i.e., build:

$cd ..

And perform the following operations:

Code

diff -rupN x/ y/ > linux-3.12.2/aufs.patch
cat aufs3-standalone.git/*.patch >> linux-3.12.2/aufs.patch



We are ready to apply the patch; we change directory to our linux kernel tree source:

$cd linux-3.12.2

And apply the patch:

$patch -p1 < aufs.patch

You will observe a long output to your bash shell but no errors.

Yolahuialtia [Cheers!] You have just patched your latest stable linux kernel tree :)

As I am upgrading from my currently running linux kernel 3.12.0, I will import the relevant .config into my spanking new and Aufs-patched linux kernel tree:

$cat /boot/config-`uname -r` >.config

and do:

$make oldconfig
(sample output)...
HOSTCC scripts/basic/fixdep
HOSTCC scripts/kconfig/conf.o
SHIPPED scripts/kconfig/zconf.tab.c
SHIPPED scripts/kconfig/zconf.lex.c
SHIPPED scripts/kconfig/zconf.hash.c
HOSTCC scripts/kconfig/zconf.tab.o
HOSTLD scripts/kconfig/conf
scripts/kconfig/conf --oldconfig Kconfig
*
* Restart config...
*
*
* Miscellaneous filesystems
*
[...]
SquashFS 4.0 - Squashed file system support (SQUASHFS) [M/n/y/?] m
Squashfs XATTR support (SQUASHFS_XATTR) [Y/n/?] y
Include support for ZLIB compressed file systems (SQUASHFS_ZLIB) [Y/n/?] y
Include support for LZO compressed file systems (SQUASHFS_LZO) [Y/n/?] y
Include support for XZ compressed file systems (SQUASHFS_XZ) [Y/n/?] y
Use 4K device block size? (SQUASHFS_4K_DEVBLK_SIZE) [Y/n/?] y
Additional option for memory-constrained systems (SQUASHFS_EMBEDDED) [N/y/?] n
[...]
OS/2 HPFS file system support (HPFS_FS) [M/n/y/?] m
[...]

Aufs (Advanced multi layered unification filesystem) support (AUFS_FS) [N/m/y/?] (NEW) m

Indeed, the directive above prompts as to whether install Aufs as a mdule, which I agree to by specifying to enable Aufs support as a module by typing: m

And subsequently follow additional options:
(sample output)...
Maximum number of branches
> 1. 127 (AUFS_BRANCH_MAX_127) (NEW)
2. 511 (AUFS_BRANCH_MAX_511) (NEW)
3. 1023 (AUFS_BRANCH_MAX_1023) (NEW)
4. 32767 (AUFS_BRANCH_MAX_32767) (NEW)
choice[1-4?]:
Detect direct branch access (bypassing aufs) (AUFS_HNOTIFY) [N/y/?] (NEW)
NFS-exportable aufs (AUFS_EXPORT) [N/y/?] (NEW) y
Readdir in userspace (AUFS_RDU) [N/y/?] (NEW) y
Respect the attributes (mtime/ctime mainly) of special files (AUFS_SP_IATTR) [N/y/?] (NEW)
Show whiteouts (AUFS_SHWH) [N/y/?] (NEW)
Ramfs (initramfs/rootfs) as an aufs branch (AUFS_BR_RAMFS) [N/y/?] (NEW) y
Fuse fs as an aufs branch (AUFS_BR_FUSE) [N/y/?] (NEW) y
Hfsplus as an aufs branch (AUFS_BR_HFSPLUS) [Y/n/?] (NEW)
Debug aufs (AUFS_DEBUG) [N/y/?] (NEW)

If I do a:

$make xconfig

I can observe and configure graphically Aufs support in the kernel tree:

make xconfig: Aufs graphical configuration

The moment to build our Debian custom linux kernel has finally arrived! Do:

$fakeroot make-kpkg clean

And I proceed to build my kernel: Xonecuiltzin which :yes: prefixed with a leading dot, I provide as an argument to --append-to-version in the directive that follows:

$time fakeroot make-kpkg --append-to-version=.xonecuiltzin --stem aufs -j8 --initrd kernel_image kernel_headers

I also provide aufs as an argument to --stem because I want to know the main reason for my kernel customization. Additionally, I provide 8 as an argument to -j. Eight(8) represents the number of threads I wish to launch, hence I make it equal to the number of cores in my machine where I am building the kernel -- for optimum performance during compilation.

After a few minutes, the build procedure ends and I take a look a my newly created Debian kernel and headers DEB packages, thus:

$ls ..
(sample output)...
aufs3-standalone.git/ linux-3.12.2/
aufs-headers-3.12.2.xonecuiltzin_3.12.2.xonecuiltzin-10.00.Custom_amd64.deb x/
aufs-image-3.12.2.xonecuiltzin_3.12.2.xonecuiltzin-10.00.Custom_amd64.deb y/

Debian build of Xonecuiltzin kernel done

To install our newly built Xonecuiltzin kernel on Debian, we need to acquire root privilege or prefix the command below with sudo:

$dpkg -i aufs-image-3.12.2.xonecuiltzin_3.12.2.xonecuiltzin-10.00.Custom_amd64.deb

... yeah, include the path if your kernel is not at your current directory location ;-)



1Our Sun has
disappeared,
our Sun has been hidden from us,

and left us in total darkness.
But we have the certainty that,

once again it will rise,

once again it will come to shine for us all.



Nahuatl quote found in an IAEA Publication (PDF) titled: Analytic Number Theory & The Nuclear Level Density.

The quote is attributed to Cuauhtemoc, last ruler of the Mexicah. On August 13, 1521, after the death of some 250,000 Mexicah and besieged for 79 days, Cuauhtemoc's metropolis Mexico-Tenochtitlan fell to the large invading armies of indigenous enemies of the Mexicah led by a small number of Spanish mercenary plunderers. After being tortured unsuccessfully to reveal hidden gold by the avaricious Spaniards, Cuauhtemoc was revered by the surviving Mexicah as Xonecuiltzin, "The Limping one", the same name/title by which one of their Deities, Tezcatlipoca, was also known.

REFERENCES:
How To Roll A Kernel the Ubuntu/Debian Way
Kernel 3.9 on Debian Wheezy/Testing
Compile Debian Kernel (Squeeze) 3.0 and Above with Aufs and squashfs
COMPILING Linux kernel version 3..2.6 | r4mi5

DISCLAIMER:P although due diligence has been applied, this resource is made available for testing/evaluation purposes on an AS IS basis. The procedure only reflect my own modifications, my limited testing, and the potential user who executes the procedures assumes all risks.

Please do not hold me or Metztli Information Technology responsible if the information provided here does not achieve the desired result. The information is provided AS IS and with the hope that it may be useful to the Internet community --especially those who need Aufs support on Debian.

Notwithstanding, There is no implicit or explicit guarantee that the information presented here is accurate --even though due diligence was exercised during the procedure. Accordingly, if an user(s) decide to implement the procedure or shell commands described here she, he, or them, do so at her, his, or their own risk. You have been forewarned.

Mexico-Tenochtitlan: July 18, 1325, Mexicah People Founded Modern-Day Mexico City



Please right-click on either image above to show video controls.


July 18, 1325, guided by their deity Huitzilopochtli, the Mexicah people's long journey from Aztatlan came to an end as they founded Mexico-Tenochtitlan. A marvelous engineering feat founded on an islet inside the great lake Texcoco, it was an extremely well planned and designed altepetl, or metropolis, and quite likely the largest and most efficiently run of its kind in the entire planet Tlalticpac (Earth).

Mexico-Tenochtitlan: July 18, 1325, Mexicah People Founded Modern-Day Mexico City

Modern Mexico City has not even a shade of a semblance to what was once the great Mexico-Tenochtitlan altepetl. After its 'independence' from Spain in September 16, 1810, the colony of ruling Spaniard-descendants (criollos in Spanish dialect) even plundered the Mexicah's eponymous nation-state ethnic name to denominate the entirety of their dominion as well. Thus, hiding behind the mythological Mexico to advance their 'mother' country, Spain's, vicious 'culture', the New Spain oligarchy has only imposed corruption, religious fanaticism that blinds the masses to the abuses of the privileged church representing the elite, impunity based on institutionalized discrimination, and archaeological, environment and ecological destruction. All of these factors evidently combine to hinder and gradually degenerate -- rather than advance -- intellectual and human development of those inhabiting the now Spaniard-bastardized 'Mexico' colony.

"I am not leaving material patrimony for you and our son, ... I'm leaving you a moral and political legacy, dying as I am for a cause, in defense of the Mexican culture."

--Emmanuel D'Herrera

Nahuatl is the native language of Mexico. It was the language par excellence spoken by the true Mexicah people who founded Mexico-Tenochtitlan in 1325, 688 years ago. Yet in 1696, the Nahuatl language was banned in the New Spain by a decree of King Charles II of Spain. Notwithstanding, the New Spain continued to observe their king's decree even after their 'independence' from Spain in 1810 and their decision to be renamed as 'Mexico'. That is a subtle indication of whose directives are actually impulsed and implemented in Mexico, which have thus far caused irreversible damage even to the lake Texcoco itself --where the altpetl or metropolis was founded-- and by extension to its inhabitants.

Mexico-Tenochtitlan: July 18, 1325, Mexicah People Founded Modern-Day Mexico City

Lake Texcoco... What Lake Texcoco?

"Pero de aquel majestuoso lago que se extendía desde el pueblo de Chalco, en el extremo sur, hasta el de Zumpango, en el límite norte, y que abarcaba cerca de 2 mil kms², hoy sobreviven sólo 10 kms²..."-- Aníbal Santiago

But of that majestic lake that extended from the pueblo of Chalco, at the extreme south, and reached the pueblo of Zumpango, at the northern limit, and which encompassed nearly 2 thousand kms², today only survive 10 kms²...

According to the Mexicah people's account of their long and arduous journey from Aztatlan (Place of the Herons), their revered deity Huitzilopochtli (Hummingbird of the South/Left) revealed a signal which predominantly guided them to their ultimate location. Prior to that, the Mexicah had been under the tutelage of Huitzilopochtli's sister, the great nahualli5 Malinalxochitl (Twisted Flower). It is said that the Mexicah underwent great suffering under Malinalxochitl's rule and that they begged Huitzilopochtli to deliver them from her tutelage.

Huitzilopochtli instructed his people to abandon his sister when she were deeply asleep and the Mexicah, ephemerally relieved, heeded his advice. When Malinalxochitl awoke and saw herself alone, she became furious and violently reacted by pitting her son Copal against his uncle. It is said that Huitzilopochtli defeated his belligerent nephew, killing him in sacrifice by extracting his yollohtli (heart) -- which the Deity subsequently threw into the emptiness, falling somewhere into lake Texcoco. That was the gist of the sign that Huitzilopochtli conveyed to his people: the Mexicah were to establish Mexico-Tenochtitlan where Copal's yollohtli --which had sunk somewhere in the lake Texcoco-- seeded the nohpalli (wide-leafed cactus) that they were to spot somewhere in the vast lake.

Teuhcalli : Atlachinolli

Cuauhtli :
Atlachinolli


Arguably, there was more to the nohpalli symbol: (Remember that we were very poetic...)

after the catastrophic destruction by the Spaniards and their indigenous allies -- bitter enemies of the Mexicah -- now it is difficult to really determine what the hieroglyphic images represent; yet by reading the explanation below you will get a better idea on how our people understood the universal connection, the aspects of nature, and relation the elements had with one another.

Let me shed some light on what will be stated below because, even though you will have read the [] insertions that follow, the meaning is deeper than that conveyed by the visual perception of an actual physical image (of an eagle perched on a nohpalli).

  • We didn't actually see [] an eagle [] proudly perched on top of a nohpalli -- what we saw was a powerful place where the sun (represented by the eagle) shimmered down displaying a place of grand intensity.
  • We saw and felt, at night, a spot where the moonlight gave off a lovely aura of feminine peace, a calming vibration, which was a reassurance that this was the place to build our new home.
  • [] The sun (i.e., the eagle, which also represents fire) [] is regarded as masculine, and the moon (which represents water) [] is regarded as feminine; together these two powerful forces represent the atl-tlachinolli; allow me to give a very brief explanation of this word (atl) [] means water and (tlachinolli) means fire, in Nahuatl. Combined, fire and water mean war (or seeking of balance).
  • The nohpalli represents the land and the thorns represent struggle.
  • The three rocks, as said in the insert, is the triple alliance between Tetzcoco6, Mexico-Tenochtitlan, and Tlacopan.

Over the field of xoxouhqui (raw/green or blue color) sovereignty irradiates Tonatiuh (the One who walks shining like fire, i.e., the Sun) as divine Metl (agave or maguey) and its blazing fire illuminates the Universe with his cihuametzin ('pencas' or rays) of light, (i.e., the Grand Gentleman who gives us life). In the center of the Sun [] transcends the august figure of Himself, and as in Teuhtihuacan on the so called perron of Quetzalcoatl we can contemplate the same solar symbol with His rays of light projecting what appears to be the head of an animal resembling an Ocelotl (jaguar), but which from a profile view morphs into a Cohuatl [Serpent] -- both symbols of the sun.7

Both (Ocelotl and Cohuatl) represent sovereign and dual divinity, yet in Tenochtitlan the sun is represented as a triumphant Cuauhtli [eagle], as described by P.Duran, J Acosta [1] and the Codex by Ramirez: 'In the early morning the eagle rises and extends its wings, absorbing the heat and the energy from the sun's rays while collecting the soothing coolness of the morning mist, and it held in its claws a magnificent bird of very precious and radiant feathers.' [2]

The eagle amplifies the solar --military-- shout. As the eagle shouts, it simultaneously disappears after giving life to the many inhabitants of the Anahuac (Surrounded by Water). The hieroglyphic, atl-tlachinolli, (which is misconstrued as a serpent/snake in the beak of a cuauhtli) corresponds with the symbols of water and fire, which over the course of generational ignorance and christian fanaticism have been distorted and confused with a serpent.

To the Nahuatl/Mexicah the prior misinterpretation is absurd, since the serpent is symbolic for [] divine wisdom (Quetzalcohuatl) and is a representation of Earth. This means the serpent could not have the solar eagle as an enemy for, if the eagle were to eat the serpent, would prevent (the serpent/snake) from fertilizing the earth.

In exploring the absurdity of the modern interpretation, we have exposed the false translation which originated with the translator of Alvarado Tezozómoc.[3] The Nahuatl text does not translate the meaning in detail. It provides a simple translation, which reads "place where the serpents whistle" (ihuancohuatl izomocayan8) [4]. The three rocks symbolize the triple foundation of the Federation of the Valley of Mexico: Tetzcoco, Tenochtitlan and Tlacopan.

Mexictli, where Metztli (the Moon) became Xictli (navel) to indicate the belly of our Mother Earth, is the place where the feminine light gives birth in blissful pleasure to our civilization; it is where the Mexicah encountered a rocky crag where metizintli [agave plants or magueyes] and nohpaltin are born. And perched radiantly on the nohpalli was a cuauhtli with its wings open and glaring -- as if challenging the sun -- intoning/chanting the shout 'Atl-tlachinolli!'. All the while proclaiming that mystical juncture where Cohuatl (Serpent) depicting Tlalticpac (Earth), Cuauhtli (Eagle itself), and Tonatiuh (Sun), are bound as one by the Great Being Huitzilopochtli. It was the symbology denoting the promised land.
9

Mexico-Tenochtitlan: July 18, 1325, Mexicah People Founded Modern-Day Mexico City

Who created a system wherein one could rise upward only by repudiating one's native blood and exploiting native people?10

The destruction of the ancient Lake Texcoco by the fascist Spain settler spawn oligarchy's nefarious paradigm that prevails in the New Spain... er, 'Mexico', has been an overt attack at the quintessence of the Mexicah peoples' existence. Further, the desecration of revered ancient places like Teuhtihuacan, even by those whose main task should be the preservation of Mexico-Tenochtitlan ancient heritage but who in reality are unscrupulous corrupt individuals, is alarming. And the fraud-imposed politicians --who front for the stateless elite who rule Mexico from the shadows-- do practice a policy of deference to foreign interests; these, in turn, have engendered a climate of violence which is gradually destroying the fabric of Mexico's society.

Although normally I post about technology, I believe in the unfettered positive development of the human beings' potential. Thus, I will finally end this long post by encouraging the technological development of Mexicah people; they have endured 492 years of marginalization under violent institutionalized oppression and discrimination. Furthermore, the Spanish dialect apparently does not facilitate excellence in mathematics, science, and consequently, technology.10 Accordingly --for the real Mexico-- recovering its ancestral native language, Nahuatl, in addition to English --the language that leads technology innovation-- might prove to be a superb combination, for...

The Mexicans are what they always have been -- Mexicans. Since (and before) 1520 they have absorbed many non-Mexicans (including other Anishinabeg as well as Asiatics, Africans, Spaniards, and so on); and their culture has changed (as do all cultures). Fundamentally, the Mexican people go back into history as far as we can see into the past. They have no need to explain their present status by denying their continuous past or by genuflecting before the shrine of mestisaje! The word Mexican historically means Aztec-Nahuan. Isn't that enough?11--Jack Forbes

References:
Mindscape3D Case: Mexico-Tenochtitlan Altepetl.
The Bribery Aisle: How Wal-Mart Got Its Way in Mexico
El gran lago moribundo de Texcoco

5Nahualli: the fanatic Spaniards usually reduced its meaning to their concept of sorceress
6Texcoco is also known as Tetzcoco
7Note how the snake/serpent (apprehension) and the jaguar were dual symbols of the sun in Teuhtihuacan; but in Mexico-Tenochtitlan the snake is only associated with the Earth.
8Zozomoca(h): for a snake to hiss
9"Sent by Chiknawi Ejekatl" But I cannot locate the URL
10Jorge Edwards opina que "somos una lengua unida pero atrasada en ciencia y tecnología"
11Jack Forbes, The Mestizo Concept:...

DISCLAIMER:P although due diligence has been applied, the above post reflects an educated assessment of the dire situation faced by a marginalized and fragmented people.

Please do not hold me or Metztli Information Technology, or its associates, responsible if the information provided here does not achieve the desired result. The information is provided AS IS and with the hope that it may be useful to the target audience and the worldwide Internet community who may want to collaborate.

Notwithstanding, There is no implicit or explicit guarantee that the information presented here is accurate. You have been forewarned.

I reserve the right to modify the blog and even to delete it without further notice.

Read more »