physical security: places to stash money
All fields of Security are of great interest to me. I am still not sure why... Today I stumbled upon these really interesting eye-openers about stashing valuables at home.
I'm Pedro Venda and this is my personal blog. I am a techno-geek, a UNIX-head, a petrol-head and a security consultant. All posts are made over my own point of view and don't necessary reflect what others may think is right or wrong. Mostly they're harmless though :) In all, this blog follows my perspective that knowledge is power and most effective when shared. The stuff you learn as you go along ... ... needs to be shared with those that might not know yet.
All fields of Security are of great interest to me. I am still not sure why... Today I stumbled upon these really interesting eye-openers about stashing valuables at home.
Posted by
Unknown
2
comments
This is one of those events in my life certainly classified as "changes everything".
I am moving into the UK tomorrow (Saturday) and starting a new job on information security. I will be living with my better half in Oxford and working nearby. This means that everything in my life changes starting tomorrow. I am sure that most of the changes will be for the better!
The worse part of this is leaving my family, my friends and Portugal...
Cheers, PJ.
Posted by
Unknown
0
comments
Luke, the author of "Terminally Incoherent" took some notes on his blog about some cool console applications. This post caught my attention (from osnews.com, I believe) and I decided to promote it further.
He believes that it is possible to survive on Linux without X and I agree, but that idea is now being avoided as much as possible by users and distributions. The idea of avoiding the console is not necessarily bad but, for people that are used to unices for a long time, it is still a powerful tool to do anything and an incredible loss if somehow it gets eliminated.
http://www.terminally-incoherent.com/blog/2007/05/21/a-day-without-x/
The short version of his post follows:
Posted by
Unknown
1 comments
Hello Everyone,
Yesterday I needed to scan some documents and I borrowed an HP PSC 1110 from my sister. Knowing that the official HP drivers for that printer/scanner are distributed only in a 160MB bundle with all sorts of unnecessary software, I thought about it (for just a second) and decided to try to do my scans on linux. I do know that the HP PSC 1110 printer is damn hard to get working but would the scanner be tricky as well?
Let's get things started: scanning on linux == SANE (Scanner Access Now Easy)
So I fired up Gentoo's emerge utils and found two interesting packages: sane-frontends and sane-backends. Looks simple...
# emerge sane-frontendsbrought along sane-backends as a dependency, as expected.
# USE="scanner" emerge hplipThis time hplip installed libsane-hpaio.so and changed /etc/sane.d/dll.conf to include the following line: "hpaio" - the backend for an entire class of HP scanners including mine.
$ scanimage --batch-mode=yes > file.pnmHow cool is that??
Posted by
Unknown
0
comments
"A very thourough and insightful analysis of the benefits of Linux vs. Windows without a lot of opinionated points. Great job!" - first comment to the blog post below, by Tavis
Things I can do in Linux that I can't do on Windows
Cheers, PJ.
Posted by
Unknown
0
comments
Hello everyone,
Sometimes things go wrong and we (me in this case) do not have a clue of where to start looking for the problem to fix it. Sometimes because of lack of time, some other times because of lack of imagination and even some other times because of lack of resources.
About one/two years ago, I had a problem with AmaroK (media player, KDE) which caused it to quickly consume all available resources when rebuilding the music library. Exactly what I mean is that the application ate about all available physical memory within a minute or so and then it kept going until all swap space was also used. At that point, the kernel's OOM (Out Of Memory) procedure kicked in and killed amarok. When amarok would restart, it had the library marked as "unclean" and would itself reinitiate the library rebuild process... over and over again. That happened because of an amarok's bug - a known memory leak when handling .mp4 files. It got fixed and I carried on with my life listening to Iron Maiden over and over again with amarok.
Until recently (maybe four months ago) the issue came back. This time a little different: amarok was not being killed by the OOM but it still ate about 85% of total memory which means the computer became unusable due to continuous swapping. The symptoms were very similar which would indicate a similar cause. I looked at the KDE's buzilla but did not find anything relevant... Eventually, due to practical reasons, I stopped using amarok and stopped listening to music while working and playing, etc until I would find some free time to really dig the problem out.
Today I decided: No more! I will listen to my music!
Strategy: If amarok cannot, surely others can!
After verifying that JuK (another KDE media player) handled .ogg media, I fired it up and started to build my music library, only to see it mimic the amarok problem.
The most trivial test yielded the most important result: *the problem was not on the media player*!
For my next test, I started one of the media players and setup a very small collection. All went well, so either there was something in my collection that consistently crashed the indexing process or it was too big. It could not be too big - I see people with collections of 100GB+ of digital music frequently, so my 20GB could not be problematic!
Then I took my collection and split it into two roughly equal parts and put JuK rebuilding both parts, in turn - one of them crashed JuK and the other did not. *There was some problem somewhere in my digital music library!*
I kept using the bissection algorithm while carefully monitoring the media player's behaviour (to foresee the leak before the computer needed 5 minutes to open a terminal window) and after about six iterations I narrowed the problem in the library to one (well known) band, where I had four albums. By applying the same method again I found the album and the specific music file that was crashing the indexing done by both media players. I re-encoded the whole album again and copied the corrupted (?) file for later analysis.
In conclusion, imagination and creativity are just as important as technical resources and determination to solve even the simplest problems. The crucial test here was probably the simplest I could do - try another media player.
Now go do something else while I listen to "Louder than Hell" once more. After that it is time for "Brave New World". :)
Cheers, PJ.
Posted by
Unknown
3
comments
This is to all time keepers that happen to have the bad idea of reading my blog. I must admit I am a terrible blogger - I have about 5 partially written posts for about two months now and my posting average is dangerously close to one per month...
To the point:
The world famous NTP daemon gained an important feature for all internet users with dynamic IP assignments. "Dynamic interface tracking" is a simple feature (from the user's point of view) that makes the NTP daemon aware of IP changes on network interfaces to avoid loosing synchronisation.
Before this feature existed, upon startup, the NTP daemon would store all the IP addresses to which it would bind. While doing its job, the daemon used those stored IPs as source IPs to contact servers and peers. If one IP would change on a given network interface, all servers and peers contacted through that interface would become unreachable because the stored source IP no longer matched the new interface's IP. In the common case of a server with a DSL internet connection, all external servers and peers are reached through the PPP interface and if that IP changes (as it does frequently in my case) no more servers can be contacted resulting in loosing synchronisation.
Stable version 4.2.4p0 of the NTP implementation (http://www.ntp.org/) includes dynamic interface tracking and an important bugfix (#765) which allows using this feature while running the daemon with an unprivileged user. The first official version including dynamic interface tracking was 4.2.4.
This feature is activated automatically and the scanning intervals can be controlled with the daemon option "-U". In my case, instead of using "ntpd -u ntp:ntp -g" I now use "ntpd -u ntp:ntp -g -U 600" and I do not have to restart ntpd regularly because of frequent IP changes (every 17h55m).
[EDIT: forgot to mention the Gentoo overlay ebuild method]
There is not yet a Gentoo Linux ebuild for ntp 4.2.4p0 (although I offered one on Gentoo bugzilla), but it is easy to overlay one and try out the updated 4.2.4:
Posted by
Unknown
0
comments

For the last three weeks, I've been using Beryl [wikipedia], the hardware accelerated window manager for Linux.
Let me say it is brilliant when seen from several different perspectives:
Posted by
Unknown
0
comments
Who would believe that 2006 would ever end?? Quickly a new year came to take 2006's place. 2007 they call it.
Sorry for my bad jokes. Now that the dust is settled and I have a little more time, I've decided to write a couple posts on different subjects. Today I'm writing about the New Year's Eve.
This year I spent the New Year's Eve with a group of friends in a very traditional Portuguese village called "Covilhã". Covilhã is located just on the second tallest Portuguese mountain chain: "Serra da Estrela". It's a dead beautiful place to visit either on the winter or on the summer.
Samples of some of the available landscapes:


With everything summed, it was a great weekend of 3 days with a new year's eve included. Already looking forward for the next new year's eve or long weekend, whichever comes first!
Cheers, PJ.
Posted by
Unknown
0
comments

Hi everyone,
I tend to do these things - start reading on a particular techie subject and next thing I know, hours passed I still have about 10 tabs to read of wikipedia articles.
I remember having done this with gas turbine technology (various types of jet engines, rotating engines, some theory, etc.), aircraft types and models, cpu types and architectures... etc.
Today I started looking up cavitation due to a recent conversation with a friend and went on to supercavitation, russian supercavitation torpedoes. Then I reviewed the ground effect, ekranoplanes, beriev Be-2500, Howard Huges' spruce goose and the Boeing Pelican. The Boeing Pelican is a potentially military device capable of carrying the daisy cutter and/or the MOAB (a.k.a. Mother of All Bombs).
This kind of dwelling through such a vast information source is something impossible before websites like wikipedia or how stuff works.
P.S.: I apologise for writing this post in 14 December 2006 and only posting it in 9 January 2007. I forgot to click "publish" and forgot all about the bog post.
Cheers, PJ.
Posted by
Unknown
0
comments