My first question is: Why? Why, if they're both hateful and fearful of change, would they need to change? Why not a newer version of Windows or a Mac?
Users aren't oriented towards their OS, they're oriented towards their tasks. Their typical question will begin with "How do I..." and then continue into "but then how do I...". So your first issue is to determine what they use and how they use it and then find out the best way to solve each of those individual use cases or problems. For example, "How do I manage my finances, I currently use Quicken?" or "How do I upload pictures from my camera?". You need to solve each of those use cases in a sane manner that's easy to use and just as good or better than what they have. Typical users, especially the ones you describe, don't want to spend any more time with their computer than they need to.
Don't underestimate a user's ability to forget things that they do on their computer. Again, they're task-oriented and so they won't necessarily remember that they need a certain program to update some infrequently used spreadsheet twice a year.
Only if you can help them complete their tasks should you switch; you shouldn't switch them to Linux because you perceive it as better; it might not be better for them and then they'll have a tainted view of Linux when in fact the problem was that they couldn't use their silly banner-creation software from 1999 on it.
For the backend why not stick with Java? You know it already. If you're thinking PHP then that's fine too but stay away from the frameworks and shortcuts for PHP because they always end up becoming a burden down the road for upgrades, ongoing maintenance, and expansion.
I've had great luck with LAMP stack and with today's cloud bits and strong hosting providers, getting the infrastructure is easier than ever.
Use the tools in Chrome or Firebug for Firefox to help with debugging.
Others have pointed out jQuery and I'll echo that. However, if you're like me you'll want to learn some of the underlying bits or the "why" something works and then augmenting with jQuery and other libraries. You'll want jQuery for most of the frontend work that you do.
Anyone have any invites to spare?
I know nothing of the self-publishing world, though I have considered it at various times. But if I was going to be publishing something for Kindle I'd likely be setting it at a higher price point to give my book separation from the spam.
It helps Mozilla by reducing the amount of code they have to maintain at one time. With a six-week release schedule, if they had to maintain each version for a year, they'd end up supporting eight or nine version simultaneously.
But it's simply not realistic for the software to change significantly in 6 weeks. Web standards don't change that much in 6 weeks to warrant this much changing in the browser. Therefore, they're supporting largely the same codebase for months and months, same as before. At some point they add major new features and these are the ones that should get the new major version number.
Simply incrementing the major version every 6 weeks will hurt Mozilla and Firefox.
Can you cite any examples where something worked in Firefox 4 but not Firefox 5?
Asking what is broken within *this* particular version is completely missing the point. The point is that someone needs to now go back to their PHB and say that FF is now at new version. Resources for the business need to be taken to examine what changed and how those changed bits will affect the organization's web site. And now this process needs to be repeated every six weeks.
At some point, something major *will* change between versions. In the past, one could look at it and say "ok, version 4.0.1 came out, probably just addressed something minor. Version 5 just came out, must be a major new release, we should look at what changed." The new numbering scheme and release schedule makes it much more time consuming to support Firefox because now every release needs to be examined with the care and attention previously only reserved for major versions.
Well-publicized schedule? New version every 6 weeks.
You missed the word "sane" in my post. Six weeks != sane release schedule for major versions of this software. And yes, the version number incrementing *does* indicate a major version.
You're right again in that people don't want to update their software, that's why Firefox (again like Chrome) does it automatically.
Hmm. Not sure if FF actually does update automatically between major versions, I didn't think so. In any event, major version changes in Firefox have broken add-ons which is a failure for the user.
I don't care if Mozilla releases every 6 weeks, every 3 weeks, or every 3 hours. I do care about supporting the browser on multiple web sites and having to work with developers and users alike. Keeping the version numbers on a major/minor/bug fix scheme actually does work; it wasn't a broken model. This version number bouncing is not for the benefit of the user. Seems to be Mozilla with a case of version number envy; their number is smaller than IE and Chrome and they want to fix it, regardless of whether it benefits anyone.
Who, exactly, is the rapid release schedule helping? It's certainly not helping web developers and organizations who try to list their supported browser versions and actually try to code towards those versions. The quickest path to get the corporate PHBs to stop supporting your browser is to have the IT staff say "Guess what, the next version of Firefox is already out so we need to make updates." At some places, support for browsers other than IE is tenuous at best, so making it more difficult to support these browsers only hurts the browser manufacturers.
Want to gain more support? Release a stable product, with wide support for standards and add-ons, and do so on a sane, well-publicized schedule. People don't care about version numbers; updating software isn't something people want or like to do. Why are you making it more difficult and cumbersome for users to use your product?
I broke the cardinal rule and read TFA. From TFA:
"Hickson mentions that the group will be dropping the HTML5 name immediately, but it we have not received a confirmation that this will happen over at the W3C as well."
So WHATWG will no longer be using numbers? WHATWG can call it "Hullapuhjelpus" as far as I'm concerned as long as W3C still continues using version numbers. Version numbers provide excellent reference points to featuresets and are useful to implementers, developers, and end users alike.
From the WHATWG Blog:
"However, shortly after that we realised that the demand for new features in HTML remained high, and so we would have to continue maintaining HTML and adding features to it before we could call "HTML5" complete, and as a result we moved to a new development model, where the technology is not versioned and instead we just have a living document that defines the technology as it evolves."
Because there's demand for new features you no longer want to use a numbering scheme? Many standards are evolving. Why not just increment the minor version when new features are added? HTML version 5.1 added this cool thing, 5.2 this cool thing, etc.
If we're dumping version numbers then why bother calling it Internet Explorer 6, 7, 8, and 9? Why not just call it "Internet Explorer"? We all know that each of those versions render pages the same, right? Hmm. I just realized that I invoked Internet Explorer in a discussion about standards. Mea Culpa.
How does removing the version number help the people who need to implement and work with the standard?
It's my job to count these. There are over 16,000,000 hosts that respond to ping on my network alone. If everyone does this I can see how the number would grow exponentially.
nmap -sP 127.0.0.0/8
"The Book of Xen", "A Practical Guide for the System Administrator"
As stated in the subtitle, The Book of Xen is written with the system administrator in mind; someone who is comfortable with tasks like installing Linux and working with the command line. While it wouldn't be impossible for someone completely new to Linux to accomplish the tasks in the book, a bit of experience would go a long way to both visualize and complete the installation and configuration steps shown in the book. As stated in the introduction, the book is organized "(mostly) alternating between theoretical and practical discussion [because] an admin needs both practical experience and a firm theoretical ground to effectively solve problems..." (xxiii).
The authors do an excellent job of explaining what Xen is and where it fits in the virtualization landscape. This explanation begins with the introduction where the reader gathers a brief history of virtualization along with Xen's place in the landscape. Xen's limitations and reasons for using Xen are also covered right in the introduction, along with an overview of the book.
Chapter 1 begins with a high-level overview of Xen. This discussion is excellent if only to get the readers on equal footing for the discussions to come later in the book. Included in this chapter is a discussion of various techniques for virtualization including Full Virtualization, OS Virtualization, and Paravirtualization. The section on Paravirtualization leads nicely into some of the underlying details of scheduling, interrupts, and memory, and other resource management which are handled by Xen and discussed later in the chapter.
Chapter 2 sends the reader down the path of installing and using Xen. It's a short chapter, coming in at about 9 pages, and the reader is expected to be able to handle an install of CentOS with just a bit of guidance from the authors on specific options to select. This is a key point for those among us who have a preference for a certain Linux distribution. The book isn't tied specifically to a single distro, as the authors note in the introduction, "[w]e've tried to keep this book as distribution- and version-independent as possible, except in the tutorial sections, where we try to be extremely specific and detailed..." (xxiv). The base or host system upon which the examples run is based on CentOS, which the authors acknowledge and highlight in Chapter 2, "[f]or the purposes of this chapter, we'll assume you're installing CentOS 5.x with the server defaults and using its built-in Xen support. If you're using something else, this chapter will probably still be useful, but you might have to improvise a bit" (13). There is discussion of the Xen-tools package in a later chapter which shows its installation under Debian Linux too. So far from being tied to one distro, the book is refreshingly neutral in this regard.
By the end of Chapter 2, the reader has a working Xen host system and a domain 0 or dom0 host upon which to provision virtual machines. Included in Chapter 3 is a discussion of how to provision guest operating systems, known as domU in Xen-speak. The authors devote a good number of pages to making this task clear, and work through examples of basic domU installation and the use of package management systems and Debian's debootstrap to create domUs. Additionally in Chapter 3 the reader learns how to convert VMware disk images to a format usable by Xen.
Chapters 4 and 5 examine details of the Xen backend, including storage and networking. Chapter 4 stands out for its recommendation of blktap and LVM (Logical Volume Manager) as the storage backend as well as an overview of LVM itself, along with the use of networked storage for Xen.
Chapter 6 looks at tools for management of Xen, focusing on Xen-tools, libvirt, and Xen-shell while Chapter 7 gives advice for hosting untrusted users with Xen. Chapter 8 discusses the use of Xen with Unix-like operating systems and includes sections on Solaris and NetBSD.
The ability to migrate the virtual machine from one physical machine to another is one of the advantages of virtualization. As pointed out by the authors, a virtual machine might be migrated to take advantage of newer hardware, to perform maintenance, or any number of other reasons. Chapter 9 is of interest for its discussion of Xen migration. Cold and Live migrations are examined and Footnote 1 on page 126 is interesting for its reference to the Kemari Project and Project Remus which are projects to add hardware redundancy to Xen.
Tools and techniques for the measurement of Xen performance are shown in Chapter 10, which walks the reader through basic usage of well-known tools such as Bonnie++, httperf, UnixBench, and others. More importantly for the Xen admin is the discussion of Xen-aware profilers like Xenoprof which is "a version of OProfile that has been extended to work as a system-wide profiling tool under Xen..." (151).
Chapter 11 covers the Citrix XenServer, which is the enterprise-grade commercial Xen product from Citrix. The authors summarized it best in the review of Chapter 11: "Can Citrix's product replace the open source Xen? As always, the answer is maybe. It offers significant improvements in management and some interesting new capabilities, but that's balanced against the substantial cost and annoying limitations" (174).
Chapter 12 begins the discussion of Hardware Virtual Machines (HVMs), which are virtualization extensions that enable "an unmodified operating system [to run] as a domU" (176). This means the ability to run an unmodified version of Microsoft Windows as a guest OS within a Xen environment. The HVM discussion in Chapter 12 leads nicely into Chapter 13, "Xen and Windows".
The main chapters of the book end with Chapter 14, "Tips", and Chapter 15, "Troubleshooting". Both chapters draw on the experience of the authors and provide value to the book for their recommendations. Though the tool of choice for troubleshooting is the nearest Google search box, it's still helpful to glance over the content in the Troubleshooting chapter if for no other reason than to maybe remember that it's there when you receive the dreaded "Error: DestroyDevice() takes exactly 3 arguments" error.
The Book of Xen is almost certainly a time-saver for anyone looking to implement Xen or virtualization with Linux. The back cover states "The Complete Guide to Virtualization with Xen". The book lives up to that statement and more."
After reading an inspiring article: "100% Web-Based Working For Web Designers", realized that it is already so possible to work in the cloud without the need of any software but only an internet connection.
There is an alternative for every desktop application in the web: file management, image editing, storage, etc. Working in the cloud does not only mean portability but also a huge decrease in the licensing costs of softwares used, no need to purchasing stronger computers every year and so. What do you think, is it worth and possible?"