sudo in CentOS

I finally got sick and tired of having to, in CentOS, type in su, followed by the root password, just to run Deadwood (which needs to run as root since it needs to bind to port 53), followed by exiting the root prompt. So, I finally did a simple RTFM with the “sudo” man page and edited /etc/sudoers so that my user account can use sudo to run the program. Just like how things are done in Ubuntu.

Come to think of it, I could have used dns_port to have Deadwood bind to a unprivileged port and then just connect to that port. But, then again, I would have to add selectable port numbers to askmara (my command-line utility in MaraDNS for making DNS queries from the command line). Nah.

Now, if only there was a sudo get_me_a_job and sudo get_my_wife_a_US_visa (well, there is the second one, but it supposedly takes about a year; I need a sudo nice -20 get_my_wife_a_US_visa so they will do it faster).

Deadwood snapshot update: Looks like I found a bug

Well, after doing a whole bunch of SQA testing, it looks like I have finally found a bug.

It looks like Deadwood isn't caching every single element like it should.

I discovered this when making sure maximum_cache_elements does the right thing.

I will investigate this bug and keep readers posted here. People can see the work I have been doing at the usual place

Update: The issue was with the test, not Deadwood; fixed and there will be a fixed Deadwood update tomorrow

---

I stand corrected.

I mentioned that the Brasero CD/DVD burning program doesn't correctly make records so Windows can see long file names on burned disks. This is incorrect; the bug is actually that there's something strange about Brasero-burned disks that make it so VMware player doesn't always see the long file names on these disks.

I will investigate and report, but this looks like a VMware player bug, not a Brasero bug.

Deadwood snapshot update; Windows XP is better than Ubuntu

I have uploaded a new snapshot of Deadwood today with tests added for upstream_servers and upstream_port.

I have just moved and haven't been able to get online at the new place yet. The place is supposed to have internet, so I will work with my new roommate and will look at the router this afternoon to see if the issue can be resolved (it could be that the key changed when they changed the ESSID but no one remembers doing this, much less the new key, or it could be that things are broken upstream).

If I can't resolve the issue with internet at home, I will not be able to release Deadwood again until Monday. Update: I now have internet working at my new place; expect to see a Deadwood update tomorrow.

This release can be downloaded at the usual place

---

While waiting for CentOS 5.3 to be released, I moved things around on my hard disk and reinstalled Windows XP.

It's a relief compared to Ubuntu. Everything works. Without problem. Things that took me days to resolve work out of the box in Windows XP: Getting a password protected screen saver (In Windows XP, it's actually done with "Change session" from the start menu) that doesn't crash the system and getting VMware to work.

When I put in my 50 meg "hockey rink" business card CD, it mounts within seconds. In Ubuntu, it would not mount at all or take over a minute to mount; this is a problem I was never able to resolve. Indeed, I spent a day pulling out my hair and wasting money burning expendable media until I realized this was an Linux-specific problem and not a problem with the media in question.

Sound in VMware isn't a problem; I can have multiple guest operating systems with sound active at the same time. In Ubuntu, only one application can use the sound card at the same time.

The keyboard just works in Windows XP; I needed to tweak configuration files to get it to work in Ubuntu.

Windows XP is a good deal more light and responsive running VMware player than Ubuntu; suspending or restoring an OS would often take two or three minutes in Ubuntu but only takes a few seconds in Windows XP. Windows XP and the Windows VMware client are far more lightweight; I can comfortably run three guest operating systems at the same time with 512 megs allocated for each guest; Ubuntu could only run two and would thrash (swap excessively and have the computer be unresponsive) with suspending or restoring a guest OS.

Comprared to Ubuntu, things work like a dream in Windows XP.

Nothing has changed since this blogger posted this why Ubuntu sucks blog back in 2007. Ubuntu still sucks (for my purposes: Having a good VMware host operating system) and Windows XP is a far better operating system.

