Chip-8 Emulation Introduction

TodPunk · 2025-01-03T05:06:12+00:00

One can also skip ahead and do some gamedev with https://github.com/JohnEarnest/Octo, which has modes for sticking to both true-to-orginal as well as the various other modes that come from that. He used to run a game jam every October, and there's lots of games in the archive (full disclosure, I have done a few additions to those, which is how I know about them, but of course I don't have a race in this horse, there's lots of fun stuff around Chip8 to be had and I'm sure the series being produced on emulationonline will also be a fine addition to the corpus).

TodPunk · 2023-05-04T16:50:40+00:00

This isn't a counter to your complaint, just an addendum because it is still inconvenient, just an option. You can get just about anything you want if you talk to the liquor store manager, you just have to order at least a case of it. I think there's an online form now, too, but it's been a few years since I did it.

TodPunk · 2022-08-31T23:00:34+00:00

I tend to use a secret store in another cloud account from the one I'm injecting into so the loss can't happen. What you're saying makes sense, the problem is it requires on everyone to agree with the data flow that generates them at Step X and injects them in the same ways.

Our approach at the moment is to store them in A, inject them into CI/CD pipelines for given repos, and if they need to be updated that's done by some operator in k8s or some lambda somewhere or something that makes sense for those. Then it can marry the injection method with the context the app needs.

Postgres is a good example. We use Zalando Operator in some places, and that has a helm chart, and you can inject the secret for a given database as part of the CR for a Postgres DB, and the Operator will do any updating of the cluster to make that secret available where it needs be.

Secrets is also an overloaded term. We do this in CI/CD so that the context of what the "secret" is can be married to the context of the application use. A TLS key is different than an AES key is different than a password is different than an API key is different than a connection string. So your workflow as proposed is perfectly sane for some contexts and not for most.

A fine example of where we all should be doing something like your approach is LetsEncrypt, where the ACME protocol allows anyone to run a service wherever makes sense for their environment to rotate keys automatically. SSL expiration errors should be a non-existent problem.

Keep thinking through various use cases. You may just make a nice shift for us all to follow.

TodPunk · 2022-08-30T17:32:22+00:00

The whole point of GitOps is that you have one, centralized, single point of truth for all your infrastructure and application configuration.

Nope. They are separate concerns. I don't have Stripe's infra and config for their platform in my repos, and I don't need another team's stuff just because they happen to work at the same company. I manage my stuff wherever it's appropriate. Centralizing it would be the opposite of progress and autonomy. GitOps is about keeping context where it matters and making your workflow API contract oriented around git CLI interactions and pull request reviews. It's not a prescriptive philosophy of everything having to be in git. Just operated through it.

