Open wireless access points and the theft analogy

Many homes and small companies are using Wi-Fi access points so that their computers can establish a wireless connection to the internet. It is still not uncommon for such access points, the devices with antennae that can transmit and receive data, to have no measures implemented to prevent undesired connections by other computers.

It has often been asked whether people who log into unprotected access points are stealing. The analogy often used is that it’s like being able to walk onto your neighbour’s house just because his front door isn’t locked, then tapping into his cable TV connection, run the cable back to your house and then watch TV for free.

This analogy, however, is false. An excellent analogy I have read goes as follows: You ring the doorbell of your neighbour’s house, the butler opens the door. Then you ask if it’s OK to watch cable TV, the butler then answers “sure, no problem.” So are you stealing cable television? No, you’re not.

The butler is simply carrying out his masters instructions, or otherwise used his own discretion when the master fails to provide explicit instructions. The open access point device is to internet access, what the friendly butler is to cable TV.

In other words: people with open access points have delegated decisions, regarding who to grant access to the network, to the access point’s software. It can decide for itself who gets permission to access your network, as you have implicitly or explicitly given it permission to do. That means that it is broadcasting its presence to the world, and any computer in the vicinity who kindly asks permission to log on, is indeed given permission to do so. This is not a mistake, this is by design.

Believe it or not, there are quite a few individuals who deliberately want to leave their access points open. It’s a philosophical decision for some, who hope that someday internet access will be open and freely available everywhere on earth, through open access points.

So there is nothing wrong about accessing open access points, and it’s certainly not stealing.

Solaris “Nevada” build 70 also fails to install: I give up

I tried installing Solaris Express Community Edition, code name “Nevada”, build 70. And this time I got a different error, which ended with the following statement:

Error 28: Selected item cannot fit into memory

After a bit of searching, I have discovered that it is likely caused by an incorrect build of GRUB. If I am correct, this will require rebuilding GRUB and creating a new ISO altogether. Translation: I cannot install this build of Solaris Express, at all, no matter how much I stamp my feet. I have to wait for build 71 to be released. But I am not going to.

It is becoming clear to me that older systems, such as mine, are to OpenSolaris developers what bugs are to windshields. They clearly don’t care, or it is so low on their priority list that they don’t even bother testing builds on these kind of systems. It may be worth noting that, yet again, it worked like a charm on my Athlon XP system.

This is ridiculous, are they just making it up as they go along? I know they make no guarantees regarding stability and such, but I am basing my choice on the HCL and the system requirements. That means I do not expect it to fly on my slow laptop, but it should at least install.

Why waste my time with incorrect minimum system requirements and outdated HCL entries? Or are these purely theoretical system requirements, for arm-chair computer enthusiasts to run on imaginary systems?

If this is the future of what SUN is touting as the “world’s most advanced operating system”, then I do not predict a very bright future. At least, it will be quite some time before I even think about trying OpenSolaris again.

OpenSolaris: no Pentium II support?

As I wrote earlier, I have been thinking about trying OpenSolaris. I checked the hardware compatibility list on SUN’s website, and my Toshiba Tecra 8000 was reported to work fine. The system requirements indicated that my laptop, with 256 MB RAM, 400Mhz Pentium II CPU and 40GB hard disk drive, should be able to run OpenSolaris just fine.

So I downloaded OpenSolaris “Nevada” Build 69 and burned a copy of the first CD image. Tried it on my Athlon XP machine, and it booted just fine. So I took it home and tried it on the laptop, but then I got the following error that repeated itself over and over again:

WARNING: init(1M) exited on fatal signal 9: restarting automatically

I googled the problem, and discovered that it is related to my Pentium II and its lack of SSE support. I also found the following bugreport: “snv boot failure since snv_66, no support for systems without SSE?”

So people with pre-pentium III CPUs are out of luck with builds 66-69, inclusive. Fortunately, it seems that a fix is to be implemented in “Nevada” Build 70, which I noticed became available for download yesterday.

I will try the first CD of that build later this evening and see if that works.

No spam for me, thank you

I’d just like to mention that wordpress.com has a great spam filter. I’ve been blogging here for just over a year now, and out of 1680 messages identified as spam, only two messages proved to be false positives. We are very pleased ;-)

Re-learning java for alt.binaries.unpack

Ever since I completed an introductory CS course in Imperative and Object Oriented Programming at my university, using mainly the Java programming language and a little C for the imperative programming part, I have been thinking about applying this knowledge to a useful programming project.

Since I did not feel much like reinventing the wheel, and considering the vast number of projects currently being developed this seemed almost inevitable, I have not done much programming these past few years. But I hope that is going to change.

Because one thing that continues to really annoy me, is the lack of decent GUI unpacking tools for Usenet binaries. In essence, something like the integrated unpacking utilities in GrabIt (alas, its unpacking features do not work in Wine), or more specifically something like AutoUnpack.

I have tried, and not without some success, to write a shell script which offers much the same functionality. But it needs to be invoked from the command line, and besides using the inconvenient cron scheduler, I don’t know how to make it run in the background like a daemon process. So instead of improving it I have given up on it.

Command line programs are simply not my cup of tea anyway, I don’t like using them as I constantly forget what options I need to use, or what the command is called, etcetera. Plastering the entire wall behind my desktop with cheat-sheets and man-pages is not my idea of user-friendly computing, thank you very much.

I need to write a program once and be able to run it anywhere, and of course it also needs a proper GUI. Mainly the first argument represents Java’s core strength, but Java will meet the second condition with equal satisfaction.

Yet, so far all I have is a rough idea. I haven’t even the faintest clue how to begin prototyping this project. Years have passed since completing the introductory programming course, and consequently my Java knowledge is dusty.

So first I must reacquaint myself with the language-formerly-known-as-Oak. I still have the original textbook I used: “Introduction to Java Programming”, third edition, by Daniel Y. Liang

Together with the freely downloadable e-book The Java Language Specification and using the Java API, I hope this is enough to regain sufficient knowledge of Java to make a fine beginning with my project.

And for the time being the project will be called “alt.binaries.unpack”. Not the shortest name, I know, but it is the most appropriate one I can think of right now.