It’s always humbling when you go on the front page of HN and see an article titled “the thing you’re doing right now is a bad idea and here’s why”
This has happened to me a few times now. The last one was a fantastic article about how PG Notify locks the whole database.
In this particular case it just doesn’t make a ton of sense to change course. Im a solo dev building a thing that may never take off, so using git for plug-in distribution is just a no brainer right now. That said, I’ll hold on to this article in case I’m lucky enough to be in a position where scale becomes an issue for me.
Yeah, I'm implementing a couple of things to make my life easier in the future. I don't use any github APIs and I'm setting up my clients to load the plugin repo URLs from my server so I can change them later if I need to. I want all of the resources my clients need to come from my domain name so I can move it around if I need to.
Yeah, I imagine this will help a lot of people who created retrospectively-cringey email addresses in their youth, but kept them over the years because of inertia
> After changing, Google details that your original email address will still receive emails at the same inbox as your new one and work for sign-in, and that none of your account access will change.
I’m curious about this too. I’d worry about a local burglar having this information, but what can a Chinese tech company do with this data that I should be concerned about?
First, just the evergrowing tracking of everything, it's just unwholesome in general.
Second, why assume a random Chinese tech company will manage to keep this information to themselves? I wouldn't exactly bet against some terabytes of videos appear on some torrent indexer. Now, combine with modern AI tools for sifting for what you are interested in, and it might hit closer to home for someone.
What I don't get is why people buy robots that carry microphones, lidars and cameras AND connect to the Internet.
I don't really care if the camera is American or Chinese, I just don't want a camera/mic in my home that I don't control. And yeah, the smartphone counts but it's a lot harder not to have one.
Assuming an efficient market it'll eventually be sold to a local burglar. Also, I imagine ICE might be interested in a list of homes where something besides English was spoken. Also there are those email scams that claim to have video of you doing something embarrassing, but usually don't. Given the trajectory of AI, their claims might start being true.
> The Chinese aren't the ones running massive scam orgs backed by their government. They're bust teaching up and innovating on a massive scale.
The scammers would be in India, backed by their government.
That's patently false. The "Indian Govt" isn't behind any scams any more than a random Sheriff abusing his power is a spokesperson for the White House - and that's generously assuming there are politicians with vested interests behind these, which I haven't seen anything to suggest.
I’ve always argued that the US is the most powerful passport despite not granting access to the most countries for one simple reason: it’s one of only half a dozen passports that lets you visit the US visa free.
Yeah I guess it depends on whether we mean practically or technically. EU countries travel to USA on a “visa waiver” so practically there are no restrictions. But technically you are issued a 90 day tourist visa upon arrival. The ESTA part was introduced to speed up processing by electronically submitting your info in advance so they can do a background check or whatever.
To build on that, I would say the most powerful passports/citizenships are the ones that let you live/work in your desired country. It may be different for different people. The ability to travel visa free to many places, while nice, doesn't always trump the right to abode in a particular place.
I would argue it's dangerous to be having US passport simply because US historically, has been in wars with of lot of countries and some people of such nations would be ready to kidnap one.
> A very weird assortment of countries, aside from Canada.
It's less weird if you know that the three Pacific island countries were formerly part of the Trust Territory of the Pacific Islands which was administered by the US for decades following the Second World War and today have Compacts of Free Association with the US.
Huh, I submitted this article last week when it came out and it didn’t get any attention at all.
This demo is super cool! I’ve been dreaming about a game with an engine like this for the last 5 years. Super happy to see people experimenting with it!
Would it be possible to do both on a single panel? In other words, put photovoltaic cells on the sunny side and thermoelectric generators on the shady side.
Photovoltaic efficiency drops as the panels overheat. Some have demonstrated active cooling methods that are net energy gain. I wonder if it would be cost effective to use these between the panels and cooling system?
I've been doing something similar to this, except with go. In my case I have a flutter frontend and a go backend that's built using go mobile. Instead of trying to figure out how to make all of my go functions use data types that are supported by the various native frameworks, I've opted to use protobuf objects for every type that is shared between the frontend and backend. This way I can expose a single go function via the flutter FFI that takes in a binary array and then converts it to a protobuf object. This gives me a nice separation of concerns between my business logic and frontend while also providing easy to use objects for the front and backend.
Not sure that I'd recommend this approach to everyone. Protobuf code generation can be finicky to set up, but I'm doing it so that I can access go's rich array of libraries in my app.
My music model is all Protobuf messages, which go from Dart/Flutter land to Kotlin/C/Swift/JS audio backends on target platforms. I also use Protobuf for saving and sharing. It’s been incredibly resilient and performant.
This is very cool! I'm going to take a look at your code.
I've been playing with the idea of creating a "protobuf db" library that would allow you define schemas in protobuf and then query them with something akin to an ORM. It wouldn't make any sense for large databases, but for embedded applications that only need to store a few MB of data, it would be perfect.
Have fun! Note that it is GPL-licensed. Also, note that the "main" branch is for a very old Dart/Flutter version (but it does correspond to what's in the App Store and on the site today).
I've been working on a separate branch, which finally builds (there were 1100+ errors), but I'm still working through iOS/macOS build things for it before merging it to main. (I've sadly had to abandon the Android build, because Google Play was a comparative pain, and FluidSynth upstream kept breaking the Android build I set up for them. But I'm reviving the project for iOS, macOS, and web at least.)
We do something similar for the UI for our audio hardware product. AES70 control messages are sent over Flutter platform channels to a Swift backend. The glue is open source - GitHub.com/PADL/FlutterSwift.
I don't understand what you mean by frontend and backend when you mention ffi. Is this backend in a remote server or just on the same app?
I used proto buf with rust, I had a rust client that spoke to my flutter frontend via dbus. The rust client connected to my remote server via a web socket and all messages were wrapped in protobuf and sent as binary. Made everything a lot more concrete... But it basically forced me to build my own much shittier version of gRPC. Since, if the wan for your network was every killed the client was notified too late and you'd end up with missing messages if the network buffer got filled. We added a message id and acknowledgement process with sqlite backing up each message.
I guess a better term for it would be frontend and business logic. On iOS and Android the business logic (backend) is run using go mobile bindings and are imported directly into the native framework. For Windows, Mac and Linux, it runs as a gRPC daemon in the background. You could use C bindings for PC, but those seemed like a hassle, and I need a daemon anyway.
Have you considered just using gRPC in this case? You gain 100% language separation (no FFI) and remote client/server at the cost of a little more call overhead.
Which platforms? My product runs gRPC client/server on macOS, Linux and Windows. No issues with privileges. Or are you trying to run it on port 443? Yeah, don't do that, run it on 8443 or whatever instead.
Then you have to deal with port collisions when some other software wants to use that port. And keeping a port open without any authentication is terrible for security, even if it only binds on localhost, so you have to find some secure way to share a key between the client and server.
Personally I wish we could just use UNIX sockets for "localhost-only TCP", but software support is just not there.
I don't worry about security too much given it is just bound to localhost, but I do use a simple password (and make it modifiable by the user). Avoiding port collisions in the real world isn't a big issue, just ask an AI for the least assigned default ports and chance of collision is minor (in worst case, also user modifiable). In return, you get free "remotability", which is kind of a big deal IMO.
I do wish gRPC allowed for easy usage of UNIX domain sockets and perhaps named pipes, however. Sometimes all you need is IPC, but in my case, I'm happy to have remote usage builtin.
You should worry, system users are relied on to effectively separate privileges even in "single-user" desktops. This has led to privilege escalation before, not to mention the potential for browsers to access these ports [0].
That said, a random password should be enough protection, even if it isn't the cleanest solution.
Most of the gRPC implementations force buffering of the whole response for large unary responses. They are not really written by people who care about performance. It’s dumb because the protobuf binary marshaled format is perfectly designed for server-side incremental marshaling.
Performance is relative. gRPC is plenty fast enough for my use case, and for that matter, almost all client/server use cases that work across the Internet. If a Javascript web client against a REST backend is fast enough latency-wise, then a local gRPC connection on a single PC is gonna feel like greased lightning. Of course, there will be a few scenarios where tight coupling of client/server are required for good enough performance, but they are few and far between.
Hah yea. I just did a deep dive into protobufs and RPC for an embedded application. Left learning a lot, and with a headache. Part of it was because this was using heapless, and I got errors until I configured the generator to use the right Vec sizes.
The best use case I've found for tiny models (<5bn params) as a reference tool for when I don't have WiFi. I've been using qwen on my MacBook Air as a replacement for Google while I'm writing code on flights. They work great for asking basic questions about syntax and documentation.
This has happened to me a few times now. The last one was a fantastic article about how PG Notify locks the whole database.
In this particular case it just doesn’t make a ton of sense to change course. Im a solo dev building a thing that may never take off, so using git for plug-in distribution is just a no brainer right now. That said, I’ll hold on to this article in case I’m lucky enough to be in a position where scale becomes an issue for me.
reply