egwor

I've built the same code but in swift. I've come to the exact same conclusions that you have on the protocol. I got Claude Code to implement TPAP compatibility solely by interacting with my local plugs, looking at the shape of responses and RFC 9383 to figure out it was SPAKE2+. It took a bit of time to figure out the last bit: that the SHA-1 of the password, then PBKDF2 with the plug's salt, split into two halves; a context of "PAKE V1" plus both sides' random numbers; empty identities

Working with blunt blades can be really dangerous. Worth taking consideration for next time.

I think that using the right tool for the job is important and saves a lot of time in the long run. There are expensive headaches that we have to resolve.

I've been doing this for years (8+ at most recent place?) and we did it about 15years ago at place before. We keep having to relearn these features, which is on eof the reasons why some groups are far more effective than others

Although I might disagree with the style of the write up, I think it is right that there are weak engineering practices applied:

- not enough information provided in commit message. - this change ought to have been split into smaller chunks (e.g. introduce indirection whilst code continues to use hardware) - limited (automated) testing - potential confusion by the author over C concepts - additional complexity which could have been hidden behind a cleaner interface rather than using defines

I agree about your points about:

- defines over multiple repo's made this more complicated that was necessary. - fault injections would have been the appropriate way to test this (or maybe mocks) - testing of randomness needs careful design, e.g. RNG seeding can be a good way

Taking a step back, we as a community of excellence need to emphasise that this isn't a criticism about the person/author. There needs to be a clear analysis of what went wrong whilst being kind to the person/people involved.

Glad that you got the colour scheme changes

I think that by exploring how different cultures and languages communicate about things opens the mind. There are concepts that can't be easily/succinctly explained in English but can in other languages. I think that we should be encouraging such breadth of thought because it allows us to appreciate new aspects of the world we live in.

Maybe this is similar to web search too. We know how to get google to return the results we want, and when we use other tools like Bing we get other behaviour.

We use gitlab at work, and I have to say that it is disappointing. The UI is so complicated to do the simplest things (e.g. to approve a MR you need to click a button that is actually a menu; the diffs are difficult to read; the 'To-do list' includes MRs that were already merged (how is that actionable?)) and it seems that they're struggling to turn around improvements quickly. The issue around the 'To-do list' including MRs that were already merged was raised years ago.

I also have to say that I'm surprised about the backlash against bitbucket. I find the UI incredibly simple and clear, as do all of the new joiners. With Script Runner you can do some pretty amazing things. It handles the huge repo's well too.

First step is to get ssh setup correctly, and second step is to enable a firewall to block incoming connections on everything except the key ports (ssh but on a different port/web/ssl). This immediately eliminates a swathe of issues!

I think the better question to ask is what services peak at a few hundred transactions per second?

I think it depends on what you're using it for. If it is a simple kubernetes config then the model doesn't matter too much. Contract that with writing the scenario for a backtest for an algo that trades on a venue: it is not the same complexity and the basic models are terrible. I've had it tell me that it has added tests to find that they're just stubs! Opus seems to be getting there, but on more complex tasks the others are a complete waste of time.

I think that hearing other points of view is important.

I see time and time again that posts insinuate that there's no other point of view, and I think that highlighting one perspective is enough to show that this (as in the article) isn't some mathematically perfect piece of advice.

I think that for the average developer this might be true. I think that for excellent developers, they spend a lot of time thinking about the edge cases and ensuring that the system/code is supportable. i.e. it explains what the problems are so that issue can be resolved quickly; the code is written in a style that provides protection from other parts of the system failing; and so on. This isn't done on average code and I don't see AI doing this at all.

I thought that new models were typically released in October. Have I misremembered or is this an unusual timing vs previous years? If so, I wonder why the earlier release?

It is a commonly used extension, which was restricted so that I could no longe remove it. What's more odd is that supposedly I was running the latest version.

I did it today. It took me thirty minutes to fix the networking because I couldn't get Little Snitch to uninstall since it didn't seem to be compatible. Basically I had to reboot in recovery mode to disable security features (csr) to uninstall Little Snitch (via systemextensionsctl). This is the worst update I've ever gone through on Mac, and I started using a Macintosh SE.

Considering that new speakers don't use SoundTouch, I wonder too. I hope that they keep the app running for a while. This kit is expensive and it can't have a short life time!

Your point was thought provoking. In problem solving the "what" and the "how" are orthogonal since the method doesn't dictate the goal. However, if it takes a long time to do something (how: working slowly eg. because you're coding on a very slow, old machine) it tends to predict that there's less accomplished (what). That suggests that this isn't 'fully' orthogonal.

Someone else raised a good point that if we're working on the wrong thing, it doesn't matter how fast we are. However, I think a more subtle interpretation is more helpful here. I think that we need to be clearer about the consequences of the outcomes: what's the value add. The way I often reason about that is whether the outcome is 'Long-term greedy' or whether the outcome is going to make us a million dollars now. I find the latter really helpful, because if we're going to make a million dollars now but it costs us 100K in tech debt, then (provided there's not a better use of the resources) that is likely a good cost-benefit outcome.

I think that’s because the barrier to entry for a beginner is much higher than say python.

Looking at the article headings these don't feel like computer science, and rather how to approach coding problems. This is useful, but not Computer Science. I think that we should refer to this as Programming Engineering or Software Engineering.

It is important to call these distinctions out in my mind because the Computer Science is often the concepts or foundations, whereas the Software Engineering is about how to convert those concepts and use them in a situation such that the concepts are well implemented, tested, and will stand the tests of time (including changing it). They're different skills and concepts.

One thing to check is whether any security/monitoring software might be causing issues. Since there are so many files in git repos, it can put a lot of load on that type of software.

In my early teens I used to try to create something like a equirectangular projection because when drawing it, it looked cool. Obviously I had no idea that it was called this. I was trying to draw reflections of a square window onto a sphere, and then I moved on to trying to cover the sphere in a checkered pattern. This is awesome to see, thank you!

I think that there are definitely bad ways to lay people off and those should be avoided. As a manager/company, not trying to do this as best you can reflects very badly in the workplace and in society.

believe it is new purchases

I think I read 20,000,000 need housing and this will impact 20,000 per year so broadly the numbers are inline.

Really impressive. Well done (and thanks for the laughs. Starting in French would be so funny)

Is this true? Do you have a source? I thought that the pros tended to make use of polar’s technology and that their heart rate monitoring (via strap) was considered the most accurate / baseline. (My sources are from what I remember dcrainmaker saying who I consider a well researched reviewer)

I think the thing folk miss is when there’s an error like divide by zero, or the calculation would return NaN. I feel like this is the main gap/concern with using JSON and it seems to be rarely discussed.

These days most washing cycles run a lot cooler. My washing powder/soap recommends 30 but I usually run at 40. I know that I need to do the occasional high temp wash too though.