Archive for October, 2008

Forcing Ubuntu (and Debian) to upgrade to a newer distribution version

Ubuntu Software Sources screen

Updates tab from Ubuntu Software Sources screen

Ubuntu is usually good at highlighting the existence of a new version of the distribution through its Update Manager. That means that 8.10 should be made available to you at the end of the month so long as you have sorted the relevant setting for 8.04 to realise what has happened. That lives in System > Administration > Software Sources > Updates. If you haven’t done that, then 8.04 will continue regardless since it is a long term supported release.

Otherwise, it’s over to the command line to sort you out. One of the ones below will do with the first just carrying out a check for a new stable version of Ubuntu and second going all of the way:

sudo update-manager -c

sudo update-manager -p

if you are feeling more adventurous, you can always try the development version and this checks for one of those (I successfully used this to try out the beta release of Intrepid Ibex from within a Wubi instance on my laptop):

sudo update-manager -d

Neither of the above are available in Debian so they seem to be Ubuntu enhancements. That is not to say that you cannot force the issue with Debian; it’s just that the more generic variant is used and, unless, you have gone fiddling with visudo, you will need to run this as root (it works in Ubuntu too):

update-manager –dist-upgrade

Ghostscript: **** Unable to open the initial device, quitting.

The above error message has been greeting me when creating PDF’s with Ghostscript on a Solaris box and does need some translation. If you are directing output to a real printer, I suppose that it is sensible enough: nothing will happen unless you can connect to it. It gets a little less obvious for PDF creation and seems to mean that the pdfwrite virtual device is unable to create the specified output file. A first port of call would be check that you can write to the directory where you are putting the new PDF file. In my case, there seems to be another cause so I’ll have to keep looking for a solution.

Update: I have since discovered the cause of this: a now defunct TEMP assignment in the .profile file for my user account. Removing that piece of code resolved the problem.

A way to combine PDF files in UNIX and Linux

My latest adventure in the world computing has led me into the world of automated PDF generation. When my first approach didn’t prove to be completely trouble-free, I decided to look at the idea of going part of the way with it and finishing off the job with the open source utility Ghostscript. It is that which got me thinking about combining bookmarked PDF files and I can say that Ghostscript is capable of producing what I need as long it doesn’t generate any errors along the way. Here’s the command that does the trick:

gs -dBATCH -dNOPAUSE -q -sDEVICE=pdfwrite -sOutputFile=final.pdf source_file1.pdf source_file2.pdf

The various switches of the gs command have very useful roles with dBATCH ensuring that Ghostscript shuts down when all is done, dNOPAUSE removing any prompts that would otherwise be given, q for quiet mode, sDEVICE using Ghostscript’s own PDF creation functionality and sOutputFile creates the output file, stopping Ghostscript from sending it to its default stream. All of this applies to Windows Ghostscript too, though the name of the executable is gswin32c for 32-bit Windows instead of gs.

When it comes to any debugging, it is useful to consider that Ghostscript is case sensitive with its command line switches, something that I seen to trip up others. I am getting initial device initialisation so it strikes me that dropping some of the ones that reduce the number of messages might help me work out what’s going on. It’s a useful idea that I have yet to try.

There is also online documentation if you fancy learning more and Linux.com have an article that considers other possible PDF combination tools as well. All in all, it’s nice to have command line tools to do these sorts of things rather than having to use GUI applications all of the time.

Interrogating Solaris hardware for installed CPU and memory resources

There are times when working with a Solaris server that you need to know a little more about the hardware configuration. Knowing how much memory that you have and how many processors there are can be very useful to know if you are not to hog such resources.

The command for revealing how much memory has been installed is:

prtconf -v

Since memory is often allocated to individual CPU’s, then knowing how many are on the system is a must. This command will give you the bare number:

psrinfo -p

The following variant provides the full detail that you see below it:

psrinfo -v

Output:

Status of virtual processor 0 as of: 10/06/2008 16:47:54
  on-line since 09/13/2008 14:47:52.
  The sparcv9 processor operates at 1503 MHz,
        and has a sparcv9 floating point processor.
Status of virtual processor 1 as of: 10/06/2008 16:47:54
  on-line since 09/13/2008 14:47:49.
  The sparcv9 processor operates at 1503 MHz,
        and has a sparcv9 floating point processor. 

For a level intermediate between both extremes, try this to get what you see below it:

psrinfo -vp

Output:

The physical processor has 1 virtual processor (0)
  UltraSPARC-IIIi (portid 0 impl 0×16 ver 0×34 clock 1503 MHz)
The physical processor has 1 virtual processor (1)
  UltraSPARC-IIIi (portid 1 impl 0×16 ver 0×34 clock 1503 MHz)

Private
  • As is commonly the case with places like these, all the views that you find expressed on here in postings and articles are mine alone and not those of any organisation with which I have any association, through work or otherwise. With regards to any comments left on the site, I reserve the right to reject any that are inappropriate. Otherwise, whatever is said is the sole responsibility of whoever is leaving the comment.