2,116 karma · joined August 14, 2007
1. Full-on libre: speech, financial flows, technical architecture, etc. (i.e., basically the entire raison d'être for Nostr)
-or-
2. Live and work inside the walled garden of Apple + Google's app stores
You really can't have it both ways.
First, the good stuff:
- As a Rust developer, the SDK tooling is really good. I went from running the installer to generating a templated app to dropping in my own app logic in about 15 minutes.
- Local development iteration is also very fast and low-friction. Building everything as small WASM components means you effectively get hot module reloading for free, without needing to shim in a bunch of extra dev-mode-only code loading logic (with all the inherent incompatibilities and heisenbugs)
- The component reuse model feels a lot easier for me to reason than interminable chains of Express middleware (YMMV, of course)
- You get actual static (WASM) binaries, which can be as small as your compiler makes them. I'm normally pretty thrilled to get a production app container down to <100MB, and the app I've been working on, even without really paying any attention to my dependency graph, is around 2MB. Storage may be cheap, but pulling ~GBs of new container layers for a given release or deployment isn't free or instantaneous.
There are some less-great things:
- The "outbound" DB adapters are _very_ bare-bones. You only have access to a small list of datatypes, and you can't really layer higher-level libraries on top b/c the APIs aren't compatible with standard backend drivers. (Furthermore, if you want to use e.g. MongoDB, Clickhouse, Dynamo, etc., etc.: sorry, I hope you have some sort of HTTP adapter lying around ready to use.)
- WIT (WebAssembly Interface Types) is a cool _emerging_ standard, but like a lot of WAS* community stuff it's still in a fractured "draft" state, and many of the actual interfaces exposed in Spin are unique to their runtime. (This also means that _extending_ something like the PG bindings requires a ton of indirection code spelunking; I gave up trying to add a few new native types after realizing I would also have to support them for MySQL and every other backend DB.)
- The development environment, while relatively complete and usable on its own, doesn't really play nice with Nix or other high-level dev environment tooling. (There are literally invocations of `rustup` inside the top-level `build.rs` for the project, so good luck providing your own paths for e.g. `rustc`.)
On balance, I'm enjoying the experience thus far and starting to think about more thing-ish was to apply the tools. I'm also looking forward to trying out more of the self-hosted infrastructure stack. I'm not opposed to paying for managed hosting, but I do occasionally build things that need to run in "offline" or air-gapped environments, so being able to bring up a full hosting environment is pretty clutch.
Heck, even if you're curious about WASM and want to try some experiments with (say) fast Rust crypto libraries or embedded database engines w/o the risk of flaky native code crashing your V8 runtime: again, you can just run WASM from a Node worker thread and keep cruisin'.
For those of us who _don't_ have a huge investment in Node, have hard requirements around e.g. memory usage, cold start times, or even just plain old _cost_ (which can become a major factor when you consider the AWS lock-in) that Lambda doesn't meet really benefit from another option.
Your good fortune in finding a stack that works well doesn't mean that folks who have different needs or constraints are dumb, ignorant, or lazy.
As an aside, I think you also might be underestimating the depth of experience and knowledge of the Fermyon crew when it comes to containers, cloud runtimes, and serverless development. This is substantially the same team that built Helm, and a lot of other Kubernetes and cloud-native ecosystem projects along the way.
If news events depict one side of the political spectrum unfavorably, "balanced" reporting plays directly into the agenda of that side. Truthful reporting of the news shouldn't always mean "all sides have valid arguments," and yet that is what our current media climate demands.
Having unforgeable signatures on every image-capture device just in case some output file could be submitted as evidence in a civil case would be a privacy and safety _nightmare_, OTOH.
Securely connect any device, anywhere.
ZeroTier lets you build modern, secure multi-point virtualized networks of almost any type. From robust peer-to-peer networking to multi-cloud mesh infrastructure, we enable global connectivity with the simplicity of a local network. We have millions of active users with hundreds of millions of devices connected to their own private mesh networks.
We're looking for data/analytics and UI engineers who want to work at the intersection of networking, security, and usability, helping an amazing community of open source and commercial users. You'll be joining a fully-distributed team of ~12 (total; six in eng) with backgrounds in Linux networking, cloud ops, cryptography, and cross-platform product development and delivery.
Data eng: https://jobs.lever.co/zerotier/aeaeb543-1217-4897-aeb3-68e6d...
UI/UX: https://jobs.lever.co/zerotier/71024431-2935-48aa-9e5c-4fa46...
I'm the head of engineering + hiring manager so if you have questions about the company, product, or roles, feel free to reach out directly: lennon.day.reynolds@zerotier.com
(We unfortunately can't sponsor visas or hire internationally at this point, so these are US-only positions.)
Whether you think that's a good or necessary thing probably tracks very closely with your beliefs about whether money and its expenditure is protected speech. Obviously that's something about which the highest courts and legislative bodies in the USA already have complex and sometimes-contradictory views, so I certainly won't claim there's a single correct answer...even if my personal beliefs fall very much on the "money is a modern social fiction in no way connected to fundamental human rights" side of the spectrum.
The difference between the two isn't necessarily technical; rather it's the requirement that you "join the crypto economy" and start buying up whatever shitcoin -- or CDS-style derivative of multiple coins -- is being used for that one website...and somehow that means "SSO is easy now!" and "anyone can make micropayments anywhere!" etc., etc.
The latter only makes sense in a world of free money from VCs that lets people spend tens of millions of dollars building a *login form* that they charge other websites to use. Their business model seemingly ignores the fact that no serious enterprise[^1] is going to run their internal authN/Z and IdM on a global blockchain.
[^1]: actually, I'm sure several companies have/will tried this, and equally certain the net result was a flaky service that was effectively just querying a Postgres table that cached the on-chain identity for a user and checking their presented token against that. I.e., yet another Postgres instance masquerading as "web3 infrastructure".
E.g.:
Literal HTML
``` <div class="active">Hello!</div> ```
Procedural JS
``` let elt = document.createElement('div'); elt.setAttribute("class", "active"); elt.innerText = "Hello!"; ```
Rust literals + HTML macro
``` html! { div(class: "active") { "Hello!" } } ```
Modern Lisp (Clojure, Fennel, et. al.)
``` [:div {:class "active"} "Hello!"] ```
Dunno about you, but when I'm comparing my template source code to the materialized DOM in my browser dev tools, the latter is a _lot_ simpler for me to reason about.
Because the speed of iteration in JS-framework-land is so fast that if you take more than a week or two setting up your dev environment your dependencies are already out of date and insecure, and the half of them that are using “require” instead of “import” stopped working with another library you depend on. Then, when you reported that, the maintainer replied to the GH issue, “modern browsers and Node releases have supported ESM loading for _ages_, like months and months before I started being a dev in 2018 so trust me, it’s stable now.”
(Not that I’ve had an experience like this, ever. And if so, not in a least six months. Or two. Whatever; I’m just slow, obviously.)
...but you're even _more_ on your own w.r.t. bugs, compatibility issues, and the basic assumption that everything will be running inside Node, and therefore trivially able to access e.g. `npx` or various scripting+automation tools.
Your best bet today is to run Node in your development environment, then use the generated code in a Deno service/CLI wrapper/etc. It's clunky, but you can get there.
I think it's going to be pretty bad if you're expecting to go through something like the process you described:
1. Cram some coding exercises
2. Breeze through a FAANG panel b/c they're hiring anyone who can balance a binary tree and carry on a conversation at the same time
3. ...
4. Pull an easy $250k base, plus stock and a twice-annual review/raise cycle
I worked through the 2001 downturn and 2008. Both times I maintained a decent amount of flexibility in where I worked and what I worked on, with the consequence that I could no longer simply demand whatever salary I wanted and an extremely senior title on my way in the door.
Given that you have software development _and_ legal qualifications you should have lots of options if you're willing to branch out a bit. Ex.: big co's need folks to own compliance for user data, financials, etc.; being a technical lawyer could be a superpower there. Ditto running audits from a bigger consultancy: anyone trying to gain PCI, SOX, or various ISO certifications -- or even just the record-keeping and reporting needed to be a public company -- needs experts in both tech and legal policy.
So: I wouldn't freak out, but I would suggest actively looking for a more creative/blended use of your skills, vs. simply throwing yourself into a FAANG candidate pipeline and hoping for the best. It'll put you ahead of other candidates, hopefully avoid some of the post-layoff hangover, and honestly probably be more fun and interesting than just slinging code that gets more people to click on ads.
But of course if the data is already sitting in object storage inside your cloud environment and all you have to do is run some MapReduce jobs to get at it...
Hence: unfair, anticompetitive, intellectual-property-right-abusing behavior. Microsoft GitHub (tm) can prevent anyone else from running the kinds of analysis they do by simple "operational security", while running literally any kind of analysis, model training, etc. they want. Don't like it? But their commercial services and products so you can run Microsoft GitHub (tm) on your very own Microsoft Azure (tm) infrastructure, using Microsoft Visual Studio Code (tm) and Microsoft GitHub Codespaces (tm) so work on _your_ code privately.
Best of all, you can still still take advantage of the huge library of "free" code offered by Microsoft GitHub Copilot (tm) to ensure your private, proprietary codebase still has all of the advantages of Open Source Software, brought to you exclusively by the Microsoft GitHub Platform (tm).
And yet, the theoretical (not even real-world) bandwidth for LoRa is in the hundreds of bytes per second; perhaps whole _kilobytes_ if you're giving up most of the range and power savings that LoRa offers for traditional IoT.
On the "small devices exchanging small amounts of data" front, LoRa, particularly for large-scale deployments like the ones Helium resells access to, faces a lot of competition from Thread, Matter, and other "home-scale" mesh options. Until Apple or Samsung puts a LoRa radio in their handsets, it's going to be a niche product. (Unlikely because Semtech owns all the patents on LoRa. One of them might _buy_ Semtech, but I imagine they'd shell out $2 per handset approximately _never_.)
You can actually get a couple of pretty beefy bare metal boxes for that budget. Or a couple of more modest ones for app servers plus a nice big RDS instance with all the trimmings. Based on past experience, that’ll get you to a few hundred rps for even a fairly complicated, poorly-tuned Rails or PHP app; your well-factored Go API server should handle 10x that pretty easily.
You might have to write some Bash or systemd unit files instead of a bunch of YAML, which may or may not bug you. I find shell easier to understand and debug than YAML-based scripting but YMMV.
From a "commercial marketplace" POV, it's basically a farce. There's no security -- it's literally just a folding table full of food on someone's porch with a clipboard to mark that you've taken your share for the week -- and the supply varies with the weather, crop conditions, and even mundane things like "the delivery truck broke down this week; shares will be small and/or late."
And yet: everyone gets fed, the farmer gets paid, and it all ends up being price-competitive with a grocery store (much less a farmer's market).
We also patronize a farmer's market for the "showcase" products that succeed there: big pretty loaves of bread, flats of fruit, etc. It's still cheaper than any high-end grocery store, the shelf life is amazing b/c it hasn't traveled 1000 miles on a truck, and we get to interact directly with the folks who make the food.
The catch -- and it's a big one, in terms of classic microeconomic indicators -- is that we can't get an arbitrary amount of any chosen good at a competitive price right on the spot. Want peaches, but the stall sold out or bugs got this week's share? Sorry; hope cherries are okay this week. Don't like turnips or beets? Well, you might need to trade with someone who does, or find a new way to prepare 'em.
There's also no "economy of scale" to speak of; the largest vendors are probably a couple of bakers who make O(thousands) of loaves per day, or the ranchers and fishermen who show up with coolers full of frozen steaks and fillets (b/c one cow or fishing boat load actually feeds a lot of people).
Oh, and basically every farmer's market is also a localized barter economy. If you watch you can see the vendors roaming between stalls, offering trades and samples with other purveyors. After-hours, there are a _lot_ of boxes of food moving from one stall to another just before the left-overs get loaded back into the truck.
So yes, strictly speaking these are all "marketplaces". It's a far cry though from Amazon swooping in to undercut the successful products on their own platform, or any major store chain selling shelf space to the highest bidder to create -- rather than respond to -- consumer demand.
Obviously it doesn't work for every product or service, but there's definitely a space to accept a little less efficiency in favor of community-level resilience.
Meshtastic doesn't use or provide a TCP/IP stack (aside from a limited TUN interface wrapper which is really more of a proof-of-concept) but any device that can connect to a node using WiFi, BLE, or USB serial can use the network.
The routing model also makes it hard to add more than a few dozen nodes to a mesh. For small groups over wide distances that's absolutely fine, but it isn't a great option if you want to connect large numbers of _people_, unless said people are clustered around a few devices sharing WiFi or BLE connection time. (Meshtastic also doesn't really support this use case b/c of a "one device == one user/identity/mailbox" model, but that's an application-level choice, not something imposed by the underlying network.)
Once upon a time, by recording a thing you made it durable *by default* and even got a copy you could do with what you liked. Now, recording and sharing words or ideas comes with zero assumption of durability. Your service provider's ToS and business fortunes might support them keeping it around and accessible for now, but there is zero guarantee that will outlast the whims and fortunes of a SaaS providers.
The combination of DRM (to lock down devices) and "everything lives in the cloud" (to keep custodianship and control of data in vendors' hands, not creators') means that without very intentional, often obscure and/or annoying manual steps, your correspondence, recordings, and other creative output will not survive you. Even _with_ painstaking effort there's every chance it won't work.
Personally, I've tried for a couple of years now to get people I work with to write important things down somewhere that isn't Slack, GDocs or another pay-to-play service. Business, personal, silly, whatever: as it stands, all of that culture and history and creativity is just going to go "poof!" as soon as some company's C-suite does the math and decides the storage and compute to make it available don't pencil out any more.
Now I just accept that unless I have 1) a complete, easily-cloned copy of something, 2) that I can access and manipulate using OSS software, 3) on a general-purpose computer I physically control, then that thing is not *mine*. If it isn't mine, I can't decide what happens to it in the near term, much less once I'm not around to lobby for access.
Being able to pay for _just_ email from a company that isn't also harvesting my mail contents for ad targeting and search relevance is honestly a huge relief to me. When I have to discuss something sensitive via email -- think medical care, financial deals and other business secrets, even hobbies and interests that I wouldn't want blasted across the Googleplex -- it goes to Fastmail, every time. (And yes, I know about encrypted email and tried to do everything with GPG signatures + payload encryption for years...along with re-sending 99% of those messages b/c the recipient could do literally nothing with them.)
For business use I'm also a big fan of their mailing-list-esque offering Topicbox (https://topicbox.com). It lets me opt-in particular outside trusted vendors and collaborators for ongoing discussion w/o having the bring them onto our domain, keeps a permanent archive of our discussions, and hosts public mailing lists for newsletters, customer discussions, etc. just as well.
Disclaimer: I am not a Fastmail employee, marketing partner, or affiliate, and I have always paid full price for my service. They're just damn good at email and one of the last effective defenders against the GOOG/MS duopoly's centralization of email and IMHO worthy of regular public recommendations for that. (Self-hosting is fun and fine for personal domains where deliverability is a nice-to-have, but for business purposes I need something that _works_ and am willing to pay for that.)
Agreed that in the general case 100ms to full paint (with interactivity not far behind) is really good.
IIUC you're suggesting people -- academic lecturers, no less, not professional streamers -- splice out sections of their lecture, replace them with a content warning, provide a contextual link to the "risky" content, and then hope that people will follow it, jump right back to the original lecture, and then come back? (And that somehow that link won't trigger the same YouTube content flag, b/c obviously they're going to at least broadly categorize outbound links to combat spam.)
This (meaning HN) community regularly nerds out over SEO, landing page optimization, and zero-friction payment flows. Why should we expect educators to be successful delivering complex content in an approachable way if we're also going to require them to carefully slice their content into "acceptable" and "NSFW" segments and deliver them separately, even when the original lecture was linear?
I’m confident any device following these guidelines would be DOA in the larger market, though. Even _if_ you could source things like LCD assemblies that fit your criteria, the expected density (high) and labor costs (low) people have for modern electronics don’t leave a lot of room for this kind of bespoke design.
I’m extremely impressed with how far Framework got on the path to “full repairability” using off-the-shelf parts without producing something that looks like a late-90s Thinkpad.
Don’t get me wrong: I love the old IBM, Tadpole, Toshiba, et. al. designs, but I don’t think that many people outside this community would be willing to pay 2-3x as much for something 2-3x larger and heavier and several generation behind in terms of performance. (Not to mention wildly incompatible with any non-hobbyist OS.)
OTOH, what you’re describing does sound a lot like why custom, hand-wired audio amplifier builders do. They manage to make a business out of it, mainly by appealing to folks willing to spend effectively unlimited money to get that “special something”.
Why is this a cool setup? B/c I can carry around a little Radxa Zero that looks like a USB-C Ethernet adapter to my iPad, Windows laptop, etc., and gets powered by the same port, and gives me Cockpit on a known local IP, mDNS advert, etc.
It’s a pretty good “hacking on the plane/train/mountain” setup, if you’re ever in the mood to try such a thing. :)
Edit/P.S.: why not just run a VM? See above re: iPad or other locked-down device; also, exposed GPIOs are useful sometimes too.
Agreed, with the seemingly-trivial but actually real elaboration: I’m excited because there’s a new version on the way and _I can decide, piece by piece, which parts of the upgrade I want._.
Having the upgrade be a literal circuit board I can swap out is 100% the value prop for Framework and I am likewise a very happy customer to see it, even if I’m happy with the current performance of my laptop and don’t need to upgrade.
Neither one is going to compete with a cheap Atmel or RISC-V MCU in cost, but on the flip side the NEO Core et. al. can run a web server, Docker containers, or a NodeJS app under modest load vs. needing everything rewritten in very tightly-managed C. :)
None of the bundled software is designed for using a keyboard, of course, so it’s going to be just as DIY as the very earliest Linux handhelds. (Anyone else remember the awful HP “iPaq” PDA Linux environment? I set one up because I could, and them never see the device again because the UX and battery life were so bad.)