ncw33

The difference is that most/all sugars are not inherently harmful, and we believe that they can be consumed safely at reasonable doses. A bit of glucose or fructose won't kill you, and is a (small) natural component of your diet. So banning sugar would be rather hard, compared to complex toxic chemicals which can't be processed by our bodies, decay slowly, and where we really have fairly limited reason to put in products.

What rewrite? Switching to python3 is a quick (almost entirely automated) process. It's really not a big problem.

How dedicated to keep it going so long! Maintenance this long-term is a time-sucking activity.

Very impressive stuff. We should see more and more of this sort of assistive technology, to alleviate and improve on the manual labour of programming. This isn't a language issue, although perhaps this sort of branch annotation in production systems is the sort of thing a futuristic language runtime might offer.

That's a different field entirely. Just because some American hospitals have trouble organising medical ethics reviews, does not mean that European or even American CompSci researchers will run into the same problems. Indeed, Daniel is (I think) positive perhaps based on good interactions with the ethics committee here (my wife is certainly happy with the ethics reviews she's had).

Even in that SSC discussion linked, many SSC commenters agree that their own ethics system was far easier, even in medicine.

Good work, Daniel. A laboriously-gathered overview of current practice, and discussion of how to determine whether uses of illegally-obtained data are justified.

Brilliant spot! I hadn't read that in the local papers - there was simply criticism of the 'boxy' design. I live right by that station, and used it for the first time this weekend (only a few days after it opened) and my wife and I commented on the attractive appearance of it.

Despite some controversies (are there enough ticket machines, enough toilets, enough train services, and so on...) Cambridge North is going to become a popular station.

Why should it bundle the kitchen sink - I wouldn't expect all codecs to come with their own container format! You can put it in Ogg or use its own more-limited native metadata handling.

It's good for the library to be robust, but four code cleanliness issues (not triggerable remotely) hardly counts as news in the world of vulnerabilities!

Keep them coming, I'm glad that so many of us who use mbedTLS are reporting these little issues and getting a better library (with an excellent track record of very few serious problems).

It is possible already - you can do `command 2>&4` to separate the output from one command in a pipeline into its own stream, then do `command2 <&4` to pull from the further down the pipeline.

I agree, Cassandra is doing here exactly what I (as a user) would expect.

When using a DB like C*, you always have to ask yourself, "does this update happen before or after this one - have I done anything to ensure that's the case?"

In this example, the second query (the UPDATE) is being partially applied before the first query (the INSERT) - and that's OK, because there's no ordering or dependency in the second query that forces it to run second. So the reordering of the queries that he's observing is legal, and can be simply avoided with "UPDATE ... IF revision = :last-rev".

Not much! Just a few bytes for each packet. Running a NAT service requires a big table of all the active connections, ie. it's stateful - IPv6 with no NAT needs no per-connection state in the router so that's a big space-saving.

If Thomas has enough time to finish it (bearing in mind the hundreds of hours it will take to bring it to production quality) - and if he has time to maintain it over the years - and if he is able to commit to years' worth of future maintenance - then this could become a very nice and usable implementation.

I think it's great when people write something for the love of it.

For a high quality TLS implementation that is production-ready, and has had extensive third-party verification and certification, I'd recommend mbedTLS from ARM.

In no so many words, the article is pointing out that O(n) + O(1) is not necessarily quicker than O(n) + O(n): both add to O(n) (since only the highest-order factor matters), and the constant factor is unsurprisingly better for array lists.

He's not benchmarking an O(1) operation against an O(n), or anything surprising, or even pointing out a "hidden" O(n) operation, it's simply a demonstration that O(n) + O(1) = O(n).

Insertion into an array list at a uniformly-distributed location is always O(n): you can't avoid moving half the list. Appending is amortized O(1).

Indeed, I clicked on the link because I thought, "That's interesting, I wonder what a Q-tip is". Then I found it was just another name for a cotton bud, and was disappointed: I'm sure there are more bizarre items than that!

Actually, the patch was announced before the details of the bug: I subscribe to the libpng mailing list, and got about a day's notice to ship the patch out before the CVE and associated details were widely publicised. They did a good job of notifying us quickly, before there was chance for the 'bad guys' to jump on my customers.

Nice, but I'm still waiting for 64-bit integer arithmetic!

For our use case, what I like about this is that we can continue to use emscripten and the technology will come to us, rather than requiring app developers to invest in yet another technology (our switchover from NaCl to emscripten was very time consuming!)

So basically, lots of big publishers are really upset that they don't know where their traffic is coming from. They were previously uncategorised because clicking on links from the Facebook app doesn't add a Referer.

Then someone noticed that the Facebook app sets User-Agent to something very obviously Facebook-y, and this is the "breakthrough" in tracking Facebook clicks.

Why post a link to that here? systemd is not perfect, but it's a well-designed and competent piece of work that makes things better for users, developers, and admins. It's been adopted by most distributions now, which must indicate merit. As a developer and user, on balance I'm delighted by the Debian Foundation's decision.

I have to say, without knowing any people involved with Apache, hindering projects from moving to git for any reason is hard to fathom. Why _wouldn't_ a new project use git? In the old days of subversion, anyone wanting to commit to a project had to send in patch files, and only the project's maintainers were allowed the luxury of saving their work each day in a convenient fashion by committing it on a branch.

To the younger generation, not using git for a new project (or similar VCS) can look like you don't want outsiders to contribute. If older bodies and projects don't recognise that, they risk not getting patches sent in. The difference between forking and making a pull request, rather than working out how to format a patch file according the mailing list's conventions, is the difference between becoming a contributor, or not bothering.