I've done this more than once without the need to reinstall (With both Vista and W7). You just re-activate. I do believe I was kinda lucky, but the "technical problem" that usually causes a BSOD (the disk driver or the graphics driver barfing up on initialization) is mostly solved on the latest versions of Windows. And it has everything to do with drivers. The new driver model allows for core drivers to die without bringing down the whole system. I'm not saying it will work everytime, but its not the dreadful experience it was with XP.

This is actually a good point. Upto Vista, this was a big issue. With Windows Vista (mostly due to hybrid/userland drivers), this started to be possible, or at least with greater success rates. But yes, it is usually way easier in Linux, even when some incompatibility arises.

So how much more is 9 than 5? 80%?

So, ICS should work without a problem in my 2.2 system? Because it doesn't. And my 2.2 is not even 4 years old.

Well, either the system is designed with a long-term maintenance cycle or isn't. Most Linux distros aren't, period. Most userland apps from 10 years ago won't even run on a modern system without recompiling. I'm actually a huge fan of FreeBSD and OpenBSD - I can pick a 10 year old FreeBSD system and upgrade it to the most stable version without (mostly) no issues. I'll probably have problems doing the same on a 2 year old OpenBSD system. That is also ok, some operating systems require a reinstall to truely work properly. And a ton of software changes - the configuration files change, the syntax changes, shared libraries are different, etc. There is nothing wrong with that - its just the way it is.

Did you tried it? Windows 8 actually runs better than XP on not-so-old hardware. I have a 6 year old laptop with it, and works quite well. And I can run 10 or 15 year old apps without a problem. If I really need XP, thats fine - I can even run a virtualized version of it. The release cycle for Windows is different than for Linux. Microsoft needs to make shure it doesn't break compatibility with most of the huge application catalog available. Linux has a different development pace, different priorities, and it is used on an ecosystem where most of the important stuff can be recompiled, and/or are provided by the companies that drive the change in kernel (Oracle, IBM, Redhat, etc). Long-term compatibility isn't a priority - at all. But there are a lot of users for which long-term compatibility is important. Denying it is just stupid.

Actually, they do. Some of the system drivers are developed with the hardware manufacturer, but others are basically developed by Microsoft. I'm talking about system drivers, the ones that work out-of-the-box, not the ones you install yourself. For those, ATI and Nvidia _also_ write them for Linux, and most of the time they still are a big pile of stinking poo.

No, they're not. I'm not a driver programmer, but you have tons of examples. Have a look at multiple non-compatible USB stacks in 2.4 kernel. Have a look in syscall changes between 2.4 and 2.6. Have a look at some sort of sound support API. Or 3D acceleration. Or true userland drivers. Or can just assign privileges to devices to a random list of people. The list goes on and on. Every OS out there has its quirks.

The binary blobs are there because the kernel developers allows them to be. There is no pressure over the manufacturers to release actual stable working drivers. And guess what? Those blobs also exist in Windows. And the hardware works.

You are. PC-BSD's pbi format does exactly the same (http://www.pcbsd.org/en/package-management/), it is not a novel idea - at all. And as many other comments point out, other platforms do it too.

Good for you. The same could be said about any software tool, really. But in the real world, some companies have hundreds-of-pages catalogues that need to be produced in multiple languages, often with different product sets, but with the same layout. And with correct color accuraccy (eg. converting RGB -> CMYK and having a proper preview on a calibrated setup). And InDesign does all that, and reading from your XML. Or from the ERP solution that has product images and is able to generate both end-user catalogs and technical catalogs from the product datasheet on the database. I'd say if you spend more than 10h tweaking any other system to do the same, you are starting to lose money - it is cheaper to just do it in InDesign - and (usually) easier to maintain and upgrade.

Try Corel PhotoPaint. Photoshop CS6 is awesome, but CS5/5.5 was a big pile of unstable poo (at least in Windows). And many of the features Photoshop users rave about were already existing in PhotoPaint for years - eg. vector layers, vector masks, smart objects, etc. And color workflow is actually sane. For simpler RGB works, you can do sane image editing with Paint Shop Pro (and actually work with big-ass images like panoramas) at a fraction of the price.

Never heard of it, googled it and seems to be Mac-only. My previous Corel suggestion is probably useless to you :)

Depends on the type of work you did. I know a lot of users (myself included) for whom InDesign and Acrobat was essential and having Photoshop there is just an added bonus. InDesign is probably the most difficult to replace piece of Adobe software (and Quark is a big pile of unstable poo and has been since forever - at least on Windows). The traditional Quark's alternative, PageMaker, was also bought by Adobe. That leaves Serif PagePlus (so many years since it was useful, now a wizard-based crap too similar to publisher), and CorelDraw - which is not really a DTP Program.
Also, there is a "headless" version of InDesign (InDesign Server) to be run as a document server - eg. automatic document conversion, catalogue generation, etc - the dynamic, database-driven templates you create on your desktop can be used to generate automatic documents based on the data you feed into it.

This is light join usage :) We actually had one MySQL application giving problems because of MySQL JOIN limit (63 or something like that).

That is not much - at all, assuming you are caching the output. As an example, the full rendering of the homepage of a specific store done in Magento (cache disabled) was around 140 queries. I have done CMS systems that perform 30-50 queries for high-traffic pages (cache disabled, PostgreSQL), and most OSS CMS platforms will usually generate between 10 and 40 queries just to render the homepage.

That is impressive. Are you handling search with MySQL or using an external system?

Is your total dataset size bigger than memory? Do you rely on JOINs? How many queries/s do you get from MySQL? Are queries scattered across your dataset, or focused on a single set of data (ie. recently used data)?

You may be using MySQL on a specific application it excels at. Or you may just be benchmarking the wrong stuff - it is not clear if you are benchmarking application users or simultaneous connections. If the latter, I usually need 200-400 simultaneous connections (max) to handle the same reqs/s as a similar 3000-5000 connection MySQL database.
I have worked professionally with both PostgreSQL and MySQL (and unfortunely all my current projects are MySQL-based) and I routinely have peformance issues with MySQL in stuff any half-decent RDBMS handles without hiccups.

Its neither lightweight or scalable, at least when compared to PostgreSQL. MySQL usually runs somewhat fine until you have databases bigger than the memory defined for buffer_pool_size. At that point, you'll start having odd performance issues (presumably due to I/O). Also, for small databases, it seems (by my empirical experience - never benchmarked this specifically) the sweet spot for buffer_pool_size is about twice the total size of the database in disk. PostgreSQL works quite well even with 256Mb of memory. Regarding scalability, well, this is a broad subject. At horizontal level, MySQL replication has a ton of issues and oddities (it is getting way better, but still there is a lot of work to be done). At a vertical level, well, if you start using it as a RDMS, you'll quickly find MySQL shortcomings: poor query planner, poor performance in complex join queries, shitty GIS support, no recursive transactions, _no_ "proper" stored procedure support (stored procedures are handled as macros and expanded inline in the queries). MySQL is great for some workloads, but not as a general RDBMS.

I would strongly disagree on that. A PhD is a degree showing that you dominate at least some base concepts needed for the specific field activity, to the point where you can apply them to something vaguely practical/usable. You don't need a PhD in the field, to create something new, and most PhDs I know are actually unable to create something new, "by design" - generically speaking, the education system promotes learning of concepts and (to a certain extent) dogmas instead of touting critical thinking and criativity. Or maybe I just hang out with the wrong crowd.

I regret not having the experience of having a degree - the university, the slow-paced learning, the networking experience.

Shure, pick a high-school dropout, give him a book about Calculus and see how it goes.

Do tell, how many self-taught (other than algebra) modern-day matematicians you know of. I actually knew one, and I'd think he's the exception - by a long shot.

You understood perfectly my point.

Disclaimer: I'm a high-school dropout.

Theoretically, hiring a PhD would give you some guarantee about what the programmer is capable of doing - you can expect him to know not only how 2nd degree equations work, but also the basics of transcendental functions and how to apply base concepts into real-life problems. Theoretically. In practice, shure, maybe most dropouts don't have the basis to understand a lot of stuff - but many PhDs don't understand it either. And some of them, while understanding it, are unable to put in in practice.

I'm one of the few (only?) completely self-taught developers on the company I work for (>100 developers). For most tasks, no "special" knowledge is needed - a monkey could do it. Even so, some academic folks struggle with concepts. For non-trivial, conceptual tasks, I'm usually at the top of the list of the guys to ask stuff. I've done stuff ranging from math coprocessor emulation to signal processing, image processing, 3d programming, embedded systems, compression algorithms, data processing/mining, etc. I'm probably not better than a good PhD (or a guy like me with proper academic background), but I'm way better than *a lot* of median ones.
I would recommend to anyone that wants to be serious either in programming or CS to get a degree - proper mathematics is something that is usually hard to learn without a teacher - but having expectations on a guy just because he has a degree is just stupid. As it is having great expectations regarding a high-school dropout.

Let me rephrase that:

It is not always an advantage... and I do prefer to work with my own resources than to rely on 3rd party "service" providers, but there are a lot of cases when choosing a provider is the sane approach.

Actually, no. Not only the negotiated salary is above average, but also we didn't have an initial cap on it - we wouldn't mind to pay more for talent.

No, I'm saying people from "industrialized" countries (what a bullshit expression, most of the 1st world countries aren't that industrialized anymore) are more lazy and self-apologizing than from other countries. And it reflects on the quality of people coming out of the universities. In contrast, it is usally easier to find above average foreign professionals than local ones - you don't need to go to India. As an example, there are several eastern european countries with lots of talented professionals. And no, it is not always cheaper.