Google Chrome OS

I suspect that the world and its dog will have heard about this by now, but in case you’ve somehow missed the announcement from Google..

Google Chrome OS will run on both x86 as well as ARM chips and we are working with multiple OEMs to bring a number of netbooks to market next year. The software architecture is simple — Google Chrome running within a new windowing system on top of a Linux kernel. For application developers, the web is the platform. All web-based applications will automatically work and new applications can be written using your favorite web technologies. And of course, these apps will run not only on Google Chrome OS, but on any standards-based browser on Windows, Mac and Linux thereby giving developers the largest user base of any platform.

If (and I emphasis if) this takes off then MS might be in for something of a rough ride in the Netbook market. The Netbook vendors have been unable to stand up to the MS monopoly with Linux on Netbooks until now, perhaps Google can start to rebalance the marked a little ?

Final report for “Inquiry into Improving Access to Victorian Public Sector Information and Data” released

The Victorian Government has been running an inquiry into access to the data that it generates, and they’ve finally tabled their report (PDF). I’ve only had a chance for a quick scan of it so far but its three main recommendations are as follows.

Firstly – this info should be made available and it should be cheap (ideally free!):

The Committee has proposed three key recommendations for access to and re-use of Government information. First, the Committee recommends that the Victorian Government develop an Information Management Framework for the purpose of facilitating access to and re-use of Victorian Government information by government, citizens and businesses. The default position of the framework should be that all PSI produced by Victorian Government departments from now on be made available at no or marginal cost.

Secondly – they should use Creative Commons licensing wherever possible!

The second key recommendation of the Committee is that the Victorian Government make use of the Creative Commons licensing model for the release of PSI. The Committee was told Creative Commons licences can be appropriately used for up to 85 per cent of government information and data, providing a simple to understand and widely used system for the re-use of PSI. Remaining Victorian Government PSI should either not be released, or released under licences tailored specifically for restricted materials.

Thirdly – and least excitingly – there should be a portal for this info..

The Committee’s third key recommendation is that the Victorian Government establish an on-line directory, where the public can search for and obtain information about PSI held by the Victorian Government. Depending on the access conditions Government has attached to specific PSI, people will be able to download information and data directly, or make contact with people in the Victorian Government to discuss access conditions.

They also have a recommendation and finding relating to state government purchasing of software related to open source:

The Committee also considers the use of open source software (OSS) within and by the Victorian Government. One of the Committee’s recommendations is that the Government ensure tendering for software is neither licence specific nor has proprietary software-specific requirements, and that it meet the given objectives of Government.

Finding 23: There is sufficient evidence of cost-competitiveness between open source software and proprietary software for government to carefully consider both options during software procurement and development.

They also consider the licensing of software developed by the government:

As noted in section 10.4.3.2 below, current Victorian Government policy is to allocate IP rights in software produced for it to the software developer, with certain restrictions to ensure the Government’s interests are protected. This means that there is nothing to restrict people who develop software for the government from subsequently releasing it as OSS.

Unfortunately it looks like MS Word stuffed up their references and headings for them – what irony! There is no section 10.4.3.2 in the PDF, it’s probably referring to section 10.3.3, which is followed by section 10.3.4 which in turn is followed by 10.3.3.1 – er ?

Even more interesting is when they talk about file formats:

Recommendation 42: That the Victorian Government require, as part of its whole-of-government ICT Procurement Policy, that software procured by the Government be capable of saving files in open standard formats, and that wherever possible, the software be configured to save in open standard formats by default.

There’s heaps more there, but I’ve run out of time to read it tonight! 🙂

(Found via OpenAustralia on Twitter)

ODF Plugfest

After the noise over whether or not the implementation of ODF (Open Document Format) in SP2 for Microsoft Office 2007 was deliberately broken for monopolistic purposes or incompetently implemented (or a combination of both) it’s nice to see that there is active interoperability work going on between vendors and developers at the ODF PlugFest, and the KOffice developers Jos van den Oever and Sven Langkamp attended and contributed to an article on the KDE DOT news website and Sven blogged about his positive experiences at the workshop.

It was first time I was going to such a workshop and I had expected that there would be fights between the different vendors like it happened in some blogs before the workshop. It was a pleasant surprise for me that the athmosphere was very friendly and productive. It was really nice to meet other people projects/companys, put the competition aside for some time, work and drink some beer together.

One neat feature mentioned there is the OfficeShots website which lets you submit an ODF document and then get back renderings of it (PDF, screenshot, ODF) from various ODF implementations. There are 8 listed at present (including KOffice), but sadly MS Word or Google Docs aren’t amongst them (yet).

ST31500341AS can be jumpered for 1.5Gb/s SATA

