Posts tagged with linux

Sugar Camp Reflections

Massive strides were made in community integration and community driven projects which will be considered or worked on in the coming months for the next release of Sugar, referred at this time as 0.86, and to be officially released in August of this year, following a 6 month release cycle of Gnome and many other open source projects.

Some of the more interesting changes that are being considered are a move away from matchbox to metacity, the well known and supported backend window manager used by Gnome. This should in theory allow for much greater integration into Gnome itself of individual sugar activities, as well as the launching of sugar in Gnome, and even speed improvements. This move is possible because the XO 1.5 will have more memory and better cpu speeds, as well as a move away from sugar being agnostic to that hardware. Sugar on a Stick was the big focus, which is now working quite well, but still not perfect.

A desire for a revival of the help application was shown and that will become one of the core fructose activities, though likely it will be totally updated and perhaps even interactive. Browse will be upgraded to have tabbed browsing, and have better support for integrated flash/gnash, pdf support and youtube casts. A demo was shown of a screencast of the usage of an activity coded at the camp, using turtle art. These quick advances show that it is not only possible to strengthen the Sugar Core and its activities, but also that one day soon we will have a ubiquitous sugar solution that will run on all distributions and platforms and most hardware.

The mention of fundraising was raised and there is a target in place of aquiring 100,000 euros within the next release cycle which will be used primarily in marketing and gathering core sugar people to the places they need face to face talks like the one provided in Paris.

Rate It! (Average 0, 0 votes)



Netbsd Live CD and Gentoo 2009 Review


Netbsd Live CD/DVD


I was eager to try out this distribution as I'd heard great things about it and
it seemed like a fine new kid on the BSD block. Firing up the cd was simple
enough, and I was greeted with the typical $ prompt signifying a c shell
prompt. I bashed myself in by using the bash command and had a little more
legible prompt. From there, I had to kind of guess how to start up X and be
prompted with a workable desktop environment. I tried several things like
startx, gdm, startkde, etc. I got lucky with startx, which brought me to a
familiar xfce environment. I am no massive fan of xfce, but next to Gnome, it
is my favorite. The layout was nice, and there was an abundancy of essential
apps which any casual user would want. The glaringly missing item though was an
install to disk option. It seems netbsd live cd really is just that. A distro
run from cd, aimed at slower low end machines. This is fine, except it should
be made quite clear from the start with a splash page or something. Another
thing I really disliked, and this goes for all the XFCE run distros, was the
difficulty in finding out how to change my keyboard settings. I must have spent
a good 20 minutes looking for this. Again, this is where openSUSE and Ubuntu
shine. Both those distros have usability perfection. I would say that Ubuntu is
the simplest, but with its simplicity it looses a little of the real cutting edge
openSUSE now has.

Gentoo 2009

I used Gentoo many years ago, when Daniel Robbins was still heading up the
project. Back then it was my distro of choice. One could learn so much about
the inner workings of building an OS from the ground up, and it became the
foundation of my Linux knowledge. Now, in a gaklaxay far far away, Gentoo had
me wondering how it had progressed so many years later. Firing it up is easy
enough with the live cd, which is surprisingly based on the XFCE desktop. I
don't mind the xfce environment so much, other than sometimes it feels a bit
unpolished. It is clearly no Gnome or KDE with all its bells and whistles, but
it sure is a whole load faster and more minimal. I first tried the text based
installer, chose the partition I wanted to install it to, and then it told me
hte feature to mkfs the partition to ext3 was not yet implemented and I should
go to the command line and do that myself. That would be fine, but there were
no instructions included on that. This led me to look for further instructions
about installing Gentoo in general, but all the help files related to XFCE and
not to Gentoo itself. So... I led myself down the graphical install rabbit
hole, which seemed to work ok. It was both easy to use and pretty. All seemed
to be going wonderfully until it ended with ''your install has failed'', along
with a cryptic message saying this could be due to any number of reasons. The
log showed this, but I bet even a Gentoorian couldn't make sense of this:

"ERROR, couold not map"+device+"to anything in the device
map"

So that was it for my adventures with the gentle little penguin known as the
gentoo. Sabayon, it seems, has run circles around its old grand daddy. I mean,
ok, the live cd works, but thats about it... I remember seeing more intriguing
desktops back in the 90s.


 


Rate It! (Average 0, 0 votes)



Knoppix 6.1 - The review

At first glance, knoppix seems to really have it all together, with a realm of software, although organised in a barely discernable fashion. But out of the box, it was able to read all my peripherals and play back my mp3s and tv series without complaints about codecs. For all the other systems, this was a problem, as I was not near an internet connection so downloading the codecs was out of the question.


The Adriane system, which is a windows interface for the blind I take it, was impressive, and a great step in the direction of making a full system easily accesible to to the hard of sight or blind.


As for the general layout of Knoppix itself, the menus and the style choices including colour and themes, I was quite dissapointed. Nevertheless, I attempted to install the operating system to disk, which I know is unusual since knoppix has traditionally been known to be a live cd/dvd idea.


This is where my problems started. First, I had to partition everything by hand, seeing as I alread had another os on the drive. This was NO trivial task, even for a seasoned parted head like myself. First, it demanded a reiserfs partition for /, and then both that and the swap partition had to be turned on (mounted) before the installer would let me do anything. I spent a good 20 minutes figuring that one out.


From then on, installation seemed to go well, until it came to the grub part. I was cryptically asked whether it should just add an entry to my existing grub or make a new one. I naturally answered I wanteda simple addition to the system. When I rebooted my computer, I was greeted with no operating system found. Hmmm, I thought. So, being quite experienced with grub issues, I loaded up a live cd, entred command line, and did the typical, find /boot/grub/menu.lst. It found 2 of them on different partitions?!?


