News

Here we go again.. So back in 2015 I spent a lot of time on a MUSL-libc port of Unity-Linux. This ended up being a lot of work. I basicaly started from scratch and got to the point of enlightenment working and then gave up. Not really gave up just ran out of a precious resource called time and then when I did get time to go back to it I had burned myself out. Figuring out how to package multiple python versions is hard enough for the big guys like Fedora, that and everything else was just daunting.

So here we are in 2017.. I wanted to get back involved in a Linux community. So I spent some time spying on Korora. Korora is awesome don't get me wrong, but I wondered how our Mandrake family was doing. I started out on Mandrake early on and went through all the ups and downs, then went to help out at PCLinuxOS, then to Unity and on and on I went into Fedora land. When Mageia forked from Mandriva I was a huge supporter and wanted to help out where I could but because of Unity and life in general I focused on other endeavors. Now that I had the time and not another project to really work on, I took a good look at Mageia and found them in an intersting place.

Their in this kinda weird mix of Fedora and Mandrake time. Recently they have had dnf ported and a lot of the Fedora pacaking tools, but then they are also still running drakxtools and their control center, which always went over well with new users. Going a bit back to my roots I felt at home, yet using dnf and other tools I felt excited. So I decided to would port mklivecd (where Unity-Linux left it in 2012) to magiea and offer a tool that I used and loved at PCLinuxOS (now mylivecd there) and I know others will as well.

In forking the tool though I started to embrace a lot of the free development and operation tools that are now available. GitHub (always used it) Travis-CI (newer and fun) and I found out copr had Mageia build containers so now I'm using copr as well for my repos. I actually have mklivecd testing itself by building ISOs. There's still some work to do, but my idea, though still kinda vague, is to use Mageia and bridge the things I loved about all the projects I have worked on in the past 10 years or so. We'll see how far I get, but I have to say automation has sure made my life a lot easier. So there's your long awaited update.. if you're still watching.

Looks like it's an early Christmas for Unity Linux. I decided to try Digital Ocean out for hosting and was impressed with their interface and ease of use.. Along with their use of KVM. I created a simple CentOS machine and copied over Unity-Linux.org (this site) to it and all worked wonderfully. So in talking with Son_Goku on chat it was mentioned that they are pretty cool with OpenSource projects like ours. So I decided to take a chance, email them about our little project, and ask for help with hosting. We were on the $5 a month plan, which is great for hosting a normal site and still pretty impressive however, I wanted to do some package building etc.. much to my surprise they actually came back with giving us a better machine and at least 6 months of sponsorship! How awesome! So Thank you Digital Ocean and Merry Christmas.

Today is the last day of November. The Holiday Season kicks off a busy time for me and my family as I am sure it does for everyone. For the last week I have spent time with friends and family and maybe a few hours messing with Unity Linux. That doesn’t mean however I that there is no big news to share.

Last week OnlyHuman and I were able to get Enlightenment 19 up and running on Unity Linux. This marks the first desktop environment to run on Unity Linux as an official Linux distribution in years. It also marks a huge milestone. At this point in development Unity Linux as what it is today is moving from a proof of concept, which might work. To coming back as an actual Linux Distribution.

The Enlightenment branch will be the first Desktop Branch for Unity Linux. With LXQt most likely to follow. However in that time period between now and official branch releases a lot has to change and be redone.
When Unity Linux (code name Phoenix) is released it will be released as a CLI based Distribution. CLI meaning command line interface.. no graphical interface. On the CLI based livecd will be an easy way to install, a method to install packages needed for Xorg (maybe even Wayland), and tools needed to remaster once the install is to ones liking.

Not long after Phoenix is released. Using the same method and tools that are on Unity Phoenix two branches will be made and released. I am not sure what the official name of the Enlightenment 19 branch will be but it will be released and the LXQt branch which will also be released soon after will revive the Synergy Linux Distribution.

