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).