FLT8

It's not' impossible', it's economically unviable. There's a difference. We really should be mandating that companies that don't pay fair market prices for the data they use to train their models must open source everything as reparation to humanity.

I have a (completely unscientific) theory that my tinnitus is a result of early exposure to CRT TV's and my brain trying to compensate for the noise. The reason I say that is that it's roughly in the same frequency band as the PAL horizontal refresh. It's been with me basically my whole life, since long before any real hearing damage would have set in anyway - I remember asking friends when I was 9 or 10 whether they could hear it too. It wouldn't surprise me if there was a window of opportunity when the brain is still plastic for these kind of "adaptations" to set in place.

I can't help but wonder whether the solution here is something like building a multi-resolution understanding of the codebase. All the way from an architectural perspective including business context, down to code structure & layout, all the way down to what's happening in specific files and functions.

As a human, I don't need to remember the content of every file I work on to be effective, but I do need to understand how to navigate my way around, and enough of how the codebase hangs together to be able to make good decisions about where new code belongs, when and how to refactor etc.. I'm pretty sure I don't have the memory or reading comprehension to match a computer, but I do have the ability to form context maps at different scales and switch 'resolution' depending on what I'm hoping to achieve.

If the tariffs are able to act as a sustained source of revenue then they're not working to bring manufacturing back to the US. If they work to bring manufacturing back then they're not going to raise much revenue (long term). Either way, the bulk of the pain is going to be borne by average people.

- Error correcting codes (viterbi, reed/Solomon, ...)

- cryptography in general

- data compression

- a lot of DSP stuff is pretty magical in it's various applications - digital filtering, modulation/demodulation, recovery of weak signals in noisy environments, beam-forming etc

There's a lot of really amazing, largely mathematical, foundation work that we now tend to take for granted and without which we'd be back in the relative dark ages.

I think it's probably about the timing. I'm not an expert, but I believe that opening the side borders requires cycle exact timing at both edges of the screen, and when you have characters enabled on the screen, the VIC-II graphics chip ends up 'stealing' memory cycles from the CPU every 8 scanlines to fetch character and font data from RAM. These lines are known as 'badlines'.

Across an entire scanline I think you normally get something like 63 6510 cpu cycles to do 'work' in, but only 23 if you hit a badline - keeping in mind that some instructions take multiple cycles to execute. This probably makes the timing difficult or impossible to manage with the characters turned on.

The amount of effort to do a single 30 minute video of this sort when scaled out to a half or full year math class is significant.

This is true if Grant is the only person doing the work, however having a well educated and scientifically engaged populace seems important enough that we (the human race) should devote a few more resources to creating high quality (and freely available) courseware for all curricula/year levels.

Start paying attention to the things that bog you down when working on code, and the things that your users (ought to) expect to be easy but that are inscrutably difficult to achieve with your existing codebase. Find high quality open source projects and study them. Read books (eg. Domain driven design [distilled]). Stay somewhere long enough to feel the impact of your own bad design decisions. Take some time occasionally to pause and reflect on what isn't working and could have been done better in hindsight. Consider whether you could have done anything differently earlier in the process to avoid needing hindsight at all.