I’ve been struggling getting a 1.5TB Seagate ST31500341AS (CC1H firmware) to work on my ageing Mythtbuntu MythTV box (Gigabyte GA-8PE667 Ultra 2) to store TV programs on, it would just stop after the SATA BIOS for the onboard Silicon Image, Inc. SiI 3112 card had ID’d it correctly, before returning its size. So I went to Jaycar and bought a two port Silicon Image, Inc. SiI 3512 SATA card instead which seemed to work fine – the kernel booted and ID’d the card OK and I could partition it but then found that when I tried to make a filesystem I got lots of these:

ata3.00: exception Emask 0x0 SAct 0x0 SErr 0x2400000 action 0x0
ata3.00: BMDMA2 stat 0x86c1009
ata3: SError: { Handshk UnrecFIS }
ata3.00: cmd 25/00:08:28:7b:a8/00:00:ae:00:00/e0 tag 0 dma 4096 in
res 51/04:00:2f:7b:a8/00:00:ae:00:00/e0 Emask 0x1 (device error)
ata3.00: status: { DRDY ERR }
ata3.00: error: { ABRT }
ata3.00: configured for UDMA/100
ata3: EH complete

which caused I/O errors and the mkfs aborted. 🙁 Some nice people on the LUV list suggested jumpering the card for 1.5Gb/s operation, but I found a post on the Seagate forums saying:

The manual for Seagate SATA drives pretty clearly states (on page 22): “1.5Gbits jumper block only applies to ST3320613AS, ST3320813AS and ST3160813AS models” So it would seem that you can’t run your ST31500341AS in forced-1.5Gb mode (though the drive does support auto-negotiation – but I guess your controller does not).

I thought I was out of luck, and then I stumbled a post elsewhere that said:

I just called to Seagate. They insist that even though the product manual (At their website) says that using the jumpers to force SATA1(150mb/s) speed not supported for my HDD(ST31500341AS) and also on top of the HDD never print the label anymore, you still set the jumper and it’ll force SATA1 speed. According to the tech support dude.

So, having a jumper to hand I decided to give it a go, and it does appear to work! Not only can I finally successfully make a filesystem, but I can also run bonnie++ on it continuously without issues and then rsync all 200GB of TV shows onto it.

Digikam Problem with KDE 4.3 beta 1

If you’re using the Kubuntu 4.3 beta 1 packages for Kubuntu Jaunty you’ll likely find that you suddenly can’t view your albums any more. I traced it down to the following error in my ~/.xsession-errors file:

Could not open library '/usr/lib/kde4/kio_digikamalbums.so'.
Cannot load library /usr/lib/kde4/kio_digikamalbums.so: (/usr/lib/libdigikamcore.so.1: undefined symbol: _ZN6Marble12MarbleWidget16addPlaceMarkDataERK7QStringS3_)

Basically Digikam needs recompiling against the version of Marble in KDE 4.3 to get its symbol names fixed. Doing it isn’t that hard, you need to do:

sudo apt-get build-dep digikam
apt-get source digikam
cd digikam-0.10.0
dpkg-buildpackage

Once that’s done (and it’ll take a while) you’ll have 3 new packages in the parent directory of digikam-0.10.0, the Digikam package, a package for showfoto and a package for Digikams debugging symbols. Just use “sudo dpkg -i ” to install them.

KDE 4.3 beta1 Released

I so hope this finally fixes my Kopete TLS problems! Need to wait for the Kubuntu packages to appear..

Update: the Ubuntu Jaunty packages are currently in the Kubuntu experimental PPA. Downloading now..

Update 2: Upgrading ain’t for the faint hearted, I’ve had to remove packages, used dpkg --force-overwrite -i /var/cache/apt/archives/$foo.deb a couple of times and generally had a fun hour or so trying to upgrade. All done now so this is being edited with the new Konqueror:

Version 4.2.85 (KDE 4.2.85 (KDE 4.3 Beta1))
Using KDE 4.2.85 (KDE 4.2.85 (KDE 4.3 Beta1))

Debian Gives Up on Glibc (Updated)

It appears that the Debian developers have finally gotten to the ends of their tethers trying to deal with the foibles of GLIBC and its maintainer. There’s a post on Aurélien Jarno’s blog saying:

I have just uploaded Embedded GLIBC (EGLIBC) into the archive (it is currently waiting in the NEW queue), which will soon replace the GNU C Library (GLIBC).

He gives a list of reasons for the change, all of which seem to make good sense. My concern (like many others) is that I worry about the impact if they are unable to keep compatibility with glibc based distros – though it’d be nice if they followed Debian’s lead on this (which they may do if this leads to a much easier working relationship with the maintainers – which doesn’t appear to be that hard to achieve!).

Update: If you’re curious to see what packages will be affected there is a list of the Debian packages built from the eglibc sources available.

(Via LWN)