AbelianGrape

I've only ever seen "one-time" in cryptography to refer to One-Time Pads (OTP). They are literally uncrackable (because every possible plaintext could be encoded by every possible ciphertext) but they achieve that by using a shared private key. The cipher becomes attackable if the key is re-used, hence the "one-time."

But that key has to be exchanged somehow, and that exchange can be attacked instead. Key exchange algorithms can't necessarily transfer every possible OTP which means eavesdropping on the exchange would make an OTP attackable. So the best option we know of that doesn't require secret meetings to share OTPs* really is to use RSA encryption. Once we have efficient quantum-resistant schemes, they'll be the best option we know.

* and let's be honest, secret meetings can be eavesdropped on as well.

Bril is the only compiler IL I know of that is specifically designed for education.

R. Kent Dybvig's compilers course has had approximately 15 "intermediate" representations designed for his course since at least 2004 -- a consequence of teaching the course using the nanopass compiler framework for scheme. You could broadly divide these into "representations that are restrictions of scheme," and "representations that are increasingly-annotated versions of UIL" where UIL is the underlying intermediate representation. As far as I know, UIL was also designed for this course.

How does this compare with GumTree? It's weird that the page doesn't even mention existing state-of-the-art tools for this task.

edit: I've compared GumTree and difftastic myself while working on a project this past week. Difftastic is harder to use programatically (the JSON format is unstable and leaves something to be desired) but other than that it's miles and miles better.

Most recently, KeyWe and modded Keep Talking with friends. Solo, still ol' reliable slay the spire.

I have a plan to teach someone how to play schnapsen and crazyhouse chess tomorrow so that's exciting.

I find there's a lot less variety in my monster train runs. Most classes have a distinctly best strategy and the artifacts generally also funnel you towards that strategy. For example, I can't remember the last time I played an Umbra run that didn't set up a morsel engine behind a warden or alloyed construct - as far as I'm concerned, those are the same strategy, it doesn't feel different. The only other build I think is viable is just "play Shadowsiege," which rarely happens early enough to build for it.

Every class in STS has at least three viable archetypes and almost every run within those archetypes still feels different to me.

I almost exclusively play for A20 heart kills. I play all 4 classes but in a "whichever I feel like today" way. I tried rotating between the characters for a while and really didn't enjoy playing silent or watcher while in the wrong mood for those classes.

My favorite deck in recent memory was probably a silent discard combo with Grand Finale as the only damage-dealing card in the deck. My favorite archetype in general is probably ice defect. A good all-you-can-eat ironclad run is great too.

I don't think I agree that STS is especially well balanced - some regular hallway combats do irrationally more damage on average even to players much better than me (for example, floor one jaw worms or any act 3 darklings). In general, the game could be quite a bit harder on A20 and still be fun for players who want a challenge. It's also weird to me that A1 makes the game easier compared to A0. Between the classes, there is a class which is clearly stronger than the others. However I also don't think this is a bad thing. Imbalances create more opportunities for new experiences, and for different kinds of players to have different kinds of fun. And that certainly agrees with "infinite replayability." I'm sure in 5 years' time I will still be seeing interactions I've never seen before.

Second Shadow of the Colossus. The moments where you can just sit and look, coupled with the soundtrack, are some of the best in gaming history. Plus that bit of tension knowing what you're about to get into...

Not only is tunic beautiful; the experience is amazing. It's even better if you try to solve the main optional puzzle as you go.

Definitely agree that it's one of the best.

Some of these depend on dialect - where my family is from, gaunt and aunt rhyme, for example.

Of course, that makes it worse, not better :P

I'm a computer scientist mainly but with a heavy focus/interest in computer architecture. My plan is to teach at a university at this point - but it seems to me like that would be a good place to create completely open standards technology from.^1Specifically because if the point isn't to make money, there's no reason to create walled gardens.

There's certainly enough interest from people who want to be able to build their own systems. What would actually worry me isn't the ability to make a new open standard or any of that. It's that AMD64 is very hard to compete with in this space, because the processors are just faster, and there is so much x86 software that people who build PCs usually want access to.

AMD64's performance is the result of years and years of optimizations and patenting new hardware techniques, followed by aggressively litigating people trying to compete. ARM performance is catching up but ARM prefers licensing their core IP over making their own systems, making it harder for them to break into the PC space even if they want to.

A new player would be in for a long, long time of unprofitable work just to compete with AMD64 - which most people are still happy with anyway.

^1 some others and I are actually working on some new ISA / open soft processors for it. However it is focused at an educational setting and unlikely to ever be used outside of embedded devices at most.

Neither spectre nor meltdown are specific to Intel. They may have been discovered on Intel hardware but the same attacks work against any system with branch prediction or load speculation. The security flaw is inherent to those techniques. We can mitigate them with better address space separation and address layout randomization. That is, we can prevent one process from reading another process's data (which was possible with the original attacks), but we can't guarantee a way to prevent malicious browser tab from reading data from a different tab (for example), even if they are both sandboxed. We also have some pretty cool ways to detect it using on-chip neural networks, which is a very fancy mitigation. Once it's detected, a countermeasure can start screwing with the side channel to prevent leakage at a temporary performance cost.

Also, disabling hyper threading won't cut your performance in half. If the programs that are running can keep the processor backend saturated, it wouldn't make any noticeable difference. Most programs can only maintain about 70-80% saturation, and hyper threading fills in the gaps. However the result is that intensive, inherently parallelizable programs are actually penalized by hyper threading, which is why you occasionally see advice to disable it from people who are trying to squeeze performance out of gaming systems. For someone maintaining a server with critically sensitive data, that was probably good advice. For your home PC, which is low risk... you're probably not worried about exposure in the first place. If you have a Linux computer you can probably even disable the default mitigations if you wanted.

These would be performance regressions, not correctness errors. Specifically, some false dependencies between instructions. The result of that is that some instructions which could be executed immediately may instead have to wait for a previous instruction to finish, even though they don't actually need its result. In the worst case, this can be really bad for performance, but it doesn't look like the affected instructions are too likely to be bottlenecks. I could definitely be wrong though; I'd want to see some actual data.

The pentium fdiv bug, on the other hand, was a correctness bug and was a catastrophic problem for some workloads.