I've been using Linux since 1995 and refused to dual boot my machine until 2003. Linux used to be more stable but harder to use; Ubuntu is trying to make another Windows but I just don't think it makes sense to try and shoestring all of the open source projects out there to make an end-user desktop. For example, Linux was never designed to allow someone to just insert or remove a CD without mounting or unmounting it; trying to make Linux do this just causes it to be unable to read media Windows XP can read without problem.

I think the real solution to making a open-source desktop environment is to make an operating system designed to be on the users desktop from the start. There are at least two projects that try to do this: Haiku OS (an open-source implementation of the failed 1990s BeOS) and Syllable (an open-source OS based on ideas from Amiga OS and other sources)

I will let people know how things work with CentOS 5.3 once CentOS 5.3 is available.

Deadwood snapshot update

I have released a slightly updated snapshot of Deadwood today; I have updated the DwMain man page to remove the BUGS section (this used to mention the "Google bug" which I have since fixed) and added tests for the maradns_uid and maradns_gid parameters. It can be downloaded at the usual place.

---

I can't wait until CentOS 5.3 comes out so I can wipe Ubuntu from my hard disk. I gave Ubuntu a second chance; the OS was just as buggy as ever.

Deadwood and MaraDNS updates; yet another Ubuntu rant

I have added a single test to Deadwood today: a test for the parameter bind_address. I now only have 16 more dwood2rc parameters to make tests for. This work can be downloaded by clicking on this link.

I have also integrated Milan Kupcevic's patch to add dns_port to zoneserver; the latest snapshot with this patch applied can be downloaded at this link.

---

Ubuntu does it again! Yet another Ubuntu bug, what a surprise.

I don't think I've mentioned on this blog that Ubuntu's build of Abiword crashes when I go to insert -> symbol. Do the folks at Ubuntu do any testing at all? Or do they just foist a beta on unsuspecting users as the latest and greatest release of Ubuntu?

