I’ve had a few requests for a 32 bit version of the Kororaa beta, so I’ve made one and it’s now available for download and testing.
Thanks,
-c
Tag Archive for 'Linux'
Page 3 of 12
That’s right folks, Kororaa is back.
I know that you’ll be looking for something Linux related to do over your Christmas holidays and New Year 😉 so I’ve just released the first installable Live DVD x86_64 beta for testing. The final release will be Kororaa 14 (derived from Fedora 14), codenamed Nemo. As with the original Kororaa, it’s based on KDE.
If you can find the time, I would really appreciate some feedback. Tell me it’s crap, tell me I suck, but tell me something 🙂 I’m really looking for suggestions on how to improve it and make sure that everything works. If you’re interested in contributing to a project like this, then here’s your chance!
Essentially, Kororaa has been re-born as a Fedora Remix, inspired by Rahul Sundaram’s Omega GNOME based Remix. I switched to Fedora about a year and a half ago, and I love it. Kororaa has re-emerged out of a desire to see others using Fedora, and so aims to provide a system which sets up a lot of the magic for you, out of the box. This is something I want my family (and all my friends) to be able to install and use. There are lots of things still to do, but I hope you’ll try it out and let me know what you think!
Kororaa aims to provide all general computing uses out of the box (well, as much as possible anyway). It aims to include the software packages that most users will want (this means Firefox for KDE, GIMP over Krita, VLC over DragonPlayer, and OpenOffice.org over KOffice Calligra, etc). Adobe’s Flash plugin and NVIDIA’s graphics drivers are each installable with a double click.
See the About page for a list of what Kororaa aims to achieve, and see the Changes page for a list of customisations and their status.
Here’s a look at the desktop, running from the Live DVD.
Thanks,
Chris
If you’re wanting to try out Fedora, but want all of your multimedia working out of the box, then give Omega a try (a Remix of Fedora). Rahul Sundaram has just released the latest version, Dalmation, which is built on Fedora 14 and available in both 32 and 64bit flavours.
Omega is a completely free and open source Linux based operating system. It is a installable Live image that includes comprehensive multimedia functionality out of the box. It is a Live image that can be optionally installed to your hard disk. Omega is 100% compatible with Fedora and a Fedora Remix only including packages from Fedora, RPM Fusion and Livna software repositories.
If you’re interested in what Omega is all about, I wrote an article on it for Linux Magazine a while back.
-c
Well it’s nothing if not interesting. The ~200 line “miracle” patch promises a huge improvement in desktop responsiveness, but Lennart Poettering (from Red Hat) has replied to Linus’ praising comments with 4 lines of bash which out-perform it, on the current vanilla kernel. (And by the way, Lennart seems to agree with Con Kolivas about this patch, in that make -j is not a valid desktop use case.)
Binding something like this to TTYs is just backwards. No graphical
session has a TTY attached anymore. And there might be multiple TTYs
used in the same session.I really wonder why logic like this should live in kernel space at all,
since a) the kernel has no real notion of a session, except audit and b)
this is policy and as soon as people have this kind of group then they
probably want other kind of autogrouping as well for the other
controllers, which hence means userspace is a better, and configurable
place for this.
To which Linus then replied:
Numbers talk, bullshit walks.
The numbers have been quoted. The clear interactive behavior has been seen.
And you’re just full of bullshit.
Come back when you have something working and with numbers and better
interactive performance. Until then, nobody cares.
So, Lennart replied with his something better, 4 lines of bash:
Here’s my super-complex patch btw, to achieve exactly the same thing
from userspace without involving any kernel or systemd patching and
kernel-side logic. Simply edit your own ~/.bashrc and add this to the end:
if [ "$PS1" ] ; then
mkdir -m 0700 /sys/fs/cgroup/cpu/user/$$
echo $$ > /sys/fs/cgroup/cpu/user/$$/tasks
fi
Then, as the superuser do this:
mount -t cgroup cgroup /sys/fs/cgroup/cpu -o cpu
mkdir -m 0777 /sys/fs/cgroup/cpu/userDone. Same effect. However: not crazy.
Of course the debate raged on because Linus thinks it’s stupid to make people have to set this up in userspace, and Lennart disagrees. Despite all this, finally everyone is at least acknowledging these issues and looking into them! Excellent.
-c
Con Kolivas (of SD/BFS fame) has posted his thoughts on the new ~200 line “miracle” kernel patch. It’s an interesting read.
In short, he had already implemented something like this in a 10 line patch to his BFS scheduler, but he dropped them because it introduced regressions.
Those following the development of the patches for interactivity at massive load, I have COMPLETELY DROPPED them as they introduce regressions at normal workloads, and I cannot under any circumstances approve changes to improve behaviour at ridiculous workloads which affect regular ones. I still see precisely zero point at optimising for absurd workloads. Proving how many un-niced jobs you can throw at your kernel compiles is not a measure of one’s prowess. It is just a mindless test.
He goes on to say:
Again, I can’t for the life of me see why you’d optimise for make -j64 on a quad core machine. It is one workload, unique to people who compile all the time, but done in a way you wouldn’t normally do it anyway. It is not going to magically make anything else better. If for some god-forsaken reason you wanted to do that, you could already do that with nice, or even better, by running it SCHED_IDLEPRIO.
Perhaps this patch really helps the existing CFS implementation, but it’s still lacking when compared to BFS. Maybe it is a step in the wrong direction, but perhaps some improvement like this is better than none at all? It might be the catalyst needed to improve the kernel further. I never could understand why we couldn’t have more than one CPU scheduler in the kernel (like we do for block I/O).
Anyway, this is all quite interesting!
-c
There’s been lots of criticism from certain camps that Linus and the kernel developers don’t care enough about the desktop and that it has too much focus on big iron. There certainly have been (and continue to be) issues with Linux on the desktop, in terms of performance. Lately there has been a push to improve it, perhaps driven by the need to have Linux running well on small devices like Android and MeeGo.
Or perhaps it stems from much further back. We all remember anaesthetist Con Kolivas’s kernel patches (Kororaa used -ck, back in the day) and schedulers which improved desktop performance a whole lot, but in the end he was shunned, and then quit development. Linus wasn’t convinced, and Ingo Molnár (the CPU scheduler maintainer) then wrote a new scheduler which was more like Con’s (ironically named, Completely Fair Scheduler). Although he quit, two years later Con was still using Linux and couldn’t stand the desktop responsiveness any more, so he created a new scheduler, BFS (with no intention if getting it into the mainstream kernel).
Why is this important? Well now someone else is having a go. The small 200 line patch by Mike Galbrait has such a tremendous impact that even Linus can’t argue with the result.
If you want to see it in action, Phoronix has an article about the patch along with some videos showing the dramatic difference.
“Tests done by Mike show the maximum latency dropping by over ten times and the average latency of the desktop by about 60 times.”
With this patch, the desktop (running GNOME) can smoothly play the Ogg 1080p version of Big Buck Bunny and glxgears at the same time, while scrolling up and down a Firefox window and.. wait for it.. performing a kernel compile with make -j64.
I don’t think that this will be merged until 2.6.38 as the 2.6.37 window has already closed.
-c
Coming from a Gentoo/Debian background, one thing that has constantly bugged me on RPM based platforms like Fedora is the lack of decent, reliable dependency removal.
It seems so simple (and Debian has done it since the dawn of time) – if I install package x which pulls in dependencies y and z, then when I remove package x, I want to remove dependencies y and z, if they are not required by any other package.
Yes, there is the remove-leaves plugin for Yum and various RPM orphan checking tools, but in my experience, they are just not reliable.
So, I’m very happy to have discovered that Seth Vidal has merged orphaned dependency cleanup on removal into Yum. Hallelujah!
It’s in rawhide yum-3.2.28-13, and I’ll do some testing soon…
The well known RPMFusion repository contains a lot of the useful software which Red Hat doesn’t ship by default (for licensing, patent or legal reasons). It is the amalgamation of several other repositories, including Dribble, Freshrpms, and Livna.
One helpful package that RPMFusion does not package however, is libdvdcss, the free software library which enables Linux to play encrypted DVDs.
Most users keep Livna around for this single purpose, but it is often offline (especially recently). So, here’s another solution – use ATrpms – another third party repository that includes lots of handy software.
The problem is, ATrpms has lots of other software which you might not want to update and which could conflict with the packages from RPMFusion. The solution? Tell yum to only include libdvdcss* packages from that repository. Easy.
To do this, simply add a new repo file (/etc/yum.repos.d/atrpms.repo) for Yum to configure it.
[atrpms]
name=Fedora Core $releasever - $basearch - ATrpms
baseurl=http://dl.atrpms.net/f$releasever-$basearch/atrpms/stable
gpgkey=http://ATrpms.net/RPM-GPG-KEY.atrpms
gpgcheck=1
includepkgs=libdvdcss*
Now, just run the following to update the repo and install libdvdcss (you may wish to remove the old package first, if you have it).
sudo yum check-update
sudo yum install libdvdcss
That’s about it!
-c
When John needed wireless for his computer at home, he bought (probably on my recommendation) a Billion 3011N – a USB wireless N device with the Realtek 8191S(U) chipset. On the box it said that it supported Linux, so I figured it was a pretty safe bet (surely that means there’s a stable driver in the mainline kernel, right?).
Turns out, no. The device has horrible support under Linux and it’s a super pain. The driver disk that came with the box does have a Linux driver, but it doesn’t always compile against the kernel and then there are configuration issues and a custom wpaconfig is required.
Gah.
So John bought another USB wireless dongle.
Anyway, so now I need a USB wireless dongle for my machine and I asked John to buy one of his spare ones from him (he has four or five). He gave me the afore mentioned Billion device. I plugged it into my Fedora 13 box, but it didn’t know much about it. So then I downloaded the open source driver from Realtek, compiled it and loaded the module. The system hard-locked – even Magic Keys couldn’t save it.
I shelved it for a while, until a bloke called Terry Polzin on the Fedora list today posted a request for help with getting a Realtek 8188S(U) working. I replied saying that I had a similar device and shared my experiences.
I told him that there is a driver in staging which supports the device, but unlike Ubuntu, Fedora only ships quality working drivers by default, so no staging drivers are included. It’s easy enough to get them though, just add the RPMFusion Free repository and install their kmod-staging package which (as the name might give away) includes the staging drivers for the current kernel.
Once you have that installed, the r8192s_usb module can be loaded, but the device still needs external (presumably proprietary) firmware to work. Fortunately, although the driver available from Realtek does not include it, it was included on the disk, and is also available in the Billion driver from their website. So, once you have put the firmware in the right place, the device just works.
Here are the steps to get it working (you will need to have RPMFusion enabled, and run these as root).
yum install kmod-staging unzip
depmod -a
wget http://au.billion.com/downloads/3011N/3011N_Linux_Driver.zip
unzip -j 3011N_Linux_Driver.zip "*rtl8192sfw.bin" -d RTL8192SU
mv RTL8192SU /lib/firmware/
Now, plug in your device and check that the module and firmware have been loaded, using dmesg. You should see something like this:
usb 1-2.3: new high speed USB device using ehci_hcd and address 16
usb 1-2.3: New USB device found, idVendor=0bda, idProduct=8172
usb 1-2.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
usb 1-2.3: SerialNumber: 00e04c000001
==>ep_num:4, in_ep_num:1, out_ep_num:3
==>RtInPipes:3
==>RtOutPipes:4 6 13
==>txqueue_to_outpipemap for BK, BE, VI, VO, HCCA, TXCMD, MGNT, HIGH, BEACON:
1 1 0 0 2 2 2 2 2
Dot11d_Init()
rtl819xU: --->FirmwareDownload92S()
usb 1-2.3: firmware: requesting RTL8192SU/rtl8192sfw.bin
rtl819xU:signature:8192, version:902b, size:30, imemsize:7408, sram size:9688
rtl819xU:--->FirmwareDownloadCode()
rtl819xU:--->FirmwareCheckReady(): LoadStaus(1),
rtl819xU:<---FirmwareCheckReady(): LoadFWStatus(1), rtStatus(0)
rtl819xU:--->FirmwareDownloadCode()
rtl819xU:--->FirmwareCheckReady(): LoadStaus(2),
rtl819xU:-->FirmwareEnableCPU()
rtl819xU:IMEM Ready after CPU has refilled.
rtl819xU:<--FirmwareEnableCPU(): rtStatus(0x0) rtl819xU:<---FirmwareCheckReady(): LoadFWStatus(2), rtStatus(0) rtl819xU:--->FirmwareDownloadCode()
rtl819xU:--->FirmwareCheckReady(): LoadStaus(3),
rtl819xU:DMEM code download success, CPUStatus(0x3f)
rtl819xU:Polling Load Firmware ready, CPUStatus(ff)
rtl819xU:FirmwareCheckReady(): Current RCR settings(0x157e20e)
rtl819xU:<---FirmwareCheckReady(): LoadFWStatus(3), rtStatus(0)
rtl819xU:Firmware Download Success!!
ADDRCONF(NETDEV_UP): wlan0: link is not ready
=====>rtl8192SU_link_change 1
<=====rtl8192SU_link_change 2
Now, you should have a wireless device and network interface, which you can check with iwconfig and ifconfig -a.
wlan0 802.11b/g/n Mode:Managed Frequency=2.422 GHz
Access Point: Not-Associated Bit Rate:130 Mb/s
Retry min limit:7 RTS thr:off Fragment thr:off
Power Management:off
Link Quality=0/100 Signal level=0 dBm Noise level=0 dBm
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:0 Invalid misc:0 Missed beacon:0
And that's it. The device should now work with NetworkManager, etc.
The main downside here (apart from the obvious) is that you will be relying on RPMFusion to build an updated kmod-staging version when you get a Fedora kernel update. Sometimes this might not happen before you get your kernel, so when you reboot, you lose your wireless (because there's no driver). If so, boot to your older kernel for a while, or build the driver yourself, or create an akmod instead of kmod.
Ubuntu users should be able to just put the firmware in the right place, as their kernel ships with the unstable drivers by default.
-c
A friend of mine who is still relatively new to Linux has started his own blog, to document some of his experiences and discoveries. He’s primarily a technical writer and tester, but I think that he might have some worthwhile things to say from a technical Linux newbie’s perspective. At the very least, it’s a great way for him to document things he wants to recall in the future!
Good luck Allan 🙂
-c