Svip

A Mercedes S-Class ain't cheap. But hasn't this been available for a year in Germany?

Yes. I was not the original creator. However, when they felt it was too much of a hassle to maintain the site, I asked to take over. The original creator of the site still owns the domain.

I agree, but I also don't want to waste too much of my life chasing SEO. Fortunately, some people find our site.

I still maintain an independent Futurama wiki from Fandom. Back when they were called Wikia, they wanted to merge with our wiki, but I insisted on a no ads policy. So talks basically went nowhere. They still have a Futurama wiki, and ours is still online. Though, these days, it's mostly other editors filling in the content, I am just a system administrator at this point.

I am still happy with our decision, because Wikia/Fandom has since then just gotten worse.

Given the description, this sounds more TUI than CLI. Honestly, when I saw the title, I thought it was a competitor to ed(1).

Scandinavian languages have the same. »Mormor« (lit. mum mum) means maternal grandmother, while »farmor« (lit. dad mum) means paternal grandmother. Unfortunately, it doesn't appear to continue beyond that (so no »mormormor«).

This thing: https://duckduckgo.com/?q=seb+le+saucier&t=ffab&atb=v101-1&i...

Like the egg cooker, this is an inherited appliance.

If you like that, you should see the hospital version: https://www.avxperten.dk/stikkontakt/lk-fuga-stikkontakt-jor...

Switzerland and Liechtenstein are outside the EU. As for the type K, type F sockets are already permissible in Denmark, and are not uncommon in newer installations. The page on type K mentions that the expectation is that type K will be phased out eventually, as newer installations use type F, but I haven't really seen a lot of type F sockets, and there are no mandates to change existing installations.

Type E and F's plug are shown in their combined version (the Schuko), which is the standard today. I have two old appliances (an egg cooker from the 1980s and a sauce machine from the early 1990s), which have the type F and type E plugs, respectively, i.e. not the combined form. Living in Denmark, the usual K to Schuko plug is using the E socket (i.e. "French ground"), which makes it hard for me to find a grounded socket for my egg cooker (which I believe is German). (Though, because this converter takes up a bit of space, on some appliances, I have removed the Schuko plug and replaced it with a type K plug to reduce space required. I have been thinking of doing the same for the egg cooker, but there is something quaint about an actual type F plug.)

My assumption is wrong. As others have noted, it's clearly parsing the title of the first result wrong. Edit: It's the parsing of the title of the infobox.

Curious that the error does not occur when searching for "Notepad+": https://duckduckgo.com/?q=notepad%2B&t=ffab&atb=v101-1&ia=we...

Was someone trying to be funny, to change a "notepad" search for "notepad++", forgetting that + has a specific meaning in regex? Same error occurs with a search for "notepad++", though, but not "notepad+", funnily enough.

The problem is that it is slower to parse an `IN` query than an `= ANY(array)` query. Because the syntax for an array in PostgreSQL is simple, PostgreSQL can use a faster parser for the array. However, with `IN`, it cannot know the type of the next element in the list. Since `IN (a, 2, (select id from table), null)` is valid SQL, it needs a parser that permits all those scenarios. But with an `{1,2,3}::integer` array, it knows it can only have one layout.

Often people do not discuss the time it takes for the database to parse the SQL query. If you run an ORM, with a one to many relationship between two tables, which are modelled in an application layer, you may wish to preload the children onto the main object. Suppose you are loading thousands, if not millions of objects, and you wish to preload all of their children, your ORM might simply do this by running two SELECTs, first the main object's table, then children's table with the parent IDs of the main objects included in the query.

When using the `IN` syntax, parsing this will be very slow compared to the `= ANY(array)` syntax. I remember running some tests to compare them, and once you get to 100'000 values, `IN` becomes significantly slower compared to `= ANY(array)`. I cannot recall whether it was 100'000 or 1'000'000 values, but at one of them, PostgreSQL just never finished the job with `IN`, where `= ANY (array)` took a couple of seconds.

Seems strange the article doesn't mention the `= ANY(array)`[0] alternative to `IN (?)`. The problem with `IN` is that PostgreSQL uses a slow parser for the subquery, since `IN` is an SQL standard, and a legacy parser is used. You can see in the EXPLAIN, that PostgreSQL converts the `IN (...)` into `= ANY(array)`.

[0] https://www.postgresql.org/docs/current/functions-comparison...

Denmark used to have that until 1997, when it was replaced by a tax based on km/l (not 100 l/km).

Not sure how it works for electric cars, come to think of it.