Another issue: Ubuntu's auto-mounter (a.k.a. hal) is really unstable. It either can't mount a perfectly good CD (Ubuntu is a little annoyed with CDs; this isn't a problem when booting from a CD in the BIOS in Windows, but it takes a couple of minutes to mount a CD in Ubuntu for whatever reason), or won't properly umount the CD/DVD when I eject it. Again, do they test anything with Ubuntu?

I'm through with Ubuntu. Next time I install an OS, I'm going to install CentOS or Fedora Core. CentOS 5.3 should come out in a couple of weeks; I'm going to make that my main OS and ditch Ubuntu. Ubuntu is nothing but a headache that makes me want to run to the Linux hater's blog.

Deadwood roadmap; On Ubuntu

I have looked at the Deadwood code in CentOS 5.2, and I'm seeing the same problem I saw in Cygwin a couple of weeks ago: DwTcp (the TCP half of Deadwood) doesn't work. Strange, because the code did work back in late 2007. So, I'm going to have to work on this code before releasing another stable release of Deadwood.

---

You know, my issue is not with Linux. My issue is with Ubuntu Linux, which is trying to make a desktop OS to compete with Windows. Linux has made a lot of progress for the end-user ever since the mid-1990s, when FVWM was the state of the art for end-user usability.

But, Linux as an end-user desktop is beta-quality at best. There's a number of reasons for this. One is that it's impossible to give Linux programmers the kind of discipline needed to make a stable end-user desktop. People constantly want to branch out in new directions and develop new software instead of making stable the software they have already developed. Since people, by and large, aren't getting paid, people aren't very motivated to the the boring, uninteresting programming that users want.

Linux kernel developers don't want to make a stable API or ABI for drivers; this results in people forced to use unstable and untested kernels to have a system that works with their hardware. Instead of continuing development on KDE3, it has been replaced with KDE4. Unfortunately, KDE4 doesn't even have a GUI-based network configuration program; so a perfectly good desktop environment has been abandoned and replaced by one without basic functionality.

Ubuntu essentially forces me to use Gnome; I tried to use it with FVWM in 2007 and 2008 and found that I couldn't do things like configure my network card with "ifconfig" and what not without some daemon erasing my configuration or making my configuration not work.

So, yes, with Ubuntu Linux I'm forced to use unstable software that crashes. This is very different from the situation in the 1990s, where, while not friendly and needing a lot of training to master, Linux had a lot more stability than the not-protected versions of Windows (Windows 3.11, Windows 95, etc.)

Linux sucks: My system has crashed three times today

Linux sucks: My Ubuntu 8.10 system has crashed three times today.

Three times.

All three times when I password protected the system. Twice, the system crashed when I inserted a blank CD or DVD while the password protected screen saver was activated. This might have been caused by VMware (which tries to make mounted CDs visible to the guest OS), so I told VMware to not look for a CD and the system didn't crash while the screensaver was active.

The third time, my boss called me in to his office to help him with an email. When I came back out again, my system had rebooted, with messages like this in the logs:

Feb 10 12:24:09 Merequetengue kernel: [ 5852.179340] compiz.real[7047] trap stack segment ip:41024e sp:7fff605b93b0 error:0
Feb 10 12:24:16 Merequetengue kernel: [ 5859.014131] metacity[6971]: segfault at 0 ip 000000000046441e sp 00007fff05278c70 error 4 in metacity[400000+88000]

Needless to say, I'm giving Ubuntu one last chance. I'm going to get rid of Gnome, which makes Windows 3.11 look positively stable, and try using the KDE desktop. Yeah, this means I have to reconfigure all of my wireless network connections again. What a pain.

I can hear the bullshit from the freetards:

• Oh, my system doesn't crash like this so it must be a hardware problem (No, because my system most assuredly does not crash like this when running Windows XP, or CentOS for that matter)
• Well, it crashes because you're a clueless Linux newbie (No, I've been using Linux since June 19, 1995, back when you were playing with GI Joe dolls)
• Maybe you should try harder to make your system not crash (No, maybe Canonical should distribute stable operating systems that don't crash three times a day)
• You must be a paid Microsoft shill (No, please take your medication when you have paranoid fantasies like this)
• You really should buy Linux-compatible hardware (Guess what, idiot freetard, I did. I bought a Dell 1420 Linux-compatible computer)

Linux sucks. No operating system worth its salt crashes three times in one day.

I'm happy the Linux haters blog is back again. Linux needs less zealots who think the three crashes I had today were hallucinations, and more people willing to look at and resolve the serious desktop usability problems Linux currently has.

Update: the third crash was not, to be pedantic, a crash; while the screen saver was running, something happened to kill the X process. It was, for all intents and purposes, a crash: I had to reboot my two VMware virtual machines and restart all applications before working again.

Kde4 is crap; no GUI network manager (and no way of installing KDE3, which does have a network manager, instead with Ubuntu); XFCE is also crap, with a very confusing menu on right click and no apparent GUI network manager.

My current workaround is to use Gnome, but to turn off all cutesy effects (right click on root window, change desktop background, then click on the "effects" tab) and to use "xlock" instead of Gnome's stupid screen locker (sudo apt-get install xlockmore then run the command as xlock). I also have detached the optical drives in the VMware guests. I'll let people know whether or not this stops the crashes.

MaraDNS snapshot update: Webpage updated

After finally getting VMware player to work in Linux, I am able to get back to finishing up the XeroBank-sponsored MaraDNS development. I have updated a new version of MaraDNS, which simply updates the MaraDNS.org webpage. I no longer have a roadmap page, since the page is outdated and the most current information about MaraDNS is right here on the blog. I have added a list of sponsors whose generosity make continued MaraDNS development and improvements possible.

The only work I have to do before releasing MaraDNS 1.3.13 is to re-verify that all of the regressions pass, and to perform a standard stress test I like to do before making a new MaraDNS release. The release should be done next week sometime.

The snapshot can be downloaded by clicking on this link

---

The reason for the delay in making a new snapshot of MaraDNS is because I decided to use Linux again. Ubuntu Linux, even. It took me the last three days to make the appropriate backups, install Ubuntu, and then struggle with getting VMplayer to work in Ubuntu 8.10.

I had a number of problems with VMware player, which I have touched on in previous blog entries. One is that the CentOS 5.2 guest was not correctly set up to handle key repeat speed in a consistent manner. I fixed this by adding divider=10 clocksource=acpi_pm to all of the kernel entries in /etc/grub.conf (in the guest operating system); here is what my grub.conf looks like:


default=0

timeout=5

splashimage=(hd0,0)/grub/splash.xpm.gz

hiddenmenu

title CentOS (2.6.18-92.1.22.el5)

root (hd0,0)

kernel /vmlinuz-2.6.18-92.1.22.el5 ro root=/dev/VolGroup00/LogVol00 rhgb quiet divider=10 clocksource=acpi_pm

initrd /initrd-2.6.18-92.1.22.el5.img

title CentOS (2.6.18-92.1.1.el5)

root (hd0,0)

kernel /vmlinuz-2.6.18-92.1.1.el5 ro root=/dev/VolGroup00/LogVol00 rhgb quiet divider=10 clocksource=acpi_pm

initrd /initrd-2.6.18-92.1.1.el5.img

title CentOS (2.6.18-92.el5)

root (hd0,0)

kernel /vmlinuz-2.6.18-92.el5 ro root=/dev/VolGroup00/LogVol00 rhgb quiet divider=10 clocksource=acpi_pm

initrd /initrd-2.6.18-92.el5.img


Note that this solution is CentOS-specific; search on vmware.com's web site for the "magic recipe" to add to other distributions' kernels.

Another is that the arrow keys and a bunch of other keys do not work. There are two solutions posted various places on the internet; the one that works best for me is the one where we just define all of the keys that don't work with VMware player. I added the following lines to /etc/vmware/config (in the host operating system):


xkeymap.keycode.108 = 0x138 # Alt_R
xkeymap.keycode.106 = 0x135 # KP_Divide
xkeymap.keycode.104 = 0x11c # KP_Enter
xkeymap.keycode.111 = 0x148 # Up
xkeymap.keycode.116 = 0x150 # Down
xkeymap.keycode.113 = 0x14b # Left
xkeymap.keycode.114 = 0x14d # Right
xkeymap.keycode.105 = 0x11d # Control_R
xkeymap.keycode.118 = 0x152 # Insert
xkeymap.keycode.119 = 0x153 # Delete
xkeymap.keycode.110 = 0x147 # Home
xkeymap.keycode.115 = 0x14f # End
xkeymap.keycode.112 = 0x149 # Prior
xkeymap.keycode.117 = 0x151 # Next
xkeymap.keycode.78 = 0x46 # Scroll_Lock
xkeymap.keycode.127 = 0x100 # Pause
xkeymap.keycode.133 = 0x15b # Meta_L
xkeymap.keycode.134 = 0x15c # Meta_R
xkeymap.keycode.135 = 0x15d # Menu
xkeymap.keycode.107 = 0x137 # Print Scrn


Finally, I had serious problems with sound playback stuttering, making it impossible for me to play back all of a single .mp3 file in my Windows XP guest operating systems. I fixed this problem by adding the following lines to the .vmx file for my Windows XP guest operating systems (this is a modification to the relevant .vmx file on the host operating system):


sound.virtualDev = "es1371"
sound.highPriority = TRUE
sound.buffering = "10000000000.0"
sound.copyDelayFactor = "1000000.0"
sound.directSound = "false"
sound.ignoreOverflows = "true"
sound.maxLength = "2048"
sound.smallBlockSize = "1024"
sound.virtualrealcorrection = "10000000000.0"
pciSound.priorityBoost = "true"


I also have these lines describing sound in the /etc/vmware/config file:


sound.Autodetect = true
sound.fileName = "-1"
sound.maxLength = 64
sound.smallBlockSize = 32


But I don't think this second batch of lines help; I had problems until adding the first batch of sound-related lines to my .vmx files.

And, oh, it's only possible to play sound on one VMware guest at a time, and not while playing sounds from other sources. I only use one VMware guest at a time that needs sound (my CentOS 5.2 guest doesn't), and have disabled all sounds in my host's Gnome user interface.

Now, observe that all of these issues are Linux-specific issues. I tested; the Windows XP 32-bit host doesn't have any of these issues (except for the CentOS one, which is caused by the Linux kernel). This is my annoyance with Linux: Things just work on Windows. Things don't work on Linux without spending days tweaking things, for a variety of reasons, mainly serious problems with Linux's sound architecture.

This is why I'm going to use a minimum of applications in Linux; the only real application I will use is VMware, and just do all my work from inside virtual machines I set up. This way, I only have the headache of configuring a minimum of applications:

• The VMware player
• The firewall (I will describe how I set up ufw to protect my system in a future blog entry)
• The core operating system (including things like the sound card, the networking, the video card, etc.)

To be fair, each release of Ubuntu results in more and more things just working; there used to be issues with getting wireless networking to work that are now as simple as configuring wireless in the GUI to resolve. The video card and sound (except inside VMware) also just worked without any hassle, complete with the default resolution being the resolution of my LCD monitor (As I recall, this was an issue in earlier versions of Ubuntu).

So, yeah, progress is being made in Linux. It might even be ready for the end-user desktop one of these years.

VMware update: Keyboard repeat problem solved

Well, playing around with VMware some more, I have discovered some issues which I have been working on fixing.

One is that the CentOS 5.2 guest had some issues with the keyboard repeat rate being inconsistent. This problem made the system nay-to-impossible to be productive on. After much struggle, and extensive Google searching, and trial and error, I found the solution was to add some parameters to the guest kernel:

divider=10 clocksource=acpi_pm

Edit /etc/grub.conf and add these two parameters to all of the lines marked kernel. Next, reboot the guest OS.

Once I did this, the issue seems to have gone away (knock on wood).

The other issue is with stuttering sound when playing a mp3 in the Windows guest OS. This issue does not appear to affect all applications; I was able to talk to my girlfriend over SkyPE in a Windows guest OS for an hour last night without any stuttering.

I haven't found a solution to this issue yet; some people indicate that VMware player 2.0 doesn't have this issue, so I will see if I get get better results from VMware player 2.0.5 instead of 2.5. I will let people know if I can resolve the Windows sound issue; my gut instinct is that this is caused by Linux, since sound in Linux is a bloody mess.

Update: The sound problem doesn't exist when using Windows XP as a host. So, this is a Linux-specific problem. Did I mention that the sound is a lot quieter in Linux than it is in Windows on the same machine? Linux sound is a disaster; until basic desktop functionality like sound works, Linux will stay in the server back room.

Second update: OK, after much prodding around on the internet, I found some useful information over at Sanbarrow.com. I added the following to the .vmx file for my Windows XP virtual machine, and it appears to resolve the issue:

sound.virtualDev = "es1371"
sound.highPriority = TRUE
sound.buffering = "10000000000.0"
sound.copyDelayFactor = "1000000.0"
sound.directSound = "false"
sound.ignoreOverflows = "true"
sound.maxLength = "2048"
sound.smallBlockSize = "1024"
sound.virtualrealcorrection = "10000000000.0"
pciSound.priorityBoost = "true"

As a related issue, adding this to /etc/vmware/config resolves the keyboard issue, and appears to be the best fix:

xkeymap.nokeycodeMap = true

Final update: The reason why I didn't have any problems with Skype last night is because I was using a USB headset. When a USB headset is connected to a guest OS, the guest OS talks directly to the USB headset and doesn't use the host's sound card, so the stuttering problems don't exist when using a headset.

Indeed, it's possible to have one guest play a song or what not while another guest plays sound through the USB headset at the same time.

Linux (OK, Ubuntu) sucks: Updates

Linux's update handling was obviously designed by a bunch of kids in their mommy's basement who spend all day on the internet, and whose mommy pays for them to have a high-speed broadband connection.

