Hacker Newsnew | past | comments | ask | show | jobs | submit | raverbashing's commentslogin

"slight modifications" it's entirely

In most places taxis can be identified as: having a specific color/color pattern and/or a ceiling fixture

It is by design because you want taxis to stand out from other vehicles


Computers got better, true

But those were much cooler than the ones today


Honestly this is not surprising, and as much as politics suck, the rocket equation sucks harder

Mars has a little bit less gravity than Earth

How big would a rocket need to be even to send a small payload (let's think 20kg/45lb) even suborbitally so that it can be caught by another spaceship

Now check how big a rocket has to be to send all of that from Earth

You'd probably have to send this on Starship. And refuel it while on orbit


https://scholar.google.com/scholar?oi=gsb20&q=Mars%20Sample%...

That paper outlines a plan to do it, which people have been trying to do since the 70s

Here is one that will launch soon: https://en.wikipedia.org/wiki/Tianwen-3


> The mission consists of 15 different vehicles and spacecraft plus two launch vehicles

Yeah still looks like an overcomplicated project

Maybe that's why China can make it work


I wonder how does this fits in the general Game development pipeline

Is it Story -> Characters -> Puzzles?

Theme -> Characters -> Story -> Puzzles?

Or everything everywhere all at once?

Are the character descriptions in this doc leading the Story or derived from it?

How much of the story is built around Gameplay and its limitations? (I think I remember GF requiring 2 CDs?)


I wonder how easy it would be to translate it today with LLMs and have a translated version running on ScummVM

Isn't ScummVM 2D only?

Nope, they integrated their sister project, ResidualVM, that does 3d

Interesting

I guess it would be "trivial" to have a bounty on each of the future numbers, since you could encrypt a bitcoin private key with it (it would probably make sense to do RSA -> AES key that encodes the BTC private key)


This makes no sense to me

If I think about asm:

function1:

    (do stuff)

    jp function1

    ret

function2:

    (other stuff)

    ret

main:

    call function1

    call function2

the 2nd call might happen internally due to branch prediction but in practice it shouldn't and the processor fixes this

Oh yeah and TFA also goes with:

> The funny bit is that C got this right.(...) but C included one more rule: loops whose controlling expression is a constant expression may not be assumed to terminate.

Well, duh! A broken clock is right twice a day it seems


With UB the compiler has no particular requirement to emit the 'ret'. (or, in the example, anything at all for the function)

They do

x86 bytecode is bytecode


I mean don't modern CPUs basically just run an x86_64 emulator on a RISC machine anyway? Like there's a layer between the microcode and the actual x86 instructions already.

No, that's a myth. It's true that the instruction decoder in a CPU core translates from ISA opcodes to micro-ops for the backend, but those micro-ops are in many cases functionally very close to the ISA instruction and decidedly not RISC-like. For example, the ADD r/m64, imm32 instruction (read from memory, add constant, write to memory) is translated to a single micro-op on several Zen architectures [1], which is far from anything you could call "RISC".

[1] https://uops.info/html-instr/ADD_M64_I32.html


No, they don't. x86 is a superscalar processor, and it does what all superscalar processors do--translate the instructions into µops for execution and dispatch to the various execution units, with the µops not being 1-1 with the original instructions. However, it was supposed to be impossible for a CISC architecture to be superscalar, so this is what spawns the myth that it's somehow cheating by executing a RISC architecture under the hood.

Thanks, I didn't know that and now I do.

Reality is very different.

The fact that x86 is not RISC, it contains many instructions which support memory as the source and destination or both, something which is often an advantage in terms of code density, and speed.


Yes, but the “architecture-independent” bytecode for these RISC machines that run underneath your various Intel and AMD CPU models is the x86_64 instruction set.

I think it's more like a (kinda) VLIW machine but yes, pretty much

VLIW implies packets of different independent instructions that can be executed in parallel. I dont think this definition is ever true for the vast majority of x86 instructions.

that bites

Yeah, works if you're 2h away from the venue.

Im away 6h from the venue and 3h from my family.

Come on...


> That marketing guy should not be talking to the press, as he does not have the skills

They have way more skills than the technical folk in doing that


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: