The Print Server is the Ubuntu computer that is directly connected to the printers.

1. On the server machine (the one the printer is attached to) open up printer manager with by going to System in the top toolbar panel, then Administration and Printing. This will open the Printer Configuration window.

2. Select Server in the menu bar, and then Settings.

3. This will open the Basic Server Settings window. If this computer only serves as a Print Server and does not need access to a printer connected to another computer select the second box.

   • Publish shared printers connected to this server

   If this computer acts as both a Print Server and a client (it does need access to a printer connected to another computer), select the first two boxes

   • Show printers shared by other systems
   • Publish shared printers connected to this system

4. Select the OK button.

That is all you need to do on the ubuntu “server.”  Next, I needed to configure my windows XP station to print to the printer as well.

WindowsXP Client Machine

1. Open the Control Panel

2. Click Printers and Faxes

3. Click Add a Printer

4. On the first page of the Add Printer Wizard, click Next

5. Choose Add a network Printer

6. Choose Connect to a printer on the internet and type http://SERVER_NAME:631/printers/PRINTER_NAME in the text box and then click next

7. On the next screen, Choose the correct driver for your printer

8. Click ok to finish

9. Right click the printer, choose properties, and then try to print a test page

# xorg.conf (X.Org X Window System server configuration file)
#
# This file was generated by failsafeDexconf, using
# values from the debconf database and some overrides to use vesa mode.
#
# You should use dexconf or another such tool for creating a “real” xorg.conf
# For example:
#   sudo dpkg-reconfigure -phigh xserver-xorg

Section “InputDevice”
Identifier    “Generic Keyboard”
Driver        “kbd”
Option        “XkbRules”    “xorg”
Option        “XkbModel”    “pc105″
Option        “XkbLayout”    “us”
EndSection

Section “InputDevice”
Identifier    “Configured Mouse”
Driver        “mouse”
Option        “Protocol” “auto”
Option          “Emulate3Buttons” “true”
Option        “CorePointer”
#    Option        “Device” “/dev/input/mice”
#    Option        “AlwaysCore” “true”
#    Option        “ZAxis Mapping” “4 5″ #for mouse scroll
EndSection

#Section “Module”
#    Load        “glx”
#    Load        “GLcore”
#    Load        “dri”
#    Load        “v4l”
#EndSection

####################
# Display 0 – 09:00.0  [ACER AL1916W]
############################################################

Section “Device” #
Identifier    “Device0″
Boardname    “Matrox Millennium G200 QuadHead”
Busid        “PCI:9:0:0″
Driver        “mga”
Vendorname    “Matrox”
VideoRam    4096
EndSection

Section “Monitor” #
Identifier    “Monitor0″
ModelName    “ACER AL1916W”
HorizSync    30-82
Vertrefresh    56-76
Option        “DPMS”
Modeline “1440×900″  106.47  1440 1520 1672 1904  900 901 904 932  -HSync +Vsync
#    Modeline “1440×900_60.00″  106.47  1440 1520 1672 1904  900 901 904 932  -HSync +Vsync
#    ModeLine “1024×768_GM”   60.00  1024 1048 1184 1328  768 771 777 806 -Hsync -Vsync
EndSection

Section “Screen” #
Identifier    “Screen0″
Device        “Device0″
Defaultdepth    24
Monitor        “Monitor0″
SubSection “Display”
Modes   “1440×900″
Depth    24
EndSubSection
EndSection

####################
# Display 1 – 09:04.0  [ACER AL1916W]
############################################################

Section “Device” #
Identifier    “Device1″
Boardname    “Matrox Millennium G200 QuadHead”
Busid        “PCI:9:04:0″
Driver        “mga”
Vendorname    “Matrox”
VideoRam        4096
EndSection

Section “Monitor” #
Identifier    “Monitor1″
ModelName    “ACER AL1916W”
HorizSync    30-82
Vertrefresh    56-76
Option        “DPMS”
Modeline “1440×900″  106.47  1440 1520 1672 1904  900 901 904 932  -HSync +Vsync
#    Modeline “1440×900_60.00″  106.47  1440 1520 1672 1904  900 901 904 932  -HSync +Vsync
#    Modeline “800×600_GM”  38.22  800 832 912 1024  600 601 604 622  -HSync +Vsync
#    Modeline “GM”  75.00  1024 1048 1184 1328  768 771 777 806 -Hsync -Vsync
EndSection

