Distros Archives - Page 4 of 11 - Yet Another Linux Blog

Unity 2010 Beta 2 Impressions

As noted previously, I’ve been pretty hard pressed lately in my secular job due to migrations and other fun activities happening throughout the past few months. I did however, get the chance to download Unity 2010 Beta 2 and give it a go. I had some problems when booting because I was brought to a blank black screen with a mouse pointer no matter what options I passed during boot. To get by this, I had to follow some IRC advice on #unitylinux (thanks wile_netbook!) and change to a second tty, kill the Xserver and GDM, followed by executing do-vesa. It’s hard to try to do it quickly though because GDM will try and restart X and switch init levels on you back to a graphical one. To get by this, you’ll need to do the following:

Drop into a different tty. Login as root…if you’re on the liveCD, the password is root. Execute:

ps aux | more

Make note of the PID for X and GDM. Write them down…replace the terms below with your PID numbers:

kill -9 PID_for_X && kill -9 PID_for_GDM && do-vesa

You now should see something other than black screen with mouse cursor. I’m not sure how many systems this affects…but I know my Dell Latitude D630 laptop took it on the chin for this one. Not a huge problem for a Beta…I mean, a distro can’t be all things to everyone.

Overall though, Unity 2010 Beta 2 is much more solid than Beta 1 was for me after getting by the initial X problem. Everything works as it should as far as sound, Internet, and wireless are concerned. I quickly removed PCmanFM and replaced it with Thunar, my file manager of choice. I removed LXPanel and installed Tint2. Installed Nitrogen to manage wallpaper. Installed Parcellite to give me a clipboard, Installed volwheel to give me a volume applet to control volume. Installed Pragha to give myself a great music player. Installed Irssi to allow me to get my IRC fix and put pidgin in play to IM. I had a usable, customized desktop within about an hour. And it’s been really solid…just as solid as my Arch Openbox desktop I run at home…which makes me feel good about this Beta.

So what else have I been working on? I’ve been working on a large (VERY large) tutorial on file permissions and making use of groups for file/directory access to add to the tutorials section of YALB. This thing has been in work since last year and I’m attempting to finish it up before the months end to give a good representation of what file permissions in Linux are for and how they work with users and groups. I’m also going to write up a tutorial on how to customize Unity 2010 Beta 2 into a lightweight Openbox desktop. So, some good updates hovering on the horizon. Stay tuned 😀

Foresight, rPath, LiveCD, and Unity Linux

Most, if not all, top distributions of Linux ship a live CD that allows an end user to preview the operating system without installing it.

Foresight Linux is the exception.

Now, this isn’t because they don’t WANT to have a Live CD…they do. The problem is that rPath, the creators of rBuilder Online, have discontinued the Live CD image creation type.

There was no announcement…no news posting…no clue dart thrown toward Foresight for this discontinuation. There was only a comment on a single bug in the rPath issue tracker just this past May…Formally discontinued…which in my opinion, is a HUGE mistake as far as community goes. Why? Because a community is a solid base on which to stand for any distribution or toolset for open source. rPath has essentially dismissed a feature that the community would find valuable and in the process alienated anyone who finds this feature valuable or desirable. But I’m not here to talk about whether or not people want to develop their own distributions on rBuilder Online using rPath tools nor the incentive to do so…I’m talking about Foresight.

So, what incentive does rPath have to help Foresight by fixing it? Not much…I’m sure there will be those that argue: “rPath has customers and their first allegiance needs to be to them” and those people would be right. But can’t the Foresight community pick up the torch for Live CD building on rBO and develop it as a community effort? Can’t a license be found that it can be released under that would prevent forking? Can’t it be modularized as a ‘plug-in’? I don’t pretend to know the answer to those questions…I just think that Foresight will continue to suffer as they have been for many, many months now with respect to not having a Live CD.

I’m sure that there will also be those out there saying “but Foresight has a bunch of Virtualized Images to choose from!! No one really cares about a Live CD!!” and I’d say you’re halfway correct. Developers don’t really care about a Live CD…but those that Foresight attempted to attract…the end user…they DO care about having something they can ‘try before they buy’. It is my belief that Foresight would be a crap-ton more popular if they had a Live CD.

So What Solutions Are There?

I don’t think rPath will suddenly fix the broken Live CD creation in rBO. I don’t think they’ll release the code anytime soon (though this is more likely than a fix). So in the meantime, what if Foresight helped out with LiveCD project that recently was taken over by Unity Linux? Both Unity and Foresight are Red Hat like distributions and use similar file structures and OS organization. I think that if Foresight were able to integrate LiveCD onto the distribution, a huge niche would be filled.

Where to Start?

Being involved both with Foresight Linux and Unity Linux gives me a unique perspective on what areas of collaboration could be developed. One thing is for sure…having both distro development teams onboard would be a huge boon to LiveCD development…and Foresight could suck in SRPMs quite easily from Unity to hit the ground running right away.

I am by no means offering to be the head of this project because I can’t even begin to know where it would start or finish. I’m just offering a workaround to a problem I’ve seen Foresight have for longer than it should have. I know the Unity Linux guys would welcome anyone wanting to get involved with helping LiveCD development. Would Foresight be open to this? I can’t answer. I hope so…Foresight needs a Live CD if it hopes to attract more people to it…and that’s something I’m keen on seeing. Is this something you’d like to see as well?

[poll id=”2″]

Clarification on Foresight and Fedora

I previously wrote about a possible “rebasing” of Foresight Linux on the Fedora platform. This conjecture was a bit premature it seems as I am completely wrong on this being a possibility 🙂 The best part about me being absolutely wrong on this is that there is still going to be benefits for Foresight and Fedora even without the rebase.

Foresight is toying with the idea of having a sub-project (completely separate from Foresight Linux base) that it has tentatively called ‘boots, a Fedora remix‘ (a play on Dora in Fedora for those of you with kids).

What would happen is that mirrorball, a tool from rPath that ‘sucks in’ repositories, would pull in a Fedora repository into a separate Foresight repository. From there, it is fully consumable by any product/project that is hosted on rBuilder Online from rPath. Conary really is one of the most innovative package managers on the planet and I’ve mentioned it once or twice before (never got around to part II on one of those though). The ability to fully suck in a RPM repository is already being done with CentOS and Scientific Linux on rBuilder Online…even Ubuntu is currently being done as well…so we have proof that it is totally possible. Once imported, Conary takes over the management of said packages.

So what does this give Foresight? A few things:

Testing of packages in 2 communities
Developer eyes/chatter in 2 communities
The ability of Foresight to cherry pick packages from a large base
Compare and contrast for packages from 2 different sources to track down bugs

So, as I said, I was wrong initially and I hope this clears up what Foresight plans to do. A sub-project will be started that imports the Fedora repository changing them from (rpm to Conary) allowing Foresight to both test and cherry pick packages from a larger base hopefully freeing up a bit more time for Foresight architects. Phew! What a mouthful, run-on-sentence that was!

Why Conary? How does this help Fedora?

I know some of you may be asking Why Conary? What does it have over RPM that Foresight should suck in a repositoroy and change it to Conary packages? The reason this is an absolute necessity is because the tools on which Foresight are built (rBuilder Online) works with Conary only…that means ISO generation and repository hosting are all mandated to be Conary based.

The other interesting part about this is that Conary blends version control with package management. It deals with changesets as packages. Imagine SVN…you have a local changeset that you’re working on and the version inside the SVN repository differs from that. You can then diff the state of your local copy to see how it differs from the remote copy. This allows you to see the changes you’ve made and allows you to see what code may be broken. Also, commits are numbered automagically so that you don’t have to worry about breaking things much because you can rollback to a previous known good state.

The same is true with Conary…you can rollback to previous known good states. You can also diff each changeset locally with the remote repository. Now imagine this with Fedora packages…if something is broken, chances are Foresight will find a fix for it much more quickly than someone in Fedora…a single command can diff the previously known good version with the broken version and find out the shortcoming. Or perhaps a known good verion in Foresight that isn’t Fedora based might be used to diff the Fedora RPM version and find out the differences in them. In all, it’s going to help developers track down problems faster. This helps Fedora…they now have a small number of Foresight developers who will be working with hundreds of popular Fedora RPMs looking to see if they work or are broken.

Most of the benefit will be measurable in Foresight because they’ll be able to use just about any package Fedora creates…but the Foresight community is FULL of very capable developers…guys that really know what they’re doing. If they can make this a collaborative effort Fedora will gain exceptionally smart developers as well…even if testing packages on a different platform, they’ll have eyeballs on these packages and if a fix is found or made for them they will definitely go upstream to Fedora.

Hopefully, this puts things right from my initial wrong. I don’t claim to be an insider for Foresight…I just know a lot of the people involved and ask questions a lot….I also pay attention to the developer mailing list. If you have any questions, please leave a comment and I’ll attempt to track down answers for them 😀

Foresight and Fedora, ClarkConnect Becomes ClearOS

Foresight and Fedora (aka “boots, a fedora remix”)

Last week it was reported by LWN and a few other Linux news sites that Foresight Linux may employ a change of direction…that is, create a spinoff project that places the Conary package manager onto a Fedora Linux base. Michael Johnson, Director of Operating Systems at rPath (which maintains the Conary based package manager Foresight uses) summed up his post nicely:

“I think that Foresight needs to be based on an upstream distro that is regularly fully updated and refreshed, and that is maintained by distro specialists with experience and expertise that is just plain missing within the Foresight development community. That distro needs to be imported into a Conary repository; that will allow Foresight to continue to use Conary to manage the process of building a set of consistent modifications relative to that upstream distro, providing a true rolling release. That would allow Foresight developers to concentrate on only the problems inherent in integrating the very latest development source against a recent base that is relatively close to the basis on which the software is maintained.”

Michael also said that it made sense to do this based on Fedora because Foresight is very Fedora-like in filesystem and the way that things are setup and handled in the guts of the operating system (paraphrasing from what I remember of IRC discussion). Also, in a comment on the LWN thread, Michael states that Foresight, if spinning off with Fedora, would still make use of “Conary, rMake, rBuilder, rBuild, and other rPath technology” and would still use Conary as its package manager which means…it wouldn’t leverage rpm and yum to keep things up to date on it.

An independent project that Foresight maintains sounds like a HUGE undertaking…(even though I’m assured repeatedly by developers from Foresight that it won’t be because it’s “automatic”). I’ve seen automagic things in the past that won’t cause a lot of work turn out to be quite a bit of work-that-is-not-work. I find this especially odd when the main complaint is that there aren’t enough OS specialists around…it sounds a bit too large to undertake. This project actually sounds like it possibly would usurp Foresight Main (Foresight Proper…Foresight Linux…whatever you call it) which is based on the stable rPath Linux and not on cutting edge Fedora like the “boots remix” would be. Therein lies the problem. The”boots, a fedora remix” would consistently be ahead of Foresight in development if the project is started and makes progress. Foresight will continually lag behind it. Can a 100% guarantee be given that Foresight can snipe packages from “boots, a fedora remix” that would always work? If not, what does Foresight gain by maintaining the project/spinoff?

I think Foresight won’t be able to maintain an independent project based on Fedora along side of the main Foresight Linux project. Sure, they may be able to at first…but then what happens when things break? Is one person responsible? 2? more than 2? I think instead of having a separate project, Foresight might want to completely base off of Fedora. This topic is extremely unpopular with Foresight developers though.

Whether or not Foresight adopts “boots a Fedora remix” is yet to be decided. It will be set before the Foresight Linux Council at their next meeting. Hopefully, they take into consideration the amount of manpower a separate project like this would encompass and maybe consider the benefits of adopting Fedora completely as a base for Foresight.

On a similar note, António Meireles, a lead developer for Foresight Linux, has posted what direction he would like to see for Foresight Linux 3…the future major release for Foresight. With improved underlying architecture that is more inline with Fedora…he may be looking along the same lines that my post here is. Whatever the case may be, it’s obvious that Foresight is starting to show a flurry of both interest and activity which is a benefit to it.

So where does this leave Fedora? They’ll benefit from having a lot of knowledgeable developers in Foresight and a few engineers from rPath working with a Fedora based project. Foresight has a great upstream relationship with the projects it encompasses…like Gnome and rPath. I would imagine this continued professionalism and cooperation will continue should Foresight base on Fedora.

ClarkConnect Becomes ClearOS

In other news, some of you may or may not know that ClarkConnect will become ClearOS and will be completely open source. The Clear Foundation will be sponsoring the development of ClearOS which is ClarkConnect re-branded with improvements. See the full announcement here. Also, a Forum Announcement Here. This brings a lot to the table including renewed commitments to documentation, community, and the operating system as a whole. The change is set to happen in the late part of 2009.

So what does this have to do with Yet Another Linux Blog? A few years ago, I wrote a review of ClarkConnect 3.2 for home users. It was well received and still gets many hits even today. Since I’ve used ClarkConnect since version 2.1 and continue to use it today for my home network…who better to take a look at how ClearOS will measure up?

With this in mind, I contacted the guys over at the Clear Foundation and they agreed to let me blog a bit about some of the changes and improvements that will be happening with ClearOS over the next few months. So look for more exclusive information from ClearOS in the near future. They’ve also asked if I’d be interested in helping out with some community endeavors they will have going for ClarkConnect and ClearOS users. Exciting stuff! ClarkConnect has really needed this shot in the arm for about the last 2 versions…they lost a couple of really good websites with FAQ’s on them. It’ll be great to get the community involved with this fantastic Home Server distribution.

Unity 3.7 Snapshot Preview Out

Gettinther announced that build 3.7…a developer environment snapshot intended as proof of concept…has been released. This is an unofficial release…It’s stable…but we consider it not even an alpha quality release…mainly because it is being used as a proof of concept to show the new technologies we’ve integrated. Gettinther wanted to have a bit larger test base for this release so he announced this in the forum only…but I figured that it would be nice to flash it to our Planet Unity readers.

The full announcement is in the forum here: http://forum.unity-linux.org/general-news-and-announcements/release-3-7-out

Gettinther advises, “It’s still rough around the corners so please excuse us for it. Also the shut down script in livecd mode generates errors. Those are not important and can be safely ignored.”

Please note that we have updated rpm to version 5, the package manager is now the Smart Package Manager as apt4rpm development has ceased, the livecd project has been updated quite a bit to conform to our updated toolchain as well, and detection has been pretty much rewritten to accommodate all the upgrades.

Also, remember that this is not a desktop…this is a core. Unity Linux strives to be a base for people to build from.

You may notice that TinyME influences are very pronounced in this release…this is because TinyME allows us to have a GUI with some of the least amount of requirements and dependencies. Developers needed a minimalistic GUI to test core components such as Smart and the updated Unity Control Center. Unity Linux core, on which derivative distributions (branches) will build, will be even smaller than the size of this ISO…as it will not have Xorg or a window environment.

Please report issues to the forum: http://forum.unity-linux.org/unity-linux-discussion/

Slackware and Zenwalk

I’ve been distro shopping lately. I had become complacent while working with PCLinuxOS because everything just works when using it. With nothing broken, I had nothing to fix 🙁 This is a good thing, unless you want things to break every once in a while so you can learn to fix them. I know, I’m a glutton for punishment.

After some initial toolings in Arch and Gentoo, I settled on Slackware…which was my first distribution I tried ever in 1995. It felt good to be coming back to Slackware…there is a simple elegance about it. It’s ultimately fast on just about every system I’ve put it on. I really like the unix like rc files Slackware has; to me, it’s simple to get things working. This could be because I cut my teeth on Solaris…but then again, I think it’s much easier to manage system services by making an rc file executable (chmod). Sure Red Hat style is ok with ‘service name start|restart|stop’ but I really like going into a directory, listing it out, and seeing all my services that execute on startup in green. Maybe it’s my nostalgia getting the best of me. I’m sure that’s it.

Regardless, I stuck with Slackware only a short while because I was interested in XFCE (not that Slack doesn’t have XFCE…just that I wanted to see a distro that prides itself on XFCE) and decided to give Zenwalk 6 a try (I’ve tried Wolvix already…it just didn’t click with me). I’d heard nothing but good things about this distro and it is Slackware based, which makes all the nostalgic parts of me tingle.

I installed and all I can say is WOW! It’s a fantastic implementation of XFCE regardless of distribution. The Slackware speed and rc system are there, greeting me on each startup/login. XFCE is done brilliantly there and really feels like a superb implementation. Updating is a snap with netpkg, something I haven’t had any experience with…it does the job nicely though. Overall, I’m quite satisfied with Zenwalk and will be sticking with it for a while. I’ll post back from time to time with any tips or tricks I might find as I’m stretching my legs so to speak in my new environment.