Installing operating systems is kind of like a strange hobby for me. I don't usually write operating system reviews; it's more to get a more informed state of the different operating systems and distributions. I run Ubuntu on my home computer have been absolutely content with it. OpenSUSE users who work with me are typically surprised how fast I can get into Synaptic, install a package, and get back to work compared to Yast, which seems unnecessarily slow. However, I try to branch out from time to time to see what other developers have been working on.
Giving OpenSolaris a try
I have recently installed OpenSolaris 2008.11 on my spare laptop. This is my second install of Solaris this year. I first tried 2008.5 and had a few problems getting a few things to work. I can't remember the details, but I was working on a production machine, so I had to remove it and install a workable OS.
For those that aren't familiar to OpenSolaris, here's brief rundown. OpenSolaris is a free Sun Microsystems product based on the Solaris operating system. It is not compatible with Linux binaries, but is a UNIX-based system so many projects can be ported to OpenSolaris. It is known for a very robust threading implementation and has much commercial support from companies such and nVidia and Adobe, which provide useful drivers and plugins.
I downloaded the latest ISO from the website and through it into the CD-ROM. The default ISO is a live CD and allows a user to jump straight into using the operating system. The live session was rather slow in my case and I was going to install it anyway, so I just started the installation. After answering the basic questions about hard drive partitions, time zones, and user information, the installation started and lasted about 30 minutes.
bash shell now the default
The shell is the most basic connection of the user to the operating system, so I'll talk about that for a second. I have always used bash in my few years of using Linux. I do not have enough experience in other shells to understand merits of bash over some other shell, but I know bash well enough to do what I expect a shell to provide. On my previous installation of OpenSolaris, bash was not the default shell. Most of the time when I use a computer with a shell other than bash, I just switch to bash and am back to an environment I am more familiar with.
It appears in this newest release that bash is now the default. I've read several forums about the debate over what the default shell should be. One such forum post features a Solaris newbie bemoaning the default ksh shell and advocating bash since it has a greater familiarity for many users. Like the repliers note, it's all a matter of preference and is easy enough to change. Going into /etc/passwd, you can change the last segment of a given user's line to specify the shell the user should be provided. More on that can be found here. OpenSolaris switching to bash by default only represents a minor convenience to me since I no longer have to change it. You can also go into the System->Administration->Users and Groups to change the default shell for a given user, which I'm assuming modifies the passwd file for you.
Joining a wireless network
Using a laptop, it's pretty important to easily connect to a wireless router for internet access. Things were a bit funky here for me. Keep in mind I could be doing something totally wrong, but I imagine if that's the case, it's probably common for many new to Solaris as I've used GNOME a long time and haven't had any problems.
After trying to fight with the problem, I joined the laptop-discuss mailing list. They seem to be more helpful and direct for solving problems than IRC. At this time, several developers are still helping me with my problem, but I did find that by switching my encryption from WPA2 (AES+TKIP) to WPA (TKIP) seemed to solve the issue.
Text Rendering
The Java Desktop System comes with the Sans font as the default. My Ubuntu machine uses the same settings, but looks much sharper. For at least a temporary solution, I went into System->Preferences->Appearances and changed the default fonts to something sharper (I liked Verdana2000). It was much nicer on the eyes.
Display Drivers
It's critical to have up-to-date display drivers provided by the manufacturer. Despite efforts to make open-source drivers for graphics cards that provide high-performance 3D acceleration, most implementations lack stability. This is due to little reference the manufacturers choose to provide.
I typically use nVidia cards and luckily nVidia provides a fully supported driver for Solaris. Interestingly, this is the ONLY driver that nVidia provides that works on both x86 and 64-bit systems. I do not know enough about drivers, the Solaris operating system, or Solaris drivers to know why only Solaris has this universal driver. 2008.11 seems to come with the nvidia driver already installed, so new user should be able to take advantage of the GPU after installation.
Getting Flash
Flash on OpenSolaris is officially supported by Adobe. This link provides two ways of installing it. I opted for the second option in the comments section, which required a certificate from Sun.
New to Solaris
If you're new to Solaris/OpenSolaris, there are a few little differences between in it and Linux. I found this blog entry at Sun, which gave me some information other users had also struggled with understanding coming from a Linux background.
Conclusions
All in all, it was a fairly easy installation. My first impressions are so so. The default fonts look kind of blurred, which I recognize from Linux distros from years back. Even the youtube videos seem kind of pixelated. And when running them, prstat says firefox-bin is taking up 76% of the CPU, which seems a little too high.
For my next endeavor, I'm going to try some basic development on OpenSolaris including getting to know the package manager, using subversion, Netbeans, etc.
Thursday, January 1, 2009
Monday, May 12, 2008
Up to Date
I've used Debian for a bit and really love the package manager. However, I'm still learning how these repositories work. My first attempt at updating my system gave me an error.
~# apt-get update
... http://ftp.debian-ports.org ... NO_PUBKEY found ...
Basically each package in the repository is signed using GPG. When apt tries to use the repository, it must have the public GPG key on hand to authenticate it. The list of repositories apt uses can be found in /etc/apt/sources.list. I read that apt could ignore this, but didn't seem like a good practice to start.
To read up on how this authentication works, I browsed a well-written article "Securing Debian Manual", which explained how Debian handled this [1]. It mentioned how to add the key, but also said that finding the public key for a given site wasn't exactly uniform across repositories. After digging around in http://ftp.debian-ports.org for a while, I went to the IRC channel and just asked. I got a response instantly. He/she posted a link to http://www.debian-ports.org/archive, which I wouldn't have found for a quite a while. It gave me two commands to download and add the key.
~# gpg --keyserver hkp://subkeys.pgp.net --recv-keys 43229C06
... (a bit of text)
~# gpg --export 43229C06 | apt-key add -
... (a bit of text)
I wasn't sure if it worked or not since I am inexperienced in doing this. I saw the phrase "gpg: no ultimately trusted keys found", which I thought my be an error. I googled the error, and was learned that by default, gpg is setup to not ultimately trust any keys and in this case it didn't matter. I'm still not sure what the rigorous definition of "ultimately trust" is, but I took their word [2].
After running apt-get update, apt updated with no mention of NO_PUBKEY, so I guess it worked.
~# apt-get update
... http://ftp.debian-ports.org ... NO_PUBKEY found ...
Basically each package in the repository is signed using GPG. When apt tries to use the repository, it must have the public GPG key on hand to authenticate it. The list of repositories apt uses can be found in /etc/apt/sources.list. I read that apt could ignore this, but didn't seem like a good practice to start.
To read up on how this authentication works, I browsed a well-written article "Securing Debian Manual", which explained how Debian handled this [1]. It mentioned how to add the key, but also said that finding the public key for a given site wasn't exactly uniform across repositories. After digging around in http://ftp.debian-ports.org for a while, I went to the IRC channel and just asked. I got a response instantly. He/she posted a link to http://www.debian-ports.org/archive, which I wouldn't have found for a quite a while. It gave me two commands to download and add the key.
~# gpg --keyserver hkp://subkeys.pgp.net --recv-keys 43229C06
... (a bit of text)
~# gpg --export 43229C06 | apt-key add -
... (a bit of text)
I wasn't sure if it worked or not since I am inexperienced in doing this. I saw the phrase "gpg: no ultimately trusted keys found", which I thought my be an error. I googled the error, and was learned that by default, gpg is setup to not ultimately trust any keys and in this case it didn't matter. I'm still not sure what the rigorous definition of "ultimately trust" is, but I took their word [2].
After running apt-get update, apt updated with no mention of NO_PUBKEY, so I guess it worked.
Thursday, May 1, 2008
Network Fixed
One thing that appeals to me about open software movements like the Hurd is the team development. IRC is a traditional method of communication on the internet--something like a very basic chat protocol. I have used IRC several times before, but usually with poor results. Often the channel is completely empty or no one wants to talk about anything related to the channel topic. But like bug-hurd, I have enjoyed the feedback from the Hurd group.
On this particular night, I jumped on and asked some questions about the e-mail I sent assuming most people on the IRC channel also followed the bug-hurd mailing list. After getting a few e-mails back saying that it worked fine for them, I found two people that gave me a few ideas of how to fix it. First, they never used any flags for qemu--the default NIC always functioned fine. This led us to believe my OS (Ubuntu 7.10) provided some wacked configuration of qemu.
Just for kicks, I ran it through kvm with no flags. I started out checking to see if my eth0 was established.
~# devprobe eth0
eth0
That's a good start. Whatever configuration kvm uses obviously didn't need any NIC flags. Starting up pfinet didn't give any errors either. Usually I use ping to check my network connection, but since that was installed yet, I tried a simple apt-get update. After a few seconds, the files started rolling in. Network connection!
I thanked the two guys on IRC and posted my solution on bug-hurd. I figure the next time someone has that problem, it will be documented in some mailing archive (if it wasn't already...).
On this particular night, I jumped on and asked some questions about the e-mail I sent assuming most people on the IRC channel also followed the bug-hurd mailing list. After getting a few e-mails back saying that it worked fine for them, I found two people that gave me a few ideas of how to fix it. First, they never used any flags for qemu--the default NIC always functioned fine. This led us to believe my OS (Ubuntu 7.10) provided some wacked configuration of qemu.
Just for kicks, I ran it through kvm with no flags. I started out checking to see if my eth0 was established.
~# devprobe eth0
eth0
That's a good start. Whatever configuration kvm uses obviously didn't need any NIC flags. Starting up pfinet didn't give any errors either. Usually I use ping to check my network connection, but since that was installed yet, I tried a simple apt-get update. After a few seconds, the files started rolling in. Network connection!
I thanked the two guys on IRC and posted my solution on bug-hurd. I figure the next time someone has that problem, it will be documented in some mailing archive (if it wasn't already...).
Playing with Debian GNU/Hurd
Debian GNU/Linux is a great operating system. Debian provides deb package management, which IMHO is the best of any distribution of Linux. Debian also packages its operating system using GNU Mach as the kernel and runs the Hurd to manage the system. It was recommended by several sites that one use Debian GNU/Hurd, if you're a beginner. I am.
First, I decided to run Debian GNU/Hurd in qemu. For those not familiar with qemu, it's a x86 hardware emulator. I chose to use an emulator as I'm not sure what hardware I had sitting around that was compatible with GNU Mach and GNU Hurd. Debian GNU/Hurd actually provides a image file specifically for qemu, so it's easy to just jump right in. I just downloaded debian-hurd-k16-qemu.img.tar.gz from the site and untarred everything. Then I just ran qemu using this as the hard drive.
~# qemu -hda debian-hurd-k16-qemu.img
After running this command, I see the GRUB menu provided. I chose the first option
After booting, I login as root (login root) and I'm running the GNU Hurd. Woo hoo! Of course the first thing to do is configure networking. Following the guide at http://www.bddebian.com/~wiki/hurd/running/qemu/,
I try setting up the network.
~# settrans -afgp /servers/socket/2 /hurd/pfinet -i eth0 -a 10.0.2.15 -g 10.0.2.2 -m 255.255.255.0
/hurd/pfinet: eth0: (os/device) no such device
settrans: /hurd/pfinet: Translator died
Okay, now I was totally lost. They didn't mention this in the guide. First, I joined the Bug-Hurd mailing list. This mailing list is not directly related to the Debian project, but is found on the GNU Hurd website under Getting Help. After a quick description of my problem, I received an answer within several hours (I have always received feedback from this mailing list within 24 hours). Someone told me how I could find the problem. First, see if the ethernet card was detected.
~# devprobe eth0
~#
Alright, that was the first problem. The network card wasn't detected correctly. To figure out what exactly devprobe does, you can type: devprobe --help. Just FYI, the GNU Hurd doesn't use man pages at the moment--not sure if they ever will. Most programs, however, can provide usage information by passing the --help. After sending this information back to the person, who responded, he chewed me out for not replying to the whole mailing list. This is just another thing I've learned along the way. They don't like having private conversations. For one reason, problems like this that are sorted out on the mailing list are archived and can be searched later by people having the same problem. Thus problems are solved once and we're not reinventing the wheel. Don't feel bad about asking stupid questions (after looking through the documentation for a reasonable amount of time).
I was then told that my Linux distribution at the time, Ubuntu 7.10, used a version of qemu with a default NIC that was not supported by the Hurd. He supplied a flag to qemu that would use a supported NIC.
I now start qemu with the following:
~# qemu -hda debian-hurd-k16-qemu.img -net nic,model=ne2k_isa
After booting the Hurd now, running devprobe gives me the following:
~# devprobe eth0
eth0
Success! A NIC card has been found and assigned as eth0. Running settrans no longer gives an error.
# echo "nameserver 10.0.2.3" > /etc/resolv.conf
Supposedly that is all it takes to get network up and running. I do a quick ping of some website to see if it works.
# ping www.yahoo.com
-bash: ping: command not found
Drat! I find out through seaching ping does not come with the install and must be manually added. So I try installing a package.
# apt-get install lynx
I figure running lynx should tell me if I have internet access. The system recognizes the package and goes to fetch it. It seems to have trouble connecting to ftp.uk.debian.org. I ping it from my Linux distro and see the site is in fact running. I e-mail bug-hurd and decide to take a break. But the Hurd is now booting in qemu!
First, I decided to run Debian GNU/Hurd in qemu. For those not familiar with qemu, it's a x86 hardware emulator. I chose to use an emulator as I'm not sure what hardware I had sitting around that was compatible with GNU Mach and GNU Hurd. Debian GNU/Hurd actually provides a image file specifically for qemu, so it's easy to just jump right in. I just downloaded debian-hurd-k16-qemu.img.tar.gz from the site and untarred everything. Then I just ran qemu using this as the hard drive.
~# qemu -hda debian-hurd-k16-qemu.img
After running this command, I see the GRUB menu provided. I chose the first option
After booting, I login as root (login root) and I'm running the GNU Hurd. Woo hoo! Of course the first thing to do is configure networking. Following the guide at http://www.bddebian.com/~wiki/hurd/running/qemu/,
I try setting up the network.
~# settrans -afgp /servers/socket/2 /hurd/pfinet -i eth0 -a 10.0.2.15 -g 10.0.2.2 -m 255.255.255.0
/hurd/pfinet: eth0: (os/device) no such device
settrans: /hurd/pfinet: Translator died
Okay, now I was totally lost. They didn't mention this in the guide. First, I joined the Bug-Hurd mailing list. This mailing list is not directly related to the Debian project, but is found on the GNU Hurd website under Getting Help. After a quick description of my problem, I received an answer within several hours (I have always received feedback from this mailing list within 24 hours). Someone told me how I could find the problem. First, see if the ethernet card was detected.
~# devprobe eth0
~#
Alright, that was the first problem. The network card wasn't detected correctly. To figure out what exactly devprobe does, you can type: devprobe --help. Just FYI, the GNU Hurd doesn't use man pages at the moment--not sure if they ever will. Most programs, however, can provide usage information by passing the --help. After sending this information back to the person, who responded, he chewed me out for not replying to the whole mailing list. This is just another thing I've learned along the way. They don't like having private conversations. For one reason, problems like this that are sorted out on the mailing list are archived and can be searched later by people having the same problem. Thus problems are solved once and we're not reinventing the wheel. Don't feel bad about asking stupid questions (after looking through the documentation for a reasonable amount of time).
I was then told that my Linux distribution at the time, Ubuntu 7.10, used a version of qemu with a default NIC that was not supported by the Hurd. He supplied a flag to qemu that would use a supported NIC.
I now start qemu with the following:
~# qemu -hda debian-hurd-k16-qemu.img -net nic,model=ne2k_isa
After booting the Hurd now, running devprobe gives me the following:
~# devprobe eth0
eth0
Success! A NIC card has been found and assigned as eth0. Running settrans no longer gives an error.
# echo "nameserver 10.0.2.3" > /etc/resolv.conf
Supposedly that is all it takes to get network up and running. I do a quick ping of some website to see if it works.
# ping www.yahoo.com
-bash: ping: command not found
Drat! I find out through seaching ping does not come with the install and must be manually added. So I try installing a package.
# apt-get install lynx
I figure running lynx should tell me if I have internet access. The system recognizes the package and goes to fetch it. It seems to have trouble connecting to ftp.uk.debian.org. I ping it from my Linux distro and see the site is in fact running. I e-mail bug-hurd and decide to take a break. But the Hurd is now booting in qemu!
Wednesday, April 30, 2008
Heard of the Hurd?
A few months ago I came across a Slashdot article The Great Microkernel Debate Continues, which peaked my interest in operating systems. The article left me specifically wondering if any projects were actually actively developing an operating system based on a microkernel.
A popular microkernel developed almost 30 years ago is the mach kernel. This microkernel has developed over the years and now has the latest implementation, GNU Mach, maintained by the GNU Project. The kernel itself provides very little functionality--it handles processes, threads, IPC, etc. Outside of this kernel, runs the Hurd.
"Hurd" is an acronym for "Hird of Unix-Replacing Daemons", where "Hird" is an acronym for "Hurd of Interfaces Representing Depth" [1]. The Hurd is a collection of servers outside the kernel, which interface directly with Mach and provide a slew of functionality: a proc server, which generates processes; a pfinet server, to handle network connections; etc.
Although is has been labeled as having a extremely slow development cycle, it is a fun and growing operating system that provides some very cool ways to think about operating systems. One of the Hurd's funnest ability's the translator. The Hurd provides a set of translator libraries, where one can create a program/server called a translator, and can have a file-name-space representation. As such, when a program like ls or an application queries the file system, this translator can return a file hierarchy.
For example, a person can cd to a directory provided by a translator ascii. When a person enters this directory and types ls, ascii receives a request for the file system. ascii can reply any way it wants, but say ascii simply shows ASCII text files of some specified directory like /tmp.
/tmp# ls
a.out source.c
/tmp# cd ~/ascii
~/ascii# ls
source.c
In the example above, a source file source.c and an executable a.out are stored in the /tmp directory. When ls runs inside of ~/ascii, the ascii translator that is running queries /tmp, uses the file command, and presents source.c as the only ASCII file. If the user cats something to this file ascii presents, ascii can either concatenate this input to the actual file in /tmp or do something else with the input. This provides a very powerful and intuitive mechanism for developers.
To read a more detailed introduction to Hurd translators and some other cool aspects of this GNU project goto http://www.gnu.org/software/hurd/hurd.html.
A popular microkernel developed almost 30 years ago is the mach kernel. This microkernel has developed over the years and now has the latest implementation, GNU Mach, maintained by the GNU Project. The kernel itself provides very little functionality--it handles processes, threads, IPC, etc. Outside of this kernel, runs the Hurd.
"Hurd" is an acronym for "Hird of Unix-Replacing Daemons", where "Hird" is an acronym for "Hurd of Interfaces Representing Depth" [1]. The Hurd is a collection of servers outside the kernel, which interface directly with Mach and provide a slew of functionality: a proc server, which generates processes; a pfinet server, to handle network connections; etc.
Although is has been labeled as having a extremely slow development cycle, it is a fun and growing operating system that provides some very cool ways to think about operating systems. One of the Hurd's funnest ability's the translator. The Hurd provides a set of translator libraries, where one can create a program/server called a translator, and can have a file-name-space representation. As such, when a program like ls or an application queries the file system, this translator can return a file hierarchy.
For example, a person can cd to a directory provided by a translator ascii. When a person enters this directory and types ls, ascii receives a request for the file system. ascii can reply any way it wants, but say ascii simply shows ASCII text files of some specified directory like /tmp.
/tmp# ls
a.out source.c
/tmp# cd ~/ascii
~/ascii# ls
source.c
In the example above, a source file source.c and an executable a.out are stored in the /tmp directory. When ls runs inside of ~/ascii, the ascii translator that is running queries /tmp, uses the file command, and presents source.c as the only ASCII file. If the user cats something to this file ascii presents, ascii can either concatenate this input to the actual file in /tmp or do something else with the input. This provides a very powerful and intuitive mechanism for developers.
To read a more detailed introduction to Hurd translators and some other cool aspects of this GNU project goto http://www.gnu.org/software/hurd/hurd.html.
Subscribe to:
Posts (Atom)