Down here in Mexico, I don't have an ultra-fast broadband connection. I don't have internet at home either. I'm just a recovering Linux fanboy trying to develop a life beyond sitting around on Slashdot and Digg all day flaming anyone who doesn't think Linux is God's gift to earth.

So, this morning, I booted in the Ubuntu that I installed last weekend (I had some time to kill before dating a girl Saturday evening). Got on the network, then started seeing if I could download the updates to bring my system up to date.

Well, except the connection here at work was seriously lagging (it does that sometimes). The DNS broke down about halfway through the painfully slow process of seeing what packages were available to be updated.

Does the update manager bother to cache the IPs of the site it connected to to get updates? Nope. Is there a usable DNS server on the localhost port in the default install of Ubuntu? Nope. Does Ubuntu come with a usable compiler and development environment so I can compile my own DNS server on the localhost port? Nope, you have to apt-get it.

apt-get is another usability nightmare. You would think apt is smart enough to figure that anyone who wants a C compiler also wants to, you know, compile programs that run. But, no. Once you get gcc, you also have to hunt down and get the "libc-dev" package to compile anything.

So, anyway, this process of looking for updates failed halfway through. I had a list of packages to update, but I have no idea if some critical security update was missed. I had better things to do with my time than to restart the "look at the big huge package lists to see what updates I need" process.

So I booted back in to Windows.

Let's compare this to Microsoft. With Microsoft, the update process is one that is perfectly usable, even on a dialup connection. It will run the updates in the background, with a low priority given to the packets uses for downloading updates. This required something Linux isn't very good at: Coordination with the people responsible for making sure the operating system is up to date and the people who implement the TCP stack is as simple as getting a few people together in a meeting room somewhere in Redmond and talk about the need to have it so downloading updates can be done on a slow connection that is often offline without affecting the user's internet experience.

The update process is one where, if something fails, like DNS dying halfway through the process, the task is stopped where the failure happened, and can be painlessly started again without needing to go back to square one. It's one where downloads can be interrupted and resumed again at any time.

The closest Linux gets is with CentOS, where I can just go here and download the updates by hand. Should the download be interrupted, I only have to re-download one package instead of the whole spiel. Once I download the updates, I then have to, by hand, see which RPM files I have on my system and update them. OK, I can kinda-sorta automate this with something like for a in *rpm ; do if rpm -qa | grep $( echo $a | awk -F- '{print $1}' ) ; then rpm --upgrade --nodeps $a ; fi ; done but that's a little unreliable and buggy.

But even that doesn't hold a candle to Microsoft's update process. Don't get me started on the distributions where the distribution maker one day lost interest in keeping the distribution up to date, making it so the distribution has no security updates whatsoever.

avahi-autoipd is evil

There is a process in Ubuntu called "avahi-autoipd" that is absolutely evil. What this process does is go out of its way to sabotage any attempt to have a static IP in Ubuntu. I've configured /etc/network/interfaces to use a static IP. avahi-autoipd ignores this configuration. I then had to use "ifconfig" and "route" to manually give my computer a static IP. avahi-autoipd then, 90 seconds later decides I don't want a static ip, erases my static ip and tries to get a DHCP ip (which doesn't work, since there isn't a DHCP server).

I tried killing the avahi process. Some evil daemon then ressurects the avahi process so that it can remove my IP 90 seconds later.

I finally did a "sudo rm /usr/sbin/avahi-autoipd" and rebooted the computer; the monster that decides I can't have a static IP is finally dead.

I'm sure there's some exotic recipe to make avahi behave. I don't care. I have better things to do with my time than to configure some new fangled daemon that doesn't work. The daemon should not be disabling static IPs every 90 seconds, end of story.

Now, I'll see if dhcp works. If not, I'll compile the dhcp client that comes with Busybox, which is, at least simple and not prone to failure.

My other Ubuntu rant: Making backups to a DVD-RW with a UDF filesystem is dog slow. We're talking hours to copy 50 megabytes of data. On a DVD-RW that I could burn in 15 or 20 minutes. Why is this so dog slow?

Linux sucks.

MaraDNS update; Ubuntu rant