So that is where we are going. If you don’t want to get to technical in how we are getting there you can stop reading now. However, there are quite a few steps that need to be taken in my mind to get us from where we are now, to something release worthy.

Out of the gate comes a very big question. Why RPM5? I have been asked this a lot and I had various answers. The RPM5 community is small and though at times some might argue can be hard to work with for a while they seemed to have the most activity and a great feature set for developers. For example automatic retrieval of source packages when building spec files with rpmbuild. There were various advantages to using RPM5 in 2010 when Unity Linux first started and it was my attempt to hang on to it. However, I have been following the few distributions that have been using RPM5 for quite some time namely PLD and Open Mandriva. There have been talks about both distributions moving from RPM5 and the reason for these talks has been the number of patches that have been needed to fix issues in RPM5. The lead RPM5 developer will argue that some of these patches have not been submitted upstream however on the mailing lists you can find a few have, and have not been included. For various reasons, albeit maybe even good reasons, needless to say they address issues Unity Linux would have to address at some point as well. OpenMandriva has 300+ patches. Granted many are for urpmi computability and various distro specific tweaks, but many are not. PLD is closer to us then OpenMandriva and they maintain over 100 patches for RPM5. Compare that to Fedora who for RPM 4 or rather rpm.org maintains 20, some of which are Fedora specific. Mageia has 7 non up streamed, Mageia specific patches. A goal I have for Unity Linux is easy maintainability, having a core package that requires hundreds of patches does not fall into that goal. There’s certain development features one such I mentioned above that I can script around, however multiple features and fixes like memory leaks, I cannot script around with RPM5.
Going further into technical details, thanks to some help from Neal (uses multiple names on IRC) the crew over at rpm.org have been very much receptive to MUSL based changes and patches going into rpm.org (RPM4). That can be seen in git with version 4.14 of RPM having support for MUSL. Also major work by Neal and MUSL members on IRC has gone into getting libsolv to work. Libsolv is a core lib needed for DNF. Using RPM4, DNF, and company gives Unity Linux a relatable and much easier upgrade chain and a community at large to lean on despite having a non GNU Toolchain.

So a massive rebuild is underway. RPM4 has already been added to the repos and a few test packages have been built using it. More tweaks need to be done to scripts and spec files will need to be updated. I have allowed the macros to also be stricter in a sense as well.

Going even further multi arch support is being worked on as well with the major change, in hopes we will also be releasing a 32 bit version as well. I struggled with even doing a 32bit version, however my EeePCs keep staring me down and for some reason I have a soft spot in my heart for them. So if you made it this far in your reading.. Long story short there’s a lot of work to do. Things are getting hammered out. If you’re involved with us this early in the game thank you for your patience. I’ll save the init information for another post, still need to do some more research on nosh. Hope you all have a wonderful Holiday!

Its been a fairly productive month of October. We finally have Xorg working with twm. You can download a mini iso and test it simply by logging in as root and running setup-xorg-base. You will have a black desktop and if you left click on it a menu will appear with the option to manipulate the windows, exit back to the terminal, or run the only application installed called mrxvt. Mrxvt is a tabbed terminal for X so nothing special there.

There has been a new folder in git created called graphical. It's a little misleading as none of the programs are really graphical, but they are being kept separate from the base packages as they are needed to run a graphical environment, but not necessarily needed to run the base command line Unity.

In actuality a majority of the core or base of Unity Linux has been packaged. Unity proper will be a command line based release. It will not include Xorg or Window environment by default. What it will include will be easy setup tools and scripts to get from command line to a graphical (Xorg, Wayland even frame buffer) remaster or even branch.

A branch is a Unity community member or members that create not just a remaster, but using Unity as a base, a seperate version of Unity contributing back packages into a contributions repository for review.

So what am I still doing packaging and not bug fixing? When Unity CLI gets released there will be two graphical releases that will be announced. One will be the reintroduction of Synergy Linux as a LxQT based distribution. The other will be a graphical version based on Enlightenment that I will be helping with.

