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