Hapax legomenon
Something seems to have gone a bit wrong with the editing of this article, as there's just one mention of "Malin", a name I assume, that doesn't seem to be explained anywhere else.
16 publicly visible posts • joined 18 Feb 2007
If you're red-green colour blind, won't it look monochrome anyway?
A few years ago I was involved in a project to design human-distinguishable bar-codes. We used colour for "bling", but chose the palettes so they were distinguishable with monochrome vision (and any combination of colour blindness). Red and green are so widely used for stop/go good/bad that I think it's hard to argue for another default (especially when they're combined with other cues such as the positioning of traffic lights or ticks and crosses, widely used in terminals.
What *would* be good (but take a lot of work in the physical mark-up world of terminals) would be role-based colours à la CSS, so that users could configure their palette in a way that would make sense across a wide range of terminal apps.
In the mean time, colour should never be a crucial element of any terminal program's output. Not just for those not blessed with full colour vision, but because one of the great things about terminal is copy and paste, and one can't rely on colour coming too, so anything copy-and-pasted mustn't lose meaning for being stripped of colour.
Isn't "code cleaning, code refactoring" meant to ease changes? Or are they saying that they haven't done enough? There're plenty of changes that one can imagine being well-received; unfortunately, most of them are probably in the long tail of features that will delight a limited number of users—in my case, support for MS Office bibliography objects, the main thing that is keeping me on MS Office for academic editing work.
I have on three occasions found that Apple hardware was the best value for money for the spec I wanted at the time: 2008 Mac mini (small quiet reasonably beefy desktop), 2011 MacBook Air (lightweight reasonably robust laptop), 2014 MacBook Pro (laptop with lots of memory and powerful CPU).
In other cases I've bought PC hardware: Samsung NC-10 (small cheap laptop), Tranquil PC ixL (replaced the Mac mini).
Previously, PC laptops with similar specs to Apple models were more expensive, or didn't have as good support for GNU/Linux: the popularity of Apple kit with GNU/Linux users means that Ubuntu has specific support, and drivers and workarounds for problems were typically straightforward to find; I probably wouldn't buy Apple for the desktop currently, as they have no models with no moving parts.
I recently switched my Lexmark X543dn to remanufactured cartridges. (Lexmark lost a case under DMCA not long ago, so 3rd party cartridges are now available.) Roughly ¼ of the cost of the originals (£15ish vs £65ish). Easily makes up for the loss of the "rewards" programme, which, like you, I didn't get a single "free" cartridge out of (mind you, my printer's 6 years old, and I don't print that much).
That does explain why BBC Radio 3's newsreaders are so much quieter than Radio 4's: I'm guessing that R4 is compressed simply because it's mostly speech, in a fairly small volume range). It does make R3 news sound peculiarly personal, though (it's the delivery, not just the volume). It's "I say old thing, have you heard..." vs "HERE IS THE NEWS".
The upgrade is all very well, only the new network manager is basically undocumented, and crashes precisely every second invocation for me, which means I can't use it; the new kernel won't suspend and resume on my laptop; and the new configurationless X.org has some serious problems, not least of which that the keyboard and mouse configuration preference applets no longer work (again, at least for me) so that I can't set the keyboard auto-repeat rates or mouse acceleration, without first restoring my X.org configuration file, and adding a magic "please don't autoconfigure" commmand.
So in sum, I had to reinstall the Hardy kernel, I can't use the new network manager, and I can't use X.org without configuration, which adds up to oh well, at least I get fixes to lots of bugs that I filed over the last six months.
I had already been recommending non-technical users I know to stick with Hardy, as it works well, and is sufficiently up-to-date for most general use purposes. This only makes me wonder if I should have taken my own advice.
I'm amazed that no commenter, let alone the article's author has made the point that XML is not text. It's simply most commonly represented as such. I presume that Google, having clever people, have other reasons for using a non-XML binary format. I can certainly imagine some: using a language designed to represent objects makes it much easier to give type guarantees, and their protocol buffer scheme might well make guarantees about the performance of the code it generates. The fact that it's not XML is interesting, but it has nothing to do with its use of binary formats.
Why the insistence on ICT? The only reason I can see is that this is about pork-barrelling as much as it is about older people. What older people need, what anyone needs, is innovative products, services and systems, not "innovative, ICT-based products, services and systems". The sooner we as a society get over our infatuation with ICT, the better. (Of course, as ICT industry enthusiasts, we have conflicting interests...)
A word making the OED is not news, it's statistics. The OED is no académie-driven Grand Robert, it's a descriptive dictionary; a dictionary of record, if you like. Its authority is scholarly, not prescriptive, and thank goodness; the lack of an « English Academy » is one of the reasons English is such an adaptive and vibrant language. (What a thought: English is run like Wikipedia! Maybe we should all switch to French after all...)
The article misses the point in a couple of ways:
"The real stomping ground of Mono is undoubtedly Linux" Actually, it's open systems. You noticed that on Mac it works fine with all the standard, open APIs (meaning most non-GUI functions, plus GUIs under X) but not with the proprietary and Mac-specific Cocoa. You then derail completely: "any efforts expended in terms of building a more feature-complete implementation of Cocoa# would, in a sense, be wasted effort from a portability point of view since Cocoa" well, no, it wouldn't be wasted, because then Mac users would be happy to run Mono GUI apps, and you've already correctly observed that they won't run apps that don't look native. And "What’s the point in writing your application using an ECMA certified, platform-neutral language when all you’re doing is making calls to a proprietary, platform-specific toolkit?" okay, so let's give up writing in C, because all we'm doing is generating proprietary, plaform-specific instructions. Seriously, this is a major part of the point of Mono: you can write one app, and it will run on Windows (where it is simply calling proprietary, platform-specific APIs) or Linux (where it is calling platform-specific APIs that may be open, but certainly aren't as neatly standardised as Mono's), or whatever other system you're on.
And then this: "I expect some pundit will be along soon to assure me that if I just added a couple of lines of gobbledegook to this config file". Why didn't you ask whether Apple could make X work decently? A rootless X server that starts automatically when required would remove all the objections to running X apps under Aqua except for the "look-and-feel" one, which for many programs is enough.
Finally, to describe Cocoa as proprietary is not entirely fair, and you didn't mention the obvious riposte of the Mac-centric open source development, namely to use GNUStep. Read this article, for example:
http://www.macobserver.com/columns/devilsadvocate/2003/20030606.shtml
Finally, your conclusion: "in terms of how/where they fit into Mac development, I think it’s time to step back and re-evaluate where we’re going." is nonsense. It fits in just like it does on any other desktop platform, and it's obvious where we're going: eventually, Mono will work fine on Mac OS. What seems to be lacking is sustained effort in that direction. All that's needed to get there quicker is more effort. Apple could help if they wanted, and, as for any minority platform, it would seem to be a big win: they're far more likely to attract than lose devotees by such a move. Equally, more Mac developers could get involved. Like most OSS projects, this one will stand or fall in the straightforward market-place of development investment, wherever it comes from.