Kung Fu flash is probably all you need, with a few caveats (eg. With KFF the drive is "emulated" by intercepting kernal vectors rather than acting as a 1541 on the serial bus, so some software that eg. uses fast loaders or relies on the disk drive for offloading computation won't work).

If you want to get fancy you could go for something like an Ultimate II+ and a usb key, which will get you a bunch of extra functionally like network connectivity, extra SID support, pretty solid compatibility, REU emulation etc (but UII+ will also cost a lot more).

Given you've got a real 1541, maybe you could just copy files/disk images across to the real thing if KFF doesn't work for a particular program I guess?

I credit the C64 that I had as a kid and magazines like COMPUTE! / Compute's Gazette for my career in software. I taught myself 6510 assembler and started writing some simple demo-like things on that machine, and got hooked on the feeling of creativity that it unlocked.

Funnily enough I'd been thinking that it's about time I tried (again, as an older person) to write a game or a demo for the old 64.

It's absolutely amazing what people are able to get out of these 40+ year old machines now, and I love that there's still a vibrant scene.

In addition to the tools specified in the article, I would also recommend "retro debugger", it's an amazing tool for single stepping through code and seeing what's going on, even letting you follow the raster down the screen to see what code is executing on given scaliness.

Also, there are some really good youtubers out there helping to demystify how various games/demos work.. Martin Piper comes to mind as a good example.

This reminds of the corporate adage: "You can choose to invest in your people and run the risk that they leave, or you can choose not to invest in your people and run the risk that they stay".

It seems to me that the smartest people would be far more motivated to leave a country where they are unable to find other people like themselves to collaborate with.

And they'd be far more likely to come back in future and reinvest their overseas earnings in a country that they felt warmth towards than one that had forced them to play life in hard mode and was actively hostile towards them.

Only you can decide where your moral compass points, and how far you're prepared to go in an opposing direction for wealth and/or fame.

I think most people will feel better working in a position that is aligned with their values, but a lot of people can also tolerate/justify a surprising amount of cognitive dissonance in aid of supporting themselves and their families.

Whether it's convincing oneself that one's work will only be used militarily against baddies that deserve it, that the people one is putting out of work with automation/AI will fall on their feet into much better jobs, or that manipulating people into spending more time in one's app is actually a public service because the app itself does some good, people will find ways of compartmentalising and living with what they do since the alternative of having a family less well provided for is seen as the bigger failure. "Suck it up princess and get on with it, you can't bear the weight of the whole world on your shoulders, and you've got kids who need to go to college"...

My main advice would be to try not to stray so far from your moral compass that you can no longer recognise yourself. No amount of therapy or donating to charity is going to fix you at that point.

I'm really glad there are people like yourself out there, asking questions like these. I wish more were like you, and I wish you good luck and happiness whatever you choose to do.

I'd love to hear about your recovery journey.. it seems like quite the gravity-well to have escaped from. Would you consider writing a blog post or sharing here?

There are a lot of weird and wonderful tax breaks in Australia likely helping to drive up the sales of utes*. I don't think it's necessarily that Aussies love driving them as much as Aussies dislike handing over more than they need to to the tax man..

[1] https://www.drive.com.au/caradvice/ute-tax-breaks-exemptions...

You never add abstractions until you can’t avoid them.

Whilst I accept that bad abstractions can really hold a codebase back, good abstractions and layering are what make code clean, understandable, and maintainable. I don't think we should throw the baby out with the bathwater.

What's important is having good designers who understand the domain and are able to judiciously select the "right abstractions" to apply at the "right time". Often this will mean people who have worked in a domain and made or experienced the consequences of mistakes previously.

Bad or inexperienced developers will write bad code. Good, experienced devs will do a little better. Don't let inexperienced devs design abstractions that you'll be stuck with for a while.

20 years ago I worked on a mainframe system that, at the time, was said to have "18 months to live". Fast forward to today, the system is more entrenched than it ever was, and still has "18 months to live".. I'm convinced it will outlive me, and probably the next generation too.

Monoliths are problematic because they are too large and unweildy;

The idea that something could become less unwieldy or overall "smaller" by splitting it into separate codebases and introducing RPC and dealing with all the other complexities I mentioned above seems fanciful to me.

As far as I can tell the only semi-reasonable reason to want to move to micro-services is social -- effectively Conways law driven by Dunbar's number -- ie. you've scaled your organisation to a point where you have too many people to work effectively together and you need to split off into smaller teams, each with a subset of your total pool of developers, and want to be able to grant each team autonomy over their 'microservice'/domain to prevent death-by-committee.

I'd still argue most would be better off modularising/maintaining the monolith so multiple teams can work on it, but I do at least understand that rationale.

even just updating the dependencies might sometimes be impossible (in a reasonable timeframe).

Consider the situation where you have a proliferation of micro-services all using a similar but slightly divergent stack, and you're notified of a security issue that means you need to update the same library across the entire fleet of services. I know what situation I'd prefer to deal with.

It's 1000x easier to refactor the monolith into a more modular form when it's in a single repo. Wait until you want to try to refactor across service boundaries in a u-services world because you got your boundaries wrong.

Additionally, as soon as you introduce RPC-style (or even event-based) interactions between services your complexity goes through the roof. You need to deal with:

- service versioning and backward compatibility

- serialisation/deserialisation complexity and latency, and synchronization of DTO-style objects between services

- more complex deployments

- far more complex testing

- in-transit encryption for data and key management (eg. Istio, ...)

- network-layer issues

- circuit breakers

- caching / other performance band-aids

- graceful degradation across the stack when services fail

- sagas or equivalent mechanism for coordinating cross-service operations and what happens when things go wrong (fsm help you if you end up needing cross-service atomic transactions because of your ill-thought-out service boundaries)

- etc.

I'm honestly amazed at how many people blindly follow the "microservices good / monoliths bad" mantra given how obviously wrong it is for most teams.

And anyone not on iOS stuck with webkit.

They couldn't be, realistically, any more closed without being an essentially infinite money sink of the kind even nation states would struggle to fund long-term. It's the public using it that's helping offset costs and also giving them the usage data that they need to iterate on the design.

Maybe they're working to tweak the chain-of-thought mechanism to eg. Insert-subtle-manipulative-reference-to-sponsor, or other similar enshittification, and don't want anything leaked that could harm that revenue stream?

Feel free to reach out, a few people from this thread seem to be doing similar things, including looking at the protocols involved and interop requirements. It would be good to combine efforts if you're that way inclined.

As far as HA integration goes, there's already an adapter available that uses the HTTP API that the tablet exposes. This of course still requires a working tablet though.

The next step for an open solution would be to either write a replacement for the tablet API that talks directly to the control box using RS485 (which will have the benefit of allowing existing integrations to work as-is), or perhaps even ignore the original API and start from scratch with something custom built for HA integration.

The original HTTP API that the tablet exposes is relatively straightforward, but it also commits quite a few sins against HTTP, such as mutating state on GET requests (making CSRF type attacks trivial). This makes a like-for-like replacement a little less palatable in my eyes.

The other tricky thing is that the tablet code is where a lot of the state is kept and the smarts of the system are located. Zone names and config, schedules, temperature sensor pairing, ... replacing the tablet API completely like-for-like might be tricky, but doing just enough to support HA integration (maybe submitting a patch to the existing integration to support the new custom API) is probably a much easier task. There should be no need to rebuild features that HA already has such as scheduling etc.

The main trouble I have with mongo or document databases in general is that using them effectively requires a lot of design thinking up front. You need to really understand your domain model, in a DDD sense. This isn't usually made clear to people.

Document databases are good for working with / storing aggregate root objects and related entities. If you don't know what that means, or are feeling your way through a new domain and aren't in a position to decide if you're really dealing with an aggregate root object or not, or think things might be subject to change later, put the tools down and go with something more conventional.

Additionally, if you do use mongo for your operational data store, you should probably consider combining it with read-projections in a relational style DB too, or at least more conventionally defined flattened collections in mongo, in order to service bulk read style queries. Aggregation queries in mongo can get out of control quickly if you're not careful. Much better to plan for that early. And if you end up separating concerns like that, you'll probably find yourself wondering why you didn't just go with Postgres from the start.

Also, Postgres. It has built in support for json data types, can index on json fields, and do most of the stuff you'd want to do in mongo while not locking you into that paradigm for the parts of your app that don't need it.

I have reached out to your email address (as described in your profile) with some additional information that I've been putting together. Let me know if you didn't receive my mail.

Interesting, not sure what's going on there then.. how recently was your system installed? Maybe they have updated the pinout on newer models? I'll go back and check though.

This is from my earlier notes, hope it helps some.

  Pin 1: RS422 +/B
  Pin 2: RS422 -/A
  Pin 3: ? - appears to be unused; connected to unpopulated pad on PCB
  Pin 4: GND
  Pin 5: ~14.2v DC unloaded
  Pin 6: GND
  Pin 7: ?
  Pin 8: ?
  Shield: GND

I've got one of these systems too. Mine hasn't died yet, touch wood, but I was concerned enough about the possibility that I went as far as documenting the comms protocol and starting to design a pi hat to talk to the main control board.

I should really write that up at some point too.

Reasons not to do this: - you don't really understand the full complexity of the domain or regulatory environment yourself - you don't have the funding available to commit to not only the development team but also the infrastructure to support them (tooling, cloud environments, security team, policies to support this, technical writer, ...) - you're not prepared to pay for top talent (assuming you can even judge it, see the point below). Starting something from scratch successfully requires a really experienced team who understand how to model and build things well. Who know how to build in sucha way that frequently changing things effectively become configuration rather than code etc etc. Most likely this means people who have 10+ years in the industry and preferably people with some product and industry experience. - you expect this will be a one-time cost hit and then effectively free in perpetuity; software is expensive to maintain, requires ongoing security patching, keeping up with library and technology updates, and ongoing commitment even if from a business perspective nothing is charging. - you don't have experts on hand who you can afford to have spending more of their time than you think is reasonable with your development team explaining in detail all of the lessons you've learnt from the current poorly performing software and what they really need. - you're not prepared for it to take at least four times as long and be four times as painful as even your worst-case initial estimates. - you're in an environment that requires eg. purchase of vendor libraries and/or integration to proprietary platforms and this impacts the economics of boutique development - you're highly regulated and software you build/use has additional complications like certification/audit/... requirements - especially if you don't fully understand or can't communicate this effectively to the build team - you don't know how to judge the competence or experience of your founding technical team; this will be critical to your success - more critical than almost anything else. One bad hire can derail your entire effort. - you want an entity that you're bound to contractually and that you can sue for remedy when things go really wrong. And they will go wrong. Of course there are lots of reasons to try to build the software yourself too, but hopefully the above gives a few counter points to think about.