An example give by donho is "SomeProject : a macOS port of Notepad++" so it seems like the name can be used which will make it appear in searches. It just has to be clearly something else.
You can tell people what something is, that is nominative use of the trademark. Actually putting it in center of the branding might be infringing, but Don Ho gave their blessing to use that, so that point is moot anyways.
The only place I see that is from a user "LiEnby" not "aletik", and none of aletik's existing messages are edited. All replies I see with the message are also to LiEnby. I don't agree with aletik's slow response in any way, but I don't think your claim is correct either. Do you have anything to prove that this was said by aletik?
If that’s the case good catch. I had the whole conversation unhidden and it was riddled with odd quotes. My bad for the misrepresentation. My conclusion still holds, fork author is a fool and is playing the slow game for no reason.
All good, and agreed the fork author is in the wrong here. I just like keeping the facts straight since that can inform better arguments and discussions.
I've been interested in doing something similar in the past, but I could really never solve issues like domain squatting and stopping individuals from claiming every name possible. Do you have a place where you keep these plans or have discussions around it? Or even just a place where I could get updates if anything does come of it?
> I've been interested in doing something similar in the past, but I could really never solve issues like domain squatting and stopping individuals from claiming every name possible
I think that's just a property of a naming system. Without something like a centralized threat of force that can know every person participating in the system - there really is no recourse. The approach we are taking is making it difficult to create a speculative market around names which seems to be the driving force behind squatters.
Happy to discuss it in more detail: hackernews@sepositus.com
(Note: that's an alias that goes to my email address which I avoid putting in public places for obvious reasons).
As someone from the US I would suggest viewing both as adversarial. I don't really trust my own government, but if I was born abroad I would trust them even less.
Warp SIMD-width should be a build-time constant. You'd be using a variable-length vector-like interface that gets compiled down to a specified length as part of building the code.
Now that I could agree with, the only place where hiccups have started to occur are with wave intrinsics where you can share data between thread in a wave without halting execution. I'm not sure disallowing it would be the best idea as it cuts out possible optimizations, but outright allowing it without the user knowing the number of lanes can cause it's own problems. My job is the fun time of fixing issues in other peoples code related to all of this. I have no stakes in rust though, I'd rather write a custom spirv compiler.
A compile time constant can still be surfaced to the user though. The code would simply be written to take the actual value into account and this would be reflected during the build.
I don't have a lot of faith there, but that's mainly due to my experience being correcting peoples assumption that all gpus waves are 32 lanes. I might be biased there specifically since it's my job to fix those issues though.
Door knob seems to return a bunch of chess pieces and analog sticks, I did get a few doors and a few knobs, but nothing I recognized as a door knob. I didn't spend a super long time looking though so that might have been the problem there. Also suggestion, giving the ability to link to specific models might be useful (I tried a few things on mobile, url doesn't change and searching for a specific model ID doesn't return the model).
From the last time I looked at these recompilation projects, they take the assembly and basically convert each opcode back into an llvm instruction and then recompiled from there. This comes with a lot of caveats though, last time I looked at it we still needed a function map of some kind to tell us where all the functions are and you still needed to replace chunks of the generated code afterwards for things like rendering, sound, controller input, and just about anything that would interact with the world outside of the cpu.
Edit: After some reading on the github page, it seems they are translating it to c++ instead of using llvm directly, but the original idea still holds. They aren't decompiling it to c++ that looks like original source code, it more like they're converting it to c++ that emulates the processor and gets statically compiled.
So it's not really just a drop and go replacement like it sounds like it'd be, but it has so far enabled the recompilation of multiple n64 games. This seems like an extension into the ps2 space.
Side note: The ps2 is a 32bit console with a 64bit alu (and some 128bit simd)[1]. So a lot of the weird tricks from the 8bit days weren't really used here. Not that there aren't weird tricks, just things like using undocumented instructions and racing the beam are less prevalent. I could be wrong here, I was growing up at this time not making games. All of this is just from research I've done in the past. Someone feel free to correct me if I'm wrong.
reply