Chris Lamb: Disabling internet for specific processes with libfiu
My primary usecase is to prevent testsuites and build systems from contacting internet-based services. This, at the very least, introduces an element of non-determinism and malicious code at worst.
I use Alberto Bertogli's libfiu for this, specifically the fiu-run utility which part of the fiu-utils package on Debian and Ubuntu.
Here's a contrived example, where I prevent Curl from talking to the internet:
$ fiu-run -x -c 'enable name=posix/io/net/connect' curl google.com curl: (6) Couldn't resolve host 'google.com'... and here's an example of it detecting two possibly internet-connecting tests:
$ fiu-run -x -c 'enable name=posix/io/net/connect' ./manage.py text [..] ---------------------------------------------------------------------- Ran 892 tests in 2.495s FAILED (errors=2) Destroying test database for alias 'default'...
Note that libfiu inherits all the drawbacks of LD_PRELOAD; in particular, we cannot limit the child process that calls setuid binaries such as /bin/ping:
$ fiu-run -x -c 'enable name=posix/io/net/connect' ping google.com PING google.com (173.194.41.65) 56(84) bytes of data. 64 bytes from lhr08s01.1e100.net (17.194.41.65): icmp_req=1 ttl=57 time=21.7 ms 64 bytes from lhr08s01.1e100.net (17.194.41.65): icmp_req=2 ttl=57 time=18.9 ms [..]Whilst it would certainly be more robust and flexible to use iptables such as allowing localhost and other local socket connections but disabling all others I gravitate towards this entirely userspace solution as it requires no setup and I can quickly modify it to block other calls on an ad-hoc basis. The list of other "modules" libfiu supports is viewable here.
Reworking Intel Glamor
The original Intel driver Glamor support was based on the notion that
it would be better to have the Intel driver capture any fall backs and
try to make them faster than Glamor could do internally. Now that
Glamor has reasonably complete acceleration, and its fall backs aren t
terrible, this isn t as useful as it once was, and because this uses
Glamor in a weird way, we re making the Glamor code harder to maintain.
Fixing the Intel driver to not use Glamor in this way took a bit of
effort; the UXA support is all tied into the overall operation of the
driver.
Separating out UXA functions
The first task was to just identify which functions were UXA-specific
by adding _uxa to their names. A couple dozen sed runs and now a
bunch of the driver is looking better.
Next, a pile of UXA-specific functions were actually inside the
non-UXA parts of the code. Those got moved out, and a new
intel_uxa.h file was created to hold all of the definitions.
Finally, a few non UXA-specific functions were actually in the uxa
files; those got moved over to the generic code.
Removing the Glamor paths in UXA
Each one of the UXA functions had a little piece of code at the top
like:
because a few
parameters that depend on the GTT size were not initialized until
after that frame buffer was allocated. I haven t analyzed what effect
this has on performance.
Page Flipping and Resize
Page flipping (or just flipping) means switching the entire display
from one frame buffer to another. It s generally the fastest way of
updating the screen as you don t have to copy any bits.
The trick with flipping is that a client hands you a random
pixmap and you need to stuff that into the KMS API. With UXA, that s
pretty easy as all pixmaps are managed through the UXA API which knows
which underlying kernel BO is tied with each pixmap. Using Glamor,
only the underlying GL driver knows the mapping. Fortunately (?), we
have the EGL Image extension, which lets us take a random GL texture
and turn it into a file descriptor for a DMA-BUF kernel object. So, we
have this cute little dance:
I spent many, many hours trying to understand why I couldn t have both nova console-log showing me the output of the log, AND have the OpenStack dashboard (eg: horizon) console to work at the same time. Normally, this is done very easily, by passing multiple times the console= parameter to the Linux kernel as follow:
Something straight out from the real world: Menu cards in restaurants are
not nice to deal with if you are blind. It is an old problem we grow used
to ignoring over time, but still something that can be quite nagging.
There are a lot of psychological issues involved in this one.
Of course, you can ask for the menu to be read out to you by the staff.
While they usually do their best, you end up missing out on
some things most of the time.
First of all, depending on the current workload in the restaurant,
the staff will usually try to cut some time and not read everything to you.
What they usually do is to try to understand what type of meal you are
interested in, and just read the choices from that category to you.
While this can be considered a service in some situations (human preprocessing),
there are situations were you will definitely miss a highlight on the menu that
you would have liked to choose if you knew that it was there.
And even if the staff decides to read the complete menu to you (which is rare),
you are confronted with the 7-things-in-my-head-at-once problem.
It is usually rather hard to decide amongst a list of more then 7 items,
because our short-term memory is sort of limited. What the sighted
restaurant goers do, is to skip back and forth between the available options,
until they hit a decisive moment. True, that can take a while,
but it is definitely a lot easier if you can perform "random access reads" to
the list of choices yourself. However, if someone presents a substantial number
of choices to you in a row, as sequential speech, you loose the random
access ability. You either remember every choice from the beginning and do your
choosing mentaully (if you do have extraordinary mental abilities), or you end
up asking the staff to read previous items aloud again. This can work, but
usually it doesn't. At some point, you do not want to bother the staff anymore,
and you even start to feel stupid for asking again and again, while this is
something totally normal to every sighted person, just that
"they" do their "random access browsing" on their own, so "they"
have no need to feel bad about how long it takes them to decide, minus the typical
social pressure that arises after a a certain time for everyone, at least
if you are dining in a group.
In very rare cases, you happen to meet staff that is truly "awake", doing
their best to not let you feel that they might be pressed on time, and
really taking as much time as necessary to help you make the perfect decision.
This is rare, but if it happens, it is almost a magical moment.
One of these moments, where there are no "artificial" barriers between
humans doing communcation. Anyway, I am drifting away.
The perfect solution to this problem is to provide random access browsing
of a restaurant menu with the help of digital devices. Trying to make
braille menus available in all restaurants is a goal which is not realistically
reachable. Menus go out of date, and need changing. And getting a physical
braille copy updated and reprinted is considerably more involved as with digital media.
Restaurant owners will also likely not see the benefit to rpvide a braille
card for a very small circle of customers. With a digital online menu,
that is a completely different story.
These days, almost every blind person in at least my social circles
owns an iOS (or similar) device. These devices have speech synthesis and web
browsers.
Of course, some restaurants especially in urban areas do already
have a menu online. I have found them manually with google and
friends sometimes in the past, which has already given me the
ability to actually sit back, and really comfortably choose
amongst the available offerings myself, without having to bother
a human, and without having to feel bad about (ab)using their time.
However, the case where a restaurant really has their menu online is rather rare
still in the area where I am. And, it can be tedious to google
for a restaurant website. Sometimes, the website itself is just
marginally accessible, which makes it even more frustrating to
get a relaxed dinner-experience.
I have discovered a location-based solution for the restaurant-menu problem recently.
Foursquare offers the ability to provide a direct link to the menu in
a restaurant-entry. I figured, since all you need to do is
write a single webpage where the (common) menu items are listed per restaurant,
that I could begin to create restaurant menus for my favourite locations,
on my own. Well, not quite, but almost. I will sometimes need
help from others to get the menu digitized, but that's just a one-time
piece of work I hopefully can outsource :-). Once the actual content
is in my INBUX, I create a nice HTML page listing the menu in a rather
speech-based browser friendly way.
I have begun to do this today, with the menu of a restaurant just about
500 meters away from my apartment. 
Every now and then I decide I'll try and sort out my VoIP setup. And then I give up. Today I tried again. I really didn't think I was aiming that high. I thought I'd start by making my email address work as a SIP address. Seems reasonable, right? I threw in the extra constraints of wanting some security (so TLS, not UDP) and a soft client that would work on my laptop (I have a Grandstream hardphone and would like an Android client as well, but I figure those are the easy cases while the "I have my laptop and I want to remain connected" case is a bit trickier). I had a suitable Internet connected VM, access to control my DNS fully (so I can do SRV records) and time to read whatever HOWTOs required. And oh my ghod the state of the art is appalling.
Let's start with getting a SIP server up and running. I went with 
You should now have your own JSCommunicator repository on your Github account. On your main page select the tab Repositories . It should be the first on the list. The url will be https://github.com/YOUR-USERNAME/jscommunicator. My Github username is JLouback, so my jscommunicator repo can be found at https://github.com/JLouback/jscommunicator.
Clone
Now you should download all that code to your local machine so you can edit it. On your JSCommunicator page somewhere around the lower right corner you ll see a field entitled HTTPS clone URL:
I don t know if this is correct, but you can just copy the URL on your browser too. I do that.
Now on your terminal, navigate to the directory you d like to place your repository and enter
Click the green button directly to the left of the branch drop down menu shown above. This will create a pull request to add your new code to the official jscommunicator code. Once you click that button, you should see this:
Make sure that the base repo (the first on the line above the green Create pull request button) is opentelecoms-org:i18n-support and not opentelecoms-org:master or another branch name. If it is, just click Edit on the right and you ll be able to select the branch from a dropdown like so:
If first repo is opentelecoms-org:i18n-support and the second is YOUR_USER:i18n-support and you ve verified (scroll down) that there are 2 files changed which are your new .properties file and the added element to the available_languages.xml, go ahead and press create pull request. It ll open a window with a text box you can add an explanation to with one final Create pull request button. Click that and you re done! You ve kindly contributed with a translation for JSCommunicator!
A common theme over the last few decades was that we could afford to simply
sit back and let computer (hardware) engineers take care of increases in
computing speed thanks to
Dear lazyweb,
I just made an account on yet another web service. On the suggestion of my
password manager, I attempted to use the password 
So I was at Ocracoke island, camping with family, and I brought my laptop
along as I've done probably half a dozen times before. An enormous
thuderstorm came up. It rained for 8 hours and thundered for 3 of those.
Some lightning cracks quite close by as we crouched in the food tent, our
feet up off the increasingly wet ground "just in case". The campground
flooded. Luckily we were camped in the dunes and tents mostly avoided being
flooded with 2-3 inches of water. (That was just the warmup; a hurricane
hit a week after we left.)
My laptop was in my tent when this started, and I got soaked to the skin
just running over there and throwing it up on the thermarest to keep it out
of any flooding and away from any drips. It seemed ok, so best not to try
to move it to the car in that downpour.
Next time I checked, it turned out the top vent of the tent was slightly
open and dripping. The laptop bag was damp. But inside it seemed ok. Rain
had slackened to just heavy, so I ran it down to the car. Laptop appeared
barely damp, but it was hard to tell as I had quite forgotten what "dry"
was. Turned it on for 10 seconds to check the time. It was 7:30 and
we still had to cook dinner in this mess. Transferred it to a dry bag.
(By the way, in some situations, discovering you have a single dry towel
you didn't know you had is the best gift in the world!)
Next morning, the laptop was dead. When powered on, the fan came on full,
the screen stayed black, and after a few seconds it turned itself back off.
I need this for work, so it was a crash priority to get it fixed or a
replacement. Before I even got home, I had logged onto Lenovo's website to
check warantee status and found 2 things:
