Readit News91edec commented on The merge vs. rebase debate graphite.dev/blog/why-ban... · Posted by u/thunderbong
But does that still lose the source commit long term? What I'd love to have is a mechanism that keeps references to the pre-squash commits at blame granularity, allowing one to dig deeper into the commit messages associated with a given line. Kind of like a sourcemap, but for squash instead of transpile.
When you squash merge on github the new commit references the old PR. If you don't delete branches on merge you would keep the commit history on that branch, but then you have to battle with branchs persisting forever.
91edec commented on Show HN: I built an AI language teacher to get you speaking gliglish.com/... · Posted by u/fabiensnauwaert
Add Danish!
91edec commented on Counter-Strike 2 – Limited Test for select CS:GO players counter-strike.net/cs2... · Posted by u/swores
I don’t play CS anymore so I don’t appreciate this firsthand. Besides the smokes, it looks pretty much the same. Do the physics feel different or something?
My understanding is that this is CSGO ported to source 2. I’m not clear on what the differences between the engines are, or if it was a rework of the original engine or completely new.
The new tick system will mean physics will be the same for everyone in matchmaking and pro. Previously 64 and 128 tick had different physics for grenades. Now thats completely eliminated.
91edec commented on Counter-Strike 2 – Limited Test for select CS:GO players counter-strike.net/cs2... · Posted by u/swores
Looking at announcement video that makes emphasis on smoke: have they ever seen smoke? Effect of a smoke grenade?
It is not meant to be a real life smoke grenade, its meant to be a gameplay mechanic. This new smoke grenade is great because it introduces counterplay and tactics.
91edec commented on The cloudy layers of modern-day programming vickiboykis.com/2022/12/0... · Posted by u/antirez
Like many other commenters (of a certain age?), I too have this unsatisfied feeling about a particular kind of modern software development. The kind where you never really dig down and design anything, you just plumb a bunch of stuff together with best practices you find on stack overflow.
Many commenters are attributing this problem to the modern high-level tools we now have access to. But I don't think this is the crux of the issue. You can face the same issue (you're plumbing things, not a designing a system) whether you are working with low level or high level components.
Heck, you could be working on a hardware circuit, but if the only thing you had to do was make sure the right wires, resistors, capacitors, etc. were in place between the chips you're still just doing plumbing work.
To me, one of the most satisfying things about programming is when you can build something great by starting with a concept for your lower-level primitives, your tools, and then work up through the higher levels of design, ultimately having the pieces you designed fit together to form something useful to the world.
This building-things-to-build-things idea is even satisfying in other areas. Just gluing a bunch of wood together to make a piece of furniture is fine, but building your own jigs and tools to be able to do the kind of cuts that enable the end design you envision is way more satisfying, and opens up the design space considerably.
If I had to lament anything (and perhaps this is what's most in alignment with the post) it's that most of the high-level primitives you touch these days tend to be sprawling, buggy, not focused, and just generally not of high quality or performance. It's possible for high-level primitives to avoid these pitfalls (e.g. Sqlite, the canonical example) but it does tend to be the exception.
I think there is still plenty of interesting and satisfying software engineering work to be done when starting with high-level libraries and tools. You just need to think about how to use their properties and guarantees (along with maybe some stuff you build yourself!) to enable the design of something more than just the (naively-plumbed) sum of the parts.
I came to this same conclusion last week when I started writing my own webgpu renderer. I went into it with no knowledge of graphics and without using libraries. Having to create my own generic abstractions for pipelines, passes and buffers has been a massive creative and educational experience.
I haven't felt this satisfaction from programming in years from my day job.
This is when I repeat my silly joke that I'd rather see Skeletor doing live coding than another anime girl with pitched upvoice.
Enough furries and anime girls, people. They are cute, but there is more to animated art
Live coding with an animated 40k Ork is something I never knew I wanted.
This shouldn't be controversial to say, but it's blatantly obvious that it's a voice changer.
My headcannon is that Asahi Lina is actually Marcan since they both have a Spanish accent/twang.
91edec commented on Valve Introduces Proton Next linuxgamingcentral.com/po... · Posted by u/WallyFunk
That makes sense from a hardware point of view. I was wondering whether there would be issues using a Steam account from an unsupported country.
It requires a Steam account in a supported country to order. But after receiving it, can you log in to an account from a different country? Technically it should be doable. But there might be some policy that stops it from working.
You can buy a Steam deck from any country and use your account, the deck isn't account locked. For example my friend bought a deck in the UK, moved to America and changed his region then came back to pick it up. We were both able to log into the device UK & US.
For normal PC's, realistically Valve/Steam are the only people who could solve or implement this for PC games as they have the tech and platform to distribute it all. Even with all that its a crazy task to try and solve due to all of the variations and new patches for games that require the shaders to be recompiled again.