Umm... what? So nobody should develop for Android because people with Android phones are cheap bastards? This kind of subjective, offensive, blanket generalisation is exactly what draws accusations of butthurt amongst the iOS crowd.

I propose an alternative: coffee shops should focus on selling good coffee, and they will get my money by selling me coffee. These brand-specific apps are PR; they provide advertising, spread awareness and recognition through word of mouth, encourage customer loyalty, so on and so forth. If a coffee shop expects me to pay them for that, they can shove it, quite frankly. Being able to pay for coffee *via* an app could be interesting, especially if it makes the process quicker and more convenient, but paying for the app itself? No thanks.

I think you misunderstand what is going on here. Server push is basically a way for sites to pre-populate a browser's cache, by sending it suggested requests for things it doesn't yet know it will need ("push promises"), and the responses to said requests (the pushes themselves). If the server pushes responses to requests that the client never actually ends up making - not even to the extent of pulling the data from its local cache - then the pushed data will never be processed.

Unless you are sitting on an unpublished proof-of-concept, the only malicious use I can see is filling up the cache of a poorly written browser with nonsense. This is already feasible with HTTP/1.x via any number of means.

To inject unsolicited, *processed* (as opposed to cached then ignored) data into a browser using HTTP/2 server push, an attacker would also need to control some resource which the client has already requested, and manipulate it in a way which results in the client needing to load the pushed resource. I don't see how this is any less onerous for an attacker than hijacking an HTTP/1.x resource: that initial hijacking, be it by XSS, rooting the server or any other already-extant method, must still be performed. In fact using HTTP/2 push arguably complicates things, since being able to inject the push itself implies either complete control over the server, or a hijack of the entire session!

Sure, the implementation of the feature itself in any particular HTTP/2 stack could be buggy, but so could anything else.

Continues to work fine for me, too, with systemd. This is one of the things I love about Gentoo: since their packaging policy is, by-and-large, to just take upstream code and provide a sensible way of building it, you can - within reasonable bounds - pick and choose exactly what goes onto your system.

I run Gentoo with systemd on the desktop, and Fedora - hence also systemd - on my laptop. The former is just expected to get through the occasional clean boot & shutdown; I think the most "advanced" feature I use is on-demand mounting of a network share (CIFS). The latter seems to sleep & wake just fine, meaning quickly, reliably, and upon the expected events.

What part of his tweet constitutes telling Christians that Christmas is "bullshit"? The part where he celebrates Isaac Newton's birthday, or the part where.... Oh, wait; that's the ONLY part. It is not mutually exclusive with celebrating the birth of Jesus, and nowhere in the original tweet - or the following explanation - does he imply that it should be.

Should the world at large be banned from honouring the memory of anyone else on that date, just because it happens to be a Christian religious festival? Sounds remarkably like religious discrimination to me.

My general take on this is that things like Cinnamon & MATE were knee-jerk reactions to GNOME 3 created purely for design reasons, with no real technical backing, and no appreciation for the amount of work which actually goes into creating a complete, properly integrated desktop and toolkit. Unsurprisingly, despite looking pretty, reports continue to crop up about them not quite working right. I'm honestly surprised MATE is still going, and whilst I wish them luck, there *were* real technical problems with the GNOME 2 underpinnings - I understand the desire to have something that is simply "GNOME 2's UI built with GTK3", and part of me wishes that had been available as an option on GNOME 3's release, but creating something reliable and maintainable into the future requires more than just hacking away on the same old code. My own personal take on Cinnamon is that it's mainly running on inertia, having built up initial popularity mainly as a function of when it was released, when Unity and GNOME 3 hatred were simultaneously peaking.

GNOME Shell does work. You may not like it, but from a pure technical standpoint, it does what it is designed to do. In terms of alternatives, I'm interested to see what - if anything - eventually becomes of Budgie and Pantheon (used as the default desktops in Evolve OS and Elementary OS, respectively, but - I believe - available for installation on other things), which are written as Mutter plugins, i.e. the same underlying technology as GNOME Shell itself. IIUC, writing Mutter plugins is the "correct" way to create alternative shells based on the GNOME 3 stack without actually forking anything, if what you want to do is outside the scope of a GNOME Shell extension.

Doesn't sound like that much of an edge case to me. These things may only need to be downloaded once on a given machine, but I assume that almost everyone who does so, does so via a browser. This sounds quite plausible to me without the need for exaggerating about using the browser "exclusively" for this purpose.

Also, GP was giving this as an example, not as the one and only case in which malicious ads get through AdBlock.

What, you mean a business model in which they expect people to actually pay in order to use something, on the Internet!? Outrageous!

In all honesty, whilst it is refreshing to see a business plan slightly more concrete than the usual "1. build a huge client base, 2. ????*, 3. profit," I can't help agreeing with you. They won't succeed without offering something very, very compelling compared to the existing offerings, and what makes the existing offerings compelling derives from the fact that everyone is already on them - hence the larger they get, naturally, the harder they become to replace. Does the average punter really find data sanctity and lack of advertising compelling enough? Clearly Ello themselves don't even think so, or they wouldn't have the concept of a basic free account. Also, starting up with an invite-only model seems to me to be based on a fundamental misunderstanding of what makes a social network tick.

* Usually translated as some combination of get acquired, sell ad space or sell user data

Er.... what? Neither TFA nor the summary make any mention of the GUI, nor advertisements. I suppose you started with the premise that the NHS did something IT-related, automatically assumed it must be bad, and then just started randomly making stuff up.

Duck season!

Yep - anyone who's ever composed music using a tracker should be familiar with this.

Hear, hear! Well played. If only I had some mod points.

This; a million times this. The problem is exacerbated by the long-running trend towards computers as consumer appliances, instead of specialised tools. I grew up coding in BASIC on an Acorn Archimedes, which was state-of-the-art at the time; when my family finally "upgraded" to a Win98 PC, the second thing I noticed (the first being the massive jump in performance) was the lack of printed reference manuals and built-in development tools. When I was at university, the teaching language was Object Pascal (via Delphi), I had a vague knowledge of Linux due primarily to the social circles I moved in, and I eventually ended up doing the bulk of my work in C++ on Solaris for the simple reason that the UNIX labs on campus always had plenty of free machines (which could not be said of the Windows labs). This rekindled my love of plain-text editors and the command line, to the extent that I still bind F12 to spawn terminals on my Linux machines (any RISC OS user will know where I'm coming from ;) ).

Had my background and social set been different, I could very easily have graduated knowing only how to do RAD on Windows via graphical IDEs. Not really fitting for a comp sci course with software development modules.

Spotted this over in the Ars sidebar:
http://arstechnica.com/gaming/2013/10/foxconn-admits-to-pushing-interns-into-overtime-to-build-ps4-parts/

If you're worried about the nebulous, evil effects of HFT affecting your order price between entry and execution, why enter anything but a limit order?

Then my point still stands - if you enter a limit order, an HFT algorithm can't make money by raising the asking price then selling to you higher than you expect. Firstly, there's a limit price on your order; secondly, how is the algo supposed to raise the asking price without buying something? It makes no sense to buy high just so that you can annoy someone else, because the algo still ends up selling to them for less than it bought.

I think you have it backwards. Unless you are entering an at-market order, your order will be executed at the price which it is originally entered. So an algorithm which "bids up" the price, which it can only really do by entering an order with a higher execution price (just entering high quotes makes no difference if nobody executes), then executes a sell to you at your (lower) bid price, will *lose* money.