Servo doesn't even attempt to be a good experience and probably never will. That's not the point. It's a testbed and a technology preview. It is ONLY meant to be useful to developers, as it provides the framework to be able to build and test extremely experemental code apart from Firefox before that code is turned into stable components to be used in Firefox.
Everybody watching from the outside thought the plan was to make Servo a replacement for Firefox. If you've actually followed the project, you'd know that's not how it's working - Servo is nothing more than a set of scaffolding for them. Firefox won't be replaced by servo, it will be rewritten one subsystem at a time.
Oh, and by the way, as many of those pieces have been matured in Servo, they've begun to include them in firefox and it's already produced huge performance wins, most of which are only in nightly right now. Take a look at https://wiki.mozilla.org/Quant... and the presentation there, and try Nightly with the Stylo subsystem (new CSS backend) enabled and see how much faster it is:)
Because of the nature of 404, the only thing that can be inferred from it is that the file is no longer there - which 99% of the time is a result of reorganization rather than deliberate removal. 410 (Gone) is the right code for a deliberate removal. You can throw a 410 via your webserver config (ie, via.htaccess or equivalent mechanisms). This response also serves as a signal to other services such as Google that they should remove access to cached versions.
Internet Archive has procedures in place for removing items from their archive as well - they will automatically detect certain robots.txt entries, and they will also accept manual removal requests.
However, think long and hard about whether something should be remove from archives - unless there is a compelling legal reason to do so, it's bad form, and if you are high profile, enough to have things to hide, someone will likely have mirrored your content, and they may respond to you taking down content by distributing it as widely as possible.
Not only are the established methods for secure erasure ineffective, but they also eat up valuable write cycles on flash chips for no tangible benefit - every write to a flash memory device is in effect a small amount of damage to the device, which when taken cumulatively over a long period of time, will eventually lead to the catastrophic failure of that device.
Worse yet is no ordinary software forensic toolset can even see that this data exists - the device consistently maps even the lowest level APIs around the hidden data - direct, physical methods of reading the data off the chips, or discovery of secret manufacturer APs that may or may not exist in any given product are the only chance to see it - the operating system is oblivious in every case, so there's no way anyone but the manufacturer itself, or a destructive examination inf a forensic lab can tell for sure.
With all that said, with extremely rare exceptions i can count on the fingers of one hand like gpg, the only software packages that even attempts to do secure deletion, in any environment, are standalone secure deletion utilities. The assumption should always be that an application does not provide secure deletion, or even secure storage of data at rest, because this is almost universally true, even in supposedly security conscious applications. If it doesn't make any specific claims about secure erasure, it most certainly doesn't do it. Insecure storage, and cleartext data at rest are the norm, even in 2016, even in supposedly "secure" applications.
Using full disk encryption, with a robust passphrase lock, or a robust passphrase lock coupled with biometrics should be the default for anyone carrying sensitive information on a mobile device.
Wordpress may be been a security nightmare a new years ago, but has steadily gotten better with security, and, at this point has the smoothest updating process, security-minded developers, and a team that's focused on proactively identifying and fixing vulnerabilities. The same can't be said for some of its plugins though.
These days, Drupal and Joomla are the real security nightmares, because of version lock-in and very poor upgrade paths. All but the largest organizations using Drupal or Joomla tend to do so without the manpower or expertise necessary to cope with the upgrade process. They tend to use consultants and contractors to develop the functionality they need, and that functionality invariably is locked to the major version it's developed against. A few years go by, and the version they depend on reaches end of life. By which point, nobody who understands the site is left, and management frequently won't pay for code to be rewritten for the latest version. Unless you can be sure there will be adequate manpower going forward to keep maintaining and keep pace with Drupal/Joomla development, it's a ticking time bomb from day one.
Wordpress on the other hand is less of a framework and more of a ready to use system - thanks to a saner plugin system, upgrades that tend not to break the plugin architecture, and built-in functionality that does 99% of what most sites need right out of the box or with readily available plugins, has huge popularity and a large base of developers, and its rare that a Wordpress site ever becomes a dead-end project with version lock-in. Even when plugins or themes break due to upgrades, they tend to be easily removed or replaced without affecting the core CMS functionality of the site.
You are still going to see more security advisories for Wordpress these days, but at this point, that's more of a function of popularity than inherently "bad" code - it's the most widely used CMS, so of course people are constantly going to be searching for bugs - and a bug that's found is a bug that gets fixed.
True, though, that's kindof a separate problem - with that said, I believe the difficulty in unlocking bootloaders and getting root *legitimately* causes more security problems in the long run, because it encourages hoarding of exploits. This effect is more evident with iOS, where you frequently see exploits hoarded until shortly after a major Apple product release, but it's actually more dangerous with Android because of how slow security updates roll out. We'd be better off if all devices had a straightforward path to root via a device wipe and toggling of bootloader flags.
This brings up an bigger consideration - Google might want to put out a security "decertification list" via the Google Play Services framework so that those sort of applications recognize the device as unsafe. A known exploitable device puts credentials and enterprise data at far more risk than a rooted one, because the user doesn't necessarily know its unsafe and will take no special precautions.
- Stop certifying new devices unless they are on the most recent two releases as of the day the hardware first ships to customers. So, that would many any hardware that releases today would have to be running Lolipop or Marshmellow to ship with the Play Store. - Require unlocked bootloaders and full AOSP releases with all necessary driver sources for the hardware to get certification and Play Store for manufactures with poor update performance, so that third parties get a crack at updating devices when manufactures and carriers lag behind. - Restructure royalty payments so that app purchases on the play store pay carriers and handset manufactuers significantly more if they are on a current release, and significantly less the older the release is. - Give strong financial incentives to manufactures to partner with google to offer the option of direct-from-google "pure" firmware that customers can elect to install AFTER purchasing the device. with all the manufacturer and carrier customization offered to said users as apps in a special section of the play store.
Looking at http://semantic-mediawiki.org/... there are a few examples that can definitely be considered enterprise users, including some high-risk government users (NASA uses it to plan EVAs for the ISS for example).
The "enterprise mentality" makes most of the alternatives too cumbersome to actually be effectively used - ultimately you have to have buy-in from you users, or what management wants is not going to matter - if it's not pleasant to use you'll be back to emailing 70 different versions of the same different Word document around in a few months time with file renames as your only version control (if you are that lucky).
1) Small-time pirates are not worth the time and energy to prosecute, but they support an ecosystem that makes it easier for the big fish to find the cracks and leaked license keys that allow them to pirate on a larger scale. Getting the small time pirates in the side door delegitimizes the black market and makes it more likely people dipping into that market are the people they do want to focus on. 2) Microsoft now sees competition in the PC operating system space.as inevitable but wants to keep as much mindshare as possible to avoid jeopardizing their very lucrative place in the enterprise. Today it's still taken as a given that most workplace computers will have Windows, and people are conditioned to think they need Windows to be productive. They need to milk that cow for as long as possible, and if the bulk of individuals are more familiar with another OS, that's going to accelerate the transition away from Microsoft on the business desktop. 3) Microsoft likely has considered making Windows free, but to do so would undermine the two Windows cash cows - the OEM "Microsoft Tax" and the enterprise market. Offering a slightly inconvenient solution which accommodates the hobbyist without allowing OEMs to preinstall or enterprises to dodge their licensing cost just makes sense. 4) Most importantly, this is a strong signal that neither Microsoft, nor their OEM partners believe in the power of a new Windows version to drive new PC sales anymore. Going forward, we'll probably eventually see consumer versions clearly become a "Windows License" rather than a "Windows 10 License".
Bug your vendor(s) for modern HTML5 applications. Java has no place in the browser anymore - not now, not anytime in the past 5 years.
We've been at the point for a couple years where JavaScript alone could do everything that plugins once did. ActiveX is pretty much dead. Acrobat Reader and Java (as a browser plugin) are in their death throes, Flash isn't far behind. Little by little, the major browser vendors are doing what they should have done some time ago and pulling the plug so that the last holdouts could die off too.
I have no sympathy for the enterprise here. It's not like you haven't had time to prepare - the major browser vendors have been saying this was coming for years. The only things left still using it are malware authors and the handful of applications that are so outdated and neglected that they may as well be considered malware themselves
Now. As for practical answers. You do what every other enterprise that holds on to software from beyond the grave does. You stick those applications in a Citrix farm sitting on hardened servers. You create an environment for each individual one of those applications, and you configure outbound network access in a whitelist-only fashion. so that the browsers on these citrix environments each access one specific mission-critical Java application. And you pay out the nose to do so, because you didn't plan ahead for the future.
Or, you stick with an outdated, insecure browser on your desktops and get owned. Those are pretty much the only options at this point.
As a customer with a technical background, there is nothing more frustrating than trying to troubleshoot an issue that the vendor already knows about and won't publicly acknowledge. Being burned in hte past has led to placing about as much trust in sales and marketing types as I would in a mob lawyer turned politician.
The things I look for as a prospective customer are: - Openness and transparency with regard to support.and development. - Responsible handling of security issues. - Openness and transparency with regard to pricing. If I have to deal with a salesperson to get pricing, I will take my business elsewhere even if it costs ten times as much.
If any of those things are lacking, or if I'm forced to deal with salespeople - or even worse, salepeople posing as support, my 15 years of IT anger and bitterness are going to drive me straight to your competitors.
More importantly, hiding issues doesn't protect your "dirty laundry" anymore, it just (eventually) makes it even more public, with plenty of time to sour beforehand. I suggest pointing management (and your sales and marketing people) to this wonderful essay from 1999, The Cluetrain Manifesto, which although a bit dated, perfectly foreshadowed where we are today with social media. Your product's issues are going to be public, sooner or later. The question is whether they are going to be public under a site your control, where the people finding their way from search results can see that you are aware of the issue and working on solutions - or even have already solved the issues, or are they going to find it in the form of some rant on twitter/facebook/linkedin/blogs that probably doesn't even reflect the current situation, and doesn't give the company the opportunity to respond.
Agile developers expect agile everything. Ubuntu happens to just be a happy compromise between agile and waterfall.
If you look at RHEL, it's 5-10 year old packages, kept alive by an enormous engineering team that backports fixes to old, dead software, which creates a huge pile of technical debt for any developer trying to use "modern", highly modular frameworks.
As far as developers go, In the Ruby, Python, and Node ecosystems, anything that's not the latest doesn't exist. They don't use the system package management, they use gem, pip, and npm. They really don't care about the underlying OS, until it gets in the way, and getting in the way is exactly what a decade-old OS does.
Just to throw out an example. Take some modern ruby on rails application, say Discourse. (discourse.org). Go download a tarball from github. Now try to make it work with nothing but software from the official RHEL repository. Let me know how that works out for you. After you tear out all your hair and skin trying to do that, try to get the pieces from 3rd party repos that will make that work. See how much you have to bring in as far as new libraries and new packages just to make it work. It's still a nightmare even with the 3rd party repos, and that RHEL support contract doesn't cover them - every single piece that's likely to break your application, is now outside of your support agreement, so your company is now wasting at least $799/year for support.
As soon as they start trying to develop on RHEL, the dirty hacks start. There are things missing - the versions of software that they need to make their dependancies work don't exist on RHEL. They end up in a kind of dependancy hell fighting with libraries that are a decade too old to compile their dependancies. One thing leads to another. Eventually, you recreate an entire current OS in/usr/local, or install one piece by piece from 3rd party repositories. At that point, it's not RHEL anymore. It might still say it's RHEL, but it's a bastardized system that looks more like an evil child of Gentoo and Fedora. (both of which are fine distributions by the way, just they aren't meant to crossbreed). The only thing you have left of RHEL at that point are the parts your application doesn't care about, which is probably not much.
Or, you can attempt to containerize with kvm, chroots, or lxc, which, while not breaking the underlying system as badly, means the application is really running on something other than RHEL.
If Red Hat wants developers back, they are going to have to be able to deliver a product with an agressive delivery schedule, maybe even a rolling release, and be able to deliver the kind of support to make operations feel good. That's a whole new territory, that nobody has touched yet, but if they are up to the challenge of keeping decade old software on life support, they are probably up to the challenge of an agile OS.
If credit cards are involved, then PCI-DSS guidelines are almost certianly mandated by merchant agreements.
PCI-DSS guidelines say, among other things that firewals are required, and that they have to be in their most restrictive ("DENY ALL") configuration, with only the specific connectivity required being permitted.
Therefore, by extension, if this is a point of sale system, and credit card processing is happening on the same network, then by extension, the firewall is required by the merchant agreement, and not only required to be present, but also required to be locked down.
The quality of support you get from forums. mailing lists, and IRC channels is almost always far better than that directly provided by the company. Support teams that are competent enough to not just be warm bodies reading from a script simply don't scale well, because support employees at that level of competency expect (and deserve) to be paid as much as developers.
The vast majority of support queries on the other hand are repeats of the same questions, over and over again from customers who can't be bothered to use Google to search for their problem which means companies have to have a filter in place. That filter can be a forum, a web form that forces you to view every single article in the knowledge base, or a team of barely trained monkeys who are underpaid, and will burn out within 3-6 months from being asked the same questions over again by customers who are, on average, so dense that they don't mention the device in question isn't even turned on until they have already nodded along and gone through 30 minutes of "troubleshooting".
The use of community based support shouldn't itself be a concern, but how that support is implemented, how it's managed, and how the company uses that community based support to triage and escalate issues should be. In the most effective, and customer friendly cases, community support basically is used to to weed out the people who can't bother to help themselves from the people who have real problems, and the latter will get real support from "power users" or even actual developers.
The key to making that work in favor of the customers that actually need help is good moderators. They need to be jaded, vicious bastards who will stamp out any hint of noise amidst the signal, who aren't afraid to humiliate someone who posts the exact same question without reading the post directly below it where someone else asked the same thing.
All of this, should of course be accompanied by the best paid support you can find, at whatever rate allows you to pay your support staff a good (at least $25 USD/HR) wage plus medical, mental health, sick days, vacation and other benefits, and generally keep them happy. This should be a "tierless" support team if at all possible - the people you put there should be able to handle anything that comes their way, or act as a liason between customer and developer when necessary. The rate for this level of support should be high enough that your support team shrugs off people asking "dunb" questions as suckers who wasted their money rather than banging their head in frustration.
Chances are, the same support people can be providing paid phone support and "escalating" cases from the forums for free support when it's needed & deserved. Everybody wins in this case - lazy people can pay to be lazy, people with no time to wait for a solution can pay for one, and people who are willing to work to find a solution can get the help they need free of charge.
Simple enough. Skip the clock entirely, and let the battery itself be the "clock". The battery dies, and the device no longer operates. It's not particularly difficult to design a system with an embedded, non-rechargable battery that lasts for a specified lifespan. There may be some variability in that time, but you can get close enough this way to kill off neglected devices by a certian point.
1. From a security standpoint, in a highly controlled environment, remote update capability is also a security risk, no matter how supposedly "secure" that capability is. The ability to configure the hardware so that hands on thr device are required to apply updates is important. Physical security is easier to verify than logical security - it's much easier to inspect seals, padlocks, and security tags than it is to inspect the device firmware., 2. Flash memory is relatively cheap, especially in the small sizes needed for firmware. The hardware required to read formware from a removable memory card is relatively inexpensive compared to the total retail price of most embedded hardware, even consumer-grade embedded hardware. Thus, firmware replacement through replacement of a compactflash/sd/microsd card is a viable option that can be easily designed in to these systems. The ability to remotely update that firmware could then either be omitted, or able to be disabled through jumpers, switches, etc. 3. Manufactuers need to recognize that hardware will last longer than it's designed, and will remain in service with someone for far longer than originally intended, and plan accordingly. Releasing the firmware and documentation under suitable free software / open source licenses from day one would be ideal, but if this isn't compatable with their business model, some form of code/documentation escrow process that gurantees eventual release of the code at "end of life" would be a viable alternative which would not significantly weaken their buisness model.
I think the right strategy for websites which have to do user registration is to just provide the user with a random password of sufficient length as to be near impossible to type correctly, much less remember, and don't even provide the functionality for users to select their own. This almost insures that the password won't be used elsewhere, it enforces password quality, and it encourages the use of a good password manager.
Nobody is forced to use Unity *yet*, but the alternatives are clearly treated as second class citizens that do not get the same level of attention to detail or integration, and makes for a substandard experience that's increasingly a throwback to the days where Linux on the desktop was *only* for geeks. With Mir on the horizon, and with many developers targeting Ubuntu specifically rather than Linux in general, that situation threatens to get worse, as we could conceivably have a large pool of software with Mir+Unity as hard dependencies very soon.
Sparkleshare (http://sparkleshare.org/) is a "transparent" front end for Git which turns it into a simple file sharing tool. This would probably be appropriate for most of the actual "file sharing" applications the OP mentions (gaining many of the advantages of Git while keeping the complexity hidden until its needed), while obviously any source code fprojects should find their way into some kind of version control repository, probably Git as well, with TortoiseGit (http://code.google.com/p/tortoisegit/) being a fairly compelling solution for a Windows shop.
The learning curve isn't particularly steep here, an hour or less should bring someone up to a functional level with Git, and even though it does have a little trouble working with binaries effectively, particularly large ones, but that's a problem common to most version control systems. git-annex (http://git-annex.branchable.com/) might provide a serviceable workaround for large binary "assets", depending on your workflow, but I haven't used it myself.
A more robust version of rsync.net's "warrant canary" (http://www.rsync.net/resources/notices/canary.txt) might help, if it were to become more commonplace, people would start to assume any provider not providing one to already be under gag order.
IANAL, but the legal theory is that while a gag order can make it illegal to speak out, it can't force someone to make falsified or fraudulent statements - any entity that has not already received a secret order is free to testify to that fact, and simply stop making that assertion at such time that they are compromised.
If this were made more robust, for example, key employees being videotaped undergoing a polygraph regularly where they are asked questions about the integrity of their service, it might just work. (I realize a polygraph isn't secure. For this purpose, however, it doesn't matter, because it provides a means to deliberately fail a test while having deniability of your intent to do so.
1. Lastpass works across all the platforms you've named, and has it's own sync. Keepass works across all of them, and only needs some form of file sync (eg Dropbox). Firefox sync will get you 4 of the 5 (all except iOS). 2. Virtually all of the circumstances that allow someone to attack the keychain program also tend to permit the undetected installation of a physical or software keylogger. The attacker may not compromise your less frequently used accounts as quickly, but they will have everything you use on a daily basis. (Further, accounts you don't use on a daily basis may be forgotten about, a side benefit of a password manager is a checklist of what needs changed in the event of compromise.) 3. Backup processes apply to password managers, as do password reset processes, and use of a password manager does not preclude use of memorable passphrases for particular accounts, particularly for things like email accounts. Right now, I use passphrases + token codes for email, banking, and my password manager itself, passphrases stored in a password manager for accounts that I have to be able to retype the password (facebook, etc), and completely random passwords at the complexity limit of whatever site I'm registering for if I'm not having to sign on to them from any of my devices (random web forums, etc)., and a shorter, more "traditional" 8 character password for my desktop, where a brute force attack is more likely to be carried out by hand than against the password hash., and ease of typing (muscle memory) is desired.
This idea has strong potential, and a way that it can be refined is to offer the user a choice between a random set of password requirements that apply only to them, and change once every few days, and a random passphrase of the xkcd sort. So, you'd have the static rules (at least 16 characters, can't be similar to username, etc), and then you'd add 4 random requirements like: - The 4th character must be a number. - The 7th character must by a symbol - The 2nd character must be an upper case letter. - The 11th character must be a lower case letter followed by the letter 3 letters before it in the alphabet. - Enter a password twice below that meets these requirements, or click here to choose the random password the system has chosen for you [fireball yelling slashed baseballs]
Password reuse impossible. Use of a password manager encouraged, and an option is still open for someone who feels the need to memorize. Because the ruleset is random, but can only be switched every few days, the user can't refresh until they find a set that their password is compatible with, and most users will take the easy way out and accept the random passphrase that suddenly looks a lot less scary, but is reasonably secure.
Of course, this is assuming that you actually have a compelling need to even have logins and passwords - if you aren't a financial (banks, credit unions, credit cards, brokerages, etc), healthcare or an email provider, or dealing with accounts for use inside your company, then you probably don't, and should encourage the user of persona or openid instead, rather than furthering the proliferation of accounts that users have to keep up with...
Webconverger (http://www.webconverger.com/) is a livecd and USB stick bootable linux distribution for kiosk applications, which also puts it in the same territory as ChromeOS for guest access, only it will work out of the box on a wider range of hardware.
By design, it gives the user a tightly locked down, full screen Firefox browser, and nothing else, but it's somewhat configurable and even supports printing (http://webconverger.org/printing/). Out of the box, it supports the Flash and Google Talk Voice/Video plugins, so most if not all websites will work out of the box, and the user can even do voice calling and Google+ hangouts.
The with the exception of the couple of proprietary browser plugins mentioned above, the software appears to be entirely open source, and they offer a free version, subscription service to customize and manage it for you, or source code if you are comfortable getting your hands dirty. Overall, this looks like one of the easiest ways to provide a safe, controlled environment for your guests, locking them into a browser window where they can do what they want, but nothing will be saved. Given the plethora of cloud apps out there to serve as as substitutes for local apps, with a little creativity, this should be all anyone who doesn't bring their own computer will need.
This is great, and exactly what one organization I once worked for did. We had "business liaison" positions within every department, and "application owners", which were dual roles - these people were generally business users, with extra training so that they could work effectively to bridge between IT and the userbase. As part of these dual roles, they were included in the IT decisionmaking and change control process, so that they knew what was up before it happened, rather than finding out afterwards, and so that they could advocate for their department's needs ("You can't change payroll the day before we run it!" "Tuesday doesn't work because that's year end closing!")
We also filtered everything IT through the helpdesk, from change controls, to access requests, to outage notification & paging, to trouble tickets and support requests. Problems which weren't reproducible were stopped there. Things that seemed to be user education would either be handled by the helpdesk, or assigned to the appropriate business liaison to see if there really was a problem and gather more details. Remote control sessions were utilized by the helpdesk to gather screenshots. Intermittent problems were weeded out unless they recurred, in which case the previous calls were referenced to verify that this really was recurring. We leveraged our engineering and operations teams for troubleshooting when appropriate to gather logs. Only after we had concrete, conclusive details of a problem did something get passed to developers - and when we did, it was handled quickly, because we'd gathered all the information efficiently and correctly.
As a result, the developer teams were able to focus on fixing bugs, not triaging problems. The helpdesk always had ready access to all the relevant teams via phone, email, and instant messaging, and was well respected within them, because we were their filter, firewall, and front line, as well as their secretaries. (And we had the decisionmaking power as far as who got paged at 3am and who didn't!)
I'm going to call BS partly on this. Most of the business world is using basic productivity software, probably Microsoft Office, with some users needing access to an accounting package or CRM.
Thin clients aren't so much about up front cost as they are about reducing long term support costs. Using thin clients in an enterprise or small to medium business environment gives you a lot of benefits to the long term bottom line. From a security perspective, you cut the "attack surface" of your network very sharply - from dozens if not hundreds or even thousands of desktops that each need antivirus, security updates, administration, and security monitoring, down to a handful of servers that you can lock down pretty tightly. From a support perspective, you are no longer managing all those desktops, you are now managing a handful of servers. You have all the data for your organization where you can make sure backups are happening, and where you can keep tabs on what data is being stored and where it's stored, so you no longer have to worry about that file with a million customer social security numbers or credit card numbers sitting on someone's desktop, where you won't find out about it until after it walks out the door. Also, with a good setup, you ease the pain of patch days a fair bit, since you don't have to chase breakage across all those desktops, just across the app servers. You remove the expectation of user control because a thin client is clearly not a desktop (the "but I can do it at home, why can't I do it here" syndrome).
These are damn good reasons to go to thin clients on the desktop, even if the up front costs are the same or even slightly more, and they apply to most desktop users. Only "high-performance" application demands, like CAD, and software development need fat desktops. Now, on the laptop side of things, internet connections in the field aren't something you can count on, even with mobile broadband and wifi penetration, it's not always there, and it's not always good enough. so thin clients aren't going to make much headway there for a long, long time.
I would respectfully disagree here. Desktop Linux is a moving target and will be for the foreseeable future. There are too many applications that are considered part of the operating system in the Linux world that have meaningful upgrades within that time frame, upgrades that even for a fairly basic end user are highly desirable, or even mandatory (at least to some users), such as newer browser packages. Highly technical users actually have it easier keeping on an LTS release (even though they are the least likely to do so), because they have the technical know-how to upgrade packages to versions that aren't part of the OS release (either via third-party repositories, repackaging the applications themselves, or via manual installation.)
With this in mind, six months really does seem about right on the desktop, especially when you consider that for Ubuntu's regular desktop releases, there's an 18 month (N+2) support cycle in place. This gives enough time to delay upgrading or to even skip one release without losing vendor support. In practical terms, considering that upgrades generally won't happen the day of a new release, the average user will upgrade every 6-14 months - once or twice a year, and the upgrade itself is comparably painless to the processes that exist for Windows - even a major upgrade can be done in place, with the system still usable before, during, and after upgrading.
Slashdot Mirror
Servo doesn't even attempt to be a good experience and probably never will. That's not the point. It's a testbed and a technology preview. It is ONLY meant to be useful to developers, as it provides the framework to be able to build and test extremely experemental code apart from Firefox before that code is turned into stable components to be used in Firefox.
Everybody watching from the outside thought the plan was to make Servo a replacement for Firefox. If you've actually followed the project, you'd know that's not how it's working - Servo is nothing more than a set of scaffolding for them. Firefox won't be replaced by servo, it will be rewritten one subsystem at a time.
Oh, and by the way, as many of those pieces have been matured in Servo, they've begun to include them in firefox and it's already produced huge performance wins, most of which are only in nightly right now. Take a look at https://wiki.mozilla.org/Quant... and the presentation there, and try Nightly with the Stylo subsystem (new CSS backend) enabled and see how much faster it is :)
Because of the nature of 404, the only thing that can be inferred from it is that the file is no longer there - which 99% of the time is a result of reorganization rather than deliberate removal. 410 (Gone) is the right code for a deliberate removal. You can throw a 410 via your webserver config (ie, via .htaccess or equivalent mechanisms). This response also serves as a signal to other services such as Google that they should remove access to cached versions.
Internet Archive has procedures in place for removing items from their archive as well - they will automatically detect certain robots.txt entries, and they
will also accept manual removal requests.
However, think long and hard about whether something should be remove from archives - unless there is a compelling legal reason to do so, it's bad form, and if you are high profile, enough to have things to hide, someone will likely have mirrored your content, and they may respond to you taking down content by distributing it as widely as possible.
Not only are the established methods for secure erasure ineffective, but they also eat up valuable write cycles on flash chips for no tangible benefit - every write to a flash memory device is in effect a small amount of damage to the device, which when taken cumulatively over a long period of time, will eventually lead to the catastrophic failure of that device.
Worse yet is no ordinary software forensic toolset can even see that this data exists - the device consistently maps even the lowest level APIs around the hidden data - direct, physical methods of reading the data off the chips, or discovery of secret manufacturer APs that may or may not exist in any given product are the only chance to see it - the operating system is oblivious in every case, so there's no way anyone but the manufacturer itself, or a destructive examination inf a forensic lab can tell for sure.
With all that said, with extremely rare exceptions i can count on the fingers of one hand like gpg, the only software packages that even attempts to do secure deletion, in any environment, are standalone secure deletion utilities. The assumption should always be that an application does not provide secure deletion, or even secure storage of data at rest, because this is almost universally true, even in supposedly security conscious applications. If it doesn't make any specific claims about secure erasure, it most certainly doesn't do it. Insecure storage, and cleartext data at rest are the norm, even in 2016, even in supposedly "secure" applications.
Using full disk encryption, with a robust passphrase lock, or a robust passphrase lock coupled with biometrics should be the default for anyone carrying sensitive information on a mobile device.
Wordpress may be been a security nightmare a new years ago, but has steadily gotten better with security, and, at this point has the smoothest updating process, security-minded developers, and a team that's focused on proactively identifying and fixing vulnerabilities. The same can't be said for some of its plugins though.
These days, Drupal and Joomla are the real security nightmares, because of version lock-in and very poor upgrade paths. All but the largest organizations using Drupal or Joomla tend to do so without the manpower or expertise necessary to cope with the upgrade process. They tend to use consultants and contractors to develop the functionality they need, and that functionality invariably is locked to the major version it's developed against. A few years go by, and the version they depend on reaches end of life. By which point, nobody who understands the site is left, and management frequently won't pay for code to be rewritten for the latest version. Unless you can be sure there will be adequate manpower going forward to keep maintaining and keep pace with Drupal/Joomla development, it's a ticking time bomb from day one.
Wordpress on the other hand is less of a framework and more of a ready to use system - thanks to a saner plugin system, upgrades that tend not to break the plugin architecture, and built-in functionality that does 99% of what most sites need right out of the box or with readily available plugins, has huge popularity and a large base of developers, and its rare that a Wordpress site ever becomes a dead-end project with version lock-in. Even when plugins or themes break due to upgrades, they tend to be easily removed or replaced without affecting the core CMS functionality of the site.
You are still going to see more security advisories for Wordpress these days, but at this point, that's more of a function of popularity than inherently "bad" code - it's the most widely used CMS, so of course people are constantly going to be searching for bugs - and a bug that's found is a bug that gets fixed.
True, though, that's kindof a separate problem - with that said, I believe the difficulty in unlocking bootloaders and getting root *legitimately* causes more security problems in the long run, because it encourages hoarding of exploits. This effect is more evident with iOS, where you frequently see exploits hoarded until shortly after a major Apple product release, but it's actually more dangerous with Android because of how slow security updates roll out. We'd be better off if all devices had a straightforward path to root via a device wipe and toggling of bootloader flags.
This brings up an bigger consideration - Google might want to put out a security "decertification list" via the Google Play Services framework so that those sort of applications recognize the device as unsafe. A known exploitable device puts credentials and enterprise data at far more risk than a rooted one, because the user doesn't necessarily know its unsafe and will take no special precautions.
- Stop certifying new devices unless they are on the most recent two releases as of the day the hardware first ships to customers. So, that would many any hardware that releases today would have to be running Lolipop or Marshmellow to ship with the Play Store.
- Require unlocked bootloaders and full AOSP releases with all necessary driver sources for the hardware to get certification and Play Store for manufactures with poor update performance, so that third parties get a crack at updating devices when manufactures and carriers lag behind.
- Restructure royalty payments so that app purchases on the play store pay carriers and handset manufactuers significantly more if they are on a current release, and significantly less the older the release is.
- Give strong financial incentives to manufactures to partner with google to offer the option of direct-from-google "pure" firmware that customers can elect to install AFTER purchasing the device. with all the manufacturer and carrier customization offered to said users as apps in a special section of the play store.
Looking at http://semantic-mediawiki.org/... there are a few examples that can definitely be considered enterprise users, including some high-risk government users (NASA uses it to plan EVAs for the ISS for example).
The "enterprise mentality" makes most of the alternatives too cumbersome to actually be effectively used - ultimately you have to have buy-in from you users, or what management wants is not going to matter - if it's not pleasant to use you'll be back to emailing 70 different versions of the same different Word document around in a few months time with file renames as your only version control (if you are that lucky).
1) Small-time pirates are not worth the time and energy to prosecute, but they support an ecosystem that makes it easier for the big fish to find the cracks and leaked license keys that allow them to pirate on a larger scale. Getting the small time pirates in the side door delegitimizes the black market and makes it more likely people dipping into that market are the people they do want to focus on.
2) Microsoft now sees competition in the PC operating system space.as inevitable but wants to keep as much mindshare as possible to avoid jeopardizing their very lucrative place in the enterprise. Today it's still taken as a given that most workplace computers will have Windows, and people are conditioned to think they need Windows to be productive. They need to milk that cow for as long as possible, and if the bulk of individuals are more familiar with another OS, that's going to accelerate the transition away from Microsoft on the business desktop.
3) Microsoft likely has considered making Windows free, but to do so would undermine the two Windows cash cows - the OEM "Microsoft Tax" and the enterprise market. Offering a slightly inconvenient solution which accommodates the hobbyist without allowing OEMs to preinstall or enterprises to dodge their licensing cost just makes sense.
4) Most importantly, this is a strong signal that neither Microsoft, nor their OEM partners believe in the power of a new Windows version to drive new PC sales anymore. Going forward, we'll probably eventually see consumer versions clearly become a "Windows License" rather than a "Windows 10 License".
Bug your vendor(s) for modern HTML5 applications. Java has no place in the browser anymore - not now, not anytime in the past 5 years.
We've been at the point for a couple years where JavaScript alone could do everything that plugins once did. ActiveX is pretty much dead. Acrobat Reader and Java (as a browser plugin) are in their death throes, Flash isn't far behind. Little by little, the major browser vendors are doing what they should have done some time ago and pulling the plug so that the last holdouts could die off too.
I have no sympathy for the enterprise here. It's not like you haven't had time to prepare - the major browser vendors have been saying this was coming for years. The only things left still using it are malware authors and the handful of applications that are so outdated and neglected that they may as well be considered malware themselves
Now. As for practical answers. You do what every other enterprise that holds on to software from beyond the grave does. You stick those applications in a Citrix farm sitting on hardened servers. You create an environment for each individual one of those applications, and you configure outbound network access in a whitelist-only fashion. so that the browsers on these citrix environments each access one specific mission-critical Java application. And you pay out the nose to do so, because you didn't plan ahead for the future.
Or, you stick with an outdated, insecure browser on your desktops and get owned. Those are pretty much the only options at this point.
As a customer with a technical background, there is nothing more frustrating than trying to troubleshoot an issue that the vendor already knows about and won't publicly acknowledge. Being burned in hte past has led to placing about as much trust in sales and marketing types as I would in a mob lawyer turned politician.
The things I look for as a prospective customer are:
- Openness and transparency with regard to support.and development.
- Responsible handling of security issues.
- Openness and transparency with regard to pricing. If I have to deal with a salesperson to get pricing, I will take my business elsewhere even if it costs ten times as much.
If any of those things are lacking, or if I'm forced to deal with salespeople - or even worse, salepeople posing as support, my 15 years of IT anger and bitterness are going to drive me straight to your competitors.
More importantly, hiding issues doesn't protect your "dirty laundry" anymore, it just (eventually) makes it even more public, with plenty of time to sour beforehand. I suggest pointing management (and your sales and marketing people) to this wonderful essay from 1999, The Cluetrain Manifesto, which although a bit dated, perfectly foreshadowed where we are today with social media. Your product's issues are going to be public, sooner or later. The question is whether they are going to be public under a site your control, where the people finding their way from search results can see that you are aware of the issue and working on solutions - or even have already solved the issues, or are they going to find it in the form of some rant on twitter/facebook/linkedin/blogs that probably doesn't even reflect the current situation, and doesn't give the company the opportunity to respond.
Agile developers expect agile everything. Ubuntu happens to just be a happy compromise between agile and waterfall.
If you look at RHEL, it's 5-10 year old packages, kept alive by an enormous engineering team that backports fixes to old, dead software, which creates a huge pile of technical debt for any developer trying to use "modern", highly modular frameworks.
As far as developers go, In the Ruby, Python, and Node ecosystems, anything that's not the latest doesn't exist. They don't use the system package management, they use gem, pip, and npm. They really don't care about the underlying OS, until it gets in the way, and getting in the way is exactly what a decade-old OS does.
Just to throw out an example. Take some modern ruby on rails application, say Discourse. (discourse.org). Go download a tarball from github. Now try to make it work with nothing but software from the official RHEL repository. Let me know how that works out for you. After you tear out all your hair and skin trying to do that, try to get the pieces from 3rd party repos that will make that work. See how much you have to bring in as far as new libraries and new packages just to make it work. It's still a nightmare even with the 3rd party repos, and that RHEL support contract doesn't cover them - every single piece that's likely to break your application, is now outside of your support agreement, so your company is now wasting at least $799/year for support.
As soon as they start trying to develop on RHEL, the dirty hacks start. There are things missing - the versions of software that they need to make their dependancies work don't exist on RHEL. They end up in a kind of dependancy hell fighting with libraries that are a decade too old to compile their dependancies. One thing leads to another. Eventually, you recreate an entire current OS in /usr/local, or install one piece by piece from 3rd party repositories. At that point, it's not RHEL anymore. It might still say it's RHEL, but it's a bastardized system that looks more like an evil child of Gentoo and Fedora. (both of which are fine distributions by the way, just they aren't meant to crossbreed). The only thing you have left of RHEL at that point are the parts your application doesn't care about, which is probably not much.
Or, you can attempt to containerize with kvm, chroots, or lxc, which, while not breaking the underlying system as badly, means the application is really running on something other than RHEL.
If Red Hat wants developers back, they are going to have to be able to deliver a product with an agressive delivery schedule, maybe even a rolling release, and be able to deliver the kind of support to make operations feel good. That's a whole new territory, that nobody has touched yet, but if they are up to the challenge of keeping decade old software on life support, they are probably up to the challenge of an agile OS.
If credit cards are involved, then PCI-DSS guidelines are almost certianly mandated by merchant agreements.
PCI-DSS guidelines say, among other things that firewals are required, and that they have to be in their most restrictive ("DENY ALL") configuration, with only the specific connectivity required being permitted.
Therefore, by extension, if this is a point of sale system, and credit card processing is happening on the same network, then by extension, the firewall is required by the merchant agreement, and not only required to be present, but also required to be locked down.
The quality of support you get from forums. mailing lists, and IRC channels is almost always far better than that directly provided by the company. Support teams that are competent enough to not just be warm bodies reading from a script simply don't scale well, because support employees at that level of competency expect (and deserve) to be paid as much as developers.
The vast majority of support queries on the other hand are repeats of the same questions, over and over again from customers who can't be bothered to use Google to search for their problem which means companies have to have a filter in place. That filter can be a forum, a web form that forces you to view every single article in the knowledge base, or a team of barely trained monkeys who are underpaid, and will burn out within 3-6 months from being asked the same questions over again by customers who are, on average, so dense that they don't mention the device in question isn't even turned on until they have already nodded along and gone through 30 minutes of "troubleshooting".
The use of community based support shouldn't itself be a concern, but how that support is implemented, how it's managed, and how the company uses that community based support to triage and escalate issues should be. In the most effective, and customer friendly cases, community support basically is used to to weed out the people who can't bother to help themselves from the people who have real problems, and the latter will get real support from "power users" or even actual developers.
The key to making that work in favor of the customers that actually need help is good moderators. They need to be jaded, vicious bastards who will stamp out any hint of noise amidst the signal, who aren't afraid to humiliate someone who posts the exact same question without reading the post directly below it where someone else asked the same thing.
All of this, should of course be accompanied by the best paid support you can find, at whatever rate allows you to pay your support staff a good (at least $25 USD/HR) wage plus medical, mental health, sick days, vacation and other benefits, and generally keep them happy. This should be a "tierless" support team if at all possible - the people you put there should be able to handle anything that comes their way, or act as a liason between customer and developer when necessary. The rate for this level of support should be high enough that your support team shrugs off people asking "dunb" questions as suckers who wasted their money rather than banging their head in frustration.
Chances are, the same support people can be providing paid phone support and "escalating" cases from the forums for free support when it's needed & deserved. Everybody wins in this case - lazy people can pay to be lazy, people with no time to wait for a solution can pay for one, and people who are willing to work to find a solution can get the help they need free of charge.
Simple enough. Skip the clock entirely, and let the battery itself be the "clock". The battery dies, and the device no longer operates. It's not particularly difficult to design a system with an embedded, non-rechargable battery that lasts for a specified lifespan. There may be some variability in that time, but you can get close enough this way to kill off neglected devices by a certian point.
1. From a security standpoint, in a highly controlled environment, remote update capability is also a security risk, no matter how supposedly "secure" that capability is. The ability to configure the hardware so that hands on thr device are required to apply updates is important. Physical security is easier to verify than logical security - it's much easier to inspect seals, padlocks, and security tags than it is to inspect the device firmware.,
2. Flash memory is relatively cheap, especially in the small sizes needed for firmware. The hardware required to read formware from a removable memory card is relatively inexpensive compared to the total retail price of most embedded hardware, even consumer-grade embedded hardware. Thus, firmware replacement through replacement of a compactflash/sd/microsd card is a viable option that can be easily designed in to these systems. The ability to remotely update that firmware could then either be omitted, or able to be disabled through jumpers, switches, etc.
3. Manufactuers need to recognize that hardware will last longer than it's designed, and will remain in service with someone for far longer than originally intended, and plan accordingly. Releasing the firmware and documentation under suitable free software / open source licenses from day one would be ideal, but if this isn't compatable with their business model, some form of code/documentation escrow process that gurantees eventual release of the code at "end of life" would be a viable alternative which would not significantly weaken their buisness model.
I think the right strategy for websites which have to do user registration is to just provide the user with a random password of sufficient length as to be near impossible to type correctly, much less remember, and don't even provide the functionality for users to select their own. This almost insures that the password won't be used elsewhere, it enforces password quality, and it encourages the use of a good password manager.
Nobody is forced to use Unity *yet*, but the alternatives are clearly treated as second class citizens that do not get the same level of attention to detail or integration, and makes for a substandard experience that's increasingly a throwback to the days where Linux on the desktop was *only* for geeks. With Mir on the horizon, and with many developers targeting Ubuntu specifically rather than Linux in general, that situation threatens to get worse, as we could conceivably have a large pool of software with Mir+Unity as hard dependencies very soon.
Sparkleshare (http://sparkleshare.org/) is a "transparent" front end for Git which turns it into a simple file sharing tool. This would probably be appropriate for most of the actual "file sharing" applications the OP mentions (gaining many of the advantages of Git while keeping the complexity hidden until its needed), while obviously any source code fprojects should find their way into some kind of version control repository, probably Git as well, with TortoiseGit (http://code.google.com/p/tortoisegit/) being a fairly compelling solution for a Windows shop.
The learning curve isn't particularly steep here, an hour or less should bring someone up to a functional level with Git, and even though it does have a little trouble working with binaries effectively, particularly large ones, but that's a problem common to most version control systems. git-annex (http://git-annex.branchable.com/) might provide a serviceable workaround for large binary "assets", depending on your workflow, but I haven't used it myself.
A more robust version of rsync.net's "warrant canary" (http://www.rsync.net/resources/notices/canary.txt) might help, if it were to become more commonplace, people would start to assume any provider not providing one to already be under gag order.
IANAL, but the legal theory is that while a gag order can make it illegal to speak out, it can't force someone to make falsified or fraudulent statements - any entity that has not already received a secret order is free to testify to that fact, and simply stop making that assertion at such time that they are compromised.
If this were made more robust, for example, key employees being videotaped undergoing a polygraph regularly where they are asked questions about the integrity of their service, it might just work. (I realize a polygraph isn't secure. For this purpose, however, it doesn't matter, because it provides a means to deliberately fail a test while having deniability of your intent to do so.
I'm sure similar creative ideas could be used :)
1. Lastpass works across all the platforms you've named, and has it's own sync. Keepass works across all of them, and only needs some form of file sync (eg Dropbox). Firefox sync will get you 4 of the 5 (all except iOS).
2. Virtually all of the circumstances that allow someone to attack the keychain program also tend to permit the undetected installation of a physical or software keylogger. The attacker may not compromise your less frequently used accounts as quickly, but they will have everything you use on a daily basis. (Further, accounts you don't use on a daily basis may be forgotten about, a side benefit of a password manager is a checklist of what needs changed in the event of compromise.)
3. Backup processes apply to password managers, as do password reset processes, and use of a password manager does not preclude use of memorable passphrases for particular accounts, particularly for things like email accounts. Right now, I use passphrases + token codes for email, banking, and my password manager itself, passphrases stored in a password manager for accounts that I have to be able to retype the password (facebook, etc), and completely random passwords at the complexity limit of whatever site I'm registering for if I'm not having to sign on to them from any of my devices (random web forums, etc)., and a shorter, more "traditional" 8 character password for my desktop, where a brute force attack is more likely to be carried out by hand than against the password hash., and ease of typing (muscle memory) is desired.
This idea has strong potential, and a way that it can be refined is to offer the user a choice between a random set of password requirements that apply only to them, and change once every few days, and a random passphrase of the xkcd sort. So, you'd have the static rules (at least 16 characters, can't be similar to username, etc), and then you'd add 4 random requirements like:
- The 4th character must be a number.
- The 7th character must by a symbol
- The 2nd character must be an upper case letter.
- The 11th character must be a lower case letter followed by the letter 3 letters before it in the alphabet.
- Enter a password twice below that meets these requirements, or click here to choose the random password the system has chosen for you [fireball yelling slashed baseballs]
Password reuse impossible. Use of a password manager encouraged, and an option is still open for someone who feels the need to memorize. Because the ruleset is random, but can only be switched every few days, the user can't refresh until they find a set that their password is compatible with, and most users will take the easy way out and accept the random passphrase that suddenly looks a lot less scary, but is reasonably secure.
Of course, this is assuming that you actually have a compelling need to even have logins and passwords - if you aren't a financial (banks, credit unions, credit cards, brokerages, etc), healthcare or an email provider, or dealing with accounts for use inside your company, then you probably don't, and should encourage the user of persona or openid instead, rather than furthering the proliferation of accounts that users have to keep up with...
Webconverger (http://www.webconverger.com/) is a livecd and USB stick bootable linux distribution for kiosk applications, which also puts it in the same territory as ChromeOS for guest access, only it will work out of the box on a wider range of hardware.
By design, it gives the user a tightly locked down, full screen Firefox browser, and nothing else, but it's somewhat configurable and even supports printing (http://webconverger.org/printing/). Out of the box, it supports the Flash and Google Talk Voice/Video plugins, so most if not all websites will work out of the box, and the user can even do voice calling and Google+ hangouts.
The with the exception of the couple of proprietary browser plugins mentioned above, the software appears to be entirely open source, and they offer a free version, subscription service to customize and manage it for you, or source code if you are comfortable getting your hands dirty. Overall, this looks like one of the easiest ways to provide a safe, controlled environment for your guests, locking them into a browser window where they can do what they want, but nothing will be saved. Given the plethora of cloud apps out there to serve as as substitutes for local apps, with a little creativity, this should be all anyone who doesn't bring their own computer will need.
This is great, and exactly what one organization I once worked for did. We had "business liaison" positions within every department, and "application owners", which were dual roles - these people were generally business users, with extra training so that they could work effectively to bridge between IT and the userbase. As part of these dual roles, they were included in the IT decisionmaking and change control process, so that they knew what was up before it happened, rather than finding out afterwards, and so that they could advocate for their department's needs ("You can't change payroll the day before we run it!" "Tuesday doesn't work because that's year end closing!")
We also filtered everything IT through the helpdesk, from change controls, to access requests, to outage notification & paging, to trouble tickets and support requests. Problems which weren't reproducible were stopped there. Things that seemed to be user education would either be handled by the helpdesk, or assigned to the appropriate business liaison to see if there really was a problem and gather more details. Remote control sessions were utilized by the helpdesk to gather screenshots. Intermittent problems were weeded out unless they recurred, in which case the previous calls were referenced to verify that this really was recurring. We leveraged our engineering and operations teams for troubleshooting when appropriate to gather logs. Only after we had concrete, conclusive details of a problem did something get passed to developers - and when we did, it was handled quickly, because we'd gathered all the information efficiently and correctly.
As a result, the developer teams were able to focus on fixing bugs, not triaging problems. The helpdesk always had ready access to all the relevant teams via phone, email, and instant messaging, and was well respected within them, because we were their filter, firewall, and front line, as well as their secretaries. (And we had the decisionmaking power as far as who got paged at 3am and who didn't!)
I'm going to call BS partly on this. Most of the business world is using basic productivity software, probably Microsoft Office, with some users needing access to an accounting package or CRM. Thin clients aren't so much about up front cost as they are about reducing long term support costs. Using thin clients in an enterprise or small to medium business environment gives you a lot of benefits to the long term bottom line. From a security perspective, you cut the "attack surface" of your network very sharply - from dozens if not hundreds or even thousands of desktops that each need antivirus, security updates, administration, and security monitoring, down to a handful of servers that you can lock down pretty tightly. From a support perspective, you are no longer managing all those desktops, you are now managing a handful of servers. You have all the data for your organization where you can make sure backups are happening, and where you can keep tabs on what data is being stored and where it's stored, so you no longer have to worry about that file with a million customer social security numbers or credit card numbers sitting on someone's desktop, where you won't find out about it until after it walks out the door. Also, with a good setup, you ease the pain of patch days a fair bit, since you don't have to chase breakage across all those desktops, just across the app servers. You remove the expectation of user control because a thin client is clearly not a desktop (the "but I can do it at home, why can't I do it here" syndrome). These are damn good reasons to go to thin clients on the desktop, even if the up front costs are the same or even slightly more, and they apply to most desktop users. Only "high-performance" application demands, like CAD, and software development need fat desktops. Now, on the laptop side of things, internet connections in the field aren't something you can count on, even with mobile broadband and wifi penetration, it's not always there, and it's not always good enough. so thin clients aren't going to make much headway there for a long, long time.
I would respectfully disagree here. Desktop Linux is a moving target and will be for the foreseeable future. There are too many applications that are considered part of the operating system in the Linux world that have meaningful upgrades within that time frame, upgrades that even for a fairly basic end user are highly desirable, or even mandatory (at least to some users), such as newer browser packages. Highly technical users actually have it easier keeping on an LTS release (even though they are the least likely to do so), because they have the technical know-how to upgrade packages to versions that aren't part of the OS release (either via third-party repositories, repackaging the applications themselves, or via manual installation.) With this in mind, six months really does seem about right on the desktop, especially when you consider that for Ubuntu's regular desktop releases, there's an 18 month (N+2) support cycle in place. This gives enough time to delay upgrading or to even skip one release without losing vendor support. In practical terms, considering that upgrades generally won't happen the day of a new release, the average user will upgrade every 6-14 months - once or twice a year, and the upgrade itself is comparably painless to the processes that exist for Windows - even a major upgrade can be done in place, with the system still usable before, during, and after upgrading.