The list seems to be slapping PM and AM together. So you could get a song about 10:02 PM at 10:02 AM, and probably the reverse.

Seems strange they would not use a 24 hour clock to associate the songs, and the songs not specifically being about before or after noon could be associated with both.

Indeed, it would feel weird to play 2 Minutes to Midnight two minutes before noon.

The advantage of doing it per 100 ml/g, means it's easy to compare foods for their nutritional values. The US way is completely opaque.

The Romans did not use war chariots, since they are basically useless in combat. They only used chariots for sports in the hippodrome.

Their feature showcase with fascism makes their version seem more biased than the Wikipedia version. I recognise we can debate whether Stalin was a true communist and not just a fascist in disguise, but leading your article with that (by virtue of having his picture before Hitler's in reading direction) seems very subjective.

I definitely prefer the ANSI left shift key, but I am keeping my ISO enter key, thank you. Indeed, I have a keyboard with an ANSI left shift and an ISO enter key.

But honestly, why not just use US Intl AltGr dead keys?

In Europe, E-routes require a clear height of 4 metres, which is the maximum allowance for a regular vehicle. So if you're a trucker, you can be safe in knowing that driving on an E-route, means your vehicle will clear all bridges.

There are definitely examples of countries upgrading their existing roads to become E-routes, which sometimes include raising bridges.

The decision from the Commission lists what the US did (linked from the article).[0] Although, I'll admit, I am not great at reading language that verbose.

[0] https://commission.europa.eu/document/fa09cbad-dd7d-4684-ae6...

The situation may obviously have changed today, it's been a few years since I last worked with Pascal. Back around 2016, we were looking for a different way of communicating between our services (you could kind of see them as micro-services, but I would not describe them as "micro"), which until then had relied on our own communication implementation on top of Windows socket. Our implementation was OK, but could not communicate beyond a single Windows machine, and it definitely did not allow multiple instances of the same services. We wanted to scale up, so we started looking into new technologies.

Our lead developer was interested in building a RabbitMQ prototype. There were two libraries around to find, but none of them were finished, so we spent a lot of time finishing one of those implementations. We also looked into ProtoBuf, but that was a steeper hill to climb. When I left in early 2019, we were still using the old WinSock communication, though I understand from former co-workers, that they've switch to an UDP-based system instead now.

That's the most vivid one I can remember, because we pushed on, despite the available libraries being weak. I also remember trying MongoDB, which required a lot of polishing the available libraries as well. Other ideas I remember pursuing briefly, until I recognised finished some of the libraries would be too tall an order.

For the record, I don't have a problem with Pascal in general, nor its community. But considering how trivial it is to find a solid robust library for modern technologies (even if kind of fads) for other popular languages, compared to Pascal, it definitely feels weird to call its ecosystem "great".

Of course, the libraries I've mentioned may be great today. But RabbitMQ and MongoDB are also a bit older technologies today.

> On the other hand, the ecosystem is great.

Hard disagree. I worked with Pascal for about 10 years, and the lack of modern libraries was a source of frequent frustration, meaning we often had to develop the solutions ourselves, or abandon an idea entirely.

Since it's a Canadian story, perhaps link to a Canadian news source? https://www.cbc.ca/news/canada/saskatchewan/thumbs-up-emoji-...

ESEA? Do you mean EASA?

According this graph[0], there were over 1 million cheque payments in Greece, Germany, Cyprus, Malta, Ireland, Spain, Portugal, Italy and France in 2020. I recognise that the data is a bit dated, but it still seems like these countries maintain the concept of cheques.

[0] https://www.statista.com/statistics/443677/cashless-payment-...

Cheques allow you to give someone a large amount of money (that would be too unmanageable with cash) without knowing anything about them but their name. Don't need to know an account number or a phone number/email address. Pretty handy.

Also, I am 36, and I live in a country (Denmark) that has entirely abandoned cheques, but I am still familiar with Danish cheques (even if I never managed one myself). Additionally, I still see them frequently when I am in France. (Though these days, the vast majority of cheques I see are US cheques, since my wife is American.)

I recently learnt that Denmark and the US are the only two countries with a fixed debt limit. Several other countries have relative to GDP debt limits. The purpose is the same; to ensure that executive branch can borrow money without having to ask the legislative branch each time. The US debt limit has existed since 1939 in its current form, but it was only recently (like since the 1980s) that it has become a hot potato. Denmark's has existed since 1993, and only been raised once, though far higher than the actual debt.

Other countries don't have these restrictions (fixed or relative), where it's usually because those countries' constitutions allow the executive branch to simply borrow money whenever it sees fit.