Sending GCM send message from nodejs.
I wanted to send a message from emacs, but it seemed to be
relatively difficult to send HTTPS POST request from emacs,
so I just decided to use handy nodejs.
The attached 'data' is attached to intent as extra, so it can be extracted by
intent.getExtras.getString("message") in IntentService#onHandleIntent()
OK, it's almost one month since we (the keyring-maintainers) gave our talk at DebConf14; how are we faring regarding key transitions since then? You can compare the numbers (the graphs, really) to those in our DC14 presentation.
Since the presentation, we have had two keyring pushes:
First of all, the Non-uploading keyring is all fine: As it was quite recently created, and as it is much smaller than our other keyrings, it has no weak (1024 bit) keys. It briefly had one in 2010-2011, but it's long been replaced.
Second, the Maintainers keyring: In late July we had 222 maintainers (170 with >=2048 bit keys, 52 with weak keys). By the end of August we had 221: 172 and 49 respectively, and by September 18 we had 221: 175 and 46.
As for the Uploading developers, in late July we had 1002 uploading developers (481 with >=2048 bit keys, 521 with weak keys). By the end of August we had 1002: 512 and 490 respectively, and by September 18 we had 999: 531 and 468.
Please note that these numbers do not say directly that six DMs or that 50 uploading DDs moved to stronger keys, as you'd have to factor in new people being added, keys migrating between different keyrings (mostly DM DD), and people retiring from the project; you can get the detailed information looking at the public copy of our Git repository, particularly of its changelog.
And where does that put us?
Of course, I'm very happy to see that the lines in our largest keyring have already crossed. We now have more people with >=2048 bit keys. And there was a lot of work to do this processing done! But that still means... That in order not to lock a large proportion of Debian Developers and Maintainers out of the project, we have a real lot of work to do. We would like to keep the replacement slope high (because, remember, in January 1st we will remove all small keys from the keyring).
And yes, we are willing to do the work. But we need you to push us for it: We need you to get a new key created, to gather enough (two!) DD signatures in it, and to request a key replacement via RT.
So, by all means: Do keep us busy!
| Attachment | Size |
|---|---|
| Debian Developers (uploading) | 266.66 KB |
| Debian Developers (non-uploading) | 204.17 KB |
| Debian Maintainers | 296.73 KB |
age and
log_modified.
Later I would like to create fully blown stats for an RFS queue, taking into account
the whole history (i.e. 2012-1-1 until now), and check its health, calculate MTTGS (mean time to get sponsored).
The list looks more or less like this:
Age Dust Number Title
37 0 757966 RFS: lutris/0.3.5-1 [ITP]
1 0 762015 RFS: s3fs-fuse/1.78-1 [ITP #601789] -- FUSE-based file system backed by Amazon S3
81 0 753110 RFS: mrrescue/1.02c-1 [ITP]
456 0 712787 RFS: distkeys/1.0-1 [ITP] -- distribute SSH keys
120 1 748878 RFS: mwc/1.7.2-1 [ITP] -- Powerful website-tracking tool
1 1 762012 RFS: fadecut/0.1.4-1
3 1 761687 RFS: abraca/0.8.0+dfsg-1 -- Simple and powerful graphical client for XMMS2
35 2 758163 RFS: kcm-ufw/0.4.3-1 ITP
3 2 761636 RFS: raceintospace/1.1+dfsg1-1 [ITP]
....
....
rfs_health.py can be found below, it uses SOAPpy
(only python <3 unfortunately).
#!/usr/bin/python
import SOAPpy
import time
from datetime import date, timedelta, datetime
url = 'http://bugs.debian.org/cgi-bin/soap.cgi'
namespace = 'Debbugs/SOAP'
server = SOAPpy.SOAPProxy(url, namespace)
class RFS(object):
def __init__(self, obj):
self._obj = obj
self._last_modified = date.fromtimestamp(obj.log_modified)
self._date = date.fromtimestamp(obj.date)
if self._obj.pending != 'done':
self._pending = "pending"
self._dust = abs(date.today() - self._last_modified).days
else:
self._pending = "done"
self._dust = abs(self._date - self._last_modified).days
today = date.today()
self._age = abs(today - self._date).days
@property
def status(self):
return self._pending
@property
def date(self):
return self._date
@property
def last_modified(self):
return self._last_modified
@property
def subject(self):
return self._obj.subject
@property
def bug_number(self):
return self._obj.bug_num
@property
def age(self):
return self._age
@property
def dust(self):
return self._dust
def __str__(self):
return " subject: age: dust: ".format(self._obj.bug_num, self._obj.subject, self._age, self._dust)
if __name__ == "__main__":
bugi = server.get_bugs("package", "sponsorship-requests", "status", "open")
buglist = [RFS(b.value) for b in server.get_status(bugi).item]
buglist_sorted_by_dust = sorted(buglist, key=lambda x: x.dust, reverse=False)
print("Age Dust Number Title")
for i in buglist_sorted_by_dust:
print(" :<4 :<4 :<7 ".format(i.age, i.dust, i.bug_number, i.subject))
_ __<;
</_/ _/__
/> > 7 )
~;</7 /
/> / _*<---- Perth
~ </7 7~\_
</7 \
/_ _ _
If you don't, the UK will have to rename itself the K. And that's just silly.
Also vote yes on whether Alex Trebek should keep his mustache.
.muttrc.
set mime_forward
set mime_forward_rest=yes
Last night I was looking for an image I knew a model had mailed me a few months ago, as we were talking about rescheduling a shoot at the weekend. I couldn't find it, even with my awesome mail client and filing system.
With some free time I figured I could write a little utility to dump all attachments from email folders, and find it that way.
It did cross my mind that there is the simple mail-utility for dumping headers, etc, called formail, which is distributed alongside procmail, but it doesn't handle attachments ..
I was tempted to write a general purpose script to dump attachments, email header values, etc, etc but given the lack of time I merely solved my own problem.
I suspect there is room for a "mail utilities" package, similar to Joey's "moreutils" and my "sysadmin utils". However I note that there is a GNU Mailutils which does things differently than I'd expect - i.e. it contains a POP3 server.
Still if you want to dump attachments from emails, have GMIME installed, and want to filter by attachment-name, or MIME-type, you might look at my trivial attachment-dump program.
Related to that I spent some time last night updating my photography site, so the animals & pets section has updated images at least.
During the course of that I found a bug in my static-site generator, templer which stopped it from automatically populating image height/widths when called in a glob:
Title: Pets & Animals Images: file_glob( "*.jpg" ) --- This is the page body, it now has access to a variable called 'images' which is a HTML::Template loop-structure containing name/height/width/etc for each image in the current directory.That should now be resolved, and life should once again be good.
After spending a while fighting with upstart, at work, I decided that systemd couldn't be any worse and yesterday morning upgraded one of my servers to run it.
I have two classes of servers:
#!/bin/sh # # Run Graphite in a detached state. # /usr/bin/docker run -d -t -i -p 8080:80 -p 2003:2003 skxskx/graphiteWithout getting into politics (ha), systemd installation seemed simple, resulted in a faster boot, and didn't cause me horrific problems. Yet. ObRandom: Not sure how systemd is controlling prosody, for example. If I run the status command I can see it is using the legacy system:
root@chat ~ # systemctl status prosody.service
prosody.service - LSB: Prosody XMPP Server
Loaded: loaded (/etc/init.d/prosody)
Active: active (running) since Wed, 03 Sep 2014 07:59:44 +0100; 18h ago
CGroup: name=systemd:/system/prosody.service
942 lua5.1 /usr/bin/prosody
I've installed systemd and systemd-sysv, so I thought /etc/init.d was obsolete. I guess it is making pretend-services for things it doesn't know about (because obviously not all packages contain /lib/systemd/system entries), but I'm unsure how that works.
Yesterday I received my official diploma for the degree of Licentiate of Philosophy. The degree lies between a Master s degree and a doctorate, and is not required; it consists of the coursework required for a doctorate, and a Licentiate Thesis, in which the student demonstrates good conversance with the field of research and the capability of independently and critically applying scientific research methods (official translation of the Government decree on university degrees 794/2004, Section 23 Paragraph 2).
The title and abstract of my Licentiate Thesis follow:
Kaijanaho, Antti-JuhaniA Licentiate Thesis is assessed by two examiners, usually drawn from outside of the home university; they write (either jointly or separately) a substantiated statement about the thesis, in which they suggest a grade. The final grade is almost always the one suggested by the examiners. I was very fortunate to have such prominent scientists as Dr. Stefan Hanenberg and Prof. Stein Krogdahl as the examiners of my thesis. They recommended, and I received, the grade very good (4 on a scale of 1 5). The thesis has been
The extent of empirical evidence that could inform evidence-based design of programming languages. A systematic mapping study.
Jyv skyl : University of Jyv skyl , 2014, 243 p.
(Jyv skyl Licentiate Theses in Computing,
ISSN 1795-9713; 18)
ISBN 978-951-39-5790-2 (nid.)
ISBN 978-951-39-5791-9 (PDF)
Finnish summary Background: Programming language design is not usually informed by empirical studies. In other fields similar problems have inspired an evidence-based paradigm of practice. Central to it are secondary studies summarizing and consolidating the research literature. Aims: This systematic mapping study looks for empirical research that could inform evidence-based design of programming languages. Method: Manual and keyword-based searches were performed, as was a single round of snowballing. There were 2056 potentially relevant publications, of which 180 were selected for inclusion, because they reported empirical evidence on the efficacy of potential design decisions and were published on or before 2012. A thematic synthesis was created. Results: Included studies span four decades, but activity has been sparse until the last five years or so. The form of conditional statements and loops, as well as the choice between static and dynamic typing have all been studied empirically for efficacy in at least five studies each. Error proneness, programming comprehension, and human effort are the most common forms of efficacy studied. Experimenting with programmer participants is the most popular method. Conclusions: There clearly are language design decisions for which empirical evidence regarding efficacy exists; they may be of some use to language designers, and several of them may be ripe for systematic reviewing. There is concern that the lack of interest generated by studies in this topic area until the recent surge of activity may indicate serious issues in their research approach. Keywords: programming languages, programming language design, evidence-based paradigm, efficacy, research methods, systematic mapping study, thematic synthesis
Figure 1 of the thesis: an overview of the mapping process
Figure 8 of the thesis: Core studies per publication yearIn fact, the whole of 20th Century philosophy of science is a big pile of failed attempts to explain science; not one explanation is fully satisfactory. [...] Most scientists enjoy not pondering it, for it s a bit like being a cartoon character: so long as you don t look down, you can walk on air.I wrote my Master s Thesis (PDF) in 2002. It was about the formal method called B ; but I took a lot of time and pages to examine the history and content of formal logic. My supervisor was, understandably, exasperated, but I did receive the highest possible grade for it (which I never have fully accepted I deserved). The main reason for that digression: I looked down, and I just had to go poke the bridge I was standing on to make sure I was not, in fact, walking on air. In the many years since, I ve taken a lot of time to study foundations, first of mathematics, and more recently of science. It is one reason it took me about eight years to come up with a doable doctoral project (and I am still amazed that my department kept employing me; but I suppose they like my teaching, as do I). The other reason was, it took me that long to realize how to study the design of programming languages without going where everyone has gone before. Debian people, if any are still reading, may find it interesting that I found significant use for the dctrl-tools toolset I have been writing for Debian for about fifteen years: I stored my data collection as a big pile of dctrl-format files. I ended up making some changes to the existing tools (I should upload the new version soon, I suppose), and I wrote another toolset (unfortunately one that is not general purpose, like the dctrl-tools are) in the process. For the Haskell people, I mainly have an apology for not attending to Planet Haskell duties in the summer; but I am back in business now. I also note, somewhat to my regret, that I found very few studies dealing with Haskell. I just checked; I mention Haskell several times in the background chapter, but it is not mentioned in the results chapter (because there were not studies worthy of special notice). I am already working on extending this work into a doctoral thesis. I expect, and hope, to complete that one faster.
Summer is cool in Mexico City.
It is cool because, unlike Spring, this is our rainy season And rains are very predictable. Almost every day we wake up with a gorgeous, clean, blue sky.
Cool, nice temperature, around 15 C. The sun slowly evaporates the rain throughout the morning; when I go out for lunch, the sky is no longer so blue, giving way to a seemingly dirty white/grayish tint. No, it's not our world-famous pollution: It's just yesterday's rain.
Rain starts falling usually between 4 and 7 PM. Sometimes it starts as a light rain, sometimes it starts with all of its thunder, all of its might. But anyway, almost every night, there is a moment of awe, of not believing how much rain we are getting today.
It slowly fades away during the late night. And when I wake up, early next morning, everything is wet and still smells fresh.
Yes, I love our summer, even though it makes shy away from my much enjoyed cycling to work and school. And I love taking some minutes off work, look through the window of my office (located ~70m over the level of our mostly flat city) and watching how different parts of the city have sun or rain; learning to estimate the distance to the clouds, adding it to the direction and guessing which of my friends have which weather.
But I didn't realize our city had so clearly defined micro-climates... (would they really be *micro*-climates?) In fact, it even goes against my knowledge of Mexico City's logic I always thought Coyoac n, towards the South of the city, got more rain than the Center and North because we are near the mountains, and the dominant air currents go Southwards, "clumping" the clouds by us.
But no, or at least, not this year. Regina (still in the far South Far because she's too far away from me and I'm too egocentric; she returns home after DebConf) often asks me about the weather, as our friends working nearer the center of the city. According to the photos they post on their $social_media_of_the_day accounts, rains are really heavier there.
Today I heard on the radio accounts of yesterday's chaos after the rain. This evening, at ESIME-Culhuac n, I saw one of the reported fallen trees (of course, I am not sure if it's from yesterday's rain). And the media pushes galleries of images of a city covered in hail... While in Copilco we only had a regular rain, I'd even say a mild one.
This city is bigger than any cloud you can throw at it.
| Attachment | Size |
|---|---|
| IMG_20140819_155052.jpg | 929.69 KB |
A little more than 2 years ago, the
Ceilometer project was launched inside
the OpenStack ecosystem. Its main objective was to measure OpenStack cloud
platforms in order to provide data and mechanisms for functionalities such
as billing, alarming or capacity planning.
In this article, I would like to relate what I've been doing with other
Ceilometer developers in the last 5 months. I've lowered my involvement in
Ceilometer itself directly to concentrate on solving one of its biggest
issue at the source, and I think it's largely time to take a break and talk
about it.
Ceilometer early design
For the last years, Ceilometer didn't change in its core architecture.
Without diving too much in all its parts, one of the early design decision
was to build the metering around a data structure we called samples. A
sample is generated each time Ceilometer measures something. It is composed
of a few fields, such as the the resource id that is metered, the user and
project id owning that resources, the meter name, the measured value, a
timestamp and a few free-form metadata. Each time Ceilometer measures
something, one of its components (an agent, a pollster ) constructs and
emits a sample headed for the storage component that we call the
collector.
This collector is responsible for storing the samples into a database. The
Ceilometer collector uses a pluggable storage system, meaning that you can
pick any database system you prefer. Our original implementation has been
based on MongoDB from the beginning, but we then added a SQL driver, and
people contributed things such as HBase or DB2 support.
The REST API exposed by Ceilometer allows to execute various reading
requests on this data store. It can returns you the list of resources that
have been measured for a particular project, or compute some statistics on
metrics. Allowing such a large panel of possibilities and having such a
flexible data structure allows to do a lot of different things with
Ceilometer, as you can almost query the data in any mean you want.
The scalability issue
We soon started to encounter scalability issues in many of the read requests
made via the REST API. A lot of the requests requires the data storage to do
full scans of all the stored samples. Indeed, the fact that the API allows
you to filter on any fields and also on the free-form metadata (meaning non
indexed key/values tuples) has a terrible cost in terms of performance (as
pointed before, the metadata are attached to each sample generated by
Ceilometer and is stored as is). That basically means that the sample data
structure is stored in most drivers in just one table or collection, in
order to be able to scan them at once, and there's no good "perfect"
sharding solution, making data storage scalability painful.
It turns out that the Ceilometer REST API is unable to handle most of the
requests in a timely manner as most operations are O(n) where n is the
number of samples recorded (see
big O notation if you're
unfamiliar with it). That number of samples can grow very rapidly in an
environment of thousands of metered nodes and with a data retention of
several weeks. There is a few optimizations to make things smoother in
general cases fortunately, but as soon as you run specific queries, the API
gets barely usable.
During this last year, as the Ceilometer PTL, I discovered these issues
first hand since a lot of people were feeding me back with this kind of
testimony. We engaged several blueprints to improve the situation, but it
was soon clear to me that this was not going to be enough anyway.
A cloud of gnocchis!
time.time()). I've started to hack on that in my own fork, but then
everything broke. The whisper project code base is, well, not the state of
the art, and have 0 unit test. I was starring at a huge effort to transform
whisper into the time-series format I wanted, without being sure I wasn't
going to break everything (remember, no test coverage).
I decided to take a break and look into alternatives, and stumbled upon
Pandas, a data manipulation and statistics
library for Python. Turns out that Pandas support time-series natively, and
that it could do a lot of the smart computation needed in Gnocchi. I built a
new file format leveraging Pandas for computing the time-series and named it
carbonara (a wink to both the
Carbon project and pasta, how
clever!). The code is quite small (a third of whisper's, 200 SLOC vs 600
SLOC), does not have many of the whisper limitations and it has test
coverage. These Carbonara files are then, in the same fashion, stored into
Swift containers.
Anyway, Gnocchi storage driver system is designed in the same spirit that
the rest of OpenStack and Ceilometer storage driver system. It's a plug-in
system with an API, so anyone can write their own driver. Eoghan Glynn has
already started to write a InfluxDB driver, working
closely with the upstream developer of that database. Dina Belova started to
write an OpenTSDB driver. This helps to make sure
the API is designed directly in the right way.
Handling resources
Measuring individual entities is great and needed, but you also need to link
them with resources. When measuring the temperature and the number of a
people in a room, it is useful to link these 2 separate entities to a
resource, in that case the room, and give a name to these relations, so one
is able to identify what attribute of the resource is actually measured. It
is also important to provide the possibility to store attributes on these
resources, such as their owners, the time they started and ended their
existence, etc.
Relationship of entities and resources
The indexer classes and their relations
Macroscopic view of the Gnocchi architecture
Cl ment drawing the logo
This is a random post inspired by recent purchases. Some things we buy are practical, others are a little arbitrary.
I tend to avoid buying things for the sake of it, and have explicitly started decluttering our house over the past few years. That said sometimes things just seem sufficiently "cool" that they get bought without too much thought.
This entry is about two things.
A couple of years ago my bathroom was ripped apart and refitted. Gone was the old and nasty room, and in its place was a glorious space. There was only one downside to the new bathroom - you turn on the light and the fan comes on too.
When your wife works funny shifts at the hospital you can find that the (quiet) fan sounds very loud in the middle of the night and wakes you up..
So I figured we could buy a couple of LED lights and scatter them around the place - when it is dark the movement sensors turn on the lights.
These things are amazing. We have one sat on a shelf, one velcroed to the bottom of the sink, and one on the floor, just hidden underneath the toilet.
Due to the shiny-white walls of the room they're all you need in the dark.
By contrast my second purchase was a mistake - The Logitech Harmony 650 Universal Remote Control should be great. It clearly has the features I want - Able to power:
# Get the Bus/ID for the USB device bus=$(lsusb grep -i Harmony awk ' print $2 ' tr -d 0) id=$(lsusb grep -i Harmony awk ' print $4 ' tr -d 0:) # pass to kvm kvm -localtime .. -usb -device usb-host,hostbus=$bus,hostaddr=$id ..That allows the device to be passed through to windows, though you'll later have to jump onto the Qemu console to re-add the device as the software disconnects and reconnects it at random times, and the bus changes. Sigh. I guess I can pretend it works, and has cut down on the number of remotes sat on our table, but .. The overwhelmingly negative setup and configuration process has really soured me on it. There is a linux application which will take a configuration file and squirt it onto the device, when attached via a USB cable. This software, which I found during research prior to buying it, is useful but not as much as I'd expected. Why? Well the software lets you upload the config file, but to get a config file you must fully complete the setup on Windows. It is impossible to configure/use this device solely using GNU/Linux. (Apparently there is MacOS software too, I don't use macs. *shrugs*) In conclusion - Motion-activated LED lights, more useful than expected, but Harmony causes Discord.
I don't really like any of the ticketing systems I've ever needed to
use, whether they've been used as bug tracking systems, user support
issue management systems, or something else. Some are not too bad. I
currently rely most on debbugs and ikiwiki.
debbugs is the Debian bug tracking system. See
https://www.debian.org/Bugs/ for an entry point. It's mostly mail
based, with a read-only web interface. You report a bug by sending an
email to submission address, and (preferably) include a few magic
"pseudo-headers" at the top of your message body ot identify the
package and version. There's tools to make this easier, but mostly
it's just about sending an e-mail. All replies are via e-mails as
well. Effectively, each bug becomes is own little dedicated mailing
list.
This is important. A ticket, whether it is a bug report or a support
request, is all about the discussion. "Hey I have this problem..."
followed by "Have you tried..." and so forth. Anything that makes that
discussion easier and faster to have is better.
It is my very strong opinion, and long experience, that the best way
to have such a discussion is over e-mail. A lot of modern ticketing
systems are web based. They might have an e-mail mode, perhaps
read-only, but that's mostly an afterthought. It's a thing bolted onto
the side of the system because people like me whinge otherwise.
I like e-mail for this for several reasons.
About torbrowser-launcher in all current Debian distros plus some thoughts and scripts for running it more securely
So, torbrowser-launcher 0.1.2-1 is now in sid (only that version has the script examples discussed below), and 0.1.1-2(~bpo70+1) are in jessie and wheezy-backports.
Originally Jacob Appelbaum packaged torbrowser-launcher, then Ulrike Uhlig stepped in and fixed some major bugs, I sponsored her uploads and somehow the idea emerged to team maintain the package, so pkg-anonymity-tools was founded. So far it's only used for having a mailing list which is used for the Maintainer: field of the torbrowser-launcher package. But we invite all maintainers of anonymity related packages to join the team! Currently there ain't even a Debian teams wiki page about it (it would be great if YOU could fix that!), so that will probably be the next thing that will happen. As for version control we intend to use the collab-maint project on alioth. So joining the team is not done by joining the alioth project (technically you can do this, but it's rather pointless), but rather by putting the pkg-anonymity-tools mailing list into the Maintainer: field of your package (and you and other people into the Uploaders: field) and subscribing to that very mailing list. Once more packages are maintained that way we'll need to see whether we'll need more mailing lists (eg one specific for commit notifications) or if we rely on client side filtering only or what else should be done.
The example scripts (available in /usr/share/doc/torbrowser-launcher/examples in the package from sid or in git) show how to run torbrowser-launcher, confined with AppArmor, in Xephyr (a virtual Xserver running on another Xserver) as another user. This, using AppArmor and Xephyr, shall have two effects:
torbrowser-launcher launcher scripts ==================================== These scripts are intended to run torbrowser-launcher (and thus torbrowser) as another user in an Xephyr window server running inside your normal Xorg session. They assume the following packages are installed: - torbrowser-launcher - apparmor - xserver-xephyr, awesome - sudo, slay, psmisc AppArmor should be enabled, but doesn't have to. I followed the HowTo from https://wiki.debian.org/AppArmor, which can be summed up as just adding one parameter to the kernel to enable it, followed by a reboot. Using Apparmor has the advantage that the browser process cannot most of the filesystem, eg saving downloads only works in ~/.torbrowser/tbb/x86_64/tor-browser_en-US/Desktop/ On wheezy, I'm using backports for torbrowser-launcher and apparmor. The scripts assume they have been copied to /usr/local/bin/ and that there is a user called "foo" (for running the actuall torbrowser(-launcher) process, and that the current user has sudo rights for the following commands: - sudo -i -u foo /usr/local/bin/tbb-l-wrapper - sudo slay foo There are two scripts, tbb-in-xephyr and tbb-l-wrapper. Only tbb-in-xephyr is to be called directly and will result in torbrowser running in Xephyr. Known problems: --------------- - dbus is not started, so some input methods won't work. (Personally I don't want/need dbus though, so I'm awaiting a solution to https://trac.torproject.org/projects/tor/ticket/10014) - not everybody likes awesome as the window manager being used ;) Ideas, questions and ToDo: -------------------------- - maybe all of this functionality could be integrated into. torbrowser-launcher itself, just writing this in shell was so easy. - or for the time being, merge these two scripts into one, doing both, depending on how its called. Also make them run from everywhere. - run this in an unprivileged LXC container, which is also apparmor confined. - (when) does this double confinement make sense? - use a more sensible named default user (instead of foo). - there should really be an option, so torbrowser-launcher doesn't detach itself, so that this "while;ps fax grep" hack can go away. - ship an usable sudoers.d example too. - support for more users / instances Feedback welcome, especially accompanied by patches!
Friday was my last day at Collabora, the awesome Open Source consultancy in Cambridge. I d been there more than three years, and it was time for a change.
As luck would have it, that change came in the form of a job offer 3 months ago from my long-time friend in Open Source, Miguel de Icaza. Monday morning, I fly out to Xamarin s main office in Boston, for just over a week of induction and face time with my new co workers, as I take on the title of Release Engineer.
My job is to make sure Mono on Linux is a first-class citizen, rather than the best-effort it s been since Xamarin was formed from the ashes of the Attachmate/Novell deal. I m thrilled to work full-time on what I do already as community work including making Mono great on Debian/Ubuntu and hope to form new links with the packer communities in other major distributions. And I m delighted that Xamarin has chosen to put its money where its mouth is and fund continued Open Source development surrounding Mono.
If you re in the Boston area next week or the week after, ping me via the usual methods!
In short: I love my MacBook Air. It is the best (laptop) hardware
I ever owned. I have seen hardware which was much more flaky
in the past. I can set the display backlight to zero via software,
which saves me a lot of battery life and also offers a bit
of anti-spy-acroos-my-shoulder support. WLAN and bluetooth work nicely.
And I just love the form-factor and the touch-feeling of the hardware.
I even had the bag I use to carry my braille display
modified so that the Air just fits in.
I can't say how it behaves with X11. Given how flaky accessibility
with graphical desktops on Linux is, I have still not made
the switch. My MacBookAir is my perfect mobile terminal, I LOVE it.
I am sort of surprised about the recent rant of Paul about MacBook Hardware.
It is rather funny that we perceive the same technology so radically different.
And after reading the second part of his rant I am wondering
if I am no longer allowed to consider myself part of the
"hardcore F/OSS world", because I don't consider Apple as evil
as apparently most others. Why? Well, first of all, I actually like
the hardware. Secondly, you have to show me a vendor
first that builds usable accessibility into their products, and I mean
all their products, without any extra price-tag attached. Once the others
start to consider people with disabilities, we can talk about apple-bashing
again. But until then, sorry, you don't see the picture as I do.
Apple was the first big company on the market to take accessibility seriously.
And they are still unbeaten, at least when it comes to bells and whistles included.
I can unbox and configure any Apple product sold currently completely
without assisstance. With some products, you just need to know
a signle keypress (tripple-press the home button for touch devices and Cmd+F5 for
Mac OS/X), and with others, during initial bootup, a speech synthesizer even tells
you how to enable accessibility in case you need it.
And after that is enabled, I can perform the setup of the device
completely on my own. I don't need help from anyone else. And after the setup
is complete, I can use 95% of the functionality provided by the operating system.
And I am blind, part of a very small margin group so to speak.
In Debian circles, I have even heard the sentiment that we supposedly have to
accept that small margin groups are ignored sometimes. Well, as long
as we think that way, as long as we strictly think economically, we will never
be able to go there, fully. And we will never be the universal operating system,
actually. Sorry to say that, but I think there is some truth to it.
So, who is evil? Scratch your own itch doesn't always work to cover everything.
How do we motivate contributors to work on things they don't personally
need (yet)? How can we ensure that complicated but seldomly used
features stay stable and do not fall to dust just because some upstream
decides to rewrite an essential subcomponent of the dependency tree?
I don't know. All I know is that these issues need to be solved in
an universal operating system.
top, with colours
Only a very short summary in English: I am Mexican. I am Jewish. I am almost completely disconnected from the local Jewish communities. And understanding the local Jewish communities is hard. There is a very interesting and brave campaign, recently started, called Neither do I The Mexican Jewish gay activist group Guimel, started off with this video (with English subtitles, if you are interested in following along). But how did I learn about this very bold initiative? By getting a hateful spam, inviting people to join a hate campaign. Right, the hate mail is not calling to violence, but it is based on premises as stupid as everybody's right not to include (to begin with).
So, the least I can do about this is to share both said hate mail and publicly denounce my shock on reading this nonsense nowadays. And, also in Spanish (I know many people following me don't understand it Sorry, it would just take too long, and after all, it's mainly for local "consumption"), this is the reply I sent to them (and to the other recipients). Sorry in advance to the Spanish speakers for my exabrupts :) This was written "as is", without much prior thought, and quite angry about what I had just read.
Buf... Expresiones como esta, que hacen evidente la cerraz n de tanta gente en las comunidades jud as, justifican claramente por qu tantos nos hemos ido abriendo, integr ndonos a la sociedad circundante. Me da verg enza ser asociado como jud o a comunidades donde se defienden estos puntos de vista; si bien yo no soy de la comunidad Monte Sinai (como resultar obvio por mi nombre), para la sociedad en su conjunto s soy un jud o (as , a secas: Jud o). Mucho nos hemos quejado colectivamente a lo largo de los siglos acerca de la discriminaci n, de que seamos considerado la "basura" del mundo, los "apestados". Y es precisamente esa actitud, ante todo y en todo momento, lo que me ha llevado a alejarme del juda smo. Soy un ser humano m s, con una historia personal nica, con una historia cultural compartida pero tambi n nica, con algunas elecciones y algunas caracter sticas que me son inherentes nicas. Algo de eso no le gusta a alguien? Por motivos racionales o irracionales? No lo puedo ni pienso evitar. Pero el que una comunidad completa sea llamada a ignorar, humillar, alienar a sus hijos, por una estupidez as de anacr nica (en el caso que lo presenta el video al que hacen referencia, y a la gente que valientemente ha conformado Guimel) me parece que simplemente va m s all de toda estupidez. Piensen bien antes de adherirse a esta campa a de odio. Substituyan la sexualidad por cualquier otra raz n en la que somos minor a. No les da asco vivir con un vendedor de telas? Con un jud o apestoso? Y s , aqu ya estoy yo tambi n dejando ir a esos demonios... que hay que mantener bajo control. Porque somos hombres y mujeres de nuestro siglo, y porque el mundo y las nuevas generaciones merecen nuestro mejor esfuerzo para ir colectivamente destruyendo la estupidez de nuestros ancestros. Seamos m s racionales. Dejemos el odio, dejemos los prejuicios. Aceptemos a los diferentes, porque todos queremos que nos acepten. Porque todos somos diferentes.
| Attachment | Size |
|---|---|
| tambien.txt | 8.55 KB |
Next.
