Athas

Most recent I remember was in 2011: https://github.com/ocaml/ocaml/issues/5419

The comments were quite often in French, however! Until relatively recently, the OCaml compiler would also sometimes emit error messages in French in some obscure cases.

What are they supposedly trying to do with Warhammer (40k)? I am aware that Amazon has the rights and are working on developing something, but apart from the Secret Level episode (which was good), has there been any details?

While some of what Amazon has made is terrible, much is good. They produce so much that the average quality is pretty close to the global average, so I find predictions challenging.

This is not the case in Haskell, because let-bindings can be self-referential, while lambdas cannot (without using a fixed point combinator). Also, in most functional languages, a let-binding causes type generalisation, which is not the case for a lambda.

This looks like an invocation of a C++ CUDA kernel through an FFI. It is not running k or q directly on the GPU.

Why not essentially treat it as a cross compilation scenario? NixOS is also source based, but I don't think such a migration would be particularly difficult. You'd use the 32-bit off_t gcc to compile a glibc with 64-bit off_t, then compile a 64-bit off_t gcc linked against that new glibc, and so on. The host compiler shouldn't matter.

I always understood the challenge as binary compatibility, when you can't just switch the entire world at once.

Not at all! Lynx is a quite serviceable Gopher client, and it is available in most package repositories. For Emacs users, elpher is available, and it is very comfortable to use. Far more than modern browsers, really.

Yes, and undoing this means it's no longer UNIX as it will no longer run on that PDP-11! (Unless you can afford a bigger disk I guess.)

The best answer is that you probably don't want to use Futhark for that - it's a specialised, rather restricted language. There are ways to encode irregular arrays, but it's not even remotely as ergonomic as in other languages (it can be plenty fast, however). For a particularly simple example, see https://futhark-lang.org/examples/triangular.html

In the future, or in a future similar language, one might well imagine an ability to "box" arrays, like in APL, which would allow true "arrays of arrays" with no restrictions on sizes.

You can just use 'map' explicitly. It doesn't have to be special syntax.

We are in a sort of similar situation, but our solution was to put a Raspberry Pi in a windowsill that runs a reverse SSH tunnel (through a server in a VPS somewhere).

Why were BOMs ever allowed for UTF-8?

But C is already capital C! Even .d would have been a better extension.

I never understood the popularity of the '.C' extension for C++ files. I have my own preference (.cpp), but it's essentially arbitrary compared to most other common alternatives (.cxx, .c++). The '.C' extension is the only one that just seems worse (this case sensitivity issue, and just general confusion given how similar '.c' looks to '.C').

But even more than that, I just don't get how C++ turns into 'C' at all. It seems actively misleading.

The pandoc binary I have is certainly large at 206MiB (more than I expected!), but it doesn't have any weird dependencies I can see. Just GMP, ncurses, and such. All the Haskell parts are statically linked, which is probably the reason it is so large.

He mentions her by name in the first paragraph (after the cover letter):

> I don’t post directly because I am in prison for killing my wife Nina in 2006.

He doesn't get into whether/why he is sorry:

> I am very sorry for my crime–a proper apology would be off topic for this forum, but available to any who ask.

Hans Reiser has previously explained why he believed the murder was justified. It is not clear to me, from this letter, whether he still believes so.

It's a tradeoff. I'm willing to accept some clumsyness in return for conceptual and technical simplicity. Others may feel different. In practice, most people who write plain text emails manage to format them pleasingly themselves (and 72 column plain text is perfectly readable on my phone, although I prefer not reading email there).

That sounds like a bug in your phone. Perhaps you should report it to the vendor? Even my ancient Emacs mail reader can reflow plain text emails when I ask it to do so. It sometimes needs to be told on a paragraph-by-paragraph basis, because otherwise it might also reflow ASCII art diagrams and such, but in practice I find it a minor problem.

It depends on your definitions and assumptions. Here 'n' is not the address, but the size of memory (or the largest possible/worst-case address). In the universe we inhabit, due to limitations on information density in a given volume[1], the worst-case random access time for a memory of size 'n' would be the cube root of 'n', because you need to transmit a signal at the speed of light between to points inside a sphere.

Real computers tend not to be able to store their information in all three dimensions (I think I once saw an argument for why this is also theoretically not feasible), and in practice appear to have worst-case access times that are logarithmic. It's fundamentally for the same reason: the bigger your memory, the more distant will be the most remote (worst-case) part of it.

Of course, in a single specific desktop or server computer, changing the capacity of your RAM sticks will likely not affect worst case access speeds, because the speed limit is likely based on the maximum capacity of the machine (a constant). So this kind of analysis is useful for pondering the ultimate limits of worst case memory accesses (and does also have some relevance huge computers), but in practice you will of course find that cache/locality effects are far more important for performance on real computers.

[1]: Since information is energy and therefore mass, a sufficiently dense store of information would collapse into a singularity, and you better hope your pointer doesn't point into one of those.

They are all viable as backend operating systems, understood as server use. I don't think it's uncontroversial to say that it what they are mainly used for, although some people also use them on desktops/laptops.

I'm not terribly familiar with NetBSD and FreeBSD anymore, but I can provide some of my own motivation for using OpenBSD on servers whenever I am able. I don’t consider myself a beginner to Unix or computers, but I do consider myself a fairly inept and inexperienced systems administrator, with no great desire to spend the time to become better, and my needs are fairly basic - just the usual web/shell/IRC/mail server stuff, and other random infrastructure needs that come along for my work. I prefer OpenBSD because it is is so minimalist, the defaults so sensible, and the documentation so good, that I trust the machines I set up. I have confidence that I did not overlook something crucial. The OpenBSD http daemon is beautifully simple - too simple for many uses, but perfect for mine. The OpenBSD mail daemon is the only mail daemon I have ever been able to set up from scratch, just from reading the man pages. Other systems are more featureful (and probalby faster), but I always worry that I might have overlooked something.

I run Linux (NixOS and RHEL) on my desktop and some servers respectively, because of needs that OpenBSD simply does not support (mostly GPU computing). Linux is fine and certainly runs very fast, but OpenBSD is the only operating system I honestly like.

I've heard someone mention that FreeBSD is "the Linux of the BSDs", meaning that it is bigger, has more features, and is faster, but (probably) also that it is more complicated. I don't know if that is actually true. My last FreeBSD experience was in 2003, where I used it because the Linux emulation could run 3D games like Enemy Territory faster than Linux itself could. (I don't think that is a common use case anymore.)

Functional languages have a core that is well suited for parallelism, but all mainstream functional languages have various features that are unsuitable for parallel execution - particularly if you want to target limited machines like GPUs.

The Futhark programming model is standard functional combinators: map, reduce, scan, etc. You can do that in any Functional language, and it is mostly trivial to rewrite a Futhark program in Haskell or SML or OCaml. Futhark removes a lot of things (like recursive data structures) to make efficient parallel execution easier (and even possible), and adds various minor conveniences. But you don't really need to add something for functional programming to be suitable for parallelism; you just have to avoid certain common things (like linked lists or laziness).

Why not just use memcpy()?

Oh definitely, there's a reason my home GPU is an AMD! The fact that driver troubles are (sort of) a thing of the past is a great win.

For which applications are AMD GPUs more suited? Last I looked at the available chips, AMD sometimes had higher FLOPS or memory throughput (and generally lower cost), but I don't recall any qualitative advantages. In contrast, just to pick something I care about, NVIDIAs memory and synchronisation model allows operations like prefix sums to be significantly more efficient.

Sorry in advance for bikeshedding. This is a cool project and the name is clearly derived from js_of_ocaml, but does anyone know why js_of_ocaml ended up with such an awkward name in the first place? I am vaguely familiar with the "x_of_y" naming scheme in OCaml (which I also find awkward, but perhaps it sounds better in French) - is that the only reason? I can't find any discussion online, so maybe I'm really the only one who finds the name awkward.

If a linker did that, changing the layout would be an ABI-breaking change. I think this opaque struct design is most common for dynamically loaded libraries, where link time optimisation does not occur (unless dynamic linkers got a lot more fancy recently).

Why would those runtimes be particularly large? I'd expect the Win32 runtime to be large, but the others should be tiny by late 90s standards. Also, I remember that Windows didn't embed that many drivers itself, but that it had a stable ABI that hardware vendors could target (I remember driver CDs). Further, while the Linux kernel is certainly smaller than all of Windows, my point of comparison was compiling an entire desktop Linux system, which also included a full set of compilers, a desktop environment like KDE, office suites, multiple browsers, etc. Someone working on Windows 2000 shouldn't have to compile all that stuff.

My main question is also not so much why compilation of Windows should be time consuming, but why it should be difficult.

Linux distributions put together the products of a a huge and very loosely organised community, and I never heard it was anywhere as horrible as these (old) horror stories of Windows development. Is it perhaps the case that the (enforced) loose coupling of open source development prevents the aggregation of build complexity and intermingled dependencies?

> I would think/guess you weren’t fully building from scratch, but from intermediate snapshots. If Linus pushed a commit, would your full build, minutes later, use it?

Yes, I would frequently download e.g. new kernel release tarballs (this was before Git) and slot it into the system. This didn't require recompiling anything but the kernel. Actually installing Stage 1 Gentoo required compiling everything (although it was on top of a compiler binary for bootstrapping.)

My hardware was cheap 2001 era consumer hardware, so I doubt it was that much faster than what the Windows developers had available. Besides, my question is more about why Windows (or anything else) would be difficult to compile, rather than just time-consuming. The nice thing about recompiling an entire operating system from scratch is that there are no external dependencies, because you're building everything! (Except the bootstrapping compiler, but for the Windows operating system there's no reason to rebuild that.)

Certainly building everything from scratch is time consuming, but why should it be difficult? Windows 2000 was developed before I became a programmer, but not too many years later (2003) I was a teenager running Gentoo, and while it was time consuming to build everything from scratch, it was easy and reliable. It was also quite easy to switch out or hack on individual parts. In particular I remember fiddling endlessly with the kernel.

Windows 2000 was certainly complex, but was it really substantially more complex than a full Linux distribution (including compilers, desktop environment, office suite, etc)? Why was it so difficult to build from scratch?