Section “Screen” #
Identifier    “Screen1″
Device        “Device1″
Defaultdepth    24
Monitor        “Monitor1″
SubSection “Display”
Modes   “1440×900″
Depth     24
EndSubSection
EndSection

####################
# Display 2 – 09:08.0  [SAMSUNG SYNCMASTER 914V]
############################################################

Section “Device” #
Identifier    “Device2″
Boardname    “Matrox Millennium G200 QuadHead”
Busid        “PCI:9:08:0″
Driver        “mga”
Vendorname    “Matrox”
VideoRam        4096
EndSection

Section “Monitor” #
Identifier    “Monitor2″
ModelName    “SAMSUNG SYNCMASTER 914V”
HorizSync    30-81
VertRefresh    56-75
Option        “DPMS”
Modeline “1280×1024″  108.88  1280 1360 1496 1712  1024 1025 1028 1060  -HSync +Vsync
#    Modeline “1280×1024_60.00″  108.88  1280 1360 1496 1712  1024 1025 1028 1060  -HSync +Vsync
#    ModeLine “1024×768_GM”   75.00  1024 1048 1184 1328  768 771 777 806 -Hsync -Vsync
#    Modeline “800×600_GM”   40.00  800 840 968 1056  600 601 605 628 +hsync +vsync
EndSection

Section “Screen” #
Identifier    “Screen2″
Device        “Device2″
Defaultdepth    24
Monitor        “Monitor2″
SubSection “Display”
Modes   “1280×1024″
Depth    24
EndSubSection
EndSection

####################
# Display 3 – 09:0c.0  [HANNS-G HC194D]
############################################################

Section “Device” #
Identifier    “Device3″
Boardname    “Matrox Millennium G200 QuadHead”
Busid        “PCI:9:12:0″
Driver        “mga”
Vendorname    “Matrox”
VideoRam        4096
EndSection

Section “Monitor” #
Identifier    “Monitor3″
ModelName    “HANNS-G HC194D”
HorizSync    31-81
VertRefresh    56-75
Option        “DPMS”
Modeline “1280×1024″  108.88  1280 1360 1496 1712  1024 1025 1028 1060  -HSync +Vsync
#    Modeline “1280×1024_60.00″  108.88  1280 1360 1496 1712  1024 1025 1028 1060  -HSync +Vsync
#    ModeLine “1024×768_GM”   75.00  1024 1048 1184 1328  768 771 777 806 -Hsync -Vsync
#    Modeline “800×600_GM”   40.00  800 840 968 1056  600 601 605 628 +hsync +vsync
EndSection

Section “Screen” #
Identifier    “Screen3″
Device        “Device3″
Defaultdepth    24
Monitor        “Monitor3″
SubSection “Display”
Modes   “1280×1024″
Depth    24
EndSubSection

EndSection

Section “ServerLayout”
Identifier    “Default Layout”
Screen        “Screen0″ 0 0
Screen        “Screen1″ RightOf “Screen0″
Screen        “Screen2″ Above “Screen1″
Screen        “Screen3″ Above “Screen0″
InputDevice    “Generic Keyboard”
InputDevice    “Configured Mouse”
Option        “Xinerama” “true”
EndSection

Section “ServerFlags”
Option        “IgnoreABI” “True”
EndSection

in command shell, type the following:

sudo passwd

It will then prompt for the new password and your done. As simple as that!

# create init.d symlinks
cd /etc
ln -s init.d rc0.d
ln -s init.d rc1.d
ln -s init.d rc2.d
ln -s init.d rc3.d
ln -s init.d rc4.d
ln -s init.d rc5.d
ln -s init.d rc6.d
ln -s init.d rcS.d

# now, install vmware
sh VMware-Workstation-6.5.1-126130.x86_64.bundle

# and then copy gentoo's init scripts over vmware's
mkdir -p /etc/vmware/init.d
mv /etc/init.d/vmware /etc/vmware/init.d/
cp /usr/portage/app-emulation/vmware-workstation/files/vmware-workstation.rc \
/etc/init.d/vmware
chmod +x /etc/init.d/vmware
rc-update add vmware default

sh VMware-Workstation-6.5.1-126130*.bundle
yum install gcc kernel-devel-`uname -r`
mv /usr/lib/vmware/modules/binary /usr/lib/vmware/modules/binary.old
vmware-modconfig –console –install-all

Slightly-less-short version:

1. The .bundles available on VMware’s site are just huge shell scripts. Thus, we execute them like one:

sh VMware-Workstation-6.5.1-126130*.bundle

2. The install should finish successfully, but it won’t run because the modules will not fit into Fedora’s running kernel. To fix that, we first need to install gcc and the kernel-devel package for your running kernel:

yum install gcc kernel-devel-`uname -r`

3. Move the directory where the module object files were installed, then run vmware-modconfig. Because you moved the object files directory, it will try to recompile them.

mv /usr/lib/vmware/modules/binary /usr/lib/vmware/modules/binary.old
vmware-modconfig --console --install-all

VMware should now run.

1) sync a whole directory from one location on the local filesystem to another, while keeping all metadata such as ownership and permissions in tact:

rsync -azvrP /media/disk/source /home/user/destination

Important note: if source does not have a trailing slash, it will create the directory source/ inside destination/ — if it does have a trailing slash, it will copy only the contents of source but not source/ itself. This is similar to `cp /source` vs. `cp /source/*`

2) sync from a local machine over ssh to a remote server

rsync -zvrP /home/user/source user@10.10.10.100:

rsync uses ssh for remote connections by default, so there is nothing special you have to do besides the remote destination syntax which is identical to scp. (Obviously, sshd must be running on the server.) In this example there is nothing after the colon, meaning it defaults to the user’s home directory.

3) sync from a local machine over ssh to a remote server on a non-standard ssh port to a non-home directory

rsync -e ’ssh -p 12345′ -zvrP /home/user/source root@10.10.10.100:/usr/local/

The -e flag takes a string identical to what you would use if you were using ssh manually. In this example, ’ssh -p 12345′ connects using port 12345 on the server. The other difference is the destination directory on the end of the remote IP. To copy from a server to yourself, simply reverse source and destination.

4) sync one directory to another, except for files ending in .iso and .img

rsync zvrP –exclude ‘*.iso’ –exclude ‘*.img’ /home/user/source /media/destination/

Nothing new here except for the –exclude option. (Those are TWO dashes, not one! Wordpress likes to change things without my permission.) This is useful for when you’re backing up a directory but don’t care to transfer huge files that you can easily re-download. For more details about fine-grained exclusion, see the rsync man page.

Command line options
Personally, about 95% of my rsync usage is accomplished with -zvrP. Below is a quick table of all the options seen in the previous examples.

-a: archive (implies -rlptoD)
  -r: recursive
  -l: copy symlinks as symlinks
  -p: preserve permissions
  -t: preserve modification times
  -g: preserve group
  -o: preserve owner (root only)
  -D: (implies --devices --specials)
    --devices: recreates character/block devices
        (receiving end must be root)
    --specials: transfer special files like named sockets

-z: compress during transfer
-v: verbose
-r: recursive
-P:
  --partial: keep partially transferred files
  --progress: show progress during transfer

-e: specify the remote shell to use
--exclude: excludes files matching PATTERN

I start this article knowing full well that it will offend people, even so, I think this needs to be said.

Now, for some background, I started using Linux sometime in 2000, my first distribution was Mandrake 7.0, and I eventually switched to Slackware 7.1 in order to try and accelerate my learning curve by forcing myself to use a more ‘pure’ environment, this worked fairly well. In the first year, my knowledge of the various modular components and how they fit together grew rapidly. At some point in 2004 I believe, I started using Gentoo on my laptop, and it quickly became one of my favorites. Several months ago, I realized I no longer wanted to spend valuable time waiting for various software packages to compile, I also grew very frustrated with their masking ‘feature’, and decided it would be time to look elsewhere.

