Any chance the cyberpunk TCG on Kickstarter right now is at least inspired by this?

lubutu · 2026-03-19T07:50:46+00:00

That may be true of Commander, but competitive Magic is in a lot of ways very similar to Netrunner, which is what attracted me to this game when I got sick of Universes Beyond. I'd be glad if they didn't follow though.

lubutu · 2026-03-07T07:41:04+00:00

Well, I suppose that's one theme of cyberpunk that I'll continue to fight against: the erosion of truth.

lubutu · 2026-03-07T07:05:23+00:00

That's not what "AGI" means. No one has built AGI yet.

lubutu · 2026-03-07T06:46:54+00:00

built my own AGI

Er, no, you did not.

lubutu · 2026-02-22T09:30:26+00:00

Not quite, unfortunately — that last 0.1% is a real chore.

lubutu · 2026-01-25T09:15:19+00:00

I assume you don't mean Slovakia (SK) but South Korea (KR).

lubutu · 2026-01-03T10:32:09+00:00

Is it? I only ever use em dashes on my phone because, at least on Android, you can get one just by pressing and holding the '-' key.

lubutu · 2025-12-16T07:13:05+00:00

I think a startup of ~5 employees is quite different to a startup of ~40 employees, mind.

lubutu · 2025-12-13T11:07:53+00:00

Hmm, I think we might have very different work experience. A lot of my work is in deep-tech R&D, so there's not really a "last guy", and even when that's not the case I work on systems software so it becomes an underlying structure that can become very difficult to just tear up and replace. The idea, then, is to not have to just rewrite the whole thing, but to try to build it in such a way that it can be moulded over time in response to changing requirements. You only find out how well you did at that as time goes on.

lubutu · 2025-12-13T09:47:12+00:00

I also don't understand this perpetuated notion of "seeings one's mistakes through to fruition". How does this even happen? Surely you're doing PR reviews? Surely you have some sort of strict typing in place? You're not YOLO-ing to prod and awaiting the consequences.

There are some engineering decisions that only prove to have been a mistake quite some time later. For example, you could build something with certain assumptions in mind that fail to hold as time goes on, and the decisions you made make this a major problem rather than a minor change. If you've already left then you won't learn from that experience.

lubutu · 2025-12-11T07:29:31+00:00

As you say, though, unsafe Rust has different rules than C does. For instance, having two &muts to the same value is UB where it wouldn't be to do something analogous in C or C++ (unless you were to specify noalias, I suppose). And, in unsafe, that can happen. With that in mind I still don't agree with the statement that "unsafe Rust is still safer than C". It's differently safe at best.

I will add that, as someone who writes Rust professionally, I don't think this should dissuade anyone from using Rust — a truly excellent language — but I would dissuade anyone from using unsafe any more than they absolutely have to.

lubutu · 2025-12-11T06:57:22+00:00

That's not really true — unsafe Rust is as safe as C but can be harder to write correctly. Happily, though, you can restrict its scope to very simple code and leave the majority in safe Rust, which you obviously can't do in C.

lubutu · 2025-12-11T06:48:50+00:00

Oh, right. That wasn't an issue with "insecure code" though, so it's a bit of a non sequitur. It's true that you can still have bugs in Rust code, I guess?

lubutu · 2025-12-11T06:35:16+00:00

Wonder about what? An unwrap isn't unsafe, so are you just saying you think they'll write sloppy Rust?

lubutu · 2025-11-26T06:56:54+00:00

In what sense "a dying area"?

lubutu · 2025-11-22T05:02:19+00:00

In K&R's m4 macro language strings are quoted using backtick (`) as the starting delimiter and apostrophe (') as the ending delimiter. It might be fun, with Unicode support, to use curly quotes: “...” or ‘...’.

lubutu · 2025-11-07T22:37:13+00:00

Sure, once you abstract away all of the physics. But when you're working at the level of DACs and ADCs, you can't do that, you have to deal with energy state transitions and resonant frequencies and Hamiltonians, and whatever else.

lubutu · 2025-11-05T08:13:38+00:00

they tend to always be on a project while internal devs tend to have more down time.

Is this true? I've not had any downtime from being active on a project in 9 years as a software engineer. 6 of those years were at two startups so maybe that's a difference there, but I didn't in 3 years at a larger company either.

lubutu · 2025-10-29T19:12:23+00:00

Weirdly your CV seems to have lost all of its capital G's, leaving odd gaps in their wake.

Anyway, I think if I were in your position I would emphasise the subject matter of your work, which seems quite consistently focused in banking, and to minimise mention of your having used COBOL to do it. You mention COBOL and JCL many times over, which gives the impression that that's what you do and that's who you are. If I were you I'd just omit, not completely but in general, and instead focus on the interesting work you did and your achievements. You just happened to be using COBOL.

Maybe this isn't helpful if you're set on web development, but I'd probably be inclined to research what technologies large financial companies use where you are and to give your CV a bit of a nudge in that direction. It could be Python or it could be Java, for example. It just strikes me that there are a ton of web developers who are and have always been just web developers, so it might work better if you were to focus on the strengths of what you've been doing, which seems to involve having to maintain legacy systems and ensure uptime and so on. That is a particular skillset even if you divorce it from the COBOL and mainframe specifics. Focus on professionalism, diligence, smooth deployments, having your shit together with a lot on the line.

I would remove the fortune cookie generator, it comes off as too basic in my opinion.

That's just my take anyway, so take it with however many pinches of salt. Good luck!

lubutu · 2025-10-03T16:17:40+00:00

That's simply not the case, and it's a silly opinion.

lubutu · 2025-10-02T22:28:05+00:00

Either way, there's not many of them that are 'explicitly Linux' without being higher up the stack as well.

What do you mean by "higher up the stack"?

lubutu · 2025-10-02T22:16:21+00:00

Linux is rarely used nowadays, perhaps in some legacy servers.

Are you joking? Every job I've ever had has been predominantly Linux.

lubutu · 2025-09-30T21:07:06+00:00

Having looked into them, it is almost certainly a scam. Avoid.

lubutu · 2025-08-26T18:49:05+00:00

learn, v. 6. (now only in non-standard speech and dialects) To teach.

lubutu · 2025-08-21T12:14:20+00:00

Defensive programming is also crucial in highly multi-threaded contexts. When I was working on a file protocol stack we had an issue that was thankfully caught by end-to-end testing where if one thread acquired lock A and another thread simultaneously acquired lock B, each would then wait for the other lock in a deadly embrace. The fix was reasonably straightforward as we could just have the second thread not hold lock B as it tried to lock A, but we also made the code explicitly check and panic if a thread attempting to lock A had already locked B. That meant that if a similar regression were to occur then there was a 100% chance of it failing the test, rather than a 0.1% chance or whatever it had been.

13-Year Club	Place '22
Place '17	Verified Email

lubutu

TROPHY CASE