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.
- 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..
> 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.