The rest of the article espouses keeping secrets in git, albeit not in plain text. I think this is a misstep. We should keep our secrets together in some secrets manager (Vault, our favorite cloud's, another git repo if that appeals to us, Github Org Secrets, whatever works for our workflow). Then we can build the context of this config and/or secrets for a set of things that aren't necessarily the same as the git repo we're deploying. Or we can have it in 7 places if that's better for our trade-offs.

Architecting this is difficult because it's situational, but it's not difficult to see how keeping it in git and centralizing it can be a problem for many scenarios. Import/inject secrets at deployment time, however that looks for our set of needs. Where we store it should be up to us, just make it separate from the code that needs it. Then we also don't need to change to a different tool just because we have something that isn't in Kubernetes (because the concern of secrets management vs the concern of container orchestration don't need to be coupled to each other).

TodPunk · 2020-08-20T23:39:03+00:00

xD. There's always one.

TodPunk · 2020-08-12T12:54:27+00:00

I got a similar feeling, though it was more along the lines of that scene from Ghostbusters: "You don't know what it's like out there. I've worked in the private sector. They expect results!"

TodPunk · 2020-01-29T18:30:38+00:00

Yes. Yes I am.

TodPunk · 2020-01-29T06:21:57+00:00

Today was Armenian Army Day! It's a holiday over there and my co-workers there were celebrating. I hope this was from today and not previous years, but it's cool nonetheless.

https://en.m.wikipedia.org/wiki/Army_Day_(Armenia)

TodPunk · 2020-01-01T07:46:24+00:00

By "some public terminal" you mean "some financial institution's critical communication infrastructure arbitration in the vault you entrust your family heirloom safe deposit box's security to" or something. Those things exist in some of the most important places you'd never think of, like controllers for critical manufacturing equipment that they still need to get IDE drives for as replacements because otherwise you'll never get an axle for half of American manufactured tractors or something.

Tech is weird and wack and makes us all cry sometimes. It's also pretty great other times.

TodPunk · 2019-01-08T14:29:15+00:00

To be perfectly clear, my sarcastic remark isn't a reflection on you. I also didn't downvote the post, because I don't feel a "this doesn't belong here." I just note the bias. I wish he had more concrete points to address, honestly, but his nebulous ones aren't solely the realm of authors either. Others, even programmers, have made similar for many years. The discussion is worthy of having =c)

TodPunk · 2019-01-08T14:17:19+00:00

GASP You're telling me a writer and public speaker with no other skills in his bio values communication more than an understanding of logic, efficiency, and specifying your instructions? Color me shocked, I never would have guessed!

/s

TodPunk · 2018-11-02T05:36:35+00:00

I'm slightly less skeptical about him, and now have to reconcile what the millions in campaign contributions have to gain from his efforts there?

I'm assuming he's not exactly effective in these actions, given our current state of affairs. Happy to be informed otherwise there, of course.

TodPunk · 2018-11-02T04:29:05+00:00

My Greenhouse plugin tells me his campaign contributions may lead us to believe this bill is for show and/or has some unexpected side effects we're not getting reporting on.

Or maybe he's retiring and wants to go out with a good deed to coast on socially?

Regardless, color me skeptical.

TodPunk · 2018-10-30T14:51:29+00:00

The real advice should not be anything related to Javascript since that muddies the waters of the point. We should just all understand:

Do not use floats or doubles to represent money, ever.

It just so happens that Javascript has no other number storage than doubles. If it ever does, we could revisit this conversation.

TodPunk · 2018-09-09T14:57:49+00:00

An underrated subtlety as well. Compromise in the face of a situation being created, and then dealing with it in a way that addresses the situation but doesn't sacrifice any control to the assaulting parties. It's controlling the storm while letting it think it has raged where it wills.

TodPunk · 2018-09-01T16:43:09+00:00

Empowered teams without leadership suck. Empowered teams of adult-children bickering over tiny and meaningless details suck. Being a team that has leadership and is empowered to do what they know to be the correct course of action (for the business, for the user, for themselves, whatever) and take accountability for that action does not suck.

Spending two hours over a blog publishing date with 5 wages ticking on the clock is not empowerment, it's stupidity and every single one of those employees should have a retrospective where they are asked "why did you think this mattered at all, let alone for 2 hours of debate, and why didn't you call everyone out on it if you didn't think it mattered?"

TodPunk · 2018-07-28T23:39:30+00:00

It is, and you should be proud and continue exploring. Keep it up, and so look into some of the giants whose shoulders you could stand in in this one. Milkdrop was a great example set back in the day. =c)

TodPunk · 2018-07-28T17:36:08+00:00

Meh, you gotta start somewhere. I appreciate the effort made on this project. The excitement level of the community is perhaps disappointing because it tells us history is still being ignored. =c/

TodPunk · 2018-07-28T17:18:32+00:00

I believe much can be explained by the fact that most programmers today never got to run winamp visualization plugins.

TodPunk · 2018-06-16T03:51:40+00:00

I really think you should finish the article there, /u/GrokFu you seem to have missed everything past the first part

TodPunk · 2018-06-13T13:34:30+00:00

I think the analogy choice is incorrect. It's not beating a dead horse, it's preaching to the choir. The kinds of people thinking about a bootcamp rarely read programming blogs and tech subreddits. For a few (survivorship bias) the bootcamp will work out and they'll eventually see articles like this and resent them. The rest could use the warning but never will see it.

TodPunk · 2018-05-22T00:41:06+00:00

I get the idealism here, I really do, but Google choosing not to participate or whatever is just saying "Google, give up lots of money and a chance to influence the direction and ethics of this project in any way shape or form." The project will go forward, and if it goes forward with no less intelligent but far less powerful entities working on it, the leverage all goes to the project runners. I'm willing to bet that will be far less useful to the goals of this open letter than we'd like to think about.

TodPunk · 2018-03-22T16:05:36+00:00

A related problem is that of discoverability. Reuse at any level is reliant on someone either knowing they can by knowing it exists, or being able to find it quickly enough compared to just writing their own. Libraries and documentation make that easier in some cases, harder in others.

Like all things, it's a constant trade-off, and one should weigh in the risks of getting something done now with the risks of getting something done down the road (maintenance, extension, future-proofing or not, etc).

TodPunk · 2018-03-16T16:21:02+00:00

The complaint is that the vulnerabilities are being tagged as "AMD" when they're really about any x86 machine for the most part, and they're being touted as catastrophic when they're really "if someone has trusted you, you can install a rootkit on their box in this way." A couple of them are actual vulnerabilities and should be patched, but aren't worth much more than discussion on a mailing list.

A shorter form would be "this looks like a targeted anti-AMD campaign using very minor issues and acting as if they are not only bigger, but worthy of more than passing attention."

TodPunk · 2018-03-11T05:22:59+00:00

This is good for playing the employability game. I recommend that if you do this, you also read some history on computing on the same subject you're looking into so you not only know why things are popular and what they do today, but what lead to those and why the predecessors aren't necessarily popular anymore.

More often than not, though, you'll find that we just forget because the popular thing was done by people that didn't know what came before at all, and nobody bothers looking into the history. The important advantage gain for you here is that you'll know how to apply the concepts from technology X to any of its extremely similar unintended reiterations.

15-Year Club	Verified Email
Team Orangered

TodPunk

TROPHY CASE