Hey all - I recently finished my mini PC build which uses custom SD card based cartridges. It's all open-source[1] and should be relatively used to recreate if you're interested!
Great write up, will be curious to see if Astro sticks around. It seems like all the static site gens last a few years then fade away - Jekyll, Hugo, Gatsby, etc.
This feels right, I can’t think of any consumer product where AI is providing value today.
I assume, like me, most consumers have been saturated with AI, tried it a few times, and found it doesn’t deliver on simplifying/improving anything. They tried it, it hasn’t helped and they’ve adjusted their mindset accordingly.
Oh hey that’s my Floppy8! Never woken up to find my stuff on HN before! So cool!
I actually just released a video earlier this week about the progression of my SD card based cartridges[0] which started with the floppy cartridges for this. If you like the Floppy8 you’ll probably enjoy seeing the dozen iterations I went through after this blog post haha
I’m mostly a YouTuber not a blogger so I have a bunch of other projects on my channel[1] in a similar vein which you might enjoy as well.
Fun fact about Hanafuda - you can still buy Hanafuda cards from a specific Japanese manufacturer who has been printing them for over 100 years and the more fun part is that that manufacturer is Nintendo! They still print traditional decks along with ones using newer IP like Mario and Kirby themes.
I own one of the original style decks and it's beautiful. Koi-Koi, played with a Hanafuda deck, is a great poker-style game that makes you feel very smart for knowing how to play even though the rules are pretty simple.
There definitely are but, perhaps by definition, items soft enough to dampen sound are often easily damaged so they aren’t great fits for most commercial locations.
They are also out of vogue as was mentioned, unless you’re a coffee shop then these “cozy” items just aren’t as common right now.
This is a really good discussion of density in different forms. I’ve always thought mobile UIs could have a density renaissance, would love to see folks questioning some assumptions of these devices - especially when the trend with LLMs is “wait a long time for a potentially incredibly wrong output” it feels like we’re going the wrong way.
This is the unspoken secret of all these mods. They’re built to be built, not played, so if there are subtle instabilities introduced which may impact practical gameplay they will likely never be discovered because the final creation just sits unused on a shelf.
To the same end, when you hire human beings anticipate them standing up for what they believe in and occasionally inconveniencing your immoral business practices. Humans on both sides, opinions and your right to voice them on both sides.
The thing with masterpieces is that they don’t hold that status because they can’t be replicated, they hold it because they were novel, innovative, and unrivaled at the time of their creation.
I never understand why people consume content like this accelerated. For me, I feel like if I felt the need to rush through something then it’s not worth consuming at all.
Firebase does that, the problem is "warning them" isn't as simple as it sounds. Developers ignore automated emails and they rarely if ever open the dashboard. Figuring out how to contact the developers using the platform (and get them to care) has been an issue with every developer tool I've worked on.
Writing directly to Firebase is rarely done past the MVP stage. Normally it's the reading which is done directly from the client. Generally writes are bounced through Cloud Functions or a traditional server of some form. Some also "fan out" data, where a user has a private area to write to (say a list of tweets) then they get "fanned out" to follower's timelines via an async backend process which does any verification / cleansing as needed.
Generally agreed on improved audit logs of some formed helping.
Re training materials, this is one of the mitigations we launched to attempt to pull security to front of mind. I do not really think this is a Firebase problem, I think average developers (or average business leaders) just don't, in general, think much about security. As a result, Firebase materials have a triple burden - they need to get you to think about security, they need to get you to disrupt the most "productive" flow to write rules, and they need to get you to consistently revisit your rules throughout development. This is a lot to get into someone's head.
For all the awesomeness of Firebase's databases, they're both ripe footgun territory (Realtime Database specifically). Our original goal was to make the easiest database to get up and running with, which I think we did, but that initial ease comes with costs down the road which may or may not be worth it, that's a decision for the consumer.
One of the things we fought for, for years after acquisition was to maintain a qualified staff of fulltime, highly paid support people who are capable of identifying and escalating issues like this with common sense.
This is a battle we slowly lost. It started with all of support being the original team, then went to 3-4 fulltime staff plus some contracts, to entirely contractors (as far as I’m aware).
This was a big sticking point for me. I told them I did not believe we should outsource support, but they did not believe we should have support for developer products at all, so I lost to that “compromise.” After that I volunteered myself to do the training of the support teams, which involved traveling to Manila, Japan and Mexico regularly. This did help but like support as whole, it was a losing battle and quality has declined over time.
Your experience is definitely expected and perhaps even by design. Sadly this is true across Google, if you want help you’d best know a Googler.
I worked at Firebase for many years and the concerns with security rules have always plagued the product. We tried a lot of approaches (self expiring default rules, more education, etc) but at the end of the day we still see a lot of insecure databases.
I think the reasons for this are complex.
First, security rules as implemented by Firebase are still a novel concept. A new dev joining a team adding data into an existing location probably won’t go back and fix rules to reflect that the privacy requirements of that data has changed.
Second, without the security of obscurity created by random in-house implementations of backends, scanning en masse becomes easier.
Finally, security rules are just hard. Especially for realtime database, they are hard to write and don’t scale well. This comes up a lot less than you’d think though, as any time automated scanning is used it’s just looking for open data, anything beyond “read write true” as we called it would have prevented this.
Technically there is nothing wrong with the Firebase approach but because it is one of the only backends which use this model (one based around stored data and security rules), it opens itself up to misunderstanding, improper use, and issues like this.
[1] https://github.com/abeisgoat/SHIPx86/tree/main