And here finally, is the crux (no pun intended) of the story. Out of all the options out there, I figured my best bet would be Debian; after all, if there is one distribution that could be considered a ‘flagship’ of the Linux community, it would have to be Debian. Furthermore I liked the idea that like Gentoo, the base system came in a minimal configuration, and you added packages as you need them. Of course, because of various factors, I didn’t get the chance to do my migration right away, and it ended up being put off for a few months.

Then one day, while googling around for some info on XULRunner, I stumbled upon Mike Hearn’s blog, where he was discussing Debian’s controversial method of forking software; it is old news, but still important to evaluate I believe. I have to say that this shocked me immensely. Despite not using the distribution yet, and therefore not being a ‘fan’ per se, I held a lot of respect for the project and it’s leaders, for fighting the good fight and standing strong when it came to software freedom. The notion that Debian could do any evil was alien to even a non-user like me. I read on and I found myself agreeing with Mike on pretty much all his points. I googled for more details on this controversy and discovered this which explains some more details about the whole incident. As near as I can see, the Debian maintainers feel that Mozilla’s linking strategy is not ‘unixy’ enough, and have decided to ‘correct’ that by changing the way the software functions on their distribution. This has the potential of breaking compatibility as noted by both Mike and Benjamin. And I would add that this is just a total slap in the face to the hard work of the Mozilla developers. Bottom line is, if you want to get all patch-happy on some piece of software, then change the name; the upstream developers do not deserve to suffer all sorts of support headaches simply because you decided to do your own thing.

The fun doesn’t stop there however. On May 13th, one of the most severe and critical security problems in years was discovered in Debian’s version of OpenSSL, and this problem affects Debian forks as well such as Ubuntu, Mint, DreamLinux (unconfirmed) and MEPIS. All of those are in the top 10 of DistroWatch as I write this (with Ubuntu in 1st place), except for MEPIS which is #12. The issue arose because once again, one of the Debian package maintainers decided to go their own way without including upstream developers in the process. The short of it is that Valgrind, a well known memory debugger, was coming up with “uninitialized data” warnings in code linked to OpenSSL. This apparently is a well known issue, and there have been discussions about why the issue comes up and what to do about it. It is related to the fact that Valgrind and IBM’s Rational Purify usually view “uninitialized data” as a bad thing, when in the case of a random number generator, it is actually necessary.

The Debian ‘patch’ essentially removes the ability for OpenSSL to generate random numbers properly, the result of which causes keys generated with OpenSSL on Debian (and it’s derivatives) to be extremely easy to guess in a short amount of time using an amateurish brute-force attack. Worse yet, this Debian ‘maintainer’ didn’t alert upstream developers to his ‘patch’ and therefore the problem went uncaught for years and has now put many unsuspecting users at risk.

I may not be a developer, but even I can see the absolute stupidity behind the OpenSSL debacle. And it is all because of their absolute refusal to respect the wishes of upstream developers regarding their software. This is nothing new of course; distributions have been doing this sort of bullshit for years. I recall back in the day when Red Hat ended up shipping a CVS version of GCC known as “GCC 2.96″, which broke compilation with many packages, the official stable GCC release at the time was 2.95.3, and this newer 2.96 version was actually a development snapshot for the upcoming 3.x releases. Then there was the whole controversy with various distributions shipping broken copies of MPlayer due to patent fears; SuSE and Debian (yep, them again) were two notable offenders as I recall.

Essentially, for whatever reason, some distributors seem to think that their Linux distribution is a proper place to dump all their dirty hacks and patches, and to completely spit at the hard work that upstream developers put into their stable releases. It is heartbreaking to see the community in this sort of uncooperative state.

Many years ago I read an opinion article titled “Does Slackware still matter?“, I remember being pretty miffed about the whole thing, but at the same time I couldn’t really produce a comeback. Over the years of course I’ve gained more insight into these matters, and I can now definitively say that, YES, it matters perhaps more than any distribution currently out there.

Patrick Volkerding started Slackware back in 1993, and the first release came on July 16th of that year. Originally not intended to be a serious project, it eventually grew, and exists to this day as the longest living Linux distribution ever. The philosophy behind the project very much obeys the “Keep It Simple, Stupid” philosophy, or KISS for short. The idea is that the system should shy away from over-reaching complexity and abstraction layers, and instead keep things clean. In following this philosophy, most of Slackware’s packages are often sparsely modified compared to their upstream counterparts, and given that this is a one-man project, it would be pretty difficult to go around patching everything and then having even more testing to deal with. There are some exceptions I would imagine, perhaps some security issues and so on; also, back when the Gnome environment came standard, Patrick would often have to clean up after the upstream Gnome, and make sure it doesn’t essentially ‘take over’ the system.

I truly believe that the Slackware way of distributing, is the right way, with minimal changes from upstream, and very few abstraction layers for configuration (bash scripts like netconfig are all that come to mind), as well as an easy to work with BSD init script set up, it is easy to see that Slackware does not ‘hide’ the system from you like many others do.

I mean let’s be clear, when you use Gentoo, with it’s bizarre init and config system, you don’t learn Linux so much as you learn ‘Gentoo’, and when you use SUSE, you don’t learn Linux so much as you’re just learning ‘SUSE’, and so on with every distribution. Now of course I may be exaggerating; after all there are more similarities than differences, and truly, experienced Linux users can easily pick up another distro and understand what’s going on. Besides, often many of the ‘default’ usual configuration files will point you in the right direction, like when editing resolv.conf on Gentoo, a note will mention how you have to add your DNS servers in /etc/conf.d/net instead. Even so, it does mean that there are serious challenges in administering many boxes with different distributions.

Of course, the first natural riposte to my article will probably be “are you against freedom of choice or something?”, and the answer to that question is no, I am not. I fully understand that everyone has the freedom to do things their own way, and of course, to the “Windows user” that joins the Linux community through Ubuntu, they probably don’t care whether resolv.conf is edited directly or whether there is some abstraction layer; but to people who want to learn system administration, it can be a pain in the ass to move between distributions if you haven’t learned how the system really works behind all the abstraction. And of course, it is a slippery slope; there are configuration hacks/abstractions, and then there are actual source code patches that change the behavior of the program in question; and we can see that this patch-happy attitude can often have some serious repercussions, like in the Debian OpenSSL case. If anything, I am not suggesting we all become robots and obey one standard ‘method’ of doing things, however I think there needs to be a more conservative attitude when it comes to breaking consistency with upstream. Let us remember that upstream projects develop the applications, and distributions are supposed to distribute.

To conclude and sum this up, when I download a package from a distribution’s repository, I think it is not unreasonable to expect the package to be the same as the one I would download from the upstream maintainer’s website. If it isn’t, then there isn’t really much of a point to pitching the idea of online package repositories as an alternative to traditional methods of software distribution. I think Mike Hearn’s example of a distribution mirror altering a package is a very good example, because in such a scenario, many individuals would be outraged and angry, and yet Linux distributions get away with this kind of thing all the time.

And that is pretty much all I have to say about that.

P.S.: As I said when starting out, I know some folks will be offended by this, and I know how articles and posts like this can easily cause flame wars, I hope there are no hard feelings. Also, it seems that one of the first instincts when reading an article like this is for people to question the author’s competency and so on, I hope you can manage to keep it civilized despite any disagreements you may have with my opinion.

The only F/OSS emulator for N64 had always been Mupen64, which was often criticized for being quite a bit less mature than Project64 and some others. In any case, it was in development so we all figured it would ‘get there’ eventually… Until 2005 shortly after the release of version 0.5.1 (win32), when the project just froze. Then 2006 came and went, then 2007… And seemingly no progress was being made. It was a sad state of affairs because Mupen64 was essentially the only hope for Linux users to have a native N64 emulator for their platform.

Now, finally. After a few years, a new team has come together to work on the Mupen64 codebase, they have dubbed their project “Mupen64Plus” (a little generic if you ask me), and they’re hard at work, hacking away. From the little research I’ve done, it would seem the leader (Richard42) of this new project was a long-time contributor to Mupen64, and the original head of the Mupen64 project (Hacktarux) was planning on adding some of Richard’s new work back to the original project. I’m not sure if this merge happened or not, but it seems that on the Mupen64 homepage, the last version is still 0.5.1 for Windows and 0.5 for Linux. So who knows what happened.

