Eyas

Some things to correct here:

- While drugs laced with fentanyl are also a problem, lots of people _do_ knowingly consume fentanyl. In fact, it has replaced Heroin in the US 'market', for example. It is also a contaminant in other drugs (cocaine, meth), due to how easy it is for fentanyl to stay in crevices, etc. It is also 'snuck in' to counterfeit pills, which is the only aspect you mention.

- The traffickers physically moving fentanyl into the country are overwhelmingly Americans. Pre 2019 traffickers used to get this straight from China, but stricter controls in China have shifted things to be staged in Mexico instead.

- The demand and traffickers are still largely American, and it is a "symbiotic" problem. US drug demand is empowering Mexican cartels and making everyday Mexicans less safe (the cartels also get most of their guns from the US). At the same time, powerful Mexican cartels mean it is much easier to "stage" fentanyl in Mexico then import it into the US than the older model of importing it directly from China.

The best pattern I've seen is hash the request and validate that it is the same one. If not, error out as it is an invalid argument.

"Best guess" can be bad if it is not well-defined, but you can still make error detection obvious rather than hidden.

Was I the only one that found `docs.fastht.ml/llms.txt` more useful than both fastht.ml and docs.fastht.ml?

Zooming out, it's interesting how many (especially dev-focused) tools & frameworks have landing sites that are so incomprehensible to me. They look like marketing sites but don't even explain what the thing they're offering does. llms.txt almost sounds like a forcing function for someone to write something that is not just more suitable for LLMs, but humans.

This ties in to what others are saying: a good enough LLM should understand a resource that a human can understand, ideally. But also, maybe we should make the main resources more understandable to humans?

It probably can in a .cc file but if you're importing another library and just have access to the header, it wouldn't know how to.

Most of the links here help with your immediate questions, but if starting with base concepts and first principles is appealing to you, I have to recommend:

- the MIT Operating Systems Engineering OCW course [^1]

- specifically, Lecture #2 [^2] which describes the bootloader for 'xv6', a reimplementation of Unix v6, which does a great job showing what a solid OS with all the basics look like

[^1]: https://ocw.mit.edu/courses/6-828-operating-system-engineeri...

[^2]: https://ocw.mit.edu/courses/6-828-operating-system-engineeri...

Honestly I kind of just enjoy writing. My blog has gotten tons of views and still gets a fair amount of traffic, made on HN's front page a bunch, and have some post translated to a few languages.

I haven't actively tried to monetize it (though I'd like to shift to income based on my own work rather than be tied to a company). I tried putting ads once in a while and it was ~decent but negligible, and kind of ruined the vibe. I have done a few one-off consulting things out of it and got some nice side-cash, but nothing meaningful.

What I do get is feeling engaged with the wider tech community. Seeing common questions and comments. A feeling that what I'm saying might resonate with some people. Interesting discussions on Twitter and HN. A few podcast invites, etc.

"What did the Arab"

1. say the moment he left the White House? "No wonder they hate us."

2. man say to the Arab woman at the bus stop? 'Your dad's the bomb!'

3. guy say when he saw a woman driving a car? "Finally, a woman who knows how to use a clutch."

hmmm

Right, but their claim is that there were proper separations that successfully did limit the blast radius.

I'm glad to hear! My series, starting with "Basic Concepts in Unity for Software Engineers" [0] is exactly designed for this and borne out of a frustration in much of the existing content.

Some folks in the replies mention just starting to code and while I totally agree, it was also helpful for me to understand... at least the concepts.

TBH when I started, the main way I did this was my finding a course on Udemy and watching it at 2x speed, still being bored out of my mind for huge chunks of it.

[0]: https://blog.eyas.sh/2020/10/unity-for-engineers-pt1-basic-c...

Sorry to hear that. I write/preview on desktop first and typically like the legibility that comes from the line spacing, etc.

What would you change to make this a better desktop experience for you? Less of the full-width photos? Text that spans wider, or just lest line spacing?

I totally agree with you. I think there are two types of "Where do I start?" that folks wonder:

- Say, I know what I want to build exactly where do I start? a.k.a -- What's the equivalent to starting at the DAO / API layer and building the integration later, in the gamedev world?

- I know I'd like to make games, where do I start coding?

I focused a lot in the article about that first question (and only briefly alluded to prototyping, etc.) -- mostly because I was interested in the theoretical question of engineering practices.

Trans folks in the LGBT movement were an inextricable part of the movement since day 1. Partly because distinctions at the time between gay men who did drag and trans women did not exist, but also partly because the overarching theme of the movement (and the hate it received) has been the sense of 'disgust' by mainstream society of its subversion of heteronormative values.

Many trans men and women lead the movement vocally when many gay men and women who could survive in the closet sat and waited.

But that's the thing, the good faith discussion happened so many times, and it has been litigated many times. For many of us, trans and non-binary folks gave us many of our rights, and they did not out of a sense of solidarity, but literally because they were fighting for the same thing (really, a revolution against gender norms and expectations).

As the gp said, however, this good faith conversation happens a few times (and has been litigated to death over and over, and continues to). But the domination in the "drop the T" movement is really dehumanizing language about trans people, accusing them of an agenda, brainwashing children, etc. It's really harmful, and it is things that gay, lesbian, and bi folks have been accused of already.

How do these work? Is it like going to the tiny settings menu and swapping the source on a monitor? I know the HDMI standard includes a way for an input to "request" a source to switch to it, are monitors with multiple inputs smarter about that sort of thing?

