linux

Microsoft's silent threat of patent lawsuits against Linux users is beginning to solidify in the last couple of days. Since the announcement with Novell, Microsoft have been busy trying to establish similar patent protection deals with other Linux vendors. However their attempts have not been greeted warmly by Red Hat who's deputy general counsel ruled out any need for such an agreement on the grounds that "we do not believe there is a need for or basis for the type of relationship".

Fortunately for Microsoft they are not easily deterred by such confidence with CEO Steve Ballmer (in the words of Boing Boing) painting Linux users as patent crooks during a Q&A session on Friday. Although Ballmer did not say it so bluntly he did openly threaten businesses running Linux by stating that the Novell patent protection is crucial otherwise:

"We (Microsoft) believe every Linux customer basically has an undisclosed balance-sheet liability."

Source LinuxWorld - Linux Users Owe Microsoft

These are definitely fighting words but at some stage they are going to have to do more than just rattle their hypothetical sabres and actually sue. If (when) that day comes it will be a very interesting moment in open source history and be a pivotal moment in the future of Microsoft.

A few days back Sun offically announced they would be open sourcing Java under the GPL to applause from most of the industry. For a long time it was generally accepted that Sun would be fully open sourcing Java, the real question lay in exactly what license would be applied and how it would be undertaken. It turns out things will take about a year to be fully open sourced but even now the OpenJDK website is looking very promising.

A few weeks after the Novell/Microsoft announcement the Samba Team have officially requested Novell reconsider their stand on patents. The Samba project is an important (if not crucial) piece of open source software that is allowing a wide variety of platforms (but mainly Linux) to compete head to head with Microsoft solutions in the workplace. Jeremy Alison co-heads the Samba project and is an employee of Novell but obviously this has not stopped the team from taking a moral stand against software patents and the actions of Novell and Microsoft.

This stance is completely opposite to the Mono team leader Miguel de Icaza's official support of the deal, but this is not surprising considering 99% of Mono development is funded and directed by Novell. I doubt Novell will heed Samba's request but at least its good to see such a prominent project take such a decisive stand on the matter.

If you are part of the Linux/Novell community last week you would have no doubt heard of the Microsoft - Novell agreement. When it was first announced it looked materially very boring on the surface comprising of a couple of virtualisation developments and a promise by the two companies to work on OfficeXML and directory system interoperability. All this is fairly trivial but what made the deal controversial was the promise from Microsoft not to sue Novell customers for using Linux.

The two 'problem' technologies that fall under this legal cloud is Mono, an implementation of Microsoft's .Net runtime for Linux and Samba, a SMB compatible client/server capable of mimicking the network functionality within Microsoft products. Whether or not there is any real legal grounds for patent infringement is a matter for debate. Neither break copyright laws and the extent of patent infringement by either project has never been described by any party. Nonetheless Microsoft has successfully created and maintained a cloud of uncertainty over these products, a feat helped in no small part by their support of the long running SCO vs IBM/Novell lawsuit (which boils down to the copyright status of some Linux code).

Over the last week I have been experimenting with SMBLDAP-Tools and some of the new features available in the latest versions of Samba 3. Whilst I've written about setting up a Samba Primary Domain Controller with an LDAP-backend before SMBLDAP-Tools makes configuring this potentially troublesome (but very powerful) combination a lot easier.

For my testing I have been using the Factory build of Samba 3.0.23C for Suse 10. Suse 10 does not have a package for SMBLDAP-Tools but Suse 10.1+ does so I used the 10.1 source package and built it for Suse 10. After a bit of hassle I also applied a patch that fixed Computer creation account problems. If you are using Suse 10.0 the SMBLDAP-Tools package I built can be downloaded from here, otherwise compiling it from source is difficult as its just a collection of Perl scripts.

Vichar Bhatt has pointed out it is possible to install the Suse Linux Enterprise Desktop start menu on OpenSUSE 10.1. Because the codebase is the same installation is straightforward, all that needs to be done is install the relevant rpm for x86 or x64 and then enable the menu applet within Gnome.

OpenSUSE 10.1 with the SLED 10 menu (click to enlarge)

The upshot of all this is you receive all the usability benefits of SLED without having to fork out any cash. It is a great tip and it really improves the OpenSUSE experience, especially now that they have released the remastered version of 10.1 which includes the working Zen update mechanism.

Centralised authentication in the form of LDAP (or similar) is very useful but Linux assumes a valid user has a directory in /home. By default Suse does not create a home directory for a user who has authenticated via an external source which is a real problem if they want to run many programs.

One way to get around this is to mount the home directory on an external server which contains the home directories but this can be difficult and a drain on network bandwidth. An easier way to solve the problem is to tell PAM (the Linux authentication manager) to create the directory on login. To do so on Suse edit the /etc/pam.d/common-session file and add the following:

Scalix runs its own instance of OpenLDAP for authentication purposes and by default this operates on port 389 which is the standard port for LDAP. The only problem with this is that you cannot run a 'proper' LDAP service (OpenLDAP, FedoraDS, eDirectory) on the standard LDAP ports without there being a conflict with the Scalix service. Fortunately there is a simple workaround that lets you run the Scalix service on a non-standard port.

Edit the /var/opt/scalix/sys/slapd.conf file and change the setting portNum to a non-standard (preferably high-level) port. In this example I will use port 6389 but it can be any port that is not currently being used by another service.

portNum 6389

Now edit the /etc/opt/scalix/caa/scalix.res/config/ubermanager.properties file and set the ubermanager.query.server.port to the same value:

ubermanager.query.server.port=6389

Save the changes and restart Scalix for the new LDAP port settings to take effect.

Recently I put a second, faster network card in a server. On booting OpenSuse 10 assigned the new card the name eth2 and the existing, built-in Ethernet device eth0. A number of applications, for example Samba and dnsmasq, typically bind to an Ethernet name rather than a specific IP or MAC address. It is possible to change the individual configuration files for each of these services but this is a little ugly considering my goal was to install the new hardware and disable the existing device, leaving everything else untouched.

A tidier solution is to assign eth0 to the new card and eth1 to the older (unused) device. Figuring out how to do this is a little confusing, there is no Yast option to configure network names and manually editing /etc/sysconfig/network/ifcfg-eth(mac address) provides no help either. Instead you must edit the file /etc/udev/rules.d/30-net_persistent_names.rules and change the device name associated to the relevant network MAC address. In a two card setup the file will look a little like this (each network device entry is on a single line):

Recently I purchased a Philips 37" LCD television (model 37PF7320/79) which is capable of 1360x768 pixel resolution. Unfortunately XFree/Xorg does not recognise this resolution so you must provide the XFree/Xorg configuration file with a working modeline. After quite a bit of tweaking I finally have this working setup for the television via a DVI to HDMI converter cable (put in xorg.conf):

Section "Monitor"
Identifier "Monitor0"
VendorName "Philips"
ModelName "37PF7320 LCD HDTV"
HorizSync 30.0-70.0
VertRefresh 50-60
Option "UseEdidDpi" "FALSE"
DisplaySize 345 195
Modeline "1360x768" 84.750 1365 1384 1516 1792 768 786 792 798 -HSync +Vsync
EndSection

Note: DisplaySize and UseEdidDpi settings force the X-server into 100dpi mode otherwise MythTV has display issues (fonts are too small) as outlined in the MythTV Wiki.

And in section "Screen" of the configuration file add 1360x768 as an available resolution to the relevant colour depth you are using. Restart X and in theory you should end up with a nice, sharp, widescreen display on the television that looks a lot better than the default stretched 1024x768.