Unity Linux now has a mirror site set up as well at unitylinux.com, we are also hosting out test isos, and rpms on there as well.It's synced more then once dailing as some of or other mirrors are only synced once a day.

Hello all,
Just wanted to give you an update of the current status of things.

As you may already know we have a working base. We are using MUSL-Libc, YUM, RPM5, and OpenRC. These things separate us from the fold. For the most part they are all working together. I get a memory leak message from RPM5 from time to time and there's various other bugs, but for the most part it works.

Last week we were releasing Test ISOs. I was able to create a LiveCD init system based off my previous work and was able to get things to boot and run. I even did some work on porting over some CLI based setup scripts from Alpine Linux and got things to install after some configuration tweaks. My first Test ISOs had EVERY package on them. So if someone wanted to build, or fix something they saw wrong they could. I then released a smaller 90M release with just some core packages.

I then went on to work on getting some mirrors and setting up a mirmon page and trying to do such in the cleanest way possible for OpenMandriva. I am not sure how well it turned out, but they now have their own folder on iBiblio and we have ours.

The last few days I have been working on Xorg & Wayland/Weston packages. Wayland and Weston have come first for the simple fact they are easier to pull in and can be compiled to run with minimal (or no) Xorg dependencies. I wanted to play with Wayland and see if I could get some type of graphical interface up and running. Rather large strides have gone into getting the Big Desktop Environments to work with Wayland. Gnome 3.18 is said to work really well and KDE/Plasma 5.4 is said to have some support (though limited to one platform?) with Wayland. There's other environments that are embracing Wayland, Hawaii Desktop is an interesting one, Moonlight, and the most interesting Enlightenment 20. So my investment in getting familiar with Wayland and maybe getting something to work, I don't feel will be wasted.

In the next few days I am going to move further into improving our makelive script (mklivecd esq script) and build some more all package ISOs, so I can play with the changes the new packages have brought and see if I can get anything graphical going. If I do get something graphical going, as minmal as it might be, I will most likely create a lighter ISO to play with.

Someone reminded me of this so I decided to post it. If you're one of the many few (haha) who are trying out the ISO I would like to point out this is a developer release. If you're not a developer by all means feel free to download and try it.. I'm not a RTFM type of guy, but I just want to save you the frustration up front of everything being done for you.. like Network Management.

For now I don't have a Network Manager included. Something that will detect your network interface bring it up and grab an IP.. you have to be the Network Manager.. Yes you.. go look in the mirror and say "I am the network manager". If all went well on boot and your network card was found to have a driver.. it should be loaded so now do this Mr. (or Mrs.) Network Manager in the command line:

ifconfig eth0 up

now press enter and do a:

ifconfig

you should see information now for eth0 (yay!). However there's no IP.. Sad.. let's get one by doing

udhcpc eth0

and now eth0 should be assigned whatever IP your network gave it. At this point you can do any number of things with wget.. and maybe install the one package that isn't already installed.. and that's really it for now, but hey it works (or should)! If you have any questions check out the IRC link. Thanks

Things are progressing (I'm a broken record with this statment), I have changed some init and boot settings to reflect our true boot opions. So any any ISO releases before 44 (I think) will be more complex in these areas then they need to be. There's now a very short string (4) of currently used boot options when you press "TAB" on the boot menu.

The one to really pay attention to is ramdisk_size=. This defines the size of the ramdisk for the livecd/usb session. Some machines have quite a bit of ram so you can make your ram disk quite large and still have a decent amount left over for actual ram use and not disk use. I think 512M is a happy middle ground. If you're like me though and still have a few machines laying around with 512M or less you may want to bring that ram disk down to 256000 (or loosely 256M). So basically this option allows you to tweak the ramdisk size as a measn to get the best performance for a particular system running live.