Hacker Newsnew | past | comments | ask | show | jobs | submit | more adrianmonk's commentslogin

I'm no historian, but looking at a map, Turkey seems geographically prone to getting trampled over and over.

It's basically the hub that connects Europe, Africa, the Middle East, and Asia together. If someone builds an empire in any of those areas and tries to expand to another one, they're going to want to control the territory that connects them. Even if they don't want Turkey for its own sake, it's a stepping stone.

In other words, if you want to not get invaded, it really helps to be off in a corner that's not on anybody's way from anything to anything. Turkey is the opposite.


I don't know if that is necessarily the case. I'm from eastern Turkey and my DNA results showed mostly Iranian and Armenian ethnicity. I'd assume, a place that was constantly trampled would have a little more variety, especially considering the last time the Persian or Armenian empires controlled the city I'm from (Malatya) was thousands of years ago.

It's valuable real estate but not so easy to conquer. Probably because of the mountains. When the Arab's were on a role, they couldn't get too far into Turkey, same with Tamerlane, as well as many other invaders throughout history.


My father, a Turk, has a couple of close Armenian friends from Arapkir, a county of Malatya, from his childhood right after WWII. Going back 30-40 years before that period, Armenians were the majority ethnic population in many counties of eastern Turkish cities. Not sure about Persians, but having an Armenian connection in a big chunk of your DNA if you're from the area shouldn't be that surprising.

Fun fact. Yerevan, the capital of Armenia, has Malatya and Arabkir districts.

edit: typo


> I'm from eastern Turkey and my DNA results showed mostly Iranian and Armenian ethnicity. I'd assume, a place that was constantly trampled would have a little more variety

Historically, being "conquered/trampled" didn't mean genetic displacement or even mixing. Especially if an established and stable population already existed there. It just meant the masses had a new master. The mongols conquered china but china is still chinese. The arabs conquered iran but iran's still iranian. The brits conquered india but india is still indian.

> especially considering the last time the Persian or Armenian empires controlled the city I'm from (Malatya) was thousands of years ago.

But turks don't speak persian or armenian. They speak turkish. They don't use armenian script but used arabic alphabet previously and now the latin alphabet. Turks aren't christian or zoroastrian or buddhist, but are muslim.

A predominantly genetic iranian/armenian population that speaks turkish, is muslim and uses the latin alphabet. That's pretty diverse.


Eastern Turkey is remarkably hard country and lowly inhabited. That natural geographical border is probably why that has been a political border frontier of many past and present states for probably 3000+ straight years.


Do you mean David's? Their web site says it's "fluoride free".

https://davids-usa.com/products/davids-sensitive-whitening-n...


Sorry, I mixed up my brands. I actually meant Ollie's. Dave's has the NAHP but not the flouride.


I think they're answering a question about whether there is a distinction. To answer that question, it's valid to talk about a conceptual distinction that can be made even if you don't necessarily believe in that distinction yourself.

As the article said, Anthropic is "working to identify and implement low-cost interventions to mitigate risks to model welfare, in case such welfare is possible". That's the premise of this discussion: that model welfare MIGHT BE a concern. The person you replied to is just sticking with the premise.


Wait, is this why when I'm having trouble seeing something small, it becomes easier when I get way more light on it?

I just assumed more photons results in a stronger signal to my rods and cones. But maybe it's making my eye shrink the aperture instead (or both).


Oh it's worse than that just pupil shrinking in dark. Basically, cone cells see color and detail but need more light, rods see in low light but mostly serve peripheral vision. So your vision system is just wholly optimized to only doing detail work in fairly bright light; nighttime is for predator evasion.

Another way to look at that: We likely evolved decent color vision to identify edible fruits. That wasn't doable with vision in the dark (and we opted out of the olfactory tech tree), so now your accurate-vision tasks are optimized for daylight.


> IPv4 would have had 36-bit addresses, about 64 billion total. That would still be enough right now, and even with continuing growth in India and Africa it would probably be enough for about a decade more. [ ... ] When exhaustion does set in, it would plausibly at a time where there's not a lot of growth left in penetration, population, or devices, and mild market mechanisms instead of NATs would be the solution.

I think it's actually better to run out of IPv4 addresses before the world is covered!

The later-adopting countries that can't get IPv4 addresses will just start with IPv6 from the beginning. This gives IPv6 more momentum. In big, expensive transitions, momentum is incredibly helpful because it eliminates that "is this transition even really happening?" collective self-doubt feeling. Individual members of the herd feel like the herd as a whole is moving, so they ought to move too.

It also means that funds available for initial deployment get spent on IPv6 infrastructure, not IPv4. If you try to transition after deployment, you've got a system that mostly works already and you need to cough up more money to change it. That's a hard sell in a lot of cases.


Author here. My argument in the OP was that we maybe would never need to transition. With 36-bit addresses we'd probably get all the people and devices to fit. While there would still be early misallocation (hell, Ford and Mercedes still hold /8s) that could probably be corrected by buying/selling addresses without having to go to NATs and related. An even bigger address space might be required in some kind of buzzword bingo AI IoT VR world but 36 bits would be about enough even with the whole world online.


And nothing like FOMO of developing markets not being able to access a product to drive VPs and CEOs to care about ensuring IPv6 support works with their products.


I don't think the theory is that the muscle memory sequences resemble each other.

Instead, it's that because muscle memory allows you to do things without thinking about it, you can get mixed up about which action you meant to perform and go through the whole process without realizing it.


Is actuating the fuel cutoff switches something that is done routinely in these aircraft, to the extent it could reasonably become muscle memory?

ETA: downthread it is mentioned that these switches are used on the ground to cut the engines


Seems akin to something like a parking brake. Something you only use at a stop, or rarely during an emergency.


They're pilots, they do hundreds of stops each year. In case of domestic pilots, even thousands. And with years of experience, switching off fuel control switches is basically muscle memory at this time now.


Was amused to see they have one of those too, with "parking brake" written on it.


> With the DuMont Duoscopic, two different channels were broadcast on a single screen. To the naked eye, the images appeared superimposed on one another. But a viewer who wore polarized glasses or looked at the screen through a polarized panel saw just one of the images.

So it would have been possible for two TV stations to team up and do a 3-D simulcast!

And it was built in 1954, the same year that Hitchcock's 3-D movie "Dial M for Murder" came out!

I highly doubt such a thing ever happened, but it would have been cool if it did.


> Was it some technical constraint of the typewriter that caused “1” to become more like “l” come XX century?

The typewriter I grew up with simply didn't have a key for it. It also didn't have a 0 or an exclamation mark or a plus sign. There were well known substitutes:

For the number 1, type lowercase letter l.

For the number 0, type uppercase letter o.

For the exclamation mark, type a period, hit backspace, and type an apostrophe / single quote.

For the plus sign, I'm not aware of a good substitute. You could maybe superimpose a slash on a hyphen, but it would look bad.

There was no division sign, and using a slash to denote division was not yet something I'd ever seen anyone do. You could probably have superimposed a hyphen and a colon to get ÷.

Oddly enough, it did have other characters which you won't find on a standard US keyboard today: ¼, ½, and ¢. The cent sign was useful, and it seems logical to me that if you're going to have $ you should have ¢ too!


In the UK, we also used to type '£' with an 'L' and backspacing and overtyping an '='.

Weirdly, I learned to type on a second hand Selectric typewriter that my parents bought cheaply at some auction, and while it had a '1' key, the only ball we had used that key for punctuation instead, so we still needed to type 'l' instead.


And since I've mentioned GNU groff elsethread, here's where it today in its "ascii" mode uses a minus sign instead of the equals sign to do the very same thing as you did on your typewriter, for "Po", the macro for producing a pound symbol.

* https://cgit.git.savannah.gnu.org/cgit/groff.git/tree/tmac/t...


Cents were a useful unit back when a dollar was defined as 1/20th of an ounce of gold (or 1/35 between the Great Depression and 1970).


> having the index as part of the file. Sadly, gzip doesn’t have the concept of a skippable frame

Looking at the file format RFC (https://www.ietf.org/rfc/rfc1952.txt), the compressed frames are called "members" and each member's header has some optional fields: "extra", "name", and "comment".

The comment is meant to be displayed to users (and shouldn't affect compression) so assuming common decoder software is at least able to properly skip over it, it seems like you could put the index data there.

One way to do it would be to compress everything except the last byte of the input data, then create a separate member just for that last byte. That way you can look at the end of the file and pretty easily find the header because the compressed data that follows it will be very tiny.


Oh, I’m pretty sure you could set a gzip header field with a full index and a zero-byte payload. You could even make it so that the size of that last block would be in a standard location in the file (at a known offset, still in the gzip header).

One issue with bgzip in particular is that it fixes the gzip header fields allowed, so you can only have one extra value (which is the size of the current block). Because of this, you can’t have new fields in the header for bgzip (the gzip flavor widely used in bioinformatics). One thing I wanted to do was to also add was a header field for sha1/sha256/etc for the current block. When you have files of sufficient size, it can be helpful to have chunk-level signatures to protect against bitrot. This is just one usecase for novel header elements (which is somewhat alleviated as gzip blocks all have their own crc32, but that’s just one idea).


The concept reminds me of that story from Reddit that was going to get turned into a movie but never did:

https://en.wikipedia.org/wiki/Rome,_Sweet_Rome

I think this is the original Reddit thread:

https://www.reddit.com/r/AskReddit/comments/k067x/could_i_de...


I’m familiar with it. Not sure what ended up happening to the project though.


Sadly the author mentioned that the script itself is stuck in rights limbo, where they sold off the rights but never saw that it'd amount to a movie, yet.


Consider applying for YC's Winter 2026 batch! Applications are open till Nov 10

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: