rciorba

I assume you're thinking of Tick-borne Encephalitis

This is not in-kernel eBPF, this is a userspace eNPF runtime, so I don't see why it would pass fewer boundaries

Because it's an implementation detail, not a change to the language itself. Similarly, when they re-implemented the dict type to preserve insert order, they also introduced it without a pep, because it was a side-effect of an implementation detail. Only later they decided people are so likely to depend on this, that they formalized it through a PEP.

I read the first Dune books in Romanian, then re-read the first one in English, and I was amazed at how nice the translation was. I actually prefer it to the original. For example, stillsuit sounds really basic, but distrai, a portmanteau of "a distila" (to distil) and "strai" (old word for clothes) lands differently for me.

And the Galaxy S5 that came after it, still had a replaceable battery while being waterproof.

I mean, the "one-queue per consumer" they eventually ended up with, is basically an inbox that the sequential process reads from.

Fair enough, this is a sign of clear progress for Eastern Europe.

And the migration exists in the other direction, you'll be amazed by how many French dentists are studying in Romania.

Those people don't really plan to stay in Romania. They intend to get their degrees then move back to Western Europe. Hell, most of my former high-school colleagues who became doctors or dentists, emigrated to Western Europe.

In Germany you can sometimes find it at Turkish grocery stores. I grew up eating it every autumn. It's still common in my part of Romania.

Firefox has such a small slice of the browser market, that I doubt Google will bother.

Just tried it for German. The cards gave me the word without their article. Because grammatical gender is so important and impacts so many aspects (adjectives, case markers, etc), you really should learn the word with the article, otherwise you'll be in a world of pain later.

The seasonality is not an exception. It's not a case of "just this once". It's a well understood thing of "every year, before the tax deadline we have crunch-time, so don't plan on going on holiday in that time". The repeated, unplanned, "just this once" exceptions are a whole different thing.

I have lived in several commie block apartments over the 30 some years I lived in Romania, and in every single one every radiator had a manual valve I could use to regulate temperature.

Having the workers acquire the lock and update the terminal themselves seems like it would cause lock contention.

An alternative would be to have only the main process do the updating and have the workers message it about progress, using a queue.

if you choose to share data with Bob, you have to accept the consequences of Bob being sloppy with your data

CANDU reactors use un-enriched Uranium. Technology exists, and has been in use for half a century.

It really depends on the use-case. Async Python is nice for IO-heavy APIs If CPU-heavy workloads are likely, I'd probably look into using go.

In terms of FE, it really depends on the skill-set in the team. I went for Vue over React when we had to have a bunch of backenders whip up a FE simply because it's more opinionated and we didn't want to have to make as many choices when getting started. Also, just rendering HTML on the server side can still get you a long way

For the DB, again, it depends on your use case and what your data-model looks like, but I think a relational DB like postgres is a safe choice 99% of the time. You might need to couple it with something else on occasion (I've reached for elasticsearch more times than I can count)

And even before apps became common-place, in Europe it was common to call a dispatch and ask for a cab at an address.

I've ordered from such a place in Munich. The novelty factor made it entertaining to watch and at some point I could identify my order being prepared. Not sure how many people you could deceive before you start to get called out, if the feed was of a different kitchen

that deal is (was?) only available in few parts of the world, sadly

Brilliant!

I just add intermediary way-points for long routes. Works well enough.

Even just using an ad-blocker will prevent this: https://github.com/gorhill/uBlock

The FB pixel is how FB gets to know about conversions. If your company runs FB adds, FB encourages you to let them know about which users converted to paying customers so it can improve the targeting of your ad campaign. And if you offer a free trial and the upgrade to paying customer happens inside the user dashboard, presto-bingo Marketing now needs you to install the FB pixel there.

It's disappointing that this is what the internet has become, and I'm happy to see issues like this brought forward. I can see value in feeding back conversion events to an ad network, but the "just let us run code on your page" style of integration needs to stop. Give developers some API to explicitly send such an event, if they really need to.

Boots. I can afford the boots I can afford today and I like them. But I am sure that 10 years from now I’ll be able to afford better ones.

If you can get 10 years out of a pair of boots it means they were good. I've had a pair of Caterpillar boots break after 2 years. I'm happy to see a review site with a strong focus on long term ownership.

Don't remember the details of the legacy app, but I don't recall seeing that. I think it just used dicts for the data and stored that in a blist.sortedlist https://pypi.org/project/blist/

blist was the one C dependency which I replaced with a pure python alternative http://www.grantjenks.com/docs/sortedcontainers/

I think PyPy is switching to cffi as the way to connect to C code so most native code "just works" now.

As far as I know extensions need to be written for cffi specifically.

cffi is a newer way of writing C extensions, developed by the PyPy project. It was designed to have a smaller&cleaner interface to let you call C code from Python. Here's Armin Rigo talking about it at EuroPython: https://www.youtube.com/watch?v=ejUzVcvTLgI

The CPython way of writing extensions is documented here: https://docs.python.org/3/extending/extending.html It seems to require you to deal with the internals of the CPython interpreter (deal with PyObject structs, reference counting, etc).

I know PyPy has some support for CPython extensions, but it has to emulate some internals and it's slower as a result.

I did. Inherited a legacy web app that did stupid things in Python in memory (basically search and aggregation).

I realized a rewrite was the best course of action, but in the meanwhile the old thing had to stay up and running, and as the volume of data increased, it started to run in to HTTP timeouts as often requests took longer than 2 minutes.

I moved the thing to PyPy, and got about a 30% speedup from that. Only one lib had to be replaced with a pure python alternative, as it was using a C extension.

It bought me enough time to finish the new implementation (duplicate the data in Elasticsearch, hey presto from over a minute to about a second to get results).

For some workloads PyPy's JIT can do wonders.

It's the same in Romania.

The Pragmatic Bookshelf https://www.pragprog.com/ deserves a mention, as they're DMR free.