OK, I have uploaded a new snapshot of MaraDNS today. This fixes a bug in the zoneserver where it did not properly inform the user they have an incorrect IP in their mararc file, and also, the Deadwood project now does something useful.

If you look in the directory deadwood-1 off of the Snapshot's directory, you will observe a number of files. This is a working (if very basic) DNS load balancer. Basically, use "make" to compile the code, and then edit the dwood1rc file to configure the load balancer. The dwood1rc file uses the same general format as a mararc file, but only supports the following three parameters:

1. bind_address This is the IP address we bind to
2. chroot_dir This is the directory the program will run from
3. upstream_servers["."] this is a list of DNS servers that the load balancer will try to contact

Basically, what the server does is listen on the address specified in bind_address. When it gets a DNS query, it will make sure this query is a query (an not an answer), then send the query, as is, to one of the servers listed in upstream_servers["."]. It will then wait up to 7 seconds for an answer from the upstream server. When it gets a reply, it sets the "this is an answer" DNS bit, then sends the reply back to the original client.

The load balancer can only handle 32 pending replies from the upstream server before it will no longer process incoming replies. When the server is overload, it currently silently drops packets.

No attempt is made to randomize the query ID nor the source port of the query when forwarding the query.

Only ipv4 is supported; there is no ipv6 support. Only DNS-over-UDP is support; DNS-over-TCP is not supported.

I plan on, before moving on to implement caching, to add support for randomized query IDs and source ports, to add user-configurable maximum wait time and maximum allowed number of pending queries, to have the server send "server fail" DNS messages if the load balancer is overloaded, and supporting DNS-over-TCP.

In the meantime, people may want to look at the Deadwood code and give me suggestions on how I can improve this code. As always, the snapshot can be downloaded here

---

It would seem that Ubuntu does not come with a firewall by default. Ugh. I'm really disappointed that, not only does Ubuntu install a bunch of services that bind to ports, but they don't bother to install a firewall to protect the system. This is really insecure. What I have done is go in to /etc/rc2.d and turn off all of the services that bind to ports. I have also downloaded an article on installing a firewall in Ubuntu, and am working on getting a firewall going.

In the 1990s, RedHat had a lot of security problems. They finally woke up and RedHat and Fedora now come with a firewall when you install the OS. Ubuntu needs to learn from RedHat's lesson.

Linux annonyance: /dev/hda now has large file problems

Ever since the creation of Linux in 1991, the way to mount IDE hard disks and CD-ROMS was to type in something like mount /dev/hda1 /mnt, or for an IDE CD-ROM drive, something like mount /dev/hdc /mnt. However, this no longer works that well in the kernel that comes with Ubuntu 7.04 (2.6.20-16-generic). If there is a DVD which is larger than four gigabytes in size, the CD/DVD-ROM drive can not access the files past the four gig limit. This was not a problem with older Linux kernels; the kernel developers broke something that has been working for years.

Instead, one has to get the udftools package via sudo apt-get install udftools, configure the file /etc/default/udftools to point to the CD/DVD-ROM device, and then mount the DVD as /dev/pktcdvd/0. Ugh. As an aside, there are online guides for making UDF packet-writing DVDs (DVD-RWs that you can write to as if they were a huge floppy disk) that give bad directions. Please read the directions in the file /usr/share/doc/udftools/README.Debian.gz for correctly formatting a packet DVD. I now have two coasters that used to be DVD-RW blanks because I did not follow these directions, but instead trusted inaccurate on-line directions. In particular, I didn't do the essential growisofs -Z /dev/hdc=/dev/zero step between formatting the DVD-RW and putting the UDF filesystem on the DVD-RW, since the on-line guide did not mention this step.

Also, when mounting a DVD-RW, you really want to mount it like mount -o noatime /dev/pktcdvd/0 /mnt since otherwise it will do very slow writes when all you want to do is read some files. Yes, I actually learned something useful from reading a Slashdot discussion. Naturally, Slashdot misattributed a quote to Linus, but hey at least the information in this thread is useful.