Perplexed as I was, I tried setting the root one to the partition knoppix was on. Reboot... same thing, no operating system. That was frustrating enough for me to pull out my trusty old ubuntu and install that, hoping it would find my other partitions and fix it all. Which it did. So.... knoppix may be a fine live dvd, but I would not recommend installing it unless you really like trouble. Once my bootloader was recovered though, knoppix was quite a delightful OS to work with. Easy access to the applications I needed for work were easy and fast to access, and I have the feeling that overall the system is quick and responsive in comparison to some of the other linux distros.


Knoppix curiously also has something called the knoppix terminal server, which looks and feels very much like a kind of LTSP server, but that just feeds fat knoppix images to other computers on the network. This would seem like a very useful feature which isnt very well documented and would be perfect for educational environments, if only the state of the applications was better. I hope to see more progress in that area in general. On a last note, it took me a good 15 minutes just to find out how to change my keyboard settings.


Rate It! (Average 0, 0 votes)



easy packaging with openSUSE's build service

Distros tend to have their own unique package management system, though some share a common base (Debian and ubuntu for example), but non can do what openSUSE's online build service does, which is build for most architectures and practically all distributions. Being able to edit a couple of files, upload them, and let the remote computer to the work is a dream come true. No longer do upstream maintainers have to build packages individually for every distro they want to support, not to mention architectures. They can follow a set of simple instructions that practically anyone can follow and have their software available on most major platforms and architectures. This document should show you how its done. It is assumed you are using openSUSE as your base distro. Special thanks go out to Jigish Gohil/cyberorg, for helping me understand these steps


The first step is to create an account with https://build.opensuse.org/ or if you already have one, log into it. Also, we need to add a little script that tracks changes by pasting the following into /usr/bin/changelog and editting your time zone and email address:


#!/bin/bash
EDITOR=vi
FILE=$1
COMMENT_FILE=$(basename $FILE .spec).changes
tmpfile=$(mktemp changelog-XXXXXX)
timestamp=$(LC_ALL=POSIX TZ=Asia/Kolkata date)
email=my@emailaddress.org
separator="-------------------------------------------------------------------"
{
    echo "$separator"
    echo "$timestamp - $email"
    echo
    echo "- "
    echo
    if [ -n "$COMMENT_FILE" ]; then
      if [ -f "$COMMENT_FILE" ]; then
        cat $COMMENT_FILE
      fi
    fi
} >> $tmpfile || exit 1
if [ -z "$COMMENT_FILE" ]; then
    lines=1
    CHKSUM_BEFORE=$(md5sum $tmpfile | awk '{print $1}')
else
    lines=$(wc -l $COMMENT_FILE | awk '{print $1}')
    CHKSUM_BEFORE=has_changed
fi
$EDITOR +$((4+lines)) $tmpfile
if [ "$CHKSUM_BEFORE" = "$(md5sum $tmpfile | awk '{print $1}')" ]; then
    exit 1
fi
cat $tmpfile > $COMMENT_FILE
rm $tmpfile

and changing the permissions of the file by doing:


 


sudo chmod u+x /usr/bin/changelog

 


Meanwhile, search the net for a package you are interested in building. It is suggested to start off with something easy, that already has the source available in rpms format, that is to say, is a package that contains the source tarball and a .spec file at least. Usually these packages look like this: package-name-version-distro-1.2345.src.rpm. Next you want to download that file to the desktop and extract it by right clicking and choosing extract here.


You can now open the .spec file which will contain the description required to build the package on rpm based systems, as well as the name and description of the package. In the opensuse build service (oBS) web page, choose create a project or subproject, and then add a package. Here you need to fill out the Name, Title and description. The name and title are usually the same and are normally just the name of the package without version number or platform. (For example, sugar-maze) Then in the description copy and paste the description you got from the .spec file.


Now its time to go to the terminal and do:


osc co home:username:subproject packagename
cd home:username:subproject/packagename
mv ~/Desktop/package-name.version.distro.src/* ./

 


Now we want to edit the .spec file and replace the line that looks something like this:


Release: 1.20090216%{?dist}

with these lines:


%if 0%{?suse_version}
Release: 1
%else
Release: 1.20090216%{?dist}
%endif

 


We will also need to add any missing requires and buildrequires. These are usually visible inside the oSB tool, when the build has been committed. That means one may need to go back and edit the .spec file, and then recommit the changes. Now we need to add an entry to the changelog, which tracks what you are doing to the package:


changelog package-name

The command interface here is vi based, so its i for insert, and :qw to write and quit. Next you will want to edit the metadata (this only requires doing the first time you build a package!):


osc meta prj -e home:username:subproject

You should change the content so it looks something like this


Finally we add the spec, changes and source tarball to the oBS:


osc add *.spec *.changes *.gz

and we commit it:


osc ci -m "uploaded new package"

Thats all it takes to have your package now building or queued to be building. If you want to create a package directly from a tarball, that is also possible, and it is suggested you use the spec file you created as the base that you will need to edit accordingly. While it is not in the scope of this document to explain how that is done, it is easy enough to duplicate a project, and use that as the base:


osc copypac home:username:subproject youroldpac home:username:subproject newpac

And then you can rename the .spec file, changes, and add the source tarball of the package you want to build. Then you can follow the same instructions above for uploading to oBS.


Rate It! (Average 0, 0 votes)