Laremere

Wasm makes no distinction between signed and unsigned integers as variables, only calling them integers. The relevant operations are split between signed and unsigned.

https://webassembly.github.io/spec/core/appendix/index-instr...

See how there's only i32.load and i32.eq, but there's i32.lt_u and i32.lt_s. Loading bits from memory or comparing them is the same operation bit for bit for each of signed and unsigned. However, less than requires knowing the desired signess, and is split between signed and unsigned.

Wasm has a great benefits over those technologies:

- Wasm has verification specification that wasm bytecode must comply to. This verified subset makes security exploits seen in those older technologies outright impossible. Attacks based around misbehaving hardware like heartbleed or rowhammer might still be possible, but you, eg, can't reference memory outside of your wasm's memory by tricking the VM to interpret a number you have as a pointer to memory that doesn't belong to you.

- Wasm bytecode is trivial (as it gets) to turn into machine code. So implementations can be smaller and faster than using a VM.

- Wasm isn't owned by a specific company, and has an open and well written specification anyone can use.

- It has been adopted as a web standard, so no browser extensions are required.

As for computation on clients versus serves, that's already true for Javascript. More true in fact, since wasm code can be efficient in ways that are impossible for Javascript.

Yeah it's not a hard thing to do, but I think Zig does it very cleanly.

As for reading structs, that's supported too: https://ziglang.org/documentation/master/std/#std.io.Reader....

readStructEndian will read the struct into memory, and perform the relevant byte swaps if the machine's endianness doesn't match the data format. No need to manually specify how a struct is supposed to perform the byte swap, that's all handled automatically (and efficiently) by comptime.

This is a reasonable way to do things, and I've used it before. However I just used Zig's method here, and like it a lot: https://ziglang.org/documentation/master/std/#std.io.Reader....

Given a reader (file, network, buffers can all be turned into readers), you can call readInt. It takes the type you want, and the endianess of the encoding. It's easy to write, self documents, and it's highly efficient.

This aligns with my prior likely release hypothesis, informed by this excellent deep dive article that looks at a lot of the arguments for either the wet market or the lab: https://www.astralcodexten.com/p/practically-a-book-review-r...

My favorite quote from the article: Fourth, for the first time it made me see the coronavirus as one of God’s biggest and funniest jokes. Think about it. Either a zoonotic virus crossed over to humans fifteen miles from the biggest coronavirus laboratory in the Eastern Hemisphere. Or a lab leak virus first rose to public attention right near a raccoon-dog stall in a wet market. Either way is one of the century’s biggest coincidences, designed by some cosmic joker who wanted to keep the debate stayed acrimonious for years to come

> 5. Engineers are not turned off by jargon—in fact, they like it.

I think the point is right, but the reasoning is off. Jargon (at least in engineering) isn't a secret language for the benefit of confusing outsiders, but more words that have more specific meaning than more common words. Eg, "Use our API to run your container images" tells me a lot more than "Use our product to run your software". Software could've been compiled binaries, virtual machine images, raw code, excel macros, whatever. This ties into other points about how engineers evaluate products.

I doubt NASA wants to put 4 astronauts on the next Starliner flight. So if NASA declares this crewed flight test a failure and requires a redo (and possibly even reverting back to a third out of one planned uncrewed flight test), Boeing is still on the hook for their operational 6 crewed flights.

Here's the problem: Starliner flies in the Atlas 5 rocket. Which is officially deprecated and all of the vehicles that will ever built have been booked. Which would mean that Boeing has to nicely ask Project Kepler for one (or more) or their remaining Atlas 5 slots. All of this also pushes back the final flight of the Atlas 5. Starliner already has 5 years where it's the only mission in that rocket, requiring hardware and operational knowledge to be on retainer just for Starliner. At least the pad that launches Starliner can also do Vulcan launches, so they won't be hogging a launch pad just for this problematic program.

If you enjoy this kind of interaction with a narrator, I recommend the game "The Stanley Parable".

Since people are making assumptions based on the title: The video is stating that if you're making a game from scratch, you shouldn't make a game engine. Instead, you should focus on what you need to implement for your game specifically, and make that. I didn't listen beyond that point so I might be missing more, but it's not saying "use off the shelf game engines."

Interesting tidbit: Talking about the upcoming Crew Dragon flight being moved around: "We will let SpaceX use our first stage booster, they'll go fly a starlink flight, ahead of our flight to get a little shakedown of that booster. It had some moisture intrusion and we want to go ahead and get that booster flown. And so there's a win win there - flying our booster on a starlink flight before our crew flight."

The complete 180 here is great to see. For the crewed demo flight of Crew Dragon, they used a brand new booster. It seems NASA didn't like the idea of flying on reused boosters, thinking they had an increased risk. Now they're liking the idea of a booster being flown an extra time.

See these posts on the LLVM issue by Andrew. They clearly state that this functionality isn't going anywhere, just the method of achieving said functionality is changing:

https://github.com/ziglang/zig/issues/16270#issuecomment-161... https://github.com/ziglang/zig/issues/16270#issuecomment-161...

INAL, not legal advice:

The existing legal code which this bill modified is linked from the bill and available here: http://uscode.house.gov/view.xhtml?req=(title:15%20section:6...

In this, it defines "intimate visual depiction". I see nothing here that would qualify in an image of Trump being in a diaper.

INAL, not legal advice:

The definition of digital forgery references the existing legal code's definition of "Intimate visual depiction", which is defined here: http://uscode.house.gov/view.xhtml?req=(title:15%20section:6...

So if you take an otherwise legal picture of someone, and add a filter which, eg, gives them a big forehead, you're fine. However, if you take a picture of and use it to create realistic porn of that person, that can sue.

The bill is here: https://www.congress.gov/bill/118th-congress/house-bill/7569...

Which links to the legal code which is modified here: http://uscode.house.gov/view.xhtml?req=(title:15%20section:6...

The original legal code defines "intimate visual depiction".

That doesn't match my recollection. The Gameboy is a early counter example: it was black and white during a time where the game gear had color, yet the Gameboy was far more popular. Also I believe the Xbox was more powerful than the GameCube.

Primary reason is that it removes a dependency on libclang, and as such is required to remove the LLVM dependency.

The Zig compiler has used Data Oriented Design for a long time, so any recent version has that, yes. The most substantial part of running the compiler right now is LLVM, hence the focus to provide an alternative. The other big focus right now is incremental compilation, which will make recompilations very fast.

Yes.

translate-c is not required for compiling pure Zig code. However, the plan is to remove the "@cImport" built in. So if your project is importing a c header, in the future you'll add build step translating it from c to Zig, and then you import it into your Zig code as a module.

Perhaps the most important part of evaluating a software dependency is identifying it's structural risks to your business/project. Eg, if you're relying on a business's product, does them going bust mean the end for your project.

In Google's case, they often will create an open source project in license, but not community. They take the reigns and hold them so tightly that if they let go, nobody is there to pick them up. Compare this to projects created by a single individual: for those to grow in contributors, diversification happens automatically. Transitioning a project in a healthy way requires others to already be actively contributing, and probably in a minor leadership role.

The thing here isn't that Google is obligated to spend engineering resources on this forever. It's that the systemic risk of choosing a major Google product at first appears low because Google is one of the most successful companies in existence. However, it's actually very high because they have a history of the above behavior.

Jared Isaacman and SpaceX already made a proposal to NASA to do a Hubble servicing mission. NASA recently responded with "no thanks". NASA feels the risk of potentially damaging Hubble in some way (eg, gas from thruster getting on a mirror) outweighs the benefits. Basically a high probability of worse performance is chosen to be more favorable than a lower probability of better performance.

Dust that isn't in light is accounted for, and is a different thing from non-baryonic dark matter.

See: https://en.m.wikipedia.org/wiki/Baryonic_dark_matter

The conclusion addresses your point:

> Without FSD, you pay attention to the road and everything else is within your control. With FSD, you still need to pay attention but now there’s the additional cognitive load to monitor an unpredictable system over which you don’t have direct control.

For the author, FSD is a worse experience in addition to costing a lot of money.

Yes, I've made what is intended to be a perfect solver (Although it in some testing it's clearly making mistakes, so I have some debugging to do yet). I'm making it because I was nerd sniped into thinking through how to handle some of the trickiness with the solving. It's not an AI in the LLM or machine learning sense, but in the previously common use of the term (eg, deep blue), or in the video game sense.

Can you please share the specifics? I'm trying to make my own AI for this game, and would like to compare mine against random play to estimate its strength.

Also, in your listing of your ai beating the random, how are you counting drawn games?

The other external view we got was mounted on one of the other flaps, and we didn't get footage from it even after the camera we did get was obscured. So some amount of damage/overheating on multiple fins is likely.

A noble idea that looks to be mired in bad design.

Once again Google ties a product to a subscription service (beyond whatever lte connectivity which would be needed anyways). They seem to be always chasing getting that recurring revenue by adding unnecessary features. This adds little value, greatly increases the maintenance cost for Google, and puts the risk on the customer for whether Google will continue thinking it's worth it.

Worst of all, "Games". As a lover of games as an artistic medium, and a game designer myself, I'm just so tired of gamification crap being added to everything else. Flashy graphics and numbers going up are the "sugar" to games' "nutrition" of interactive experience, mechanical exploration, and emotional expression. Rewarding children with external rewards over building internal motivation is dubious at best, and incredibly harmful at worst.

This article was posted on August 28, 2023. The giraffe was born 31, 2023. So presumably none of the models tested included this particular giraffe in its training data. To directly compare it to GPT-4o, which was released recently, is an invalid comparison. I wouldn't be surprised if GPT-4o does better on novel recognition tasks like this, but you'd need a new novel concept in an image to directly compare GPT-4o and the models tested in this post.

I did. I didn't say it was a weather scrub.

For anyone who doesn't follow rocket launches: Launch scrubs happen /constantly/. It happens to everyone, and a single scrub is not a sign of problems with a program.

If it takes multiple scrubs with months of delays before it finally launches, then it'll be another thing to add on to Starliner's list of difficulties fulfilling their contract with NASA. However a scrub or two is business as usual.