"The differences for what they are, certainly are not compelling reasons at all to use C over C++ unless you have some constraint which demands you must avoid an overhead associated with C++"
I never claimed otherwise. My point is that C++ is not a superset of C, and should not therefore be used to compile C source files or write files that target C compilers unless one is fully aware of the fact that C++ is _not_ C with some added features.
"C99 includes that provides standard types for things like integers guaranteed to have exactly 32 bits and such. While I'd expect it to be renamed to , it would be quite surprising if C++ 0x didn't include essentially the same thing."
I would hope that this will be the case too, and of course there is nothing to prevent particular compiler implementers from including something like it now, but something that currently depends on vendor support is by its nature not an aid to portability at all. This is also a problem with C compilers, because not all of them are fully C99 compliant despite the standard having been ratified and published in 1999. Those writing portable C are thus forced to use older methods, and while I fully admit that this is not a problem with C itself (which is defined by the standard), it is a problem that nonetheless still exists for most real-world coders who must write portable C and C++.
""2) Use of the extra abstraction mechanisms provided by C++ tends to result in code that is both larger and less performant. This is not a desirable attribute in a systems programming language.""
"This depends heavily upon what you do and how you do it. Some C++ features tend to lead to code that's slower than the most obvious equivalents in C -- but in other cases, exactly the opposite is true. Just for an exceptionally obvious example of the latter, try sorting an array of integers with qsort and then do the same with std::sort."
You are of course correct, because getting the most from any programming language is highly dependent on what is being done and how. Note however that while template-based generics are an extremely powerful feature that can produce highly performant code with type safety features that are completely lacking from C's "generics via void pointer" approach, it does not come free of charge. For example, the code for sorting a list of integers in C++ may be comparable in size to the C one, but this is not the case if one is sorting various different types via templates; here, the fact that the compiler will generate what amounts to an entirely separate set of routines for each type can quickly bloat C++ code far beyond that of its C equivalent, and that may not be something that people working in (for example) embedded systems can afford. Of course, such tradeoffs between size and speed are as old as computing itself, and not something particular to C++.
"To my knowledge, the language contains two actual ambiguities, both of which are resolved by fiat, so to speak. One of these was inherited from C, while the other is new to C++ (though fundamentally similar to the one inherited from C).
My guess is that you aren't talking about those though -- and in fact, there's a pretty fair chance you don't even know what they are."
If you read what I said, it is obvious that I was talking about things that are ambiguous to people learning to write programs in C++, not ambiguities that compilers have problems resolving (which should be resolved by compiler writers, and never impinge upon people writing code in a language).
"There are a fair number of things many people misunderstand about C++, and many people call their misunderstanding ambiguities (or various less repeatable names) but that's a rather different sort of thing."
I am not referring to these as ambiguities (and my comment did not restrict itself to ambiguities as the sole source of problems for people learning C++). By "ambiguity", I am referring to symbols whose meanings change with context such as the "&" operator. Note that I do not include operator overloading here, as ambiguities that this may introduce are a matter of software design, not the feature itself (although the way the iostreams class overloads ">" does I think serve as a poor example of the way operators should be overloaded).
"I'm personally convinced that the concept of intuition applying to programming languages in general is pretty much nonsense as well. Programming is a learned skill, not a
"C++ is virtually a superset of ANSI C so I don't make the distinction between the two. C++ is C with classes, exceptions & rtti to me. The difference that exist are mostly irrelevant to modern programming. These days as far as most programmers or indeed compilers go, C++ and C are one and the same with a few switches to control stack unwinding or other behaviour for.c or.cpp extensions but little else."
What you see is demonstrably incorrect.A partial list of incompatibilities follows (based on the latest standards, i.e. C99 and C++98) follows. You can find plenty more by Googling.
1) C++ has synonyms for certain operators such and "and" for "&&", "not" for "!", etc. and the macro preprocessor "knows about" them. These tokens could however be defined in a C program as having specific meanings other than those that are assumed by the C++ compiler.
2) Boolean types. C++ has them, C doesn't. Obviously, this can cause problems if a C program tries to define ones with the same names, but different values than the C++ ones.
3) Character literals in C are ints, whereas those in C++ are chars. Thus, sizeof('x') in C will return sizeof(int), whereas sizeof('x') in C++ will return sizeof(char).
4. in C, clog is declared in math.h as a complex natural logarithm function, whereas in C++ it is the standard error output stream declared in iostream.
5. The comma operator in C always results in an r-value even if its right operand is an l-value, while in C++ the comma operator will result in an l-value if its right operand is an l-value.
6. C allows literals having types other than primitive types (e.g., user-defined structure or array types) to be specified in constant expression, whereas C++ does not.
7. const qualifiers in C result in a variable that has external (static) linkage and therefore is visible to other modules; in C++, const items by default have internal linkage, and must be explicitly prefix by "extern" to behave as C const objects do.
8. C distinguishes between a function declared with an empty parameter list and a function declared with a parameter list consisting of only void. The former is an unprototyped function taking an unspecified number of arguments, while the latter is a prototyped function taking no arguments. In C++ on the other hand assumes both to be a function that takes no arguments.
I could go on and on, as there are around 50 known and documented syntactic or semantic differences between C99 and C++98. These do not include stuff that C++ has which are not in C, but are items that are nominally common to both languages, but which each compiler will see differently to the other, and therefore either choke on, or compile into code that does not behave identically. C++ is not therefore a superset of C, and anyone who compiles C code with it, or uses it to write code for a C compiler assuming that it is a C superset could be in for a very rude awakening indeed.
"Your DLL problems are a problem of Windows, not of C++"
To be fair, it can also occur on UNIX (a catch-all category which should be read as including Linux) with shared objects. But you are right in saying that this is not a C++ problem as such: shared libraries / DLLs are features of particular OS families that should not be specifically supported by a general-purpose programming language like C++.
NB: I share the general consensus that C++' handling of modularity leaves a lot to be desired. In particular, the loose coupling between headers and source modules together with the ability of any header to redefine the values of constants etc. imported from prior headers is both a potential and actual source of problems. I can understand C++ _supporting this_ for compatibility with C, but Bjarn should IMO have added another better system for use with new C++ code. If something like this had been done properly from the beginning, then they wouldn't have had to retro-fit name-spaces at a later date, because the module name could have also served as a name-space identifier, as was the case with Pascal and Modula-2, later borrowed by more modern languages such as Python and Java.
Indeed: even C code that compiles under C++ can have a subtly different meaning that can bite hard in the form of intermittent bugs that can be extremely difficult to trace. IMO this is actually worse than languages like Java and C#, which are C-like but don't pretend that they are either supersets or "enhanced subsets" of C. It is also the reason why most C programmers use a C compiler rather than a C++ compiler, and also why most commercial C++ setups ship with a C compiler that gets automatically invoked on modules with a ".c" extension.
NB: Objective-C is a true C superset in that it will compile standard C programs just as a C compiler without the "Objective" bits would.
"With C++ I can write one piece of code that can process pixels with 8 or 16 bit integer channels or 16 or 32 bit floating point channels. Fanboys of Objective C and Java are obviously not writing image processing software."
And C++ fanbois are prone to assume silly things about other languages from what somebody they agree with says about them. As an example of this, the fact that Java has templates seems to have escaped you.
Java: lots of examples here, as Sun's JAI (Advanced Imaging API) is specifically designed for image processing. Google is your friend.
People are also doing image processing in Python because it is used by lots of scientists, and image processing is something they do. And of course good old venerable C, which completely lacks all the "++" bits which you seem to think are necessary for writing any type of software.
"Without such important features as operator overloading, constructors, stack-based objects, and references, I really can't take Objective C seriously."
And these are necessary to write software because... Oh, that's right, you need a Turing complete language to write any conceivable piece of software, and what's that? A language can be Turing-complete without having any of these? What strange heresy is this?
"I can't imagine it being used for much mission critical software, that's for sure."
It seems you are incapable of imagining lots of things that exist, but that's your problem. For example, one thing that has escaped your imagination is the fact that C++ is far from being the language du jour for writing mission-critical software: the bulk of what can truly be classified as mission critical (i.e. extremely high reliability stuff where lives are at stake such as medical embedded systems, aerospace, real-time operating system kernels, etc,) are written in C or Ada, usually with a liberal sprinkling of assembler. How can this be when these languages lack all of those amazing features that you insist are necessary for them to be taken seriously? Is it possible that they are missing critical pieces of functionality that can only be implemented by using references to pass parameters? Maybe you should tell them!
"Obviously if you're writing a number crunching app, a game, a driver, a kernel, a shared library or something with high performance, low level or compatibility requirements then you need C++"
You don't need C++ for any of these things, because they can be just as easily written in C. In fact, C is usually a better language for these things than C++ because it is far more widely supported by other languages: C libraries can be used by (to name a few) BASIC, Python, Ruby, Pascal, Fortran, Objective-C, Objective CAML, Eiffel, Smalltalk, etc., etc., etc. By contrast, C++ libraries can be used by, well, C++.
Bjarn says he wants to make C++ an even better systems programming language. The way to do this is apparently by adding features to a language already groaning under the last batch, far from all of which have been consistently implemented in all (or even a majority of) compilers. None of these features seem to address the fact that as a systems programming language, C++ has most of the same shortcomings as C, while adding a few of its own:
1) It is no more portable than C. In particular, various fundamental data types are still dependent on the underlying CPU architecture for their size and format, leading to copious macro #ifdef sections in low-level code that must run on a variety of different systems.
2) Use of the extra abstraction mechanisms provided by C++ tends to result in code that is both larger and less performant. This is not a desirable attribute in a systems programming language.
3) It is already an extremely complex language that requires an extremely complex compiler to implement it. This makes it very difficult to validate, thereby rendering it useless for whole classes of systems programming tasks (e.g. high-reliability embedded systems).
4) The language is a mine-field of ambiguities, overloaded meanings, and counter-intuitive default behaviours that conspire to make it incredibly difficult to learn properly. There are so many potential pit-falls that even very experienced programmers from other languages have trouble writing high-quality code with it, meaning that the language is actually a source of problems in many projects rather than a mechanism for solving them.
It is thus not (as Bjarn claims) a "better C", at least in a systems programming context, because nearly everything it adds is largely superfluous to systems programmers, and comes at a cost that they are unwilling to pay. This is especially true in what is by far the largest segment of systems programming, i.e. embedded systems, many of which are programmed in _significantly simplified_ versions of C, not the goya-esque monster that is modern C++.
NB: it is very difficult to design a single language that is equally useful for both high-level applications programming and low-level systems programming because they have fundamentally different requirements. Systems programmers require precise control of minutiae, whereas applications programmers want something that lets them churn build quality end-user systems with a minimum of pissing around. C++ falls between these two stools, adding nothing useful to C's systems programming capabilities, while being so concerned with nit-picking minutiae that writing high-level applications in it is like scrubbing a very big floor with a very small toothbrush. It is IMO well-suited to only one notable application domain: games development, which is unusual in requiring a mixture of both low and high level code.
"I've defending one of my retail stores twice with a weapon."
That's use of force, which you've said elsewhere you don't believe in.
"I only wish the thief took the time to threaten me rather than run off. "
So you could use force against him. Sounds like you're pretty enthusiastic about the whole idea of using force!
"My wife is hot, and she also has an impeccable aim. She took down a guy 3 times her size at a party who was violating her space."
Again, use of force, which you obviously revel in. It would therefore appear that what you're actually against is the use of force by others.
""How do you expect all these property rights you keep going on about to work without laws?""
"Mutual cooperation."
Which historically doesn't work in communities that are larger than a few dozen individuals because (a) petty jealousies and squabbles fuck it all up by splitting the single cooperative community into two that cooperate against each-other; and (b) said communities tend to get overrun by large collections of organised armed fellows who have discovered that taking what they want from little cooperative communities is both easier and a lot more fun that cooperating with them. It's been tried countless times throughout history, and it has _always_ failed unless the community was (a) extremely small and geographically isolated; or (b) had damn all that anyone wanted, and so wasn't worth bothering to attack and rob.
Modern anarcho-capitalism is not therefore a system based on any form of practicality at all: it is a survivalist fantasy land where cooperating groups of rugged individualists hold off Mad Max style bands of brigands who are never numerous, and don't have access to tanks or other advanced military hardware. Because they know that naughty people who would take from others and enslave them are too stupid to gather together in large numbers, organise themselves effectively, and use the very best military technology, which is why would-be conquerers like Alexander, the Romans, Attilla, Ghenghis Kahn etc. were routinely thrashed by small, rugged bands of individualists who mutually cooperated them into oblivion.
Region codes are not a copy protection system: they are a distribution control system that lets the movie industry say when DVDs are released into different markets, the content of those DVDs, and how much they cost. Region coding does not therefore fall under the DMCA, and bypassing it is not illegal; the actual copy protection mechanism for CDs is DCSS, and it _is_ illegal to bypass that (although doing so is trivially easy from a technological viewpoint).
"Everyone is running IBM architecture still today and Apple was screwed precisely because IBM missed a beat, it's design was reverse engineered and IBM's monopoly was broken by cheaper clones."
The point here is that they _were_ clones of IBM's system, i.e. they were simply riding on the coat tails of a monopoly, making essentially identical machines to said monpololy. And it wasn't simply Apple that got screwed: CP/M, Oasys, and a bunch of other successful operating systems were simply swept aside to be replaced by what was initially an inferior operating system. This is why I keep saying that what we are living under now is the _same monopoly_ that IBM established: it is irrelevant who makes the computers themselves, because they are simply continuing a legacy that the old IBM monopoly established: they still have ROMs with reverse-engineered code in them that emulates stuff in the original IBM PC and AT; they have CPUs in that are capable of running that ancient instruction set; and they use an operating system containing bits that can trace their roots back to that first IBM PC DOS.
"Microsofts entry into the server market was obviously an attack on Unix and they have gained much ground helped by the ever faster x86 architecture and cheaper wintel pricing at the low end of the market."
Microsoft's initial entry into the server market was with XENIX, a UNIX for X86 systems that the original SCO (i.e. the one that is now Tarantella) wrote for them. There were also a number of other X86 UNIX implementations that came before Windows/NT, and like other UNIXes, were mostly used as multi-user systems running text mode applications on arrays of dumb terminals. Windows/NT was a very different beast to that, and targeted a completely different market, i.e. those with networks of PCs who wanted a centralised repository of shared file and print services. The only cross-over point was the now mostly defunct UNIX workstation market, which NT did target; however, one could easily argue that it was ever more powerful and cheap graphics cards driven by the PC gaming market that really sounded the death-knell of these incredibly expensive machines, not anything Microsoft did.
" lot depends on if Microsoft can keep the target moving fast enough. I think with the OS this is hard as I haven't seen much innovation coming from osX that they can steal, possibly document sharing and collaborative working in Office 2009 might keep them ahead of the game for a bit longer."
Innovation and newness are largely irrelevant when you earn money from 90% of the computers being sold anyway. Vista will be the first major overhaul of their core OS since XP was launched in 2001, yet the much more regularly updated Linux and OS X systems are still unable to make much of a dent in Microsoft's desktop dominance. They therefore do not need to stay ahead of anyone to succeed, because people are still buying what is now is now a rather old product in computing terms, and one that has garnered an immense amount of bad publicity from massive and often extremely damaging virus and worm outbreaks.
"And then of course there is.NET whilst the development tools are fairly crap, the platform has the advantage that they could fix some of the crappy bits of Java."
I've not noticed the.NET dev. tools being particularly crappy when compared with what else is out there. However, I do agree that they fixed some of Java's design flaws, thereby forcing Java to respond with similar capabilities. Hopefully, both platforms will continue to be heavily supported, as the existence of each is driving improvements in the other.
"I'm not sure you could say a move to opensource would form a completely new monopoly" I wasn't really thinking about open source, but rather companies such as Google, who (if they did displace the existing "children of IBM" monopoly) would be doing so via a technology that was not even a consideration when the existing monopolies became entrenched. For that sort of
"Ok so we switched from a hardware monopoly owned by IBM to an Operating System monopoly owned by Microsoft. I fail to see quite how this is the same monopoly, unless you define whatever the current monopoly in the IT industry is as the same monopoly."
We did not switch from anything. Nearly everybody is running Intel CPU instruction sets because IBM selected Intel's 8088 for their PC, despite the fact that it was a dreadful processor when compared with the competition (already well established 8 bit CPUs such as Zilog's Z80 were at least as performant, and a _lot_ cheaper, while virtually every one of the newer 16 bit processors was superior in every respect, and comparable in price). We are likewise running Microsoft software because IBM selected Microsoft as the OS supplier for said PC. Again, the OS itself was basically a piece of junk that nobody would have bothered with if it hadn't been part and parcel of a PC with IBM written on the box, yet it ended up dominating the market. The emperor may have changed, but it is the same empire.
"As I've already mentioned I think large multinationals and government may start demanding an open document format for future compatibility reasons"
The odd government may, but multinationals will continue to use MS software unless there is a 100% reliable mechanism for converting all documents. Less that 100% means that (a) they will have to continue using MS software with some of their legacy data, and (b) they will be faced with maintaining two formats, which is costly. They will therefore stick with MS because it is cheaper and easier.
"If MS falls into line then the monopoly is already heavily crippled."
Not if "falling into line" means perfect imports, but feature-crippled exports. Microsoft's core corporate market thus gets the ability to handle any OpenOffice documents they may be sent, while remaining locked in to Office formats for their own data. Net change: zero.
"The lock in to VBA-backend databases is more of an issue but I think you exaggerate the usage of this."
I am not exaggerating anything. Custom MS Office development is extremely common in business settings, and not only for in-house stuff. There is a substantial third-party industry whose products are written in VBA for sectors such as company admin, medicine, law, accountancy, video and car hire, and a host of others. It is not only an extremely cheap and easy way to develop software, but also one that is amenable to significant end-user customisation without needing to learn programming, and that makes it a popular application platform for businesses of all sizes.
"A business could still mandate all normal word documents are saved in an open document format but allow MS office VBA applications."
Why would they bother to do that if they are locked into Office by VBA, macros , etc.? They'll still have to pay MS for Office licenses, so where is the _business case_ for such a policy?
"Microsofts strength has always been seeing another companies new idea, cloning the technology and adding it into the windows portfolio."
Microsoft's strength has been their ability to take ideas that others have developed, and implement them in a way that fits in with their corporate goals, which are basically to ensure that Microsoft customers remain Microsoft customers. And this is what they will do with OpenDocument if they are forced to adopt it: all they need to do is make it both a bit inconvenient to use, and feature-poor when compared to their own formats to ensure that most users won't bother with it.
"As you are probably aware some governments *are* now telling microsoft that they might switch to a different office suite unless MS support an open document format in MS office"
But none have actually switched yet, so MS are far from being in a position where anyone substantial can force them to do anything. And they're fighting this on several fronts: they are seeking ratification from standards bodies for their new Office XML format, and
It's actually amazing how stable and solid that foot under the iMac is. The great big slab perched on what looks like a base that's far too small for it gives the impression that it would topple if you breathed on it hard, yet it's actually rather more stable than some monitors I have that are on what appear to be much more substantial stands. It's quite an impressive bit of engineering.
NB: the Apple attention to detail seems to rub off on Mac peripheral manufacturers too. They seem to be better thought out and are often built to a higher standard the equivalent stuff for PCs, which all too frequently seem to come in incredibly ugly plastic or folded sheet metal cases with extremely cheap and nasty connectors. Of course, this often means that a Mac peripheral costs more, but they are often so much nicer that I've started buying them for my Windows PCs as well as the iMac (most third party Mac peripherals come with drivers for Windows -- Macs on the other hand don't seem to need specialist drivers that often).
What makes you think that politicians would suddenly become wise and considerate if they had the power to pass any law they wanted, and make it stick? If that were the case, then totalitarian regimes would have by far the most carefully-considered and fair laws, because they do not have a review process of any sort.
Quote from the original subject: "The change in Intel's brand is the first step in a $2.5 billion _marketing campaign_, BusinessWeek reported earlier" (emphasis mine).
This is a piece of business news, not hardware news. That's why it's in BusinessWeek, and mentions things like stock prices and what executives had to say, while completely ignoring what Intel actually make. They could be a manufacturer of hamburgers or hammers, and the story would be equally applicable. This one should be under the general "IT" category, not hardware.
Come on, be fair. The government was just acknowledging the fact that imbibing extremely large quantities of beer makes the idea of being nuked to death look far less bleak than would be the case if one had to face that same prospect while sober.
How does a new company slogan get lumped in under the "hardware" category? It is a marketing-related topic that has no more relevance to hardware than a new McDonalds slogan does to nutrition. Who edits this stuff?
Same here. I have an iMac G5 sitting among various other computers, and nobody ever notices the others at all: they are invariably intrigued by the Mac's looks, screen, generally quiet operation, and how it has "a much nicer Windows" than the one that came with their own PCs.
It's certainly a possibility. However, I think a more likely explanation is that the XBox is their hardware design, so they _know_ a TMP module is there, and can use it pervasively throughout the system software and firmware. This will not be the case with Vista, which MS has already stated will not require the presence of a TPM module, and I believe them, because they want lots of their existing users to upgrade, including corporate users, and only a very small proportion of existing hardware has a TPM module.
Consoles on the other hand have always been more heavily locked down than PCs, and the primary reason has nothing to do with piracy. The main source of income for a console manufacturer is the royalties they earn from games written by both themselves and third-party developers, hence the fact that some are willing to sell the console itself at quite a substantial loss for a fair while. To ensure that third-party software developers and distributors cough up their royalties, the manufacturers make it as difficult as possible to run "unauthorised" software: if you want to write a game for that platform, you need to negotiate with the manufacturer so that they will get their cut. That's why Sony etc. get so nasty about mods that let people bypass their console's protection mechanisms: enough people with modded consoles could spawn en entire industry of third-party games that the console manufacturer earns nothing from, thereby invalidating their entire business model.
With the above in mind, I'm pretty sure that MS are not in the least keen on having hackers bust the protection on the XBox-360. They are however realists, and know that there are a lot of people out there for whom a new and tough protection system is a far more entertaining challenge than any game could provide. If the console is as successful as MS obviously hope, it will therefore end up being attacked by thousands of hackers who can use the Internet to pool their knowledge, and Microsoft's engineers are savvy enough to realise that any automated security system can be broken if enough people with sufficient skill are determined to do it. They have also learned from the past that it is far better to admit this publicly than pretend that a system is unbreakable, because even a whiff of the word "unbreakable" will get armies of hackers thrashing away at the thing just to prove them wrong, and gain the kudos of being the first to break the "unbreakable" system.
Being overpriced (in the eyes of consumers) was definitely a factor, but then most consumer electronics are overpriced at the beginning, and are only bought by enthusiasts. And MiniDisk players did drop in price over time (although their media didn't, or not by much), and were subject to many promotions with hefty discounts (I remember several). They still didn't sell in significant numbers, and my conviction that DRM had a lot to do with this comes from a notable personal experience.
I was looking at a MiniDisk recorder in a UK dealer during the mid 90s (I no longer live in the UK), when a spotty youth who was in the company of several similar items said something like "I wouldn't buy one of them if I was you, mate. My brother bought one, and it won't let him record _anything_. They're crap". The assembled youth similies nodded and muttered in general consent ("crap", "total crap", "crappy", "fucking crap", and variations thereof).
Note that as is usually the case with rumours, this one had grown in the telling. It was likely that the brother's MiniDisk system had been difficult about recording _something_, and this had rapidly metamorphosed into _everything_ during re-telling. But this is the same process that drives rumour mills the world over, and which every consumer product from cornflakes to cars has to cope with. If the general consensus down the pub is that product X is "fucking brill!", local dealers sell lots of X; if they say it's "a pile of shite", it sits there on the shelf.
The increase in quality did not offset its limitations in the eyes of customers. As I said before, people will not accept something that is better in some areas than what they already have, but imposes restrictions in other areas that they are not accustomed to. If MiniDisk had been marketed as play-only personal medium that used cheap little players with cheap little disks, then it might have taken off if there was enough content for it. But Sony marketed it as a recording system that was better than tape, and then tried to stop people from doing tape-like things with it. It flopped and is no more, just like DIVX, and DAT-based music recorders, and a whole bunch of other "do what we say" technologies.
I really do hope you are right. However, 25 years in the computer industry has taught me that it is prone to being dominated by massive and overbearing commercial monopolies. The name of the monopoly may change (it used to be IBM, now it's MS, but they wouldn't be in that position if they hadn't been in bed with IBM when it was the big, bad monopoly). And these monopolies persist even when governments take action to try and thwart them. Group Bull for example was heavily funded by the French government in an attempt to break IBM's stranglehold on their computing sector. All government procurements were from Bull; heavy subsidies allowed Bull to undercut IBM in virtually every sector; yet despite this, IBM's share of the French IT market kept getting bigger and bigger.
"I wouldn't understimate the effect of price, most people do not like paying for things if they can get by with something free!"
People opt for what they think offers the best value, and this is not necessarily the item with the lowest price. The fact that MS Office has a user base which dwarfs that of all other similar software combined (including both commercial and open source offerings) would seem to indicate that most of the people who want office productivity software consider that the MS version offers better value than any of the others, free or otherwise.
"Most peole would also be happy with MS Office 5 years ago from a functionality perspective."
Indeed, as is indicated by the fact that people don't upgrade Office anything like as often as MS would like. There is actually a significant proportion of people still using Office-97, because it does what they want and they see no reason to upgrade. Note though that they are sticking with an obsolete version of Office, not switching to OpenOffice.
"Also, most people don't use VBA(or even know what it is) nor do they access databases from office files."
You are wrong about this. Custom VBA Office applications, Word and Excel macros, and stuff that uses MS Access (often as a front-end to corporate RDBMS systems) are very common indeed in both business and government environments, which are precisely the ones where MS is most entrenched, and from which it derives the bulk of its profits. If OpenOffice cannot migrate or at least handle this sort of thing, then it will remain forever on the sidelines, because every small business and individual who has to deal with these corporations will stick with MS Office rather than risk going with an at best only partially compatible alternative.
"If some goverments/countries switch to OpenOffice it's likely some companies will also switch to OpenOffice."
See the example of IBM and Group Bull above. Some may switch, but most won't, because dealings with government are usually handled by specialist departments in companies, and they frequently use different software from the rest of the organisation. This will even be the case for government contractors, who may well use OpenOffice for exchanging documents with the government itself if that is a requirement, but continue to use MS Office for internal stuff, communicating with suppliers, etc.
"Microsoft may be unsucessful at blocking OEMs from installing OpenOffice/StarOffice on new PCs in the wealthy west too. Once one OEM rolls out free unlimited office suites there is going to be more pressure on the others (OEMs even on Dell)."
None of which will affect big businesses at all, because they buy their PCs without operating systems or software and install Windows etc. from disks that MS supply as part of bulk licensing deals. And if the big businesses are still using MS Office, those who deal with them will have to use it too. So the only people who will end up bothering with a pre-bundled version of OpenOffice will be those who probably wouldn't have bought MS Office anyway, i.e. pretty much the situation we have now.
"Once upon a time no one thought IBM would lose it's dominant position ei
"They had a "non-fragmented" market back a handful of years back. Dell tossed it to the curb, most likely due to pressure from Bill and Co. only months after doing it. "
Where is your evidence for the fact that this was due to MS pressure, and not simply a case of a corporation changing their strategy to one that they think is more profitable? IMO the fact that Dell exists solely to make profits would seem to indicate that this is in fact the most likely explanation, not your typically/. MS conspiracy theory.
"And don't go and tell me "fragmented"- what are the main distributions?
Red Hat SuSE Debian Slackware Mandriva"
Running which window managers and desktops? Using what versions of the Linux kernel, GNU tools, compilers, and core libraries (they vary, even with distros released in the same time frame)? Oh look, two different package managers! A whole bunch of different menu structures and categories -- where do I add the entry for my system? Gee, they've just released a new version of distro X, and it's got new core libraries that break my app. Now I've got to resolve it so I can field support calls from all four customers on that distro.
"XP Professional XP Home Media Center 2003 Server Vista(Eventually...)
Each of the above setups realistically, with the exception of XP Home/Professional, have ever so slightly different hardware requirements and available driver profiles."
But the same compiled app with the same installer will work on _all_ of them. And I can write that app using some pretty old development tools and libraries too: my commercial Windows dev. tools haven't been upgraded since 1998, and they still produce executables that run perfectly on not only the versions of Windows you list above, but also Win95, Win98, and WinME. This is not the case with Linux, where applications can easily fail on slightly different versions of the same distro. And don't try blathering that this isn't the case, because it has happened to me, and to a number of other people I know on many more than one occasion.
"Each of the above setups realistically, with the exception of XP Home/Professional, have ever so slightly different hardware requirements and available driver profiles"
None of which matters to commercial software authors, because it is easy to write an application that will install and run on all of them. Hardware designers will target drivers at whichever versions they think will be profitable for them, and not the others. Windows-95 has already slid off the radar-screen, and Win98 is rapidly going the same way, yet these two "distros" between them still account for around 25% of the total Windows user base, i.e. at least ten times as many people as all the desktop Linux users combined.
"Gee... Seems they have the same level of "fragmentation" and not all hardware can be realistically supported with each version- some drivers really only work with 2003 server or XP only, etc."
You are missing the fact that there is a massive difference in scale. Each of those Windows versions (with the exception of Vista, which hasn't been released yet) has orders of magnitude more users than all of desktop Linux combined. Thus, the (actually rather slight) differences between Microsoft distros divides a user base of tens or hundreds of millions into four or five _mostly_ compatible segments, whereas Linux is dividing at best one 20th of that base into several in some cases rather incompatible segments. Add to this the fact that hardware and software developers can get all their tools, SDKs, documentation, and support from one company, and you have a situation where it is actually cheaper and easier to target tens of millions of Windows users than a few desktop Linux users.
Slashdot Mirror
"The differences for what they are, certainly are not compelling reasons at all to use C over C++ unless you have some constraint which demands you must avoid an overhead associated with C++"
I never claimed otherwise. My point is that C++ is not a superset of C, and should not therefore be used to compile C source files or write files that target C compilers unless one is fully aware of the fact that C++ is _not_ C with some added features.
"C99 includes that provides standard types for things like integers guaranteed to have exactly 32 bits and such. While I'd expect it to be renamed to , it would be quite surprising if C++ 0x didn't include essentially the same thing."
I would hope that this will be the case too, and of course there is nothing to prevent particular compiler implementers from including something like it now, but something that currently depends on vendor support is by its nature not an aid to portability at all. This is also a problem with C compilers, because not all of them are fully C99 compliant despite the standard having been ratified and published in 1999. Those writing portable C are thus forced to use older methods, and while I fully admit that this is not a problem with C itself (which is defined by the standard), it is a problem that nonetheless still exists for most real-world coders who must write portable C and C++.
""2) Use of the extra abstraction mechanisms provided by C++ tends to result in code that is both larger and less performant. This is not a desirable attribute in a systems programming language.""
"This depends heavily upon what you do and how you do it. Some C++ features tend to lead to code that's slower than the most obvious equivalents in C -- but in other cases, exactly the opposite is true. Just for an exceptionally obvious example of the latter, try sorting an array of integers with qsort and then do the same with std::sort."
You are of course correct, because getting the most from any programming language is highly dependent on what is being done and how. Note however that while template-based generics are an extremely powerful feature that can produce highly performant code with type safety features that are completely lacking from C's "generics via void pointer" approach, it does not come free of charge. For example, the code for sorting a list of integers in C++ may be comparable in size to the C one, but this is not the case if one is sorting various different types via templates; here, the fact that the compiler will generate what amounts to an entirely separate set of routines for each type can quickly bloat C++ code far beyond that of its C equivalent, and that may not be something that people working in (for example) embedded systems can afford. Of course, such tradeoffs between size and speed are as old as computing itself, and not something particular to C++.
"To my knowledge, the language contains two actual ambiguities, both of which are resolved by fiat, so to speak. One of these was inherited from C, while the other is new to C++ (though fundamentally similar to the one inherited from C).
My guess is that you aren't talking about those though -- and in fact, there's a pretty fair chance you don't even know what they are."
If you read what I said, it is obvious that I was talking about things that are ambiguous to people learning to write programs in C++, not ambiguities that compilers have problems resolving (which should be resolved by compiler writers, and never impinge upon people writing code in a language).
"There are a fair number of things many people misunderstand about C++, and many people call their misunderstanding ambiguities (or various less repeatable names) but that's a rather different sort of thing."
I am not referring to these as ambiguities (and my comment did not restrict itself to ambiguities as the sole source of problems for people learning C++). By "ambiguity", I am referring to symbols whose meanings change with context such as the "&" operator. Note that I do not include operator overloading here, as ambiguities that this may introduce are a matter of software design, not the feature itself (although the way the iostreams class overloads ">" does I think serve as a poor example of the way operators should be overloaded).
"I'm personally convinced that the concept of intuition applying to programming languages in general is pretty much nonsense as well. Programming is a learned skill, not a
"C++ is virtually a superset of ANSI C so I don't make the distinction between the two. C++ is C with classes, exceptions & rtti to me. The difference that exist are mostly irrelevant to modern programming. These days as far as most programmers or indeed compilers go, C++ and C are one and the same with a few switches to control stack unwinding or other behaviour for .c or .cpp extensions but little else."
.A partial list of incompatibilities follows (based on the latest standards, i.e. C99 and C++98) follows. You can find plenty more by Googling.
What you see is demonstrably incorrect
1) C++ has synonyms for certain operators such and "and" for "&&", "not" for "!", etc. and the macro preprocessor "knows about" them. These tokens could however be defined in a C program as having specific meanings other than those that are assumed by the C++ compiler.
2) Boolean types. C++ has them, C doesn't. Obviously, this can cause problems if a C program tries to define ones with the same names, but different values than the C++ ones.
3) Character literals in C are ints, whereas those in C++ are chars. Thus, sizeof('x') in C will return sizeof(int), whereas sizeof('x') in C++ will return sizeof(char).
4. in C, clog is declared in math.h as a complex natural logarithm function, whereas in C++ it is the standard error output stream declared in iostream.
5. The comma operator in C always results in an r-value even if its right operand is an l-value, while in C++ the comma operator will result in an l-value if its right operand is an l-value.
6. C allows literals having types other than primitive types (e.g., user-defined structure or array types) to be specified in constant expression, whereas C++ does not.
7. const qualifiers in C result in a variable that has external (static) linkage and therefore is visible to other modules; in C++, const items by default have internal linkage, and must be explicitly prefix by "extern" to behave as C const objects do.
8. C distinguishes between a function declared with an empty parameter list and a function declared with a parameter list consisting of only void. The former is an unprototyped function taking an unspecified number of arguments, while the latter is a prototyped function taking no arguments. In C++ on the other hand assumes both to be a function that takes no arguments.
I could go on and on, as there are around 50 known and documented syntactic or semantic differences between C99 and C++98. These do not include stuff that C++ has which are not in C, but are items that are nominally common to both languages, but which each compiler will see differently to the other, and therefore either choke on, or compile into code that does not behave identically. C++ is not therefore a superset of C, and anyone who compiles C code with it, or uses it to write code for a C compiler assuming that it is a C superset could be in for a very rude awakening indeed.
"Your DLL problems are a problem of Windows, not of C++"
To be fair, it can also occur on UNIX (a catch-all category which should be read as including Linux) with shared objects. But you are right in saying that this is not a C++ problem as such: shared libraries / DLLs are features of particular OS families that should not be specifically supported by a general-purpose programming language like C++.
NB: I share the general consensus that C++' handling of modularity leaves a lot to be desired. In particular, the loose coupling between headers and source modules together with the ability of any header to redefine the values of constants etc. imported from prior headers is both a potential and actual source of problems. I can understand C++ _supporting this_ for compatibility with C, but Bjarn should IMO have added another better system for use with new C++ code. If something like this had been done properly from the beginning, then they wouldn't have had to retro-fit name-spaces at a later date, because the module name could have also served as a name-space identifier, as was the case with Pascal and Modula-2, later borrowed by more modern languages such as Python and Java.
Indeed: even C code that compiles under C++ can have a subtly different meaning that can bite hard in the form of intermittent bugs that can be extremely difficult to trace. IMO this is actually worse than languages like Java and C#, which are C-like but don't pretend that they are either supersets or "enhanced subsets" of C. It is also the reason why most C programmers use a C compiler rather than a C++ compiler, and also why most commercial C++ setups ship with a C compiler that gets automatically invoked on modules with a ".c" extension.
NB: Objective-C is a true C superset in that it will compile standard C programs just as a C compiler without the "Objective" bits would.
"With C++ I can write one piece of code that can process pixels with 8 or 16 bit integer channels or 16 or 32 bit floating point channels. Fanboys of Objective C and Java are obviously not writing image processing software."
s . Could have found a lot more stuff, but can't be bothered just to provide even more proof of the fact that you are talking utter crap.
And C++ fanbois are prone to assume silly things about other languages from what somebody they agree with says about them. As an example of this, the fact that Java has templates seems to have escaped you.
As to image processing:
Objective C: http://en.wikibooks.org/wiki/OsiriX_Specification
Java: lots of examples here, as Sun's JAI (Advanced Imaging API) is specifically designed for image processing. Google is your friend.
People are also doing image processing in Python because it is used by lots of scientists, and image processing is something they do. And of course good old venerable C, which completely lacks all the "++" bits which you seem to think are necessary for writing any type of software.
"Without such important features as operator overloading, constructors, stack-based objects, and references, I really can't take Objective C seriously."
And these are necessary to write software because... Oh, that's right, you need a Turing complete language to write any conceivable piece of software, and what's that? A language can be Turing-complete without having any of these? What strange heresy is this?
"I can't imagine it being used for much mission critical software, that's for sure."
It seems you are incapable of imagining lots of things that exist, but that's your problem. For example, one thing that has escaped your imagination is the fact that C++ is far from being the language du jour for writing mission-critical software: the bulk of what can truly be classified as mission critical (i.e. extremely high reliability stuff where lives are at stake such as medical embedded systems, aerospace, real-time operating system kernels, etc,) are written in C or Ada, usually with a liberal sprinkling of assembler. How can this be when these languages lack all of those amazing features that you insist are necessary for them to be taken seriously? Is it possible that they are missing critical pieces of functionality that can only be implemented by using references to pass parameters? Maybe you should tell them!
"Obviously if you're writing a number crunching app, a game, a driver, a kernel, a shared library or something with high performance, low level or compatibility requirements then you need C++"
You don't need C++ for any of these things, because they can be just as easily written in C. In fact, C is usually a better language for these things than C++ because it is far more widely supported by other languages: C libraries can be used by (to name a few) BASIC, Python, Ruby, Pascal, Fortran, Objective-C, Objective CAML, Eiffel, Smalltalk, etc., etc., etc. By contrast, C++ libraries can be used by, well, C++.
Bjarn says he wants to make C++ an even better systems programming language. The way to do this is apparently by adding features to a language already groaning under the last batch, far from all of which have been consistently implemented in all (or even a majority of) compilers. None of these features seem to address the fact that as a systems programming language, C++ has most of the same shortcomings as C, while adding a few of its own:
1) It is no more portable than C. In particular, various fundamental data types are still dependent on the underlying CPU architecture for their size and format, leading to copious macro #ifdef sections in low-level code that must run on a variety of different systems.
2) Use of the extra abstraction mechanisms provided by C++ tends to result in code that is both larger and less performant. This is not a desirable attribute in a systems programming language.
3) It is already an extremely complex language that requires an extremely complex compiler to implement it. This makes it very difficult to validate, thereby rendering it useless for whole classes of systems programming tasks (e.g. high-reliability embedded systems).
4) The language is a mine-field of ambiguities, overloaded meanings, and counter-intuitive default behaviours that conspire to make it incredibly difficult to learn properly. There are so many potential pit-falls that even very experienced programmers from other languages have trouble writing high-quality code with it, meaning that the language is actually a source of problems in many projects rather than a mechanism for solving them.
It is thus not (as Bjarn claims) a "better C", at least in a systems programming context, because nearly everything it adds is largely superfluous to systems programmers, and comes at a cost that they are unwilling to pay. This is especially true in what is by far the largest segment of systems programming, i.e. embedded systems, many of which are programmed in _significantly simplified_ versions of C, not the goya-esque monster that is modern C++.
NB: it is very difficult to design a single language that is equally useful for both high-level applications programming and low-level systems programming because they have fundamentally different requirements. Systems programmers require precise control of minutiae, whereas applications programmers want something that lets them churn build quality end-user systems with a minimum of pissing around. C++ falls between these two stools, adding nothing useful to C's systems programming capabilities, while being so concerned with nit-picking minutiae that writing high-level applications in it is like scrubbing a very big floor with a very small toothbrush. It is IMO well-suited to only one notable application domain: games development, which is unusual in requiring a mixture of both low and high level code.
That's true of a lot of scientists and mathematicians, though.
"I've defending one of my retail stores twice with a weapon."
That's use of force, which you've said elsewhere you don't believe in.
"I only wish the thief took the time to threaten me rather than run off. "
So you could use force against him. Sounds like you're pretty enthusiastic about the whole idea of using force!
"My wife is hot, and she also has an impeccable aim. She took down a guy 3 times her size at a party who was violating her space."
Again, use of force, which you obviously revel in. It would therefore appear that what you're actually against is the use of force by others.
""How do you expect all these property rights you keep going on about to work without laws?""
"Mutual cooperation."
Which historically doesn't work in communities that are larger than a few dozen individuals because (a) petty jealousies and squabbles fuck it all up by splitting the single cooperative community into two that cooperate against each-other; and (b) said communities tend to get overrun by large collections of organised armed fellows who have discovered that taking what they want from little cooperative communities is both easier and a lot more fun that cooperating with them. It's been tried countless times throughout history, and it has _always_ failed unless the community was (a) extremely small and geographically isolated; or (b) had damn all that anyone wanted, and so wasn't worth bothering to attack and rob.
Modern anarcho-capitalism is not therefore a system based on any form of practicality at all: it is a survivalist fantasy land where cooperating groups of rugged individualists hold off Mad Max style bands of brigands who are never numerous, and don't have access to tanks or other advanced military hardware. Because they know that naughty people who would take from others and enslave them are too stupid to gather together in large numbers, organise themselves effectively, and use the very best military technology, which is why would-be conquerers like Alexander, the Romans, Attilla, Ghenghis Kahn etc. were routinely thrashed by small, rugged bands of individualists who mutually cooperated them into oblivion.
Region codes are not a copy protection system: they are a distribution control system that lets the movie industry say when DVDs are released into different markets, the content of those DVDs, and how much they cost. Region coding does not therefore fall under the DMCA, and bypassing it is not illegal; the actual copy protection mechanism for CDs is DCSS, and it _is_ illegal to bypass that (although doing so is trivially easy from a technological viewpoint).
"Everyone is running IBM architecture still today and Apple was screwed precisely because IBM missed a beat, it's design was reverse engineered and IBM's monopoly was broken by cheaper clones."
.NET whilst the development tools are fairly crap, the platform has the advantage that they could fix some of the crappy bits of Java."
.NET dev. tools being particularly crappy when compared with what else is out there. However, I do agree that they fixed some of Java's design flaws, thereby forcing Java to respond with similar capabilities. Hopefully, both platforms will continue to be heavily supported, as the existence of each is driving improvements in the other.
The point here is that they _were_ clones of IBM's system, i.e. they were simply riding on the coat tails of a monopoly, making essentially identical machines to said monpololy. And it wasn't simply Apple that got screwed: CP/M, Oasys, and a bunch of other successful operating systems were simply swept aside to be replaced by what was initially an inferior operating system. This is why I keep saying that what we are living under now is the _same monopoly_ that IBM established: it is irrelevant who makes the computers themselves, because they are simply continuing a legacy that the old IBM monopoly established: they still have ROMs with reverse-engineered code in them that emulates stuff in the original IBM PC and AT; they have CPUs in that are capable of running that ancient instruction set; and they use an operating system containing bits that can trace their roots back to that first IBM PC DOS.
"Microsofts entry into the server market was obviously an attack on Unix and they have gained much ground helped by the ever faster x86 architecture and cheaper wintel pricing at the low end of the market."
Microsoft's initial entry into the server market was with XENIX, a UNIX for X86 systems that the original SCO (i.e. the one that is now Tarantella) wrote for them. There were also a number of other X86 UNIX implementations that came before Windows/NT, and like other UNIXes, were mostly used as multi-user systems running text mode applications on arrays of dumb terminals. Windows/NT was a very different beast to that, and targeted a completely different market, i.e. those with networks of PCs who wanted a centralised repository of shared file and print services. The only cross-over point was the now mostly defunct UNIX workstation market, which NT did target; however, one could easily argue that it was ever more powerful and cheap graphics cards driven by the PC gaming market that really sounded the death-knell of these incredibly expensive machines, not anything Microsoft did.
" lot depends on if Microsoft can keep the target moving fast enough. I think with the OS this is hard as I haven't seen much innovation coming from osX that they can steal, possibly document sharing and collaborative working in Office 2009 might keep them ahead of the game for a bit longer."
Innovation and newness are largely irrelevant when you earn money from 90% of the computers being sold anyway. Vista will be the first major overhaul of their core OS since XP was launched in 2001, yet the much more regularly updated Linux and OS X systems are still unable to make much of a dent in Microsoft's desktop dominance. They therefore do not need to stay ahead of anyone to succeed, because people are still buying what is now is now a rather old product in computing terms, and one that has garnered an immense amount of bad publicity from massive and often extremely damaging virus and worm outbreaks.
"And then of course there is
I've not noticed the
"I'm not sure you could say a move to opensource would form a completely new monopoly"
I wasn't really thinking about open source, but rather companies such as Google, who (if they did displace the existing "children of IBM" monopoly) would be doing so via a technology that was not even a consideration when the existing monopolies became entrenched. For that sort of
"Ok so we switched from a hardware monopoly owned by IBM to an Operating System monopoly owned by Microsoft. I fail to see quite how this is the same monopoly, unless you define whatever the current monopoly in the IT industry is as the same monopoly."
We did not switch from anything. Nearly everybody is running Intel CPU instruction sets because IBM selected Intel's 8088 for their PC, despite the fact that it was a dreadful processor when compared with the competition (already well established 8 bit CPUs such as Zilog's Z80 were at least as performant, and a _lot_ cheaper, while virtually every one of the newer 16 bit processors was superior in every respect, and comparable in price). We are likewise running Microsoft software because IBM selected Microsoft as the OS supplier for said PC. Again, the OS itself was basically a piece of junk that nobody would have bothered with if it hadn't been part and parcel of a PC with IBM written on the box, yet it ended up dominating the market. The emperor may have changed, but it is the same empire.
"As I've already mentioned I think large multinationals and government may start demanding an open document format for future compatibility reasons"
The odd government may, but multinationals will continue to use MS software unless there is a 100% reliable mechanism for converting all documents. Less that 100% means that (a) they will have to continue using MS software with some of their legacy data, and (b) they will be faced with maintaining two formats, which is costly. They will therefore stick with MS because it is cheaper and easier.
"If MS falls into line then the monopoly is already heavily crippled."
Not if "falling into line" means perfect imports, but feature-crippled exports. Microsoft's core corporate market thus gets the ability to handle any OpenOffice documents they may be sent, while remaining locked in to Office formats for their own data. Net change: zero.
"The lock in to VBA-backend databases is more of an issue but I think you exaggerate the usage of this."
I am not exaggerating anything. Custom MS Office development is extremely common in business settings, and not only for in-house stuff. There is a substantial third-party industry whose products are written in VBA for sectors such as company admin, medicine, law, accountancy, video and car hire, and a host of others. It is not only an extremely cheap and easy way to develop software, but also one that is amenable to significant end-user customisation without needing to learn programming, and that makes it a popular application platform for businesses of all sizes.
"A business could still mandate all normal word documents are saved in an open document format but allow MS office VBA applications."
Why would they bother to do that if they are locked into Office by VBA, macros , etc.? They'll still have to pay MS for Office licenses, so where is the _business case_ for such a policy?
"Microsofts strength has always been seeing another companies new idea, cloning the technology and adding it into the windows portfolio."
Microsoft's strength has been their ability to take ideas that others have developed, and implement them in a way that fits in with their corporate goals, which are basically to ensure that Microsoft customers remain Microsoft customers. And this is what they will do with OpenDocument if they are forced to adopt it: all they need to do is make it both a bit inconvenient to use, and feature-poor when compared to their own formats to ensure that most users won't bother with it.
"As you are probably aware some governments *are* now telling microsoft that they might switch to a different office suite unless MS support an open document format in MS office"
But none have actually switched yet, so MS are far from being in a position where anyone substantial can force them to do anything. And they're fighting this on several fronts: they are seeking ratification from standards bodies for their new Office XML format, and
It's actually amazing how stable and solid that foot under the iMac is. The great big slab perched on what looks like a base that's far too small for it gives the impression that it would topple if you breathed on it hard, yet it's actually rather more stable than some monitors I have that are on what appear to be much more substantial stands. It's quite an impressive bit of engineering.
NB: the Apple attention to detail seems to rub off on Mac peripheral manufacturers too. They seem to be better thought out and are often built to a higher standard the equivalent stuff for PCs, which all too frequently seem to come in incredibly ugly plastic or folded sheet metal cases with extremely cheap and nasty connectors. Of course, this often means that a Mac peripheral costs more, but they are often so much nicer that I've started buying them for my Windows PCs as well as the iMac (most third party Mac peripherals come with drivers for Windows -- Macs on the other hand don't seem to need specialist drivers that often).
And thus do I secure myself at least an MBE in the 2006 New Year Honours List...
What makes you think that politicians would suddenly become wise and considerate if they had the power to pass any law they wanted, and make it stick? If that were the case, then totalitarian regimes would have by far the most carefully-considered and fair laws, because they do not have a review process of any sort.
Quote from the original subject: "The change in Intel's brand is the first step in a $2.5 billion _marketing campaign_, BusinessWeek reported earlier" (emphasis mine).
This is a piece of business news, not hardware news. That's why it's in BusinessWeek, and mentions things like stock prices and what executives had to say, while completely ignoring what Intel actually make. They could be a manufacturer of hamburgers or hammers, and the story would be equally applicable. This one should be under the general "IT" category, not hardware.
Come on, be fair. The government was just acknowledging the fact that imbibing extremely large quantities of beer makes the idea of being nuked to death look far less bleak than would be the case if one had to face that same prospect while sober.
How does a new company slogan get lumped in under the "hardware" category? It is a marketing-related topic that has no more relevance to hardware than a new McDonalds slogan does to nutrition. Who edits this stuff?
Same here. I have an iMac G5 sitting among various other computers, and nobody ever notices the others at all: they are invariably intrigued by the Mac's looks, screen, generally quiet operation, and how it has "a much nicer Windows" than the one that came with their own PCs.
It's certainly a possibility. However, I think a more likely explanation is that the XBox is their hardware design, so they _know_ a TMP module is there, and can use it pervasively throughout the system software and firmware. This will not be the case with Vista, which MS has already stated will not require the presence of a TPM module, and I believe them, because they want lots of their existing users to upgrade, including corporate users, and only a very small proportion of existing hardware has a TPM module.
Consoles on the other hand have always been more heavily locked down than PCs, and the primary reason has nothing to do with piracy. The main source of income for a console manufacturer is the royalties they earn from games written by both themselves and third-party developers, hence the fact that some are willing to sell the console itself at quite a substantial loss for a fair while. To ensure that third-party software developers and distributors cough up their royalties, the manufacturers make it as difficult as possible to run "unauthorised" software: if you want to write a game for that platform, you need to negotiate with the manufacturer so that they will get their cut. That's why Sony etc. get so nasty about mods that let people bypass their console's protection mechanisms: enough people with modded consoles could spawn en entire industry of third-party games that the console manufacturer earns nothing from, thereby invalidating their entire business model.
With the above in mind, I'm pretty sure that MS are not in the least keen on having hackers bust the protection on the XBox-360. They are however realists, and know that there are a lot of people out there for whom a new and tough protection system is a far more entertaining challenge than any game could provide. If the console is as successful as MS obviously hope, it will therefore end up being attacked by thousands of hackers who can use the Internet to pool their knowledge, and Microsoft's engineers are savvy enough to realise that any automated security system can be broken if enough people with sufficient skill are determined to do it. They have also learned from the past that it is far better to admit this publicly than pretend that a system is unbreakable, because even a whiff of the word "unbreakable" will get armies of hackers thrashing away at the thing just to prove them wrong, and gain the kudos of being the first to break the "unbreakable" system.
Being overpriced (in the eyes of consumers) was definitely a factor, but then most consumer electronics are overpriced at the beginning, and are only bought by enthusiasts. And MiniDisk players did drop in price over time (although their media didn't, or not by much), and were subject to many promotions with hefty discounts (I remember several). They still didn't sell in significant numbers, and my conviction that DRM had a lot to do with this comes from a notable personal experience.
I was looking at a MiniDisk recorder in a UK dealer during the mid 90s (I no longer live in the UK), when a spotty youth who was in the company of several similar items said something like "I wouldn't buy one of them if I was you, mate. My brother bought one, and it won't let him record _anything_. They're crap". The assembled youth similies nodded and muttered in general consent ("crap", "total crap", "crappy", "fucking crap", and variations thereof).
Note that as is usually the case with rumours, this one had grown in the telling. It was likely that the brother's MiniDisk system had been difficult about recording _something_, and this had rapidly metamorphosed into _everything_ during re-telling. But this is the same process that drives rumour mills the world over, and which every consumer product from cornflakes to cars has to cope with. If the general consensus down the pub is that product X is "fucking brill!", local dealers sell lots of X; if they say it's "a pile of shite", it sits there on the shelf.
The increase in quality did not offset its limitations in the eyes of customers. As I said before, people will not accept something that is better in some areas than what they already have, but imposes restrictions in other areas that they are not accustomed to. If MiniDisk had been marketed as play-only personal medium that used cheap little players with cheap little disks, then it might have taken off if there was enough content for it. But Sony marketed it as a recording system that was better than tape, and then tried to stop people from doing tape-like things with it. It flopped and is no more, just like DIVX, and DAT-based music recorders, and a whole bunch of other "do what we say" technologies.
"I think you are unnecessarily pessimistic."
I really do hope you are right. However, 25 years in the computer industry has taught me that it is prone to being dominated by massive and overbearing commercial monopolies. The name of the monopoly may change (it used to be IBM, now it's MS, but they wouldn't be in that position if they hadn't been in bed with IBM when it was the big, bad monopoly). And these monopolies persist even when governments take action to try and thwart them. Group Bull for example was heavily funded by the French government in an attempt to break IBM's stranglehold on their computing sector. All government procurements were from Bull; heavy subsidies allowed Bull to undercut IBM in virtually every sector; yet despite this, IBM's share of the French IT market kept getting bigger and bigger.
"I wouldn't understimate the effect of price, most people do not like paying for things if they can get by with something free!"
People opt for what they think offers the best value, and this is not necessarily the item with the lowest price. The fact that MS Office has a user base which dwarfs that of all other similar software combined (including both commercial and open source offerings) would seem to indicate that most of the people who want office productivity software consider that the MS version offers better value than any of the others, free or otherwise.
"Most peole would also be happy with MS Office 5 years ago from a functionality perspective."
Indeed, as is indicated by the fact that people don't upgrade Office anything like as often as MS would like. There is actually a significant proportion of people still using Office-97, because it does what they want and they see no reason to upgrade. Note though that they are sticking with an obsolete version of Office, not switching to OpenOffice.
"Also, most people don't use VBA(or even know what it is) nor do they access databases from office files."
You are wrong about this. Custom VBA Office applications, Word and Excel macros, and stuff that uses MS Access (often as a front-end to corporate RDBMS systems) are very common indeed in both business and government environments, which are precisely the ones where MS is most entrenched, and from which it derives the bulk of its profits. If OpenOffice cannot migrate or at least handle this sort of thing, then it will remain forever on the sidelines, because every small business and individual who has to deal with these corporations will stick with MS Office rather than risk going with an at best only partially compatible alternative.
"If some goverments/countries switch to OpenOffice it's likely some companies will also switch to OpenOffice."
See the example of IBM and Group Bull above. Some may switch, but most won't, because dealings with government are usually handled by specialist departments in companies, and they frequently use different software from the rest of the organisation. This will even be the case for government contractors, who may well use OpenOffice for exchanging documents with the government itself if that is a requirement, but continue to use MS Office for internal stuff, communicating with suppliers, etc.
"Microsoft may be unsucessful at blocking OEMs from installing OpenOffice/StarOffice on new PCs in the wealthy west too.
Once one OEM rolls out free unlimited office suites there is going to be more pressure on the others (OEMs even on Dell)."
None of which will affect big businesses at all, because they buy their PCs without operating systems or software and install Windows etc. from disks that MS supply as part of bulk licensing deals. And if the big businesses are still using MS Office, those who deal with them will have to use it too. So the only people who will end up bothering with a pre-bundled version of OpenOffice will be those who probably wouldn't have bought MS Office anyway, i.e. pretty much the situation we have now.
"Once upon a time no one thought IBM would lose it's dominant position ei
"They had a "non-fragmented" market back a handful of years back. Dell tossed it to the curb, most likely due to pressure from Bill and Co. only months after doing it. "
/. MS conspiracy theory.
Where is your evidence for the fact that this was due to MS pressure, and not simply a case of a corporation changing their strategy to one that they think is more profitable? IMO the fact that Dell exists solely to make profits would seem to indicate that this is in fact the most likely explanation, not your typically
"And don't go and tell me "fragmented"- what are the main distributions?
Red Hat
SuSE
Debian
Slackware
Mandriva"
Running which window managers and desktops? Using what versions of the Linux kernel, GNU tools, compilers, and core libraries (they vary, even with distros released in the same time frame)? Oh look, two different package managers! A whole bunch of different menu structures and categories -- where do I add the entry for my system? Gee, they've just released a new version of distro X, and it's got new core libraries that break my app. Now I've got to resolve it so I can field support calls from all four customers on that distro.
"XP Professional
XP Home
Media Center
2003 Server
Vista(Eventually...)
Each of the above setups realistically, with the exception of XP Home/Professional, have ever so slightly different hardware requirements and available driver profiles."
But the same compiled app with the same installer will work on _all_ of them. And I can write that app using some pretty old development tools and libraries too: my commercial Windows dev. tools haven't been upgraded since 1998, and they still produce executables that run perfectly on not only the versions of Windows you list above, but also Win95, Win98, and WinME. This is not the case with Linux, where applications can easily fail on slightly different versions of the same distro. And don't try blathering that this isn't the case, because it has happened to me, and to a number of other people I know on many more than one occasion.
"Each of the above setups realistically, with the exception of XP Home/Professional, have ever so slightly different hardware requirements and available driver profiles"
None of which matters to commercial software authors, because it is easy to write an application that will install and run on all of them. Hardware designers will target drivers at whichever versions they think will be profitable for them, and not the others. Windows-95 has already slid off the radar-screen, and Win98 is rapidly going the same way, yet these two "distros" between them still account for around 25% of the total Windows user base, i.e. at least ten times as many people as all the desktop Linux users combined.
"Gee... Seems they have the same level of "fragmentation" and not all hardware can be realistically supported with each version- some drivers really only work with 2003 server or XP only, etc."
You are missing the fact that there is a massive difference in scale. Each of those Windows versions (with the exception of Vista, which hasn't been released yet) has orders of magnitude more users than all of desktop Linux combined. Thus, the (actually rather slight) differences between Microsoft distros divides a user base of tens or hundreds of millions into four or five _mostly_ compatible segments, whereas Linux is dividing at best one 20th of that base into several in some cases rather incompatible segments. Add to this the fact that hardware and software developers can get all their tools, SDKs, documentation, and support from one company, and you have a situation where it is actually cheaper and easier to target tens of millions of Windows users than a few desktop Linux users.