The things I took away from reading Niven was transfer booths. The world has homogenized because information and people were transmitted instantly one from corner of the globe to another.
I loved the conservation of momentum "hack" for those teleportation booths. Go on, everyone who hasn't read it, see if you can guess how he dealt with that.
AOL mail and Verizon mail had both been migrated to the yahoo mail backend when I left the company. This one kind of feels like a weird acquisition to me as that’s the story for a lot of AOL properties these days - a differently branded front end to the same services as their Yahoo counterpart. It would surely be much more costly to run AOL outside Yahoo as now you need to spread the costs of maintaining all that across fewer users
> Verizon handed their email service over to AOL some years ago. I wonder if this will be the end for my unused @verizon.com account.
Yeah. I have some biz clients with long-held verizon.net email accounts. Ever since 2017, verizon.net has felt like some barely-there netherverse, where the laws of physics keep upending themselves for funsies.
In this analogy, the laws of physics are pop/imap/smtp settings (and auth req), which aren't at all well-tethered. I suspect the engineers have the server settings printed on D&D dice; I think they reroll their mail servers whenever the game isn't exciting enough.
So what happens to those biz email accounts now - now that the entire AOL snowglobe has been picked up by a different corporate toddler? I have no way to tell.
Great idea! Thinkpads (used to?) have an Active Protection System that used a Free Fall Sensor IMU to park the HDD read/write head in the event of a fall. Don't know if there's an API, though.
That was from Algol 68. Algol 60 used BEGIN/END blocks when the body of a do loop (or a then or else block, etc.) had more than one statement. Bash was influenced by Algol 68.
All I can think of is that it was a way to look at the end of a long program which wouldn't all fit on a display. Predating, I suppose, the 'tail' program, or whatever the DECSYSTEM 20 equivalent was.
I assume that it would be clearly useful if your terminal was a slow paper teleprinter. Once you got used to reading listings with the lines in reverse order, which shouldn't really be very difficult, LISTREVERSE would let you start reading from wherever you had got up to in your partly-completed listing, then cancel whenever you'd got enough context, instead of having to guess in advance how far up the program you'd want to look. You could even then print out the same range of lines again unreversed, if you wanted.
My best friend George (Gyuri) from college is Hungarian and I've picked up a few words (mostly cuss words) from him. One of the hardest parts for an English speaker to learn about Hungarian and Finnish is that the length of a sound (how long you articulate it) is significant. Finnish uses doubled letters for this, Hungarian uses accents (a vs á, o vs ó, etc.) for vowels and doubled letters for consonants. I've gotten to where I can hear the difference when listening to George speak Hungarian but it took some effort.
> One of the hardest parts for an English speaker to learn about Hungarian and Finnish is that the length of a sound (how long you articulate it) is significant
I'm not a native English speaker, but I'm pretty sure it exists in English as well.
Absolutely, think "lick" vs "leak". I think the author means Hungarian maybe uses very similar looking letters to denote this (ie "lik" and "lík").
In Hungarian also every vowel comes in pairs of short-long: a-á (what vs high),
e-é (ever vs eight), "o-ó" (moss vs most), "u-ú" (put vs you), "ö-ő" (fur vs ... well long version has no English equivalent I think but German does: schön).
"Hungarian has seven pairs of corresponding short and long vowels. Their phonetic values do not exactly match up with each other, so ⟨e⟩ represents /ɛ/ and ⟨é⟩ represents /eː/; likewise, ⟨a⟩ represents /ɒ/ while ⟨á⟩ represents /aː/.[14] For the other pairs, the short vowels are slightly lower and more central, and the long vowels more peripheral."
Typically, when people talk about "long" and "short" vowels they are referring to a combination of duration and pronunciation (e.g. English "bat" vs. "bate"), and that appears to be the case here as well. If you are interpreting the terms differently, I'm not sure what sense you have in mind.
> Typically, when people talk about "long" and "short" vowels they are referring to a combination of duration and pronunciation (e.g. English "bat" vs. "bate"), and that appears to be the case here as well.
Finnish vowels and most Hungarian vowels come in short-long pairs that
- only their lengths differ, their pronunciations do not (meaning: IPA denotes them with the same letter but with or without a colon)
- their lengths are *phonemic*, that is they are *said to be* different phonemes, they are *perceived as* different phonemes, and there are example words that differ only at them
You can observe this property in the table I've linked for i, o, ö, u, ü [0]. You can find minimal pairs for them at [1]. (Note that [1] groups these vowel pairs as "Vowels with length difference: I – Í | O – Ó | Ö – Ő | U – Ú | Ü – Ű" which does not include A - Á and E - É.)
A-á and e-é are not such pairs. They differ in pronunciation (see the IPA in [0]), and their lengths, while are somewhat defined, never contrast (no minimal pairs for them). Also you can pronounce any of these four with arbitrary length, it will stay the same phoneme.
edit: I find your previous quote 'misleading'. I would say 'wrong', but it avoids to say anything factual. At least in out of context--the rest of the wiki page clarifies everything.
Your position sounds cogent and may well be a more accurate description of Hungarian (e.g. that its long/short vowels are more like Latin than English). I don't know Hungarian, so I can't say.
The rest of this thread is consistent with people assuming the broader definition of long/short.
This is an important sign when someone who is not Italian speaks Italian. The double consonant, for example in the word bello/a, indicates a longer “l” sound, but English speakers in particular do not hear the longer sound and therefore pronounce it as belo/a. Or, when they are told about the longer sound, they pronounce it in a caricatured way as bellllo/a.
Vowel length is generally not semantically significant in English. Vowels are lengthened before voiced consonants, for example, and we don’t even think about it. Compare “cab” and “cap”. As noted here, some Hungarian vowels, such as ’a’ and ‘e’ do change sound when lengthened, but some don’t. Those are the ones that are harder to distinguish for speakers of languages like English.
I've yet to hear a non-Finn get doubled consonants right, ever. Kukkakaali. Ikkuna.
Somewhat easier but still challenging is getting the wovels in the right place. They're just different, and the barrier is as hard going the other way but Finns have more practice in speaking English than the other way around. It's similar to the idea that it's very very hard to learn a tonal language if you grew with non-tonal languages.
Forgive my ignorance, but I'm not sure what this is showing me. I'm running it on my home linux system, which is connected to the Internet via Verizon FIOS. The map shows three red dots, none of which are near me.
It's only showing connections directly initiated by your computer. Not anything "upstream" of you like the FIOS router. It would also show any connections TO your computer, but being behind NAT on a normal home network, that would likely be nothing unless you've intentionally punched holes.
I’ve wondered if there should be two string types in C, analogous to different length numeric types. Short strings (“tokens”? “words”?) could be Pascal style strings and longer strings (“buffers”) could be standard C-style null terminated strings. I’ve never tried to work this out for real, it just seems to me that one-size-fits-all strings might not be the best model.
I think it would be better to have the string type being the address and length pair. Pascal strings store the length immediately before the data, which is different than what I think is better is to store the length separately.
reply