phs2501

Dithered 8-bit is approximately the same / slightly better noise floor as a cassette anyway, so if that's the market they're trying to compare to it's "reasonable". (Still silly as hell IMHO, but whatever makes people happy!)

One of the most annoying input-related things that happened to my desktop (Arch) in the last year is when evdev got replaced with libinput by default as the X11 input module. Easy enough to revert, but quite frustrating trying to figure out why mouse acceleration suddenly feels acutely horrible.

All the tweakable options were different (and fewer) in xinput, and I was not able to recreate an acceleration curve that felt comfortable.

I realize it's an old refrain, but its quite frustrating having old, featureful software replaced with new, more limited/broken versions.

Can you briefly explain how a PF anchor is not equivalent to a iptables chain? From a very short perusal of the PF documentation it appears to be the same concept to me (i.e. a set of filtering rules you can branch to from another part of the ruleset...)

Make multiple connections to the database. A transaction is at the "scope" of a connection anyway, and I don't think there are any useful semantics for multiple SQL statements being executed in parallel in a single transaction anyway, so it's likely Postgres is trying to save you from yourself here.

I'll agree that the PHP Postgres API appears to be very low-level, and the fact that it does not offer callback support may be due to the fact that PHP doesn't have a standard event loop to plug into. There may be higher-level libraries that do better here. (I don't know much about PHP.) Postgres is perfectly usable in an async manner from other languages, however.

IMHO, the biggest reason to use a language like Node when you want to do async programming is that for any random library you choose there's a 98% chance that it properly supports async as well and won't block on you. For better or worse async is pervasive in the ecosystem. Even in good languages like Python that have (allegedly; I've not used them) good async frameworks, most libraries will block as it's the normal I/O mode for the language, which really limits what you can use. I can't imagine the situation will be any better in PHP.

Personally I would like some way to navigate through the whole thread in some sort of reasonable order. My preference would be depth-first with the leaves sorted by the most recent post /in that subtree/. This matches how tools like newsreaders and Mutt will sort threads, and I believe how Gmane worked as well. (Though I will admit that for something like a web site that does not keep the state of whether posts are read or not, reordering leaves like that may be confusing. In a tool like Mutt it is useful behavior as when new posts come in they will naturally gravitate to the bottom [or top, depending on your sort order] of your message list).

In particular I'd like to be able to, starting with a particular post, repeatedly hit "next" and be assured that once I hit the next sibling post to the original I've read that entire subthread. Gmane let you do this just by whacking the space bar; if you weren't at the bottom of a post it would page down, if you were it would go to the next one.

In other words I'd like it to behave as much like a good NNTP newsreader as possible.

Semi off-topic: What is up with the lkml.org threading interface and why is it so ridiculously inconsistent?

I've always found it really frustrating that lkml.org seems to be the canonical web link that comes up for kernel mailing list discussions because of this, as I really find the threading there frustrating; it's nearly impossible to determine whether you've read the entire (sub-)thread.

Back when Gmane was alive I usually gravitated there as an alternative.

Oh, I'm aware it makes no difference internally; I picked that documentation because I am somewhat intimately familiar with it as I worked on a product with that CPU and did a lot of driver work. My only point was to the poster I was replying to, who wrote "because when you number the bytes and bits you will see that the bytes are written left-to-right, while at the same time the bits are written right-to-left". That assumes that bits are universally numbered starting with 0 at the LSB, which isn't true.

At least in Freescale's PowerPC documentation, it's convention to number the bits left-to-right in big-endian. So the most-significant bit is bit 0, which matches up with the most-significant big-endian byte being 0. See, for a random example, page 1101 of https://www.nxp.com/docs/en/reference-manual/MPC8379ERM.pdf.

Personally I prefer the little-endian representation.

Well if it means that AMD couldn't ship any x86 processors and Intel couldn't ship x86-64 (i.e. AMD64) processors, that effectively means neither of them could ship any modern x86 processors at all, so that's effectively mutually-assured destruction. If that were in any danger of happening I'd bet dollars to donuts it'd be renegotiated immediately since they both stand to lose everything.

Uh, yes it does. It has no /out of order/ execution but it certainly has speculative execution. They mention quite often in talks how they predict EBB exits and not each branch. They even go so far as to follow that EBB exit chain to speculatively load code from DRAM several calls ahead, which is much more speculation than current CPUs are capable of.

You basically can't make a deeply-pipelined processor fast without speculative execution.

Given how fast this plotter (not the type in the OP) throws paper around I'd say it works, at least in ideal circumstances.

https://www.youtube.com/watch?v=BYGPSAD5L_k

The monitor and map image (though not the screen contents obviously) are from the opening cutscene of Ultima VII.

https://youtu.be/JfqOZlNxbfI?t=106

Dropbox and encfs. There's a Windows client for it too if you need access there (http://www.getsafe.org/).

COM is its own ABI and does not use the C++ ABI:

"Unlike C++, COM provides a stable application binary interface (ABI) that does not change between compiler releases.[3] This makes COM interfaces attractive for object-oriented C++ libraries that are to be used by clients compiled using different compiler versions."

The others seem to be mostly embedded kernels or unikernels which will be tightly linked into your code anyway, so there's no issue of ABI incompatibility with those.

Allowed speed is not as simple as just where you are; it also depends on the trackside signals and how the track in front of you is lined and/or occupied. For example, if you are 1 mile from an interlocking you might be able to proceed at track speed because you will be going straight through it (clear signal) or you might need to slow down to, I.e., 20 mph as you are going to go through a switch to another track (approach diverging signal). One of the main complexities of PTC is getting all that signaling data onto the locomotive, combined with the route and rules, so that it can actually make the right decision. (Keep in mind that on the US's relatively slow freight railroads "cab signals"; I.e. seeing signal indications in the cab of the locomotive, is relatively uncommon. Signals are generally trackside only and are also often 50+ years old. They work fine, but they're not exactly networked in any modern sense. Updating all this trackside equipment is one of the primary costs of implementing PTC.)

Be's use of C++ (at the kernel/library API/ABI level) would have doomed it in the long term IMHO. There have been several incompatible C++ ABI bumps since then, all of which would have broken compatibility. See the current Be clones which still have to use an ancient version of GCC to not break compatibility with existing software.

NeXT's ABI interfaces (C and ObjC) were and are much more stable.

(I'm not saying don't use C++, just don't use C++ and expect a stable binary API. You need to wrap it in a C API instead unfortunately. There's too much magic in C++ to have a stable ABI and still be able to evolve the language.)

How do you plan on supporting user/process level coroutines and multiple stacks / stack switching within the same turf? Obviously the CPU needs to be involved because you've got all the ancillary belt and spiller state that needs to be switched as well.

For that matter have you guys touched on how stack unwinding is going to be handled yet? How do I implement exception handling, longjmp, CL's non-local GOTO, etc?

They've repeatedly said they want to run current software well, presumably including software that forks and does not follow up with exec (regardless of how ill-advised that may be; obviously opinions vary on this). Trapping to emulation on fork would seem to fly in the face of this.

That being said I'm still not sure how you can get all of fork's semantics out of this mechanism...

(For that matter various sneaky VM aliasing tricks ["magic" circular buffers mapped twice in a row so that any size and position block is contiguous, same file mapped in multiple processes with different (non-contiguous) memory mappings] are going to fail miserably with the virtual-addressed cache. It may well be worth not being able to do those things for the benefit of moving the TLBs, but it also flies in the face of "will run current software.")

Thanks, that's very interesting. Seems like it'd also be "interesting" to write a compiler for though, especially since you have to manage stack hygiene for four stacks simultaneously. And I'm not sure, but doesn't allowing each functional unit to directly read the top four entries of the other FUs' stacks reintroduce some of the kind of potential hazards that the Mill belt (with its SSA-style usage) tries to avoid?

Yeah, who knows. I mostly think the Mill is a pile of interesting ideas that just might, if they're very lucky, eventually become a product. I'm certainly not holding my breath though.

Regarding their intentions, they've said repeatedly that they want to sell chips. It'd therefore be pretty stupid IMHO to not open up as much as they can the toolchain to get software to run on their chips, including the specializer. For that matter they should definitely also be releasing the chip specification data (insn/op bit patterns, functional unit slot arrangement, latencies, etc) that's used to create the specializer so people can roll their own if they want.

Then again this is the same world where Intel ME is an ultra-suspicious closed blob and you can't get datasheets on tons of chips to save your life, which makes no sense to me either. So I'm probably not a very good judge of what's reasonable.

Well, their exposed ISA and ABI are probably considered to be genAsm, which is the aforementioned mostly-LLVM-based IR. The concrete machine code will mostly likely only ever be generated by the specializer in the real world. Consider the specializer to be the static software equivalent of the x86-to-uOp decoding core in the hardware of a modern x86. On the one hand it can only make static scheduling decisions, whereas on the other hand it can look at the entire program being translated to make those decisions rather than just the window of instructions the x86 decoder can see during execution.

I really think this is the only path to make a long-term-viable staticly-scheduled architecture. Otherwise you'll wind up with the Itanium problem, which is that you eventually need to rewrite/reorder code internally (in hardware) as your architecture evolves, which kind of removes the advantage of having the static scheduling in the first place.

The impression I get is that their odd assembler is pretty much there for development expedience while they are hand-writing assembly. I can't imagine that their specializer (the thing that runs at install or run time which converts the generic load module to specialized concrete machine code for the processor you have) will produce as an IR form assembly that will then go through a C++ compiler... that would just be crazy. And the weird C++ assembler is definitely for the concrete machine code; the generic form is supposed to be very similar to LLVM IR.

Amongst other things it (a C++ assembler) would be slow as hell and require a huge amount of runtime. Ideally the specializer would be a single binary that would convert a generic load module to a specialized one with no intermediate steps. My guess is that they will generate such a specializer with their current generic specification tools.

The Mill belt is actually (conceptually) a fixed-size FIFO queue; LIFO stacks have been done reasonably often before (see stack machines) but since there's only one stack head they don't support parallel operations particularly well.

The iPod mounted as a perfectly-functional Firewire disk, yet you still had to use iTunes to put music on it for it to be playable on the device. (It was filed away in obfuscated filenames...)

Yeah, that would have been more interesting.

This is technically a meow generator generator.

The RTGs on Voyager weighed 37.7kg for 157W (initial) of electricity. The later RTGs on Galileo and Cassini weighed 57kg for about 300W.

[1] https://en.wikipedia.org/wiki/MHW-RTG [2] https://en.wikipedia.org/wiki/GPHS-RTG

It's the first single orbital booster to have been launched from two sites actually, much less landed. The shuttle almost made it to a second launch site and would have been first here until they killed the Vandenberg pad after Challenger.

There's also a "sudo" for windows distributed as a chocolatey package that I've used for at least a year. Appears to do pretty much the same thing as this one.

https://chocolatey.org/packages/Sudo

Wouldn't the spinning one see the other "orbiting" rather than spinning? If gravity is not strong enough to cause that orbit and there's no thrust evident that could explain the delta-V causing the orbit, couldn't you then conclude that you're spinning without an external reference?