My work device is a Chromebook unfortunately and the policy on installing some of this stuff on it (e.g. also Mouses without Borders) is no good.

Maybe part of the reason this problem is less common than I'd imagine is because companies are not typically as strict on what you install on your work machine? My last job certainly was.

Oh certainly not "check up", but try to get a human to look at it and respond to the appeal with more than boilerplate.

Sure, to me the ridiculous part is:

- it's weird to be mistreated by your employer's own product (just the irony bend to it)

- if you want to appeal after a dead end, your choice is to make a huge public PR nightmare, or try to make an internal post/plea that gains traction. you'd be doing your own employer a service if you could have this issue resolved without a PR nightmare

This story is just absolutely ridiculous: The poster _works at Google_ and even tried to escalate internally for days, to no avail.

Gatsby doesn't offer a syntax highlighter out of the box. It has markdown (and MDX) components that generate pages, and those in turn can have syntax highlighting plugins. AFAICT prismjs indeed is the predominant one used by Gatsby sites (at least, in mine). But thanks to SSR prismjs will typically run at compile time.

Thank you! I'll bookmark this comment as I'm trying to take stock of what would be most helpful.

There are two kind of opposing directions I see a need for:

- "Beginner Unity" take tailored for an Engineer. E.g. let's talk about the input system, frame-rate independence, overview of rendering/lighting, a high level overview of the editor, etc. And get that out of the way.

- Satisfying what I might call a thirst for idioms/best practices from a SWE perspective. E.g. separation of concerns in MonoBehaviors, using ScriptableObjects, etc. Also maybe overview of things like "Should I still use Git with Unity or look into Collaborate?" and the like.

My current sense is that I'll end up toeing the line between these two. But, regardless of this specific series, I enjoy writing about best practices and software patterns in anything I'm working on, and Unity is no exception -- so stay tuned!

I am not, it's news to me!

I'm with you there, but (and, this is an unpopular opinion) I think it would be even better if it went the way of Go. Go will randomize iteration order of unordered collections (at least in development builds?) on purpose so you learn not depend on it. The "tricky" thing with Unity is that you might find a consistent client behavior and unknowingly depend on it.

I think with time/experience you'll learn to spot what to ignore (frame lengths, etc) and what you could count on. And just to test fully-build games often, and across clients.

* C# does something similar with hash across builds (so you don't depend on serializing/deserializing hashes and expect them to work; they want the freedom to change hash functions).

Instructions of a "God" game object, try a ScriptableObject! But you're right cross object communication is tough.

I end up relying on asset-ized SOs to do a lot of this. When communication between any two nodes is mostly one directional, events and triggers work great. (Ryan Hipple has a great talk on this, just search for "Ryan Hipple ScriptableObject".

Maybe a less intense example here is, for example, custom shaders. You can get better terrain systems that do exactly what you want, etc from the Unity asset store.

Especially for a software engineer, there's of course always the fantasy of coding everything on your own. I might not get a platformer system because that seems "fun" to implement, but shaders often feel so beyond me that I'd just rather get someone's optimized shader.

Unity is unlikely to unseat Unreal as the primary engine used by AAA games/movies, but it still has a decent share in both AAA games and movies.

Still, the game engine market is unlikely to be dominated by a single player anytime soon. I think you'll continue to see something that looks rather similar to the mobile OS space: lots of players, but ~2 dominate the space. Unreal's revenue cut is also a lot more prohibitive than Unity's, so you'll also keep seeing a healthy indie ecosystem (which translates to a community, assets, etc.) in Unity.

A lot of Unreal's recent investments are incredibly impressive. Especially with better rendering and realtime raytracing. But Unity is also making some big investments, DOTS (see https://unity.com/megacity for example) comes to mind in particular.

That might be true for for some terrain systems, but AFAICT it is still common for other objects (e.g. units, buildings, etc.) to be loaded like that.

There is a market for purely code-generated games, and especially so with procedurally generated games. But honestly, for most cases, yes I think the 90th percentile answer is to get over this.

I kind of wrote about "keeping it all in code" and why it isn't desirable in the second installment: https://blog.eyas.sh/2020/10/unity-for-engineers-pt2-six-pra...

But once you get the placement / connection / injection right, you'll still be spending the bulk of your non-testing development time in the code editor.

Real DOD-style ECS is being baked into the core of the "new way" of programming Unity, but a lot of that is in preview packages. Much of how Unity is used today actually involves very little ECS.

See https://unity.com/dots

Totally agree! It's also actually a bit harder, I think, because making games is a bit creative/artistic. You'll often see forum posts/answers on "getting something to work" rather than "good architecture" (there are a few exceptions).

The second installment (already published) talks about some of these best practices, but it doesn't quite dig into architecture just yet.

I'll have to check out Heaps. But you're totally right that the "Unity way" of using the editor isn't how a lot of us would naturally gravitate to creating a game. I learned to like it, though (I think).

For me, I realized that wanting to "keep it all in code" is a learned habit, and part of why I learned it is because the tooling when everything in code is just so much better. I can navigate references, etc., count on compiler errors runtime errors, etc. But none of this fundamentally required me to keep it all in code _if_ the tooling allows it. With ~2020 it feels like the tooling is getting to that point.

It's not just about "developer interoperability" vs "program interoprability". Implementing Java APIs means that entire libraries can run.

Sure you might not be able to take a legacy SWING Windows Java app and run it on android, but you can run entire libraries in your android app. It absolutely _is_ about interoperability in both cases. Perhaps to varying degrees