As you may know, Fedora totally redid their Anaconda installer starting with Fedora 18. There are many reasons for it and I'll not go into that here but one perception out there in Internet land is that the partitioning section of the newer Anaconda installer is a pain to use. I must admit that when I first started using it (installing Fedora 18 alpha and beta releases), I really did not like the changes. This dislike persisted for some time until I finally got used to it. Then time passed. Fedora 19 development started, ran its course, and then Fedora 19 was released. It offered some Anaconda refinements. Now Fedora 20 is approaching its beta release and there are yet more Anaconda refinements.
Since I build my own personal remix of Fedora with the stuff I want pre-installed, I do a lot of installs... to test stuff out. I've definitely gotten used to the newer Anaconda now and I actually like the partitioner. The last time I installed Fedora 17 (to test my last remix build, it has since gone EOL) I actually felt weird using the older Anaconda. I actually prefer the newer one now.
Few people do as many installs as me... and some are still stuck in the "not liking the newer Anaconda" stage. Their main gripe seems to be that the partitioner is very confusing and somewhat broken. I disagree with them and I've been doing some troubleshooting with a couple of problem installs users were having. Turns out their problems had less to do with Anaconda and more to do with having terrible pre-existing partition layouts on their hard drives. I though it might be useful to examine two cases where I have the actual fdisk listings of their partition tables. I'll not mention the names of the users who provided them to spare them some negative attention.
Example one - Let's just jump right in. Here's an image that shows a really poor pre-existing partition table:
Here is a somewhat incomplete
fdisk -l listing for it.
Device Boot Start End Blocks Id System /dev/sda1 63 80324 40131 de Dell Utility /dev/sda2 81920 20561919 10240000 7 HPFS/NTFS/exFAT /dev/sda3 * 37459968 204937215 83738624 7 HPFS/NTFS/exFAT /dev/sda4 307337216 312578047 2620416 f W95 Ext'd (LBA) /dev/sda5 307339264 312578047 2619392 dd Unknown
That almost looks reasonable until one examines the details closely. There is a gap between the end of sda2 and the start of sda3. There is a gap between the end of sda3 and sda4. sda4 (the extended partition) is very small and as a result sda5 (a logical inside of the extended) is very small. What we have here is a bunch of free space but no way to get to it. One can NOT make any additional primary partitions. One can NOT make any additional logical partitions... and to the best of my knowledge... one can NOT make any more extended partitions. All of that free space (> 50GB) is in a virtual no-man's land.
How did this poor partition layout manifest itself in the Anaconda installer? The partitioner said there was plenty of space to install Fedora but whenever you went to actually create partitions / mount points it would give an error about there not being enough room to create said partition. Basically Anaconda was confused by the layout but really didn't have a way to communicate that the layout was unworkable. The end user is left with the impression that Anaconda is horribly broken when it was really a badly mangled pre-existing partition table that was to blame.
Example two - Here's another example of a really poor pre-existing partition layout as witnessed by the complete
fdisk -l output.
Disk /dev/sda: 320.1 GB, 320072933376 bytes 255 heads, 63 sectors/track, 38913 cylinders, total 625142448 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x0008cbe0 Device Boot Start End Blocks Id System /dev/sda1 476313598 625137344 74411873+ 5 Extended /dev/sda2 16065 157765631 78874783+ 83 Linux /dev/sda3 160312635 476295119 157991242+ 83 Linux /dev/sda5 602389368 625137344 11373988+ 82 Linux swap / Solaris /dev/sda6 * 476313600 528878053 26282227 83 Linux /dev/sda7 528891993 602389304 36748656 83 Linux
I wish I had a screenshot of what that looks like inside of gparted but I don't. Just look at the start and end sectors for each partition. sda1 starts somewhere in the middle of the drive. sda2 is near the front. sda5 is after sda7. I don't think there is freespace and if an install is to be done, the user needs to reuse one or more existing partitions.
What did Anaconda do with this? The user reported that the install progress bar just hung at a very low single-digit number. The user just ended up having to power cycle after waiting entirely too long for it to finish when it wouldn't. After rebooting the install seemed to be functional but what exactly happened to make the installer get stuck is unknown. Anaconda gave no indication that there was an issue and did its best to work but obviously got confused.
How did these partition tables get mangled? - For both partition tables, I don't think any sane partitioning program would allow a user to create those partitions on purpose so you really have to ask... how did they get that way? To the best of my knowledge, both users engage in the practice of distro hopping. Distro hopping is where one is interested in using or playing with a different Linux distribution with some regularity. One of those users might be the host of a popular Linux-related podcast who reviews one or more different Linux distros every week... or not. :) But seriously, those partition tables can only be the result of multiple Linux installers, using different methods, strong-arming their way. An odd partition operation to make this distro install... and another one later... and maybe more down the line... and you get a mangled layout. Or at least that is the best explanation I've been able to come up with.
How should Anaconda respond to pre-existing unusable or sub-optimal partition layouts? - It would be nice if Anaconda could play the part of partition therapist and recognize when a user has a really bad partition table that is virtually impossible to work with... and just inform the user in a kind but clear way that they need to fix that before Fedora will install. Historically Anaconda seems to just get confused and error out... thinking that it could do something with it but failing. Can this be fixed? I'm not sure but I hope so. I certainly don't expect Anaconda to figure out methods of fixing the bad partition layouts but they do exist and a small portion of users are going to run into trouble. Luckily I've yet to see a situation where Anaconda makes the situation worse by breaking existing OS installs.
But wait, there's more - It turns out that both users had additional partition related problems.
User one has a Dell laptop that offers a special featured named DirectMedia. Go ahead. Take a little time to read that wikipedia link especially the Design Controversy portion of it. It turns out that the existence of that odd extended / locigal partition combination might just have been the result of MediaDirect... and even if they had been able to install Linux, at some point later when Windows was booted again, MediaDirect would have probably regenerated the problematic sda4/sda5 combination probably breaking any Linux install that was done. Now that takes "Made for Microsoft Windows" to a new and more scary level doesn't it? :(
User two once used dd to backup the contents of one partition to another and as a result had two partitions with the same UUID. As you will recall, one of the U's in UUID stands for unique but in this case it wasn't. Just what confusion might that lead to? They reported on a few occasions that most boots of their computer things were normal but other boots the contents of their home directory would totally change... only to change again next boot. After they figured out that they had two partitions with the same UUID it started to make more sense.
Conclusion - The point is that where there is smoke there is sometimes fire and no Linux distro installer can be a complete fire extinguisher in all situations. Some users have bad partition layouts and it would be a good idea to take that into account. Oh, how about a recommendation... boot your machine with some live media that includes gparted and get your partitions in ship-shape before installing. gparted is more battle tested for partitioning, resizing, etc than any distro's installer. Lastly, the newer Anaconada isn't so bad so get over it! :)
It was recently announced that the Raspberry Pi (RPi) has sold 1.75 million units in the 1.5 years they have been available. That is seen by most folks as a screaming success. In contrast, the One Laptop Per Child project (OLPC) has sold about twice as many OLPC units in about 6+ years... yet it is seen by some as a quasi-failure.
Target Audiences - Both projects have targeted the education market. OLPC is aimed at general education and early grades whereas the RPi is targeted at the same and older age groups specifically in computer science education.
The OLPC has been sold specifically to governments and school systems and while they dipped their toes in the consumer market with the Give 1 Get 1 programs, those efforts were not well executed and as a result only became a small fraction of their sales. The bulk of the RPi sales have been directly to the retail market. RPi is still working on educational materials and it is still unclear how well it will do within school systems. Retail sales may still help with the RPi goals but to what degree is unclear. It appears the bulk of their sales are going to hobby type projects and I'm not sure if those qualify.
Copy Cats - The hardware of both projects launched new mass-market product categories because oddly the retail and wholesale mega-corps got scared and had to introduce competing products. The netbook did quite well for a couple of years but the pricing on more traditional laptops dropped low enough to practically eliminate it. There are a large number of ARM-based RPi like single-board computers (not counting the embedded market that pre-existed) but I'm not sure that any of those will be notably successful. RPi clones are somewhat overlapped by the mini-Android clone market.
Hardware and Pricing - Both projects have had unanticipated delays in their design and production phases but they made it through. OLPC ended up being more than double their target price, which appears to have been unrealistic... while the RPi, perhaps having a closer relationship to a component manufacturer, hit their targets. The OLPC is a more complete gadget whereas the RPi requires a significant amount of hardware extras before it is usable. While it is easy to overlook the extra costs associated with the RPi, they are definitely real.
Both projects have revisited their designs coming out with newer hardware releases. The OLPC is in their fourth iteration and they completely changed CPU arches yet the outsides look exactly the same. The second RPi release doubled the RAM without a price increase... awesome.
Software - One major difference is in software. The OLPC Project designed a custom user interface and several stock educational activities on top of Linux whereas Raspberry Pi hasn't had to do as much in the way of software. Both projects have successfully relied on the communities that sprung up around them to augment the software both provide but the RPi seems to have a ways yet to go with the software for their target audience.
Roots and Expectations - Given the similarities and differences between both projects, why is one more often perceived as a greater success than the other? I think a lot has to do with the roots and expectations. One had a big name and lots of media up front and was expected to "change the world" and the other, not so much. I think that is the main reason for the perceptions but there is certainly more to both projects than such a simplified type of judgement conveys.
Unanswered questions - Here are some of the questions that come to my mind. Did I leave any out?
How well will RPi do inside of school systems?
Will RPi rev their hardware like OLPC has with major changes? If so, how will it impact manufacturing costs and pricing?
Will any of the wanna-be products be able to significantly poach users away from RPi or will RPi do that themselves with a later model?
Does the current RPi model B have such a strong mindshare that a future model may be overshadowed by it?
What future plans does the OLPC project have?
How many more OLPCs could have been sold if they had added the consumer retail market as a target and executed as well in that space as RPi has?
OLPC has taken a small foray into the consumer market by allowing their name and look be to be used by one budget Android tablet maker. How well will that do and will there be others?
How exactly do these OLPC licensed third-party projects benefit the OLPC project?
And lastly, will any of those questions ever be answered??! :)
Conclusion - In any event, I'm glad we have both projects and wish them continuing success and a long future. Keep up the great work everyone. Will there be any other projects that make it this level? I certainly hope so. We definitely need more open hardware in the market.
I saw this mentioned on the Fedora Planet. Andy Grover gives a presentation on The Linux Way and how while it is based on The Unix Way, it has been updated for a new era. The real content starts about 4 minutes into it. Enjoy!
I use CentOS quite a bit myself and I know a lot of other CentOS users. Here is a video of one of the main developers (Karanbir Singh ) within the CentOS Project explaining how the CentOS Project works and builds what it builds. Enjoy!
Anyone who has been following my computing adventures on this website for very long will probably already know I'm a big fan of remoting protocols. Ones I've used so far include SPICE, VNC, RDP, X11 redirection, X11 tunneled thru SSH, and NoMachine's NX 3.
There are two new developments in this area. The first is the recently released NoMachine NX4 and the second is x2go. I've had a chance to play with them both and what follows are my initial reactions.
NoMachine NX 4 - If you didn't notice, NoMachine finally released their NX 4 product line. I say finally because I think I saw the first "NX 4 is coming soon" blurb in the pages of Linux Journal magazine about 2.5 years ago. NoMachine has also totally redone their website for the new release. NX 4 is closed / proprietary software. They do offer a gratis download where you can have one user and you don't have to fill out any annoying forms to get to the downloads. If a single user meets your needs, you are good to go. If you want more users, pick out one of their products that meets your needs. Their commercial offerings allow for multiple users on a single host or a session broker to scale users across multiple servers.
What's new in this release? Besides moving to complete closedly software (NX 3 had GPL'ed libraries), NX 4 offers a lot of new features. The NX 3 protocol was basically an extremely efficient rejiggering of the X11 protocol and as a result, NX 3 only ran on servers that offered X11... primarily Linux. The NX 4 protocol is completely new / different and as a result they have made it multi-platform. In the past they had NX 3 client applications for Windows and Mac but not the server side. With NX 4, they now support Linux, Microsoft Windows and Mac OS X servers. So far I've only tried NX 4 on Linux but I'm sure Mac users are going to be very happy because their remote access options have been very limited.
NX 4 has gone a long way to add features that people want in a modern remoting protocol. For example, it now supports multi-media quite well even at fairly modest bandwidth limits. That isn't to say that it is magic but it does amazingly well. It supports sound and video. It has client side session recording. Files can easily be copied between client and server. I also believe client-side USB devices are supported although I have yet to try that. NX 4 has a new, modern interface that is pleasing. It is easy to use especially when you learn the config hotkey in the client (ALT+CONTROL+0). NX 4 is very scalable and can dynamically adjust to changing bandwidth conditions.
Some things I don't like: The NX 4 protocol no longer runs through SSH on port 22, as NX 3 did. NX 4 runs on port 4000... and a result I think it takes a little more effort to initially set up... mainly because anyone using a firewall will have open up a new port. If you are the one with control of the firewall that is no problem, but if not, it might take some effort. In the past, NoMachine had separate packages for the server and the client. Now there is only one package that includes both client and server... so if you want only the client, you are going to end up installing the server as well. I hope in the future they split the package in two again. I wonder if the single package is a marketing ploy or a sign that they didn't spend as much time on the packaging as they should have. At least they offer the Linux version in rpm, deb, and tar.gz formats.
Update: (25 NOV 2013) I got an email from No Machine's Gian Filippo who mentioned that they do have separate client and server packages but they are in the enterprise section. He also said that NX4 can still use ssh for transport except that it was extra work to do so and Windows and Mac users won't have sshd by default so ssh isn't the default. Again, I think this is an option in the enterprise packages.
x2go - The Fedora Project released Fedora 20 Alpha this week. Being the big Fedora fanboi that I am, I was reading about the new features in the Alpha release. Many of the new features caught my eye but the one relevant to this blog post is x2go.
x2go is based on the GPL'ed NoMachine NX 3 libraries. x2go is NOT the first project based on those... as the more well known FreeNX came first. Unfortunately the development of FreeNX stalled and the last updates seem to be from 2008. x2go appears to have picked up NX 3 ball and run with it. Not only have they modernized the code to run on contemporary systems but they have also added a number of new features. They supposedly have a session broker application that can scale connections across multiple hosts turning x2go into a more complete terminal services solution. I have only tried the simplest case of installing the server on a physical host as well as a KVM virtual machine and connecting to it from a single client. In the simple case, it works quite well. They supposedly have added sound, file sharing, and client-side USB... all running through SSH... but I haven't tried all of that just yet.
x2go is still based on X11 so the server side is not available for Microsoft Windows nor Mac OS X. They do have client applications for Windows and Mac. I tried the Windows client and it looked and worked great. x2go will be available in quite a few distributions via stock repos. Is x2go available for your preferred Linux distribution yet? I wish Fedora had x2go packages for Fedora 19 as it will be a few more months before Fedora 20 is released. I certainly hope the EPEL packagers will make x2go available for EL6 (and EL5 if possible) at some point and I expect it to be a stock package in EL7.
Overall, x2go works quite well.. and over a LAN it easily rivals SPICE... except maybe for video. I haven't had a chance to try it in lower bandwidth situations although I expect it to work quite well as NoMachine's NX 3 product line was excellent.
Conclusions - Which do I like best... NX 4 or x2go? Both have their pluses and minuses. I prefer FLOSS software but yes NX 4 has some additional capabilities that under certain conditions I might want. For example, if I wanted remote access to a Windows machine or a Mac, x2go is not an option. NX 4 is going to be a hard sell on Windows systems because Microsoft's RDP is there by default and well entrenched.
When Fedora 20 comes out and is my distro of choice, adding x2go will be a no-brainer. If it becomes available for EL, I'll use it there too. At this stage it is hard to say because I haven't tried out any of the more advanced use cases. How well does x2go scale? Which desktop environments are written well enough to accommodate multiple users? Once I've had more time with both of them I might have a more complete answer... but at this point I'm glad there are more options in remoting protocols. Which ones do you prefer?
Here's Gabe Newell from Valve / Steam talking about Gaming on Linux also from LinuxCon. Enjoy!
LinuxCon 2013 NA is this week. Here's the keynote from Linux Foundation head Jim Zemlin entitled, "The State of Linux". Enjoy.
I've been playing one form or another of electronic Mahjongg for a number of years. One of the first games I remember was Activision's Shanghai for my Atari ST back in the late 80's. In modern times I mostly play KMahjongg. GNOME has a pretty good flavor too... but since I've been using KDE for so long, I've got more time in with KMahjongg. One feature of the Atari ST version that I miss was the competitive mode that had two flavors: 1) two player, take off as many tiles as you can before you choke and hand it off to the other player, or 2) Take off one tile and pass it to the next player... or at least that is how I remember it. KDE has a second flavor of Mahjongg for online play named Kajongg but I haven't figured that out yet. Anyone played Kajongg?
One question I've been asking myself over the years though... is how good am I at Mahjongg? I'm posting this video to show a sample play session. It isn't my best game/time but it isn't bad... and I also show my top 10 times. Anyone else close to me? I challenge you to post your top times. The video has no sound. I could have put some loud trance beat behind it, but I find those videos annoying. I prefer the default tile layout (dragon?) and the traditional tile theme.
Here is a link to my slides from my talk on Home Automation with the Raspberry Pi.
Red Hat Summit is going on in Boston this week. Here is promo video they released about Red Hat turning 20.