We had an old ("old" meaning installed a year ago) installation of Fedora v3 running a CMS that was publishing data to Windows Server 2003 over Samba. Occasionally, at the same time in the middle of the night that the publishing occurred, Windows Automatic Updates would download some patch for Windows and reboot the server. Obviously that was a mistake on our part to let these two actions coincide. But the bigger problem was that the Samba link didn't just drop when Windows rebooted. Instead, it locked up. So by the afternoon the next day, people are pulling their hair out trying to figure out what the @#% is wrong with this stupid CMS server, and why it just starts working again when we reboot Linux. We finally narrowed it down to a Windows server reboot--a Samba failure to drop the link.

http://www.linuxforums.org/forum/servers/98115-samba-mount-does-not-drop-timeout.html

What should happen is a timeout should occur, an error should be raised to the calling application (the CMS service), the service should halt, and then when the Windows server comes back up and the CMS service on Linux reattempts to access the path, Samba should reattempt to build the link and either succeed or fail.

That was Fedora v3. Now were' using RHEL 5, and meanwhile I'm using Ubuntu 7.04 at home on my laptop. I'm expecting a much smoother Samba experience now. But unfortunately, we cannot even seem to get our Samba links to even work, much less behave correctly (i.e. drop) when the Windows server goes down. Now I'm having all kinds of different issues.

The first issue is on my laptop at home, when I use the Network browser in Nautilus to browse my shared folders on my home machines, everything goes erratic. It sees everything really fast one minute, then it locks up for five minutes the next. I click on a folder, it becomes a file. I hit refresh, it can't "see" anything. I go up the tree a couple branches, it finally starts seeing things. I go back into the branch I was in, and it displays it pretty quickly. I copy a folder to the clipboard, and paste to /home/jon, and nothing happens.

Now it could very well be a Nautilus issue, but then here's the other problem ...

At the office, we now have RHEL 5, we have been trying to migrate off the old Fedora 3 system and onto the new system. And now this happens:

http://www.linuxforums.org/forum/servers/102298-samba-cifs-mount-point-wont-allow-read-write-non-root-user.html

Essentially, once the Linux user writes to the Samba share, the share becomes "owned" by root and the user can't do diddly squat. This essentially breaks our publishing plans, rendering the Samba link useless.

Fortunately, Microsoft was kind enough to implement NFS support in Windows Server 2003 R2, and R2 is the build we just erected for the new environment. I'll try that next. But it still makes me wonder, what on earth happened to Samba?? It's only been around for, like, a decade!

The Mono Project over at http://www.mono-project.org/ really needs help, mainly with quality control and distribution maintenance.

For a long time, I have been very glad for Mono, always smiling when I see it mentioned in the press such as SD Times articles or in announcements and Internet buzzes like the one about Moonlight, the Silverlight-to-Mono port project. It has always annoyed me when people would dis the Mono project as being nothing but an intellectual tinkering, something or other, because I thrive in .NET and as much as I admire Linux I need a transitional environment before I can embrace it. I have full confidence in the Mono team's ability to write excellent .NET-compatible code that runs on Linux.

But there are some painful quality control issues going on with Mono, and personally I think it just needs one or two people to jump in and help out, if the team is willing to embrace another helping hand. Otherwise, they need to get their own act together.

The biggest issues I believe are with GTK# and with the Mono-Develop IDE. While the Mono team would likely argue that an IDE does not make up a programming SDK like .NET, one must appreciate the fact that in the Windows world, .NET and Visual Studio are like peanut butter and jelly--they can be eaten on bread alone but the experience is incomplete unless they are together.

I have no problem with Mono or MonoDevelop being incomplete. My issue is with the broken installation process. The whole idea of .NET on the Microsoft front was to eliminate "DLL hell" by allowing folks to both install multiple versions of DLL side-by-side and GAC them, as well as to enable and even encourage software developers to distribute non-GAC'd distributions of libraries that can execute revised functionality for objects being called by an application that expects an older version.

The MonoDevelop solution, or at least the one that is disributed by the Fedora project's Extras repository (yum install monodevelop), installs all of the dependencies, but with incompatible versions of GTK# (et al). So when you fire up MonoDevelop, in addition to getting an error about MonoQuery.addin (not sure what that one's about), if you start a new GTK# project, despite GTKSharp clearly showing up in the References, you get a compile error saying that the Gtk namespace cannot be found.

I have installed Fedora at least five times in the last week or two, in VMWare, trying different yum / rpm installation sequences, trying to figure out where I went wrong. I have reached the conclusion that I wasn't going wrong--the MonoDevelop and/or Mono teams are the ones who did wrong.

One might argue that it's Fedora's problem since they were doing the distro. Wrong again; the Mono project's web site's download links are distribution-targeted, such as for SuSE and Fedora, but the Fedora links are for Fedora 5 (that's TWO major releases old), and are strongly versioned for Fedora 5 when installed. When I use the noarch installer, at the end of installation you get an error message, "it appears that some graphics applications might not run correctly, please install those libraries individually", and MonoDevelop still doesn't "automagically" fix itself.

GAC is overrated. Backward compatibility support for future-versioned libraries inherent in the CLR is as key to Mono's success as side-by-side version installations. This is a fundamental problem with using RPM technology with Mono. You cannot install an older version of GTK# when a newer version is already installed. You can do a force install, but at what cost? What breaks?

I'm still trying to get this stupid thing going. But be sure, I would rather drop Mono than drop Fedora 7 for Fedora 5 or for SuSE (which I also have installed on a VM, and I'm unimpressed with it).