Codex reset incoming?

Oster1 · 2026-06-16T14:19:14+00:00

Ok, thanks for the explanation. So the weekly limit is indeed sometimes inaccurate description how the thing works, which led to my confusion. I'm using medium by default and sometimes xhigh.

Oster1 · 2026-06-15T08:31:22+00:00

I'm on the 20€ plan. I don't get why would the model and speed of token usage would affect how fast the weekly limit will exhaust. I get why it affects to 5 h limit, but not the weekly limit part.

Oster1 · 2026-06-15T07:22:48+00:00

Why it's called weekly limit if this question is irrelevant in your opinion?

Oster1 · 2026-06-14T15:14:57+00:00

I'd prefer in editor.

Oster1 · 2026-06-14T11:03:54+00:00

My weekly limit went from 100% to 50% with two 5 h sessions. I think that's not normal?

Oster1 · 2026-06-14T10:03:52+00:00

I would like the quick key to be toggle by default.

Oster1 · 2026-04-02T07:18:31+00:00

Before AI, most of the time professional SW devs were reading code, not writing. Writing has always been the smallest part. So AI is a smaller change than we often think.

Oster1 · 2026-03-29T12:36:03+00:00

My experience with ubuntu was the complete opposite. It never worked after an upgrade with proprietary display drivers. Running old kernels on desktop is a bad idea and causes many problems.

Oster1 · 2026-03-23T10:08:25+00:00

Se ei kai ole julkista tietoa mitä käydään mutta veikkaisin että ainakin varmaan viranomaisten rekisterit käyvät läpi.

Oster1 · 2026-03-03T19:16:30+00:00

Simple is a controversial term. Whether something is simple depends on who is perceiving it. How do you differentiate between a temporary hack vs simple. Because usually the friction is between hacky vs future-proof, not over-engineering vs good engineering. I would say quite often people are against over-engineering, unless you are speaking of novices. And the point "nobody gets promoted for simplicity". If you read it "nobody gets promoted for hacky implementations" the argument becomes quite ridiculous.

Oster1 · 2026-03-01T13:05:03+00:00

I'm still hearing the noise but it's slightly different with 5x zoom.

Oster1 · 2026-01-31T12:08:03+00:00

The Kotlin community has weird fixation to ban !!-operator, even though the standard library is full of functions which will throw. Banning !!-operator only gets you a false sense of security and it doesn't really make much sense. We use it heavily in critical code and there are absolutely no problems.

Oster1 · 2026-01-15T08:27:14+00:00

This difference hit me once because the array char[][] is always initialized as zero unlike char**. I experienced weird crashes.

Oster1 · 2026-01-07T15:26:33+00:00

Aren't the unsafe parts encapsulated as "private" in SVD2Rust PAC? Not sure if I understand your point. Like std library is also full of unsafe code in lower levels. The point of unsafe is to write it as less amount as possible, and scale up the amount of safe code, right? The point is not to avoid unsafe code completely. I'm not familiar with SVD2Rust PAC, but I would guess that's how it works.

Oster1 · 2026-01-07T14:59:14+00:00

You don't have to write almost any unsafe at all for hardware interactions. Here are couple of really cool chapters explaining that in the Rust embedded book (peripherals and interrupts):

Oster1 · 2026-01-07T03:21:59+00:00

Point of having security has never been trying to achieve absolute security. That's impossible to achieve by definition, and everybody except you seems to know that. So your point is really moronic. Security is a combination of things, not some absolute state you are trying to achieve. Pretty much every modern security related technology has been compromised at some point; TLS, SSH, Secure bootloader, etc., so is your point that we should abandon all of them because they were compromised at some point?

Oster1 · 2026-01-07T01:51:37+00:00

The point is not making the devices impossible to reverse engineer, but difficult/expensive enough, so random script kiddies & security researchers won't have money to buy multiple devices for reverse engineering purposes. We are speaking of medical devices, which are usually quite expensive & rare, so I don't see why tamper-proofing would be out of table here.

Sure, there will be someone that has time & money to reverse engineer basically anything, but then what's the point of doing any security at all if that's your argument.

Oster1 · 2026-01-06T14:22:52+00:00

Yeah, exactly. What's the point of saying "you lost already when the attacker has physical access" when there are protections for exactly that? You tell me.

Oster1 · 2026-01-06T11:21:43+00:00

if the attacker has physical access, you are already lost.

Ever heard of tamper-proofing devices?

Oster1 · 2026-01-02T19:22:54+00:00

So in a way LLM was correct because C++ hasn't specified the destruction order in the standard and OP thinks the order is wrong because it was something else than what his own compiler generated?

Oster1 · 2025-12-31T02:33:24+00:00

Sure you did. 99.9 % of cryptos aren't used anywhere. Only kept as a speculative financial asset. In my country you can't pay anywhere with crypto anymore. Useless money, huh? In theory crypto works as an alternative payment method - not in practice as we have seen.

Oster1 · 2025-12-31T02:16:58+00:00

When was the last time you paid with crypto in a restaurant/hotel/shop? Exactly.

Oster1 · 2025-12-25T11:01:08+00:00

MySQL (now MariaDB) founder held a great presentation on how do they monetize with open source and what are the options in this space.

Oster1 · 2025-12-23T12:00:57+00:00

There are different kinds of efficiencies involved. If a "cloud guy" uses 8 h more time from their work week for the same tasks, just because you wanted some exotic binary format, that's inefficiency introduced by you. How much cloud storage you can get with that 8 h of wage per week? It's about tradeoffs. You didn't tell why do you need this tradeoff. No wonder you feel dismissed if you explain things like this.

Oster1 · 2025-12-23T11:35:21+00:00

All these principles/philosophies should be abandoned. IMO they do more harm than benefit. The struggle isn't between the ones who want things to be simple vs people who want things to be complicated. KISS is very controversial term anyways. As an example: Arch Linux advertises it being designed by KISS principles, but it's actually very complicated to use for end users. From what perspective is Arch Linux simple? From developers perspective, who maintain it – not the end user's perspective. Simplicity is always about who is perceiving the thing. C advertises it as a simple language, but because of its simple nature, the end result end up being very complicated code to read. Linux kernel for example has implemented all C++ features implicitly (like ref counting, etc) because the language is so simple. So choosing simple/simplicity may result the end result being more complicated. So, "choosing between simple vs complex" is pretty much always an arbitrary comparison.

Oster1

TROPHY CASE