« April 2006 | Main | June 2006 »

May 2006 Archives

May 7, 2006

Why current RFID is bad

I'm not going to say that RFID is bad as a whole, but its current implementation leaves a lot to be desired. So many races towards ease and convenience don't take into account the importance of security. Wired has a great article on RFID hacking at:

RFID Hacking Underground

I would like to see such technology used more widely, but only after someone has taken the time to understand and deal with the consequences of RFID hacking. Why do I like RFID (and yet refuse to buy/partake in services like ExxonMobile's Speedpass)? Because it is extremely convenient. Currently, I only use one type of RFID knowingly: the Illinois I-Pass - driving through the tolls without one is more costly and a waste of time. I'm willing to risk being ripped off for the convenience I gain. (The amount that I could be ripped off is also minimized to the amount in my account at this time.) As it stands, security continues to be an afterthought with all that is technology and it is quite frustrating. Programs and systems are simply more expensive when done right and done securely, but the pressure to save money makes people willing to cut corners. Sad.

May 9, 2006

darwinports(.org) Hacks - Add manpages to Your Path

I started using DarwinPorts when I first received my MacBook Pro because unlike Fink, it seems to do a "more" native build of apps for which there are ports; more simply put, they said in their documentation that it was likely that the Intel line was supported without any tweaks on the part of the user (although they hadn't tested all of the ports at that point). One thing, however, that I didn't realize was that the manpages for all of the apps I was installing weren't being added to the normal man location (/usr/share/man), but to /opt/local/man. So, a quick look around the net revealed that modifying /usr/share/misc/man.conf and editing the section where it is obvious that you can add:

MANPATH_MAP /opt/local/bin /opt/local/man
MANPATH_MAP /opt/local/sbin /opt/local/man

osxhints.com shows ways of doing this in your profile (i.e. editing .profile with export MANPATH=/usr/local...), but I find the above cleaner - that's just me though. You can also create a symlink to dump all of the manpages from /opt/local/man into /usr/share/man, but again, I like editing man.conf. Use what works for you - either way, it can be done.

May 11, 2006

What I think of Porn/.xxx

I don't know how to be more concise: ICANN's decision on .xxx : dumbass :: riding a bike with no seat : just plain stupid
Whoever put pressure on ICANN to nix the decision to create a "porn only" domain is missing something so completely valuable: you aren't going to rid the net of pornography, period. You would have made it a lot easier for administrators like myself to be able to at least block a whole TLD that we don't want people to have access to, instead of having to depend on poor software AI to figure out which domains have pornographic content and which don't. Regardless of my opinion of the state of pornography on the net, this is a lose lose for everyone involved. Shame on ICANN for bowing to what can only be conceived as political pressure.


ICANN's board on Wednesday voted nine to five against the proposal, which would have led to the creation of a .xxx domain suffix for pornography sites.
The plan has drawn considerable controversy over recent months, with conservative groups campaigning against the domain due to concerns that it would legitimize pornography. Advocates of the plan have denied this, claiming that it would make it easier for Web users to avoid porn. (via ICANN rejects .xxx domain on News.com)

Well, you just decided to allow for a situation wherein it is difficult and prone to error managing who can and cannot see those sites - 'cause you certainly can't control it.

May 13, 2006

Point the Finger, Why Programming is Difficult

I am not a programmer. I aspire at times to become one, but I don't consider myself to be in that league of extraordinary gentlemen (forgive the movie reference). I have tended to be a tinkerer, put it all together guy - figure out what the problems are and find someone who can help with fixing the technicalities (e.g. reprogramming) of a given problem. I have been spending more time lately trying to understand how programming conceptually works (object oriented vs. things like programing in c) and one of the biggest actual programing projects I've ever been involved in was done primarily in Ruby/Rails. In the years since college, I have somehow been able to avoid learning anything solid and complete when it comes to anything. (That's a subject to discuss on as one of my alter egos.) There is one thing, however, that I have learned and learned quite well: there is no lack of crap software out there and there is no lack of people who think they are programmers and yet don't have the gumption to follow through on a project when they run into problems. People often (even the smart ones who know better) expect stuff to just work and when it doesn't, they like to point the finger.
My years of reading the misc@openbsd.org list has taught me an invaluable lesson of what comment with or without context actually means. OpenBSD is known for a lot of things, the most important of which is security. The other thing that most people know about OpenBSD is that the misc@ list is relentless when it comes to picking apart people who don't take the time to do their homework. Before I felt comfortable with the inside (and mind you, I rarely post or answer anything on the misc@ list) workings and the people who put their souls into the project, I was always nervous that the questions I was about to ask would be torn to shreds and my tattered remains be paraded about in some sick sort of "let's tar and feather the idiot orgy." That never happened. I've never seen it happen to someone who is genuinely trying to do their homework and are stumped. I see it when it is deserved. By deserved, I mean someone who hasn't taken the slightest bit of time to google a question or even look at OpenBSD's main web page and handbook. Let me put it simply: people, OpenBSD is developed by people because they want to do it and it is free for you to use. You didn't pay for it, so you have no right to expect it to work the way you want. If you want something to change, you have to kindly convince a developer that your needs are their needs OR you need to learn to do it yourself. I have yet to run into a situation where OpenBSD hasn't met or exceeded my needs - not because OpenBSD is my end-all, be-all, but because I use it for what I feel it is best able to do (for me, routing, firewalling, web hosting and email hosting). Could I use it as a desktop/workstation machine? Sure, but I'd have to give up all of the media applications I've come to enjoy using on my Mac. So, I do the pragmatic thing: sell my soul for the desktop and keep my soul on the server. To be honest, I'd live fine if my desktop/workstation were taken away from me - I'd be pissed, but I would live. My servers are another story. They just have to work. Most of the requests I see from the individuals who die a fireball death are those of mememememe and you must do as I say. Bull. They don't and I'm glad as hell that they don't succumb to what many other projects seem to do. As humans, we desire to make people around us happy (unless we truly are sullen individuals) and this often causes us to do things that don't make sense. It really is difficult to say no or confront someone when they are wrong.
For some reason, programmers seem to rarely be told no and rarely say no to someone else who is asking for something idiotic. I don't know how else we could have ended up where I see us today - a bunch of people who will never become really good at what they do because they get away with producing claptrap and a lot of people asking software to do something that it really isn't meant to do.
My latest experience has to do with a bit of ego, a bit of naivety and I think a bit of frustrated laziness. Everyone wants to take the path of least resistance, but sometimes you can't and have to accept the fact that things don't always work the way you expect. I run a small web and email hosting service (that remained after I sold the ISP portion of Anywhere Technology) and had to deal with a programmer who neither wanted to listen to what I had to say nor provide me with trouble-shooting reports that would have cleared up any misconceptions sooner than later. I don't like it when people claim that something I manage doesn't work, but it is a fact of life. If the claim is made, however, the first thing I do is actually see if the problems are due to a bad configuration or something that happened (what? I have no idea, but I'll do my best to find it). I know in the past that I would often try to find a way out - a reason that had to do with bad instructions or bad programming or ... anything but me. What I found more often than not, though, is that if it is obvious that it works for others, there is likely something different about my setup or my procedure that is causing difficulties. Programming is not easy and it is less easy for those of us who do web work on different platforms. The person I dealt with was so quick to jump the gun and point out what they felt were problems caused by the environment I was giving them that they were completely ignoring that what they were given is what it is (so ist Programmieren) - that means, no environment is ideal and that is part of the difficulty of dealing with and developing technology. They were not having trouble with me because of something I had done, they were having trouble because my platform/environment was not behaving as they had expected. The problem compounded when rather than questions, accusations were thrown about.
This is the primary reason why I continue to spend money on running my own hosting service instead of using one of the better commodity hosters out there. It is not because I think they can't do what I am doing - or even do it better - it is that I realize that if I want to avoid having to adjust my programming style (rather, constantly watch that the program or application I am intending to use has been well tested on platform xyz), I can adjust the environment to fit the needs of my programs or applications. Therefore, while I trust others to do the job I do, I simply find it easier to do it myself to accommodate my constantly changing tastes. If you do chose to go down the road of using someone else, you give up the flexibility and are likely to spend more time doing bug tracking. The ideal environment that every programmer yearns for is simply that which they are comfortable using.
Pointing the finger at your platform provider is easy. (I like to do so with Apple all the time. The difference, I feel, is that I am criticizing a claim that they are making (and not fulfilling) and not the platform in particular.) It lets you off the hook from a lot of frustration and a lot of hard work. It doesn't make you a better programmer, though. It certainly won't make you successful over the long run either. If there is one important lesson I have learned from my dad it is to know thyself, know thy environment and accept it or be lazy and call it quits. The more quickly you accept that you can only change those things over which you have direct control, the more likely you will be able to finish what you are doing and move on to the next project. Successful people appear to either change and mold their environment directly or deal with the tools they were given in such a way that they find success even with what others would give up on. We are our own worst enemies, right?

About May 2006

This page contains all entries posted to steven n fettig's Jitterin' Thoughts in May 2006. They are listed from oldest to newest.

April 2006 is the previous archive.

June 2006 is the next archive.

Many more can be found on the main index page or by looking through the archives.

Creative Commons License
This weblog is licensed under a Creative Commons License.
Powered by
Movable Type 3.33