One of the things I love about software, particularly open source software, is innovation can come from anywhere. Sometimes it appears out of large tech companies such as Red Hat, IBM or Sun and other times it can come from one person writing code on a second hand computer in their college dorm. Software is really the expression of ideas and concepts, which can come from anyone. So I really enjoy seeing small open source projects try new things. Some will succeed and be adopted and some will fade away, but the amazing thing is to see people put their idea out there and present it to the world. Which is why I was thrilled when a few people directed me to Paldo and suggested it was worth a look.
Paldo, which stands for “pure adaptable Linux distribution”, is a project focused on software packages and package management. Specifically, Paldo’s developers want to provide software which remains as close to their upstream source as possible. This cuts down on patching in the distribution and, in theory, allows any required patches to easily flow back to the original projects. As developer Jurg Billete told me:
Package management is handled a bit differently than in most other distributions. Upkg distinguishes between installed and selected packages. The set of installed packages consists of all selected packages and their dependencies. If a package has not been selected explicitly and is not needed as a dependency anymore, it gets removed on upgrade. This avoids a lot of conflict potential that may occur in other distributions and makes it possible to upgrade for a long time without re-installing the distribution every time a new version gets released.
Paldo packages are also very close to upstream packages. We only use Paldo-specific patches where really necessary. We do not even use separate -dev packages, which makes it very convenient for developers.
Software packages are provided in four different repositories, intuitively (and familiarly) labelled Stable, Testing, Unstable and Experimental. Reading through the project’s website I got the impression Paldo’s developers are trying to make a distro which has similar characteristics to Debian, but with fewer architectures and an attempt to offer just one application per task. The website continues to focus on packages, giving them their own special area where a user can search for software by name and, if the package is available, learn all sorts of information. Data provided includes a package’s dependencies, what packages in turn depend on it, the current version, and other interesting tid-bits. All of this software, we’re told, is handled by Paldo’s package management system, called Upkg, which we’ll talk about later.
The project’s website is well laid out and easy to navigate. It has a simple, clean and attractive presentation that I enjoyed. For new-comers there is a Wiki, which includes helpful information about setting up and using Paldo. At the moment, the Wiki has documentation in seven languages (German, English, French, Italian, Portuguese, Spanish and Polish), making Paldo accessible to a wide range of people. There’s also a forum on the website, giving users a place to interact and receive assistance.
I downloaded the latest Stable offering from Paldo, version 1.21, and burned it to a CD. The disc kicked off a GRUB boot menu with several different language/keyboard combinations to choose from. Once the user makes a selection, Paldo boots into a Gnome desktop with a blue and grey theme. The menu bar is placed at the top of the screen and, at a first glance, nothing really jumps out at the user. Poking around a little, we find a fairly common selection of programs. There’s a text editor, archive manager, OpenOffice, the GIMP, a video player, an audio player, a webcam app and disc burner. There’s also a VNC client, Evolution for e-mail, Inkscape, the Epiphany web browser and GParted for disk management. A little experimentation shows that Paldo comes equipped with codecs to play mp3 files and most popular video files, however pointing my web browser to YouTube showed Flash wasn’t installed. Also available is the GNU Compiler Collection, giving developers a good platform to start from. One disappointment I found while using the live CD was that my keyboard layout wasn’t recognized. Selecting the proper layout, either from the GRUB menu or from the Gnome configuration tool had no effect and I regularly found what I was trying to type wasn’t what was appearing on my screen.
The installer appears to be unique to Paldo and isn’t here to hold your hand. Like most things in Paldo, a little previous experience with Linux is expected. The user is asked to enter their regional information, including their preferred language, keyboard layout and time zone. I noticed, with some disappointment, my time zone isn’t an available option. The next screen allows the user to select which partitions will be assigned to which mount points. Possible options are the root directory, /home, /boot and swap. The installer doesn’t handle partitions itself, but does provide a button to launch GParted. So far as I can tell, there isn’t any option to assign other mount points besides the four mentioned above. The installer gives the option to install GRUB and then requests a new password for the system’s root account. The last step is to create a non-root account. The installer quickly copies Paldo’s files to the hard drive and the process is complete. Rebooting the machine takes the user directly to a Gnome login screen.
For my experiment with Paldo I used a generic desktop system (2.5GHz CPU, 2GB of RAM and nVidia graphics card) and my HP laptop (dual-core 2GHz CPU, 3GB of RAM and Intel video card). Once logged in, I discovered my keyboard layout was handled properly. The system was quick to respond and generally performed well, at least on my laptop. When running Paldo on the desktop system, my screen looked like someone had broken a stain-glass window and scattered the tiny pieces across my monitor. I was able to work from the virtual terminals without any problem, but the desktop was completely unusable. On the laptop, things went much smoother, with video, sound and my network card all working perfectly. My Novatel mobile card worked without any configuration on my part and the touchpad was handled well. My webcam also worked without any tweaking. Unfortunately my Intel wireless network card wasn’t picked up, but otherwise Paldo handled the HP hardware well.
The distribution’s security is pretty good, with the exception that both the live CD and the locally installed version run a secure shell service, giving users (including root) remote access. This concerns me as the root password for the live CD is publicly available. The user is automatically logged in to the live CD environment as a non-root user and I was happy to see the installer insist on setting passwords for the administrator and creating a regular user account. Once installed, the root directory is locked down, preventing regular users from accessing the administrator’s files.
Getting back to Upkg, it’s an interesting tool which is based on Mono and appears to be inspired by Debian’s Aptitude. I was unable to find a graphical package manager and so took to the command line to try out Upkg. The Paldo website has a brief tutorial on using their package manager, though it left me with some questions. For example, what’s the difference between upkg-add and upkg-install? According to the man pages, upkg-install “adds the specified package to the package selection”; upkg-add doesn’t have a man page. I soon found this to be a moot point because neither command would do anything useful on my system. Running upkg-add, upkg-install or upkg-remove resulted in a long string of Mono error messages, concluding with “Could not generate script!” I checked the project’s forum and found others had had this same issue and most had corrected it by clearing Upkg’s cache. I followed these instructions, but was still unable to add or remove packages from my machine. I was able to search for software using upkg-search (which doesn’t have a man page either), though the results were rarely useful. For example, if I go to Paldo’s website and search for “chess”, I’m given a package called pychess. Running a search for “chess” using upkg-search returns gdm, ghostscript and gnome-themes, because each of these packages contains a file with the name “chess”. Sadly, pychess, on the other hand, is not returned as a valid result.
After a few days of using, or trying to use, Paldo, I was beginning to feel like my experiment was cursed. The first time I downloaded the Paldo live CD image, the file I received was corrupted (its checksum didn’t match the one on the project’s download page) and I had to download a second time. Likewise, the first CD I burned turned out to be a coaster. Paldo failed to handle my desktop’s video card and my laptop’s wireless hardware. My keyboard layout wasn’t handled properly by the live CD, my time zone wasn’t supported by the installer and I was unable to get Upkg to install, remove or update any software. Some of these issues are just poor luck and no fault of the project while others are bugs and will hopefully be fixed. The developers have some interesting ideas, I especially like their vision of clean package management, regular updates and providing one application for each task. It sounds simple and uncluttered. The fact my Novatel mobile modem worked out-of-the-box is impressive as it’s a feat most other distributions don’t accomplish. Judging from the forum posts and review requests I received, Paldo works really well for some people. I’m sorry to say I’m not one of them.
I have a feeling that yet another Linux distribution is not exactly what most people have in mind when thinking about innovation.
That said, good of luck for the Paldo team.
Implementation is innovation.
What you’re referring to is new paradigms. They don’t come along too often.
There you go again…
Anything that gets package management closer to the source is welcomed.
The main reason I would never use Linux full time is because I expect to be able to upgrade to the latest Firefox the day it’s released—not six months later along with a distro upgrade. Downloading the bin from Mozilla is not good enough. I shouldn’t have to install software in my home directory, compile it myself, or work outside the package manager (so that I’m tied to manually updating) just to use a damn web browser.
You probably need to use Arch Linux, then. I haven’t used it myself – don’t mind waiting a couple of weeks for an update of an application – but based on what I heard, it does fulfill your criteria.
I’m an arch user, but it does not hardly fulfill this criterion. They are indeed quite fast for a Linux distro in terms of up-to-date (and functional) packages, but you can’t say that packages are there the day a new version of software X is released.
The problem is that Linux, unlike Windows, is a very heterogeneous environment — there’s not one “the Linux”, but many different ones, and just because a binary works on distro X, it does nowhere near run on distro Y.
Windows has two flavors — 32 and 64 bit, and that’s it. So, in providing two binaries, you’re done for the whole OS. For Linux worst-case, you need as much packages as there are distros out there. This is an unmanageable task.
As I understand it, if you choose to manually install the binary from Mozilla you can also set it to automatically check for future updates.
It sounds like your main concern boils down to the time it takes for the distros you’ve tried to provide updates. Different distros take different amounts of time.
I don’t believe Mac / Windows have a centralised system for updating applications from 3rd party vendors. If you want the latest and greatest then you’re free to install them yourself.
On the Mac it’s not too bad. Sparkle is very, very common amongst cocoa apps, and Firefox provides its own updates in a timely manner. The update experience on third party Mac apps is usually so high that it downplays the benefits of using a central repository system.
I’ve _never_ had a good experience with Apt.
apt is the best part of using Ubuntu/Debian.
Wow! Really? I am not a BIG linux user but… apt is one of the things that makes Ubuntu, Debian and other distro’s usable. And the cutting edge repositories are usually chock full of pretty stable software.
Many would agree with this.
Still, I’d say it’s a cultural thing. Nothing is exactly preventing mozilla from making a .deb instead of a tarball. The deb would violate debian packaging guidelines, but it would work without the user ever knowing about this.
Chrome for Linux does this exactly right, proving that packaging system is not the problem here.
What you’re describing is not a Linux problem rather it’s a distro problem. Sounds like you need a rolling release distribution. For the record, *buntu’s are not rolling releases. They are static until a new release comes out. Personally, I prefer Sabayon because it has the best of all possible worlds: binary package management (via Entropy), sources package management (via portage), multimedia and plug-ins included out of the box, Cutting edge KDE or Gnome desktops (others available via package manager). Plus lots more. And, it’s a rolling release. Other fantastic rolling distributions are Arch, Gentoo proper, Sidux, Mandriva with Cooker enabled, Fedora with Rawhide enabled, OpenSUSE with Factory enabled. Good luck!
Then you’re a freaking moron. No one is going to hold your hand and do things for you like you are some kind of damned toddler.
Grow up and get a freaking life, and in the process learn how to things for yourself like zipping your pants instead of having mommy do it for you.
If you don’t mind compiling packages from source, give Source Mage GNU/Linux a try. It’s kind of like Linux From Scratch with an advanced package manager that resolves dependencies automatically. The install disc (which is a bit like the minimal Gentoo install disc) installs just a very basic GNU/Linux system without Xorg, and then you can update this base system and use the package manager to install what packages you want.
The package manager was written in BASH and it has an optional ncurses frontend that displays menus for configuring the package manager and for installing/removing/upgrading packages. The package manager can also be used without the frontend, by executing the package manager commands straight from the BASH command prompt.
Source Mage GNU/Linux has a policy to avoid patching upstream software, as long as it compiles and doesn’t introduce conflicts with other packages. This policy applies also to package configuration — you need to make do with the config files that the original developers have decided to include in their packages.
The package manager installs the necessary dependencies automatically, and it prompts for every optional dependency, so you can choose whether to install it or not. When you upgrade a package, the package manager remembers what optional dependencies you chose, so you don’t have to answer the same questions on every upgrade.
Source Mage GNU/Linux has two branches to choose from — “testing”, which gets “rolling release” updates and “stable”, which gets updates once a month. Because Source Mage GNU/Linux doesn’t offer binary packages (just scripts that download, compile and install packages), it is easier for the package maintainers to keep the package-scripts up-to-date.
Source Mage GNU/Linux is an excellent distro for advanced users, but it’s not for newbies. If you’ve already tried Linux From Scratch but you got tired of maintaining a GNU/Linux system without a package management system, then Source Mage GNU/Linux is just what the doctor ordered. But if you have never tried Linux From Scratch, then Source Mage GNU/Linux is not the pony you’ve always wanted.
Because that’s what I understood from reading this article. Aptitude does *everything* that this upkg package manager claims to be able to do – and does a better job while we’re at it – but somehow remains unknown to many users of Debian and Debian-based distros. It still amazes me that some people will deal with apt-get occasional hiccups instead of using the superior dependency solving abilities of aptitude.
Having said that, I don’t want to belittle the work of Paldo’s developers and wish them the best of luck.
I don’t think I’ve ever had an issue using apt-get :p
I’ve had the opposite experience. Apt-get usually works fine, but aptitude has done some serious screwing up. One memorable situation is when I wanted to install pidgin in Ubuntu. I used aptitude, and it tried to remove basically all my development packages (gcc, binutils, etc) as if they’d been marked for automatic removal. However, when manually checking the package information via apt that wasn’t the case. I never did figure out why it tried to do that. The other times it screws up is when it’s trying to compensate for dependencies, I’ve had it propose some very strange resolutions. And I love the “Accept this solution?” prompt when pressing no just takes you in an infinite loop around the same solution again and again. Hello, bug…
I’ll stick to apt-get, thanks.
In general, in my experience, the “weird” behaviors of aptitude can be avoided if you always run it with -R which tells it to not include Recommends by default, which is what apt-get has always done.
apt-get is mostly unmaintained and contains known, serious dependency resolution issues. It is, if not fundamentally broken, definitely relying on a design that will not last.
aptitude is designed to not have apt-get’s deficiencies and largely succeeds. I maintain that they would have been better served by making it command-line-argument compatible and then making it provide an apt-get link, then conflicting with apt-get once it has been its remaining issues worked out. Drop in you-never-noticed-we-replaced-it-did-you? compatibility is something that ought to be embraced more often.
Hmm. Now there’s an idea for a mini project: Write an apt-get to aptitude argument rewriter, then install it at /usr/bin/apt-get and see how it works. And, where aptitude does not yet support the functionality, you could internally call apt-get.real.
Tried that, it never helped. Telling it to not use recommends didn’t stop it from wanting to remove my entire development environment, and the other resolution problems where when removing packages, not when installing them.
It is sort of like if you took slackware, lowered the bar for what is included (pat will not use stuff that doesn’t work, these guys will patch it, even though they say their point of differentiation is that they are “pure”), and decided instead of going for stability, they would go for bleeding edge.
Interesting idea, but at the end of the day, it is Yet Another Linux Distribution that isn’t really going to bring anything to the table we haven’t seen before.
This sounds like something a SuSE or Fedora refuge might say since it describes a problem solved long ago in Debian land. The package manager contributes something to this ability, but as Ubuntu has shown a lot of the effort is careful, thoughtful packaging.
I have to ask: Why invent yet another package manager? Package formats abound and every existing one probably does What You Want, and certainly some existing one does what you need. Dependency resolvers are not trivial to write correctly and, again, many good ones exist. Why would you poorly clone something you can re-use while claiming to have a goal not related to building the clone? Why reinvent this wheel *again*?
We don’t need yet another distribution with yet another incompatible package format, archive scheme, package manager, etc.. What innovators should try to do is build better UIs, better process, and (generally), *make policy decisions* and carry them out to logical conclusions. Experimentation with system policy is extremely valuable and often difficult in established distributions either because the distributions are too focused on neutrality or too committed to policies they already have, implicit or explicit.
This is not NixOS, where a new package system is the easiest way to implement some radically different architectural and policy ideas. There is no need here to re-write what others have re-written before.
I encourage everyone to scratch his own itch and do whatever he likes, including building new distributions for any reason. However, I cannot support this waste of effort!
While I am not the type that will bash any new distro, I am wondering what is innovative about this distro.
The main thing setting it apart from other distros is the package manager. But the package manager is not innovative, just different. If you want to see an innovative package manager, look at GoboLinux or NixOS.
Any package manager that conforms to the totally illogical FHS, doesn’t support multiple versions, uses a database rather than the file system, and can break stuff with updates can not at all be called innovative.
Please explain how the FHS is illogical? Read something on why/how the FHS works. And why you’d really want multiple versions of the same program is beyond me, unless you are a developer, in which case you won’t be using the package manager anyhow.
Last I checked, dpkg uses both a database system and files, as does rpm I believe (or they just use db, can’t recall, been awhile since I had to restore one (thank the gods, it finally improved where the rpm db wouldn’t corrupt itself and hose your system))
And for the record, ANY software update can break things, whether it’s dependencies in the package manager, or a new version suddenly has a broken implementation of a feature. These are called bugs, report them.
I rarely comment on things, but bashing the FHS is one of the things that really irritates me, because the only people who ever complain about it are people who are too lazy to educate themselves on WHY the file system is that way. Frankly, it’s one of my favorite things about *nix. Windows’ file system layout is garbage, you never know where ANYTHING is.
Wow, someone else appreciates the logic of fhs, not just me. Seriously, I was starting to feel old and I’m not even very old to begin with. The fhs makes perfect sense to me, and I love that I can always find something I’m looking for quickly when I need to.
I understand the FHS quite well, and I agree it is logical. The layout however doesn’t work well with several versions of the same library. It’s not impossible, but you have to work around the inherent limitations in the FHS. That said the FHS is quite flexible so it’s not unusable. And if you don’t understand why certain binaries going into /usr/bin , read the FHS documentation.
That said, I really don’t like the FHS that much. A GNUstep-like layout is more to my liking, but it really depends on your needs (surprise surprise :p ).
Actually, different library versions are no problem. That what libxxx.so, libxxx.so.1, libxxx.so.2.x.x, etc are for or is that what you meant by having to work around the fhs? It’s multiple applications at different versions that can be a real pain especially if it’s a badly-coded piece of software that is hard-coded to look for its shared data in one place, and that data is different across versions. That’s the real bitch. That being said, if you have an app like that a GNUStep-like layout wouldn’t save you from that headache either.
Actually it would. Well, depending on the exact layout used. There are several layouts to choose. And one appfolder can easily contain several versions of the application and for several architectures (think fat binary). Launching the right version of the binary inside the appfolder is however a wee-bit tricky.
Of course one could also claim that the headache was just moved to a different place; let’s call it stomachache or something like that.
🙂
This is not a new distro. 1.21 stands for 21 previous releases. Each release cycle is three months.
I’ve tried Paldo recently.
Upkg is interesting in that it parses XML spec files and generates bash install scripts from it.
The problem is that its written in Mono and therefore extremely slow even on my Core i7. Upkg also lacks many features found in other package management systems, such as the ability to restrict certain packages from upgrading.
The stuff of nightmares.
No kidding! They should try to sneak in m4 and makefiles in there as well…
Give me XML over M4 any day. Yuck, M4 is why I never use autoconf for my own projects, a clunkier syntax I can’t think of except for maybe troff.
I won’t bitch on their package manager Upkg being a Mono application (which is, among other things, quite a heavy dependency IMHO), but…
…go to their About page:
http://www.paldo.org/index-section-about.html
The Upkg link goes here:
http://www.upkg.org/
Now, take a guess: they stop paying for the domain etc. etc.
And upkg.org is this way for at least 1 year!
Back in 2008, the upkg.org site was redirected to Paldo’s main page:
http://web.archive.org/web/20080114065525/www.upkg.org/
The last time Upkg.org was a site on its own was somewhere in 2007:
http://web.archive.org/web/20071122023032/www.upkg.org/index-sectio…
Duh.
x
Edited 2010-03-11 13:27 UTC
I’v used Paldo very often, in various different versions from the past and more recently with both stable and testing versions.
upkg – The reason it did not work with the reviewer is because he forgot to write “sudo” before upkg-install. It’s unforgivable that someone who writes a review fails to use sudo to install a Linux software.
graphic desktop – never ever saw in the foruns anyone with that kind of problem, with any kind of video hardware. I use an nvidea card too in my desktop. Always worked perfectly for me, with Paldo.
Keyboard – I used both the english and portuguese (ç á à ), and never had any problem with both. In the foruns only saw one problem, regarding a portuguese configuration, and only in very specific cases.
Paldo CD image – I never head a corrupted iso or md5 problem. This looks like problems with the reviewer net connection.
time zone – The list of Time Zones in Paldo includes all places in the world, or at least all those included in any other distro. The reviewer should have said what’s his location and the keyboard he uses.
“The fact my Novatel mobile modem worked out-of-the-box is impressive” – this is not impressive at all, anymore. I’v got one too. Most people know that all main distros today support this kind of equipment.
Paldo failed to handle … my laptop’s wireless hardware – I never saw anybody in the forums presenting any problem with wireless hardware. Paldo is using updated versions of NetworkManager, witch support that equipment.
The forums at Paldo have many references to its superior performance, stability, always very updated, and good support for old hardware.
This is a poor review, looks biased, failed to provide details that could lead the developers to check the related problems, and seems to intend to demotivate users to try the distro by themselves.
Paldo owners are two very senior developers, and have been since a few years involved with the creation of the new Linux programming language called “Vala”. I agree that they may have been too much busy to further develop Paldo. It may change in the future.
In the hopes of clearing up a few points…
Upkg – I did run the various upkg commands with admin rights, I’m stunned some days, but not so stunned as to try to install packages as a regular user.
Graphic desktop – This one struck me as odd too. Only Paldo and one other distro have ever had this problem with my video card.
CD image – It probably was my connection’s fault, or my download manager. As I pointed out in the review, some of the problems were just bad luck.
Time zone – I’m in North America. I don’t want to go into more details on that, but the installer is missing a few locations.
Modem – I try out about a distro a week and Paldo is one of about five distros that has automatically handled my modem without any problems. Others can get it working with some tweaking or manual setup, but Paldo handled it perfectly and I felt it deserved some credit.
Wireless – Getting my wireless card detected is about a 50/50 thing. Some distros manage it, others don’t seem to have the driver.
I understand you not liking the review and that’s fair. For what it’s worth, I did e-mail the developers with my observations (in more detail than contained in the review) in case they wanted to explore the issues with me. I’m sorry if seems like I’m trying to discourage people from trying Paldo, that wasn’t my intent. This was a sharing of my experience, not an attempt to knock the distribution. As I said, it seems to work fine for quite a few people.
Ok. I’m happy you did contact or emailed the developers regarding the issues you perceived. I further investigated who you are, after my comment, and could not expect the opposite, from you. If they failed to answer, seems to be their problem. You could also have used the forums, and I’m sure Juerg would have answered you. You know sometimes people does not receive all mails due to spam filters. Anyway you missed to mention that fact at your review, and that’s why I mentioned it. Still I find strange your upkg install problem, but … I’ll concede you the benefit of the doubt.
It’s not bad but oy, upkg is a mess. When it works, it works great. When it doesn’t, it borks with odd errors, the man pages are incomplete and the documentation is poor.
Paldo is a great idea poorly executed.
I really like to read reviews about both hardware and software.
Because I use to read many, and some of them are quite extensive, I got the habit to start my readings from the end, because it’s the place where the conclusions, final thoughts, or summary are presented. Based on it, I may read all the article, a part of it, or anything else. I guess many people do the same.
Regarding the present review, due the above mentioned, it’s my opinion that few users will feel compelled to explore Paldo, loosing the opportunity to try a less known distribution that may well feet their needs.
So, before this article steps down from the front page, I decided to come back to leave a link to an older review of Paldo, with the only intent being the hope that it may be useful to someone.
It’s always nice to have choice and/or to get a second opinion, about everything.
http://www.linux.com/archive/articles/122676
In this review, fortunately, Susan Linton’s hardware was well supported, and so, not surprisingly, the “bottom line” will probably lead the reader to think that Paldo is worth a try.
Yes, paldo has been around for years. I’ve used it for more than a year to run my daily box. It’s stable, fast and rolling-release current.
UPKG works fine as a command line updater, although it could use more wiki resources to help one get used to it. paldo does require a little more than newbie linux skills and some command line use to get the most out of it.
I would switch from paldo to something else if it didn’t work consistently well. It’s just an OS, after all.
Well, I’m a paldo user since 2008, which means 2 years of using this distribution.
Paldo is a simple distribution, but certainly it needs work. Our documentation is not the greatest but if you ask on IRC or forums you’ll probably get what you need.
Paldo uses as their package manager their own called Upkg, this is a hybrid package which means if there is no binary for that package it will compile it from source, but some people can make a mistake with gentoo. This is not gentoo, the proposition is not to make it compile with different CFLAGS or USE Flags, the idea is to not overbook the server and make disnecessary compilation.
Everything on stable branch has a binary on the server, not everything on testing has binary on the repos and almost all the packages from unstable have to be build from source.
Another thing is that on this review the author claimed problems on his network, upkg is not like apt-get or yum or zypper, it does not have a file that describe everything on the repo and then the package manager proceeds with this informations. Upkg download each xml spec for each file that is necessary to look and then writes a bash script to do the job (which does a great job) so if during the process of installing something the network fails the package manager will fail as it will not be able to check the specs it needs.
Now this is a small distro, also gnome-focused, and the developers are also developers of vala language so you do get the latest of vala on paldo.
This system uses the packages the most similar to the release as it can so unless it is needed you will see that a very small quantity of patching is done (not as small as Slackware).
The installer does not offer everything it could, but as we all should understand this is not a distro to any levels right now, else it would have a packagekit backend and other things.
Now also concerning the isos. There is not a fixed release as this review claims it is the 1.21, the best way to say is that this is stable 1.21+. Paldo uses branches stable testing unstable and experimental, similar to debian’s. But the isos are regenerated so fi last week it was said that this is the 1.21 iso then today, one week later the release, you will see that the iso is probably not the same it is already upgraded with the latest updates of the branch it corresponds.
Another thing that was not talked in here. Upkg allows a very easy way to create your custom installable livecd. The official iso is actually generated after bootstrapping the package paldo-livecd on the repository. But as I said before there isn’t enough documentation and so people don’t know that yet. With this feature it is easy to redistribute the distro in a custom way. Make your own package for plymouth and your own kernel and then create a livecd and use it anywhere.
Paldo is a community effort it needs lots of upgrades but if we can have a better wiki maybe people won’t mind some little quirk. Because as far as I know a used-widely operating system is not bug-free or is Ubuntu, openSUSE, Fedora and Mandriva perfect. Or better the most used OS on the world is the most bugged one (Windoze
) .
PS.: The Paldo64 is not multilib so 64 edition has not skype and wine.