I’ve been hanging out in the IRC channel for the new project for a few days now, it’s more of a developer channel, so I’m a bit out of place, even so, I like hanging out, I figure maybe I’ll learn a thing or two from the masters. :)

It seems everything is well underway. Their homepage already has a release, version 1.3, which worked pretty well for me barring a few issues. This is obviously only an initial release, so don’t expect it to be light-years ahead of the original Mupen64, but with time it could evolve to be the best out there. If you have any problems with this release, make sure you file a bug report in the “Issues” section of that page (I filed one for Ogre Battle the other day), developers need info on problems to be able to fix them, and if you’re not a developer, this is the best way to help. Make sure your report is detailed, provide the md5 hash for the rom you’re using, and list which plugins you were using. Trying different settings on the plugins and seeing if there are different results, and adding this info to your bug report(s) can go a long way towards helping along with debugging.

So now we mere mortals can only wait and see how this unfolds, but it definitely looks very promising. A big thank you to all the individuals working on this fork, and keep up the good work. The N64 and Emu fans of the world are all rooting for you! (I’m such a ham…)

A note on closed-source emulators:

I must say I’ll never understand the concept behind the “closed-source emulator”. After all, the philosophy behind the emulation community at large is to make sure that old classic games do not become forgotten or die off just because a console is no longer in widespread use. After all you can only have so many game systems hooked up in your living room at once, and a lot of these old games can often be more fun then many newer titles. To me, a closed-source project is always more vulnerable for many reasons, not only does it not benefit from the open-source “with enough eyes, all bugs are shallow” philosophy, but I would imagine that a closed codebase is easier to attack if you’re a company. Think about UltraHLE and Bleem! back in the day, if they had been Open Source, it would’ve been impossible to stop the code from spreading and evolving. Neither Nintendo nor Sony would have any legal recourse to stop individuals from hacking on the code. If preserving the classics, and making sure they can run on modern platforms is your goal, then opening the code under an OSI-compliant license is the only realistic option to achieve that goal, otherwise companies do have the power to stop you if they choose.

In any case, that aside, something has been bugging me, and as usual, I can’t just let it go.

Some individuals have been referencing my post, only to be shot down by people claiming my 3rd point is invalid because EA supposedly handled the PS3 port work. I have to say, nice detective work. I haven’t kept up with console release news recently, so I missed the story about EA having done the port.

However… This is completely irrelevant regarding my point. Sure, in the article I imply that Valve did it, ok, so substitute Valve for “EA”, the important point is that the code EXISTS. Somewhere, somehow, there is a version of the Source Engine out there that is powered by OpenGL. Furthermore, I would be willing to bet that the OpenGL work, at the very least, is all Valve’s, and that EA only did the PS3-specific bits.

Why do I say something so speculative? Because when the HL2 source code was leaked years ago, the engine used OpenGL as a backend. Now we all know that the HL1 engine was based on Quake1, and that the Source Engine was developed from scratch specifically for HL2, but it’s possible the general engine components were done first, and the rendering backend last, so maybe this OpenGL code from the leaked version was actually an evolution of the HL1 rendering backend, who knows?

Of course, when you factor in the Postal III port, everything more or less falls into place, and you start to get a picture of what’s going on, Valve has to have their own OpenGL somewhere, because I just can’t see a dev house like RWS or Akella writing an entire rendering backend on their own, if they were going to go through that trouble they would’ve been better off using an engine that fit their needs better.

Now I hope this settles the issue. Keep in mind that my post wasn’t designed to be authoritative on the issue, I am merely looking at the various clues, and drawing certain conclusions from them. If I am wrong, and there isn’t a Linux port, well, the points stand up on their own, in the end all it will mean is that Valve completely wasted some source code that they already had in their hands, for whatever reason.

Anyways, that’s it for me. Until next time, take care of yourselves, and each other. :)

PS: Linux is HOT!

PS: Linux is hotter in the jacket…