Google frequently tests out new ideas, and quite a few of their ideas have long Beta test cycles. Common wisdom is that these products either aren't ready for market or Google is trying to get others to test them. There is definitely some truth in both of those statements, but these comments need to be explored in more detail.
As a case in point, I believe it was approximately 2006 when Google acquired the assets for Android, an operating system with a Linux kernel and a Java application stack, designed to be used with Smart phones. Google had an idea to run with this to make their products and services available to gadget users everywhere. Google modified both the Linux kernel and the Java application stack to create their version of Android, and got quite a few people in both areas all up in arms.
In the case of the Linux kernel, I am pretty sure that several of their changes have, in fact, worked their way back into the Linux kernel. They are too useful and important for that not to have happened. But Oracle had a number of concerns about the way that the Java code (and the name and license that go with it) are being used, and they filed a legal suit. Today, I saw a note that suggests that the case may go on for years unless both Google and Oracle change the way in which they are approaching the suit. At the present time, that delay would seem to favor Google, but Sun did have success in a previous legal suit against Microsoft, and Microsoft simply created C# instead. Could Google have a similar strategy, especially if this drags on? Perhaps by the time anything happens, Google will change the plumbing anyway.
But what about the Chromebook? Could Google have a similar strategy - a long term strategy, to assess the market for Cloud-based netbook (and other form factors) operating system? Could it be that the Cr-48 really WAS just a PROTOTYPE and a pilot project? Could it be that the Acer and Samsung models, which are only planned to be sold over the Internet, are merely test market vehicles to gain additional real world experience, and to further validate the ideas and marketing before creating an all-out, energetic marketing plan?
Some have speculated exactly what I just mentioned. It took from 2006 until 2009 before Google, Verizon Wireless, and Motorola came out with the Droid in a big marketing splash. It took another year for more Android products to come out. The Android is still developing itself in the tablet form factor, but is well established in the smart phone form factor. Could it be that this next year will be a trial period to see what works with the Cloud-based ChromeOS Chromebook?
I have reason to believe that this is the case. I believe that the younger generation, who carry around all kinds of devices, could be sold on a completely network-based system. They use them now in their smart phones and tablets.
Google has shown that they do not need to be the first ones out there in the market with a particular idea to do it right. Jolicloud and Joli OS have certainly beaten Google ChromeOS out, but the Joli OS is not an integrated hardware and software product; the Chromebook on ChromeOS is. The iPhone on iOS is too.
Do you think that Google is on the right track to experiment here? Do you think that Oracle is troubled, perhaps because they have been trying, on and off, for the past decade to create a network computer? Could Oracle and Google strike a deal at some point and finally make a network computer a reality?
What are your thoughts on any of these topics and questions? I would be interested in seeing another dialog on this one.
Wednesday, June 01, 2011
Tuesday, May 31, 2011
antiX derivative still "Looking Good!"
Anyone who follows and reads my journal, blogs, for forum posts anywhere on the Internet, including this blog, knows that I have been a big Debian software enthusiast for many years, and that in recent years, I have developed a particular enthusiasm and attachment to two of the MEPIS projects, SimplyMEPIS (for an easy, stable desktop system) and antiX (for a light, extremely flexible, customizable, and modifiable desktop or server system).
As proof of how flexible MEPIS has been, antiX has been in existence over five years now and it has three derivatives (or "flavors") of its own, the original, "full" version, a cut down "base" version, which includes a graphical user environment and customization tools, but withholds the applications so that you can select the ones you prefer, and then there is an even more minimal approach called antiX "core", which provides the installation and configuration tools, but no graphical user environment or applications, so you completely build what you want from scratch.
In years past, some of the MEPIS Community developers have created revisions, respins, and proof of concept (PoC) builds for various environments and activities. Right when KDE 4.0 came out, for example, a community member who goes by the forum name of Danum, created special MEPIS builds for KDE 4, has created his own derivatives, and continues to guide people on building their own respun distributions, using MEPIS as a base with newer KDE desktop components.
Marcos, a few years ago, did the same, demonstrating how easy it was to build Xfce and LXDE versions with MEPIS themes and applications, but replacing the desktop, inserting either Xfce or LXDE in place of KDE.
The antiX distribution goes all the way back to 2006, is really a lot like the very first MEPIS distribution from May 2003, and it has been officially recognized and sanctioned by Warren Woodford as a supported and acceptable MEPIS derivative.
Now there is an antiX derivative. It's not officially sanctioned as far as I know, but it certainly is a nice derivative, and we've already had a few builds of it, and it's called Swift Linux. Conceived by Jason Hsu, it was originally created to support some contract work involving forensic activities, such as recovering files from old and failing systems that were using Windows. Jason had been using Puppy, but found antiX had more of the tools and applications that he wanted, overall, but Puppy had, for him, easier desktop navigation.
Therefore, as so often happens in free software, Jason took what he considered to be the best features in Puppy Linux and antiX Linux, remembered the humor in the creation of Hannah Montana Linux, which had been built as a fun exercise about a year ago by another developer, based on Ubuntu. The result: Jason created Swift Linux to be a fast, easy to use derivative of antiX and SimplyMEPIS, combining some of the best features seen in Puppy, antiX, and Ubuntu, providing a solid forensic distribution that also works great as a light, every day distribution.
Taking that humor from Hannah Montana, Jason created iCarly Swift Linux, Taylor Swift Linux, NASCAR Swift Linux, and Magnum PI Swift Linux, in addition to a standard Swift Linux and an extra light Swift Linux. This demonstrates the ease in putting themes to systems that are otherwise similar, even identical, and it also demonstrates how to add and remove features, customizing a system for particular needs.
Jason Hsu, in doing so, further builds my case at why antiX makes such a great platform for custom configurations. It isn't the only platform that can do these things; there are many out there these days, but these are some of the best examples, and they even come, not only with great software, but a fun sense of humor as well.
As proof of how flexible MEPIS has been, antiX has been in existence over five years now and it has three derivatives (or "flavors") of its own, the original, "full" version, a cut down "base" version, which includes a graphical user environment and customization tools, but withholds the applications so that you can select the ones you prefer, and then there is an even more minimal approach called antiX "core", which provides the installation and configuration tools, but no graphical user environment or applications, so you completely build what you want from scratch.
In years past, some of the MEPIS Community developers have created revisions, respins, and proof of concept (PoC) builds for various environments and activities. Right when KDE 4.0 came out, for example, a community member who goes by the forum name of Danum, created special MEPIS builds for KDE 4, has created his own derivatives, and continues to guide people on building their own respun distributions, using MEPIS as a base with newer KDE desktop components.
Marcos, a few years ago, did the same, demonstrating how easy it was to build Xfce and LXDE versions with MEPIS themes and applications, but replacing the desktop, inserting either Xfce or LXDE in place of KDE.
The antiX distribution goes all the way back to 2006, is really a lot like the very first MEPIS distribution from May 2003, and it has been officially recognized and sanctioned by Warren Woodford as a supported and acceptable MEPIS derivative.
Now there is an antiX derivative. It's not officially sanctioned as far as I know, but it certainly is a nice derivative, and we've already had a few builds of it, and it's called Swift Linux. Conceived by Jason Hsu, it was originally created to support some contract work involving forensic activities, such as recovering files from old and failing systems that were using Windows. Jason had been using Puppy, but found antiX had more of the tools and applications that he wanted, overall, but Puppy had, for him, easier desktop navigation.
Therefore, as so often happens in free software, Jason took what he considered to be the best features in Puppy Linux and antiX Linux, remembered the humor in the creation of Hannah Montana Linux, which had been built as a fun exercise about a year ago by another developer, based on Ubuntu. The result: Jason created Swift Linux to be a fast, easy to use derivative of antiX and SimplyMEPIS, combining some of the best features seen in Puppy, antiX, and Ubuntu, providing a solid forensic distribution that also works great as a light, every day distribution.
Taking that humor from Hannah Montana, Jason created iCarly Swift Linux, Taylor Swift Linux, NASCAR Swift Linux, and Magnum PI Swift Linux, in addition to a standard Swift Linux and an extra light Swift Linux. This demonstrates the ease in putting themes to systems that are otherwise similar, even identical, and it also demonstrates how to add and remove features, customizing a system for particular needs.
Jason Hsu, in doing so, further builds my case at why antiX makes such a great platform for custom configurations. It isn't the only platform that can do these things; there are many out there these days, but these are some of the best examples, and they even come, not only with great software, but a fun sense of humor as well.
Friday, May 20, 2011
The Full Monty stumbles after a great start!
Nothing quite like a different view for a while. At least one person likes the colorful new theme. I'll keep it at least a while before deciding on whether to go to something a bit more muted or to keep with this one a while longer. It certainly beats the drab, default appearance, at least for a change of pace.
Speaking of a change of pace, that's what I did today. I went over to PCLinuxOS and messed around there for a while. I have what is known as the "Full Monty" version of PCLinuxOS installed - it came out around the Holidays. It's big, it has everything you can possibly imagine in it, but it also defaults to turning on an incredible number of services, so it is one of the more sluggish systems I have, but I can also do just about anything I may want or need to do with it, yet I actually came upon not one, but two issues with it today, and how I found them was related.
I started up a torrent to download Fedora 15 in the Xfce desktop edition, one of the four major respins that the community project is now offering. I used Ktorrent to do the download, and it was real quick because quite a few people were grabbing it. I was probably getting somewhere in the 1.5-1.8 Mega Bytes per second throughput; multiply that times eight and I was probably seeing 12 to 15 Mbps on a download, pretty good!
But then I wanted to move the file. First I burned the image. That went well, and since PCLinuxOS is fundamentally KDE based, I used k3b to do the job, and it did that well too.
That's about when the problems began. I have a Western Digital external USB drive, where I store ISO images and Virtualbox images in one partition, movies and videos in another one, Windows backups in a third one and Norton snapshot backups in a fourth one; four partitions; two are ext3 format; two are NTFS format.
I have a script that I use on most of my systems, actually two of them, one to mount the USB drive partitions and another to unmount them: mountUSB.bash and unmountUSB.bash. I mounted /dev/sda8 and created /media/sda8, and that's when I first started to notice a problem. The shell came up, but man, was it sluggish. Creating the directory probably took 10-15 seconds, an eternity when I can do it in 1-2 seconds at the max on most other systems. Then the REAL problem came up: the USB devices were not created, and if there was an automated mechanism to create them and make them accessible, it wasn't working. I didn't mess with it; why bother when I have at least ten other systems that can do this right and quickly?
So the sheen came off of this "Full Monty". It had been working quite well and the overhead hadn't presented any issues until today. But now there are two issues: overhead at the command console level is excessive, and for me, unacceptable. Automatically configuring a USB disk drive that works in Windows and in numerous other Linux distros does not auto mount, auto configure anything, and it seems not to work.
I may replace the "Full Monty" with a more basic PCLinuxOS in the future, but I may just wait until they issue an updated ISO image. This system does a lot of things well, but I finally found a few things where it bombed out. They could undoubtedly be fixed, but it isn't worth it to me; the Debian Sid system I am using now does all of these things effortlessly and it is already my every day default system.
Speaking of a change of pace, that's what I did today. I went over to PCLinuxOS and messed around there for a while. I have what is known as the "Full Monty" version of PCLinuxOS installed - it came out around the Holidays. It's big, it has everything you can possibly imagine in it, but it also defaults to turning on an incredible number of services, so it is one of the more sluggish systems I have, but I can also do just about anything I may want or need to do with it, yet I actually came upon not one, but two issues with it today, and how I found them was related.
I started up a torrent to download Fedora 15 in the Xfce desktop edition, one of the four major respins that the community project is now offering. I used Ktorrent to do the download, and it was real quick because quite a few people were grabbing it. I was probably getting somewhere in the 1.5-1.8 Mega Bytes per second throughput; multiply that times eight and I was probably seeing 12 to 15 Mbps on a download, pretty good!
But then I wanted to move the file. First I burned the image. That went well, and since PCLinuxOS is fundamentally KDE based, I used k3b to do the job, and it did that well too.
That's about when the problems began. I have a Western Digital external USB drive, where I store ISO images and Virtualbox images in one partition, movies and videos in another one, Windows backups in a third one and Norton snapshot backups in a fourth one; four partitions; two are ext3 format; two are NTFS format.
I have a script that I use on most of my systems, actually two of them, one to mount the USB drive partitions and another to unmount them: mountUSB.bash and unmountUSB.bash. I mounted /dev/sda8 and created /media/sda8, and that's when I first started to notice a problem. The shell came up, but man, was it sluggish. Creating the directory probably took 10-15 seconds, an eternity when I can do it in 1-2 seconds at the max on most other systems. Then the REAL problem came up: the USB devices were not created, and if there was an automated mechanism to create them and make them accessible, it wasn't working. I didn't mess with it; why bother when I have at least ten other systems that can do this right and quickly?
So the sheen came off of this "Full Monty". It had been working quite well and the overhead hadn't presented any issues until today. But now there are two issues: overhead at the command console level is excessive, and for me, unacceptable. Automatically configuring a USB disk drive that works in Windows and in numerous other Linux distros does not auto mount, auto configure anything, and it seems not to work.
I may replace the "Full Monty" with a more basic PCLinuxOS in the future, but I may just wait until they issue an updated ISO image. This system does a lot of things well, but I finally found a few things where it bombed out. They could undoubtedly be fixed, but it isn't worth it to me; the Debian Sid system I am using now does all of these things effortlessly and it is already my every day default system.
Thursday, May 19, 2011
The latest changes - appearance and distro changes
Blogspot recently made some additional themes available, so I decided to mess around with them for a while. I am not sure the one I just selected is going to hang around long - unless I get some feedback in its favor, but I thought it would at least present a topic of conversation for five minutes before we tire of it and go on to something else.
One "Something else" that I spend a lot of time on is distribution testing. Today, right from the start, I fired up the system where I have what I refer to as the "Test Systems": Sabayon 5.5, Linux Mint Xfce 201104 Debian Edition (or LMDE Xfce for short), Mageia 1 - now a release candidate, Swift Linux 0.1.0, with the "Taylor Swift" art work, (creator Jason Hsu's concession to the fact he liked what developers did a year ago, creating a "Hannah Montana" derivative of Ubuntu for their children), Absolute Linux 13.37, openSUSE 11.4 with the newly added "Tumbleweed" rolling release repositories, which turn the 11.4 release into a perpetual rolling release (which works GREAT), Joli OS 1.2, and Xubuntu 11.04, plus the "dark horse" that I run three times a week for my part time evening job, Windows 7.
Today I spent most of the time with Mageia. This morning I went to upgrade it, thinking that if I ran upgrades I would get the current Release Candidate. I was surprised to find no upgrades, and I did not notice any Release Candidate wallpapers or other art work, so I went to get the RC 1 ISO image. The US Mirror, ibiblio, did not have them yet, but at least two of the German mirror sites and a French site DID have it; the German sites had better throughput for me today, so that's where I got the image. 3.7 GB later, I found it filled up the disk, and I discovered that the Mageia partition that I am using right now "only" has 12 GB, whereas the partition where I have Swift Linux (which is where Mandriva USED to be, has around 20 GB. I had originally intended to install Mageia over Mandriva, but I installed it over LMDE instead, which had been on sda5. I wanted to wipe it anyway, but I ended up bringing in LMDE Xfce later. So a future project will probably be to wipe sda8 where Swift Linux is now, and maybe I will do some kind of partition to partition copy, so that I can write about it and tell newcomers some innovative (but possibly complicated for them) ways to accomplish this quickly.
Anyway, after essentially two nearly 4 GB downloads, I got the new Mageia, and then I did the long DVD burn, then finally the install. I then spent some time over at Sabayon 5.5, which I have currently given the task of managing the Master Boot Record (MBR) for booting up multiple systems (the aptosid that used to be in its place previously had this responsibility). So I spent some time with Sabayon 5.5, updated the GRUB boot loader and updated the system, then went back to Mageia. I also spent some time with Linux Mint Xfce and updated it while I was there, because it's partition also has a lot of free space, enough to handle that big DVD, so that's where I created my Mageia DVD image. Mint Xfce is behaving well in Debian rolling release form, much better than the previous LMDE, in fact. Prior to Mint coming out with a Xfce Edition, I had added Xfce to my version, and used it instead of GNOME on my desktop.
So I used Mageia, Sabayon 5.5, and LMDE Xfce Edition in my testing work today. Just prior to switching to Windows 7 tonight for my evening job, I started up Absolute Linux 13.37, a Slackware 13.37 derivative, and this is a nice, light, fast distributtion, a slam it in place and use it type of distribution. The installer looks very plain, just like Slackware, but the installed software looks much nicer than Slackware in its default appearance.
A few comments on Absolute Linux. Several creators of small distributions, especially those who use IceWM in their work, lift ideas and techniques from Paul Sherman's Absolute Linux work, and they frequently comment with highly complementary words on his work. I can echo their sentiments, and tell you that Absolute Linux and antiX (and its remasters) are among the finest in their implementation of IceWM. I think antiX and Absolute Linux are very close in their implementation, but we have to give the nod to Absolute, not antiX, in this regard, for leading the pack, because antiX got several of its ideas from earlier works in Absolute Linux and a few of the helpers on the antiX project encouraged anticapitalista to include IceWM. I also lobbied to make IceWM the default Window Manager in antiX, reasoning that beginners might have a slightly easier time with it, and veterans can easily switch to the Fluxbox that they often prefer.
Anyway, that is enough rambling from my Absolute Linux system; Windows 7 and the evening mailing list are calling! :-)
If I have any readers, let me know if you'd like a dark theme or this loud background theme that I am using right now.
One "Something else" that I spend a lot of time on is distribution testing. Today, right from the start, I fired up the system where I have what I refer to as the "Test Systems": Sabayon 5.5, Linux Mint Xfce 201104 Debian Edition (or LMDE Xfce for short), Mageia 1 - now a release candidate, Swift Linux 0.1.0, with the "Taylor Swift" art work, (creator Jason Hsu's concession to the fact he liked what developers did a year ago, creating a "Hannah Montana" derivative of Ubuntu for their children), Absolute Linux 13.37, openSUSE 11.4 with the newly added "Tumbleweed" rolling release repositories, which turn the 11.4 release into a perpetual rolling release (which works GREAT), Joli OS 1.2, and Xubuntu 11.04, plus the "dark horse" that I run three times a week for my part time evening job, Windows 7.
Today I spent most of the time with Mageia. This morning I went to upgrade it, thinking that if I ran upgrades I would get the current Release Candidate. I was surprised to find no upgrades, and I did not notice any Release Candidate wallpapers or other art work, so I went to get the RC 1 ISO image. The US Mirror, ibiblio, did not have them yet, but at least two of the German mirror sites and a French site DID have it; the German sites had better throughput for me today, so that's where I got the image. 3.7 GB later, I found it filled up the disk, and I discovered that the Mageia partition that I am using right now "only" has 12 GB, whereas the partition where I have Swift Linux (which is where Mandriva USED to be, has around 20 GB. I had originally intended to install Mageia over Mandriva, but I installed it over LMDE instead, which had been on sda5. I wanted to wipe it anyway, but I ended up bringing in LMDE Xfce later. So a future project will probably be to wipe sda8 where Swift Linux is now, and maybe I will do some kind of partition to partition copy, so that I can write about it and tell newcomers some innovative (but possibly complicated for them) ways to accomplish this quickly.
Anyway, after essentially two nearly 4 GB downloads, I got the new Mageia, and then I did the long DVD burn, then finally the install. I then spent some time over at Sabayon 5.5, which I have currently given the task of managing the Master Boot Record (MBR) for booting up multiple systems (the aptosid that used to be in its place previously had this responsibility). So I spent some time with Sabayon 5.5, updated the GRUB boot loader and updated the system, then went back to Mageia. I also spent some time with Linux Mint Xfce and updated it while I was there, because it's partition also has a lot of free space, enough to handle that big DVD, so that's where I created my Mageia DVD image. Mint Xfce is behaving well in Debian rolling release form, much better than the previous LMDE, in fact. Prior to Mint coming out with a Xfce Edition, I had added Xfce to my version, and used it instead of GNOME on my desktop.
So I used Mageia, Sabayon 5.5, and LMDE Xfce Edition in my testing work today. Just prior to switching to Windows 7 tonight for my evening job, I started up Absolute Linux 13.37, a Slackware 13.37 derivative, and this is a nice, light, fast distributtion, a slam it in place and use it type of distribution. The installer looks very plain, just like Slackware, but the installed software looks much nicer than Slackware in its default appearance.
A few comments on Absolute Linux. Several creators of small distributions, especially those who use IceWM in their work, lift ideas and techniques from Paul Sherman's Absolute Linux work, and they frequently comment with highly complementary words on his work. I can echo their sentiments, and tell you that Absolute Linux and antiX (and its remasters) are among the finest in their implementation of IceWM. I think antiX and Absolute Linux are very close in their implementation, but we have to give the nod to Absolute, not antiX, in this regard, for leading the pack, because antiX got several of its ideas from earlier works in Absolute Linux and a few of the helpers on the antiX project encouraged anticapitalista to include IceWM. I also lobbied to make IceWM the default Window Manager in antiX, reasoning that beginners might have a slightly easier time with it, and veterans can easily switch to the Fluxbox that they often prefer.
Anyway, that is enough rambling from my Absolute Linux system; Windows 7 and the evening mailing list are calling! :-)
If I have any readers, let me know if you'd like a dark theme or this loud background theme that I am using right now.
Wednesday, May 18, 2011
Another brief memory usage study using Debian Sid, Xfce, and Seamonkey
I am using the Nightly Build of the Seamonkey Internet Suite, and as part of that suite I have the Web browser and the Email client currently running. Two features that the recent Seamonkey builds offer that were not present in earlier releases are the standard availability of Sync, the tool which maintains browser, cache, cookie, and password information across browsers on different systems and the availability for the browser tabs and bookmark entries to display Website icons.
The Website icon feature, in particular, seems to result in quite a bit more browser memory being actively used in order to be able to display each Web site icon. In particular, the Seamonkey image now consumes over 700 MB of virtual memory and around 260 MB of resident memory, and even 41 MB of shared memory, all significantly larger amounts than required by the 2.0.13 or 2.0.14 released version of Seamonkey, which usually consume in the 300-400 MB of virtual memory, 90-150 MB of resident memory, and 20-30 MB of shared memory. Performance of the new browser, using more memory, however, easily exceeds that of the previous versions, as well as improved functionality, and since the headroom for more memory has a comfortable ceiling, still only about a quarter utilized, this seems to be a wise optimization in favor of performance at the expense of more memory I/O and fewer disk I/O requests for more virtual memory.
Comparing the total amount of memory on the system needed with this Xfce and Debian Sid combination with the Seamonkey Nightly browser to that we saw recently with PCLinuxOS, we find a total system memory utilization of 369 MB. Several of the scenarios with PCLinuxOS were using as much or more memory; for instance, PCLinuxOS with the "light" IceWM window manager, but the memory hungry Chromium Web browser, was using between 520-550 MB, and around 549 MB with KDE and Chromium. The Chromium browser was the big consumer there with PCLinuxOS, whether running KDE or IceWM. With Firefox replacing Chromium, memory usage dropped a bit, and I found Firefox used 297 MB of memory with IceWM and around 420 MB of memory with KDE.
So what I see here with Debian Sid and Seamonkey is about what I'd expect, though I was a bit surprised to see peak virtual memory requirements as high as they are with Seamonkey, yet I find the actual consumed resources to be more reasonable, and the overall system resources needed to be quite reasonable for the hardware that I am currently using.
The Website icon feature, in particular, seems to result in quite a bit more browser memory being actively used in order to be able to display each Web site icon. In particular, the Seamonkey image now consumes over 700 MB of virtual memory and around 260 MB of resident memory, and even 41 MB of shared memory, all significantly larger amounts than required by the 2.0.13 or 2.0.14 released version of Seamonkey, which usually consume in the 300-400 MB of virtual memory, 90-150 MB of resident memory, and 20-30 MB of shared memory. Performance of the new browser, using more memory, however, easily exceeds that of the previous versions, as well as improved functionality, and since the headroom for more memory has a comfortable ceiling, still only about a quarter utilized, this seems to be a wise optimization in favor of performance at the expense of more memory I/O and fewer disk I/O requests for more virtual memory.
Comparing the total amount of memory on the system needed with this Xfce and Debian Sid combination with the Seamonkey Nightly browser to that we saw recently with PCLinuxOS, we find a total system memory utilization of 369 MB. Several of the scenarios with PCLinuxOS were using as much or more memory; for instance, PCLinuxOS with the "light" IceWM window manager, but the memory hungry Chromium Web browser, was using between 520-550 MB, and around 549 MB with KDE and Chromium. The Chromium browser was the big consumer there with PCLinuxOS, whether running KDE or IceWM. With Firefox replacing Chromium, memory usage dropped a bit, and I found Firefox used 297 MB of memory with IceWM and around 420 MB of memory with KDE.
So what I see here with Debian Sid and Seamonkey is about what I'd expect, though I was a bit surprised to see peak virtual memory requirements as high as they are with Seamonkey, yet I find the actual consumed resources to be more reasonable, and the overall system resources needed to be quite reasonable for the hardware that I am currently using.
Monday, May 16, 2011
LMDE - the Xfce variety
LMDE stands for Linux Mint Debian Edition. Xfce, at one time, stood for the XForms Common Environment because the early editions of Xfce used XForms to create a common desktop environment.
The Xfce project originally began around the same time as another desktop environment project, KDE, around 1996. Xfce, in its early implementation, was similar to CDE, the Common Desktop Environment that was prevalent on UNIX workstations in the mid to late nineties. CDE was pretty ugly, and so were the early implementations of Xfce, but arguably Xfce worked better than CDE ever did, and Xfce became portable to a lot more systems.
Xfce was eventually rewritten to use the Gtk+ in 1999, and that was what was available during the Version 3 life cycle. In Version 4, Xfce migrated further to the Gtk+ 2 libraries, and this opened the way to significant new development, including a solid file manager and a new SVG icon set. The current version, included in the Linux Mint Xfce 201104 Edition (the actual name of the release), which is the Linux Mint Debian Edition for Xfce, adds a number of additional features, http://en.wikipedia.org/wiki/Xfce provides some interesting history and details, from which I extracted much of this information.
As far as this 201104 release, this is the first LMDE that has been configured for use as a "Debian Edition". Past releases came out after the main Linux Mint versions (which use GNOME for their desktop environment), but this caused quite a bit of delay in their release. The idea for LMDE was first tested with a GNOME desktop, and this Xfce edition is the first of what will probably end up being most of the other Mint editions that will be based on a Debian rolling release core in order to save on development effort and result in more frequently updated software.
The software itself works quite well. For those familiar with traditional versions of Mint, this edition is not quite as finely polished at this stage in its life as the primary Mint editions, but on the other hand, it is a bit more flexible and a lot more current. We can expect it to become slightly more polished over time, though probably not to the extent of the official Mint releases.
For a veteran like me, I definitely prefer these LMDE versions to the primary versions of Mint, but not everyone would agree with that, and that is why it is great to have choices and alternatives. This one is pretty good for those with some Debian experience, and it is somewhat easier to deal with than a stock Debian system, but you can still do most things that you do with a genuine Debian system, so in some ways it adds to the flexibility commonly found on a Debian system. These editions are all based on Debian Testing, a solid core of software.
The Xfce project originally began around the same time as another desktop environment project, KDE, around 1996. Xfce, in its early implementation, was similar to CDE, the Common Desktop Environment that was prevalent on UNIX workstations in the mid to late nineties. CDE was pretty ugly, and so were the early implementations of Xfce, but arguably Xfce worked better than CDE ever did, and Xfce became portable to a lot more systems.
Xfce was eventually rewritten to use the Gtk+ in 1999, and that was what was available during the Version 3 life cycle. In Version 4, Xfce migrated further to the Gtk+ 2 libraries, and this opened the way to significant new development, including a solid file manager and a new SVG icon set. The current version, included in the Linux Mint Xfce 201104 Edition (the actual name of the release), which is the Linux Mint Debian Edition for Xfce, adds a number of additional features, http://en.wikipedia.org/wiki/Xfce provides some interesting history and details, from which I extracted much of this information.
As far as this 201104 release, this is the first LMDE that has been configured for use as a "Debian Edition". Past releases came out after the main Linux Mint versions (which use GNOME for their desktop environment), but this caused quite a bit of delay in their release. The idea for LMDE was first tested with a GNOME desktop, and this Xfce edition is the first of what will probably end up being most of the other Mint editions that will be based on a Debian rolling release core in order to save on development effort and result in more frequently updated software.
The software itself works quite well. For those familiar with traditional versions of Mint, this edition is not quite as finely polished at this stage in its life as the primary Mint editions, but on the other hand, it is a bit more flexible and a lot more current. We can expect it to become slightly more polished over time, though probably not to the extent of the official Mint releases.
For a veteran like me, I definitely prefer these LMDE versions to the primary versions of Mint, but not everyone would agree with that, and that is why it is great to have choices and alternatives. This one is pretty good for those with some Debian experience, and it is somewhat easier to deal with than a stock Debian system, but you can still do most things that you do with a genuine Debian system, so in some ways it adds to the flexibility commonly found on a Debian system. These editions are all based on Debian Testing, a solid core of software.
Friday, May 13, 2011
Debian APT Part 2: Installing Unreleased Software
There is a two part article that was originally written at the Linux Gazette, and it is now referenced in TLDP, The Linux Documentation Project. It is about installing, not just the standard software applications, which is discussed in the first part of the article series, but having the ability to install newer, less rigorously tested versions of software. Debian uses the terms Stable, Testing, Unstable, and Experimental to describe its four main binary software repositories, but perhaps a better description would refer to the extent of testing performed on the software. From my perspective, Stable contains completely tested, verified software that passes all entry criteria. Testing contains software that has passed the basic unit testing done in the Experimental stage, and has also passed the first qualification level of testing, successfully moving from Experimental to Unstable, and passing the intermediate criteria to be considered Testing, which is software that has passed basic functionality and is ready to undergo rigorous tests in order to be a candidate for the next Stable release.
http://tldp.org/LDP/LGNET/86/tougher.html is the location of the second part of this series, "Installing Unreleased Software".
http://tldp.org/LDP/LGNET/86/tougher.html is the location of the second part of this series, "Installing Unreleased Software".
Subscribe to:
Posts (Atom)