Unless you have fairly narrow requirements, and want a generic Unix-like server or desktop, you'll almost certainly have best luck with FreeBSD (in terms of software availability, hardware support etc).

MATE? Xfce? LXQt?

The nice thing about text logs is that, even if they are corrupted at some point, the rest of the log is still perfectly readable.

You're missing a cloud solution here.

Most of the "streets" on that map are actually parking lots - naturally, those aren't public. But there's still plenty of public streets, and yes, checking Google Street View coverage is a good way to see what they are. 157th / Microsoft Way, for example, is public, and goes right along a bunch of buildings. Ditto 31st, 36th, 163rd etc. 150th is right next to the Mixer, which is where a lot of 'softies go to have lunch, and on the other side of that there's 40th.

Is that area settled?

I think you're confusing K&R C with B. It's B which doesn't really have types at all other than "machine word".

Function arguments in all versions of C always had types. I think that what you're referring to here is that it is possible in C (ANSI as well as K&R, actually) to call a function without having it declared at all, or having it declared but without specifying the argument list (when parens are empty - this necessitated the later use of (void) argument list to declare true argument-less functions in ANSI). When you do that, there are some implicit promotions that happen before the call known as "default argument promotions" - e.g. any integral type shorter than int is promoted to int, and float is promoted to double. However, after those promotions, the formal argument types for the function that you're calling must match the types of the actual arguments you pass in there - even though there's no compiler diagnostic for it (since, well, it doesn't know the prototype at the point of the call), any mismatch is undefined behavior. The only exception is that you can pass signed int/short/long where unsigned int/short/long is expected, and vice versa, but only if the value you're passing is representable in both types; and you can pass char* in place of void* (+/- any cv qualifiers) and vice versa. Anything else is U.B. In particular, passing a char* where int is expected is U.B.

With casts, you can of course cast two pointers to ints, and then do whatever you want with them. This makes sense, since you're not doing pointer arithmetic then, it's just the standard operator + defined for ints with appropriate semantics. But the original discussion was in the context of trying to concatenate two C strings (i.e., char* pointers), which will not compile with any version of C.

Washington State has no personal income tax. So the only tax that it sees from Microsoft employees is the sales tax on their purchases, and the property tax on their houses.

The campus is a bunch of buildings with mostly public streets running between them.

Types are an artifact of an imperfect system - what matters is the meaning. The only reason why we even have separate int and float types, for example, is performance, and legacy semantic differences (like different behavior for division by zero or overflow) - from a common sense perspective, the type should just be "rational number", and whether the underlying representation is integer, or floating-point, or a true rational, does not matter in the slightest. In languages which still choose to expose that difference in their typing system, it still makes sense for them to try and patch over that difference by at least making the values largely interchangeable (or even directly introducing some form of subtyping relationship to codify that, like Scheme's numeric tower).

Well, except labels don't necessary point to the function entry.

But the craziest version of this that I've seen is in Algol-60. There, "label" is actually a data type of sorts - while you cannot declare variables of that type, you can use it to declare procedure (function) arguments. At runtime, the procedure can then goto such a label argument, which allows for a nonlocal exit to the point designated by the caller (in effect, this is setjmp/longjmp - devised in 1958!).

They also had the notion of a "switch", which is basically an array of labels - either locally declared, or also passed as a procedure argument in a similar fashion.

Now that makes sense. Yeah, the way I'd read it is definitely by assuming that order of execution follows textual order.

It sounds a lot like one of the quirks in ancient languages that slowly evolved over time. More recent BASIC dialects are also chock full of these (which is why it was very nice when QBASIC did a clean new syntax for loops).

This is not what "deterministic" means, though. Deterministic means same inputs given same outputs. In your case, you're getting different inputs.

The difference that you're describing is compile-time determinism vs runtime determinism.

This is standard Pascal, not specific to FreePascal. IIRC it was also the case for Modula-2, Delphi and other derivatives.

It is actually fairly logical in a statically typed language. The only reason why C needs different operators for this is because it didn't have the boolean type originally, so you needed some way to tell whether these two integers are to be treated as bools or as collections of bits. Since Pascal always had proper booleans, it could just overload the same operator.

Because iterator has iteration state, and you might want two parts of code to iterate over the same collection concurrently (it doesn't even have to be threads - it might be just nesting, e.g. a function is iterating over an array, and during one iteration calls another function which also iterates over the same array).