I know a lot of folks are talking about what they do, or what dot file managers they use, but there's something to be said for building a workflow that works for you. Pretty clever setup!
1,094 karma · joined May 7, 2008
To be super honest, you might be right too. You might go down a huge engineering effort to build this in only for 5% of your customers to ever engage it. I think the real question is what percentage of your customers will feel better knowing that the have the choice to set those limits, and how will that comfort actually improve their trust with Fly, and cause them to choose it over another cloud provider.
It may end up being a lot like this feature we had in a platform that I used to support. It had a just-in-time analytics pipeline that at one point required tens of thousands of dollars in compute, storage and network hardware alone to function. Based on our analytics, it was barely used compared to the usage of the rest of our app, which made the zounds of resources and fairly frequent support attention it needed feel silly in comparison, so I advocated to sunset it. Product assured me that, regardless of how silly it might be to continue supporting this feature, it was a dealmaker, and losing it would be a dealbreaker.
So yeah, y'all might be right in that the majority of your customers don't actually want it. But maybe what they do need is to know that it's there, ready for them if they ever need to engage with it.
By virtue of shipping around an entire system's worth of libraries as a deployment artifact, you are indeed drastically increasing the payload size. It's easy to question whether payload efficiency is worthwhile when the advent of >100, and even >1000 Mbit internet connections available to the home, but that is certainly not the case everywhere. That said, assuming smart squashing of image deltas and basing off of a sane upstream image, much of that pain is felt only once.
You bring up that you built a system that helped you quickly and efficiently configure systems, and that discipline and good systems design can bring many of the same benefits that containerized workloads do. No argument! What the Docker ecosystem provided however was a standard implemented in practice that became ubiquitous. It became less important to need to build one's own system, because the container image vendor could define that, using a collection of environment variables or config files being placed in a standardized location.
You built up a great environment, and one that works well for you. The containerization convention replicates much of what you developed, with the benefit that it grabbed a majority mindshare, so now many more folks are building with things like standardization of config, storage, data, and environment in mind. It's certainly not the only way to do things, and much as you described, it's not great in your case. But if something solves a significant amount of cases well, then it's doing something right and well. For a non inconsequential amount of people, trading bandwidth and storage for operational knowledge and complexity are a more than equitable trade
If I'm on a road trip, and I need a quick meal, and my choices are "buy from place that makes me use their app" or "buy from place that doesn't make me use their app", I'm gonna choose the option that is more convenient to me, which is, the one that doesn't make me download anything, sign up for an account, and pester the hell out of me 2 hours after I have already forgotten about that particular fast food joint to let me know if that if I only buy 39 more Big Macs that I can get a free small fry.
I don't really want fast food to begin with. The food quality at any vendor has continuously gone downhill (or my standards have raised, could be some combination therein). If they want any hope of capturing my business still, they'll only get it if they keep that process as frictionless as possible.
Password authentication, which only uses your password to establish you are authentically you, does not establish the same level of cryptographic trust, and also does not allow the SSH server to bail out as quickly, instead needing to perform more crypto operations to discover that an unauthorized authentication attempt is being made.
To your point, you are storing the secret on your filesystem, and you should treat it accordingly. This is why folks generally advocate for the use of SSH Agents with password or other systems protecting your SSH key from being simply lifted. Even with requiring a password to unlock your key though, there's a pretty significant difference between key based and password based auth.
Sibling commenters have it right - if a computer is an appliance to them, then going for the simplest, least likely to accidentally mess up option is the best one.
That's not to say that they're not interested in providing more quality. There's heavy investment in per-video, and sometimes per-video-section encoding and next generation codecs like AV1. The goal for them though is to get more quality with the same or less storage and bandwidth budget.
I see that it's free, but I feel like this could have easily been a $1 app.
Grats on making a really neat little focused tool!
Speaking of ROMplers and the SNES, these inexpensive ROMplers from Roland and Korg were what much of the music of these consoles were made on, with many of the SNES soundfonts bing made up of highly truncated versions of the ROMpler's samples. The sound of second, third, and fourth generation Final Fantasy games as composed by Nobuo Uematsu heavily used the Roland SoundCanvas SC-55, with the final title he was lead composer on, Final Fantasy 10, essentially using fully rendered tracks using the platform, with then-modern arrangement and production techniques instead of the soundfont + tracker-style music programming used on the SNES and PS1 titles (the PS1's SPU is essentially a souped up SPC700, hearkening back to its roots as the SNES CD, allowing developers to make music in much the same way, albeit with higher resolution samples, more channels, and more effects).
To your point though, the the Genesis' YM-2612, in Yamaha's OPN family was a similar chip to the Yamaha OPL-family chips used by the SoundBlaster platform, albeit it featured complex FM operators that wouldn't be seen on SoundBlaster cards until the versions with "OPL 3" chips became prevalent, which was inconsistent on the SB16 family.
> 1. I don't know if HTTPS is the best analogy...
IMO, the lynchpin to HTTPS accessibility was that we made cutting certificates easy, and most importantly, free. By eschewing the baseline requirement for cutting a certificate to being able to validate that the site on the domain is trusted by virtue of a relationship between the hostname and the certificate requester, and providing an API to automate the renewal process, opting into HTTPS went from "administrative burden that needed a sysadmin to manage" to "service any hosting provider could leverage". LetsEncrypt and the ACME protocol, and Cloudflare before them, did much to radically change the landscape for making HTTPS accessible to everyone. [1] That makes the analogy pretty apt to me, IMO.
2. You make a very valid point here. By virtue of letting SMTP languish so long, bandaiding it as we went, instead of opting for a major refactor of how email works, we made an environment that was rife for consolidation. As a result, it makes sense that we might have to boil the frog to make a change.
3. I'd love to see it, but I'd be interested in learning how key exchange/trust works. I'd be interested to see how you'd envision enabling new senders to send you mail.
4. This feeds back into my comments on 3. With established contacts, this is great, but in a world where, say, you were giving a talk, and wanted to offer folks that listened to your talk a way to contact you afterwards, how would you distribute the token? If someone abuses the permissions, how do you invalidate it? I can't foresee this being an all-or-nothing system, and don't really see a system where creating some sort of one-way or two-way trust between individual senders and recipients is at all feasible.
[1] Let's Encrypt stats: https://letsencrypt.org/stats/
Part of the desire is the collectability. To be able to get a rare, prized Pokémon. In the original games, part of this was centered around there being two editions of a game, with some of them only in the other, with the desire to make trading a social activity. That said, it certainly didn't stop people from buying two Gameboys, two copies of Pokemon, and collecting them all on their own.
Some folks just have a compulsion to have everything.
After moving to DNS-01 validation, which comes with the added benefit of letting me cut certs for services that aren't publicly exposed with way less orchestration required than with TLS-01 style validation, my experience was suddenly much better. Assuming the DNS provider is working (and if it's not, you're hopefully getting an API error from them before LE attempts to validate the record, the failure state happens well before any check failure backoffs happen at LE. At this point, regardless of whether I'm using Traefik, Caddy, Nginx, or any other reverse proxy, I'm pretty committed to only using DNS-01 based validation from LetsEncrypt from now on, or if I have to do TLS-01 based validation, to make darn sure things are right the first time with the Staging API first.
Which, speaking of, if you cut a Staging cert with LE via Traefik, there's no good way to invalidate the staging cert. You have to munge the ACME JSON to remove the cert and restart Traefik (could maybe do a SIGHUP? didn't try) to get it to pickup the changes.
All said, lots of weird silent failures and behaviors, but the biggest pains are making dependent service errors opaque.
On the front, working with a publisher can help with funding. A publisher will often times front a fair amount of development costs, which depending on funding sources will often time make up a significant portion of the revenue needed for development. When people see exclusivity deals, that happens because the developer receives advanced funding for development costs, usually a significantly larger amount than one would receive from a publisher that has no platform associated with it.
For smaller studios, these teams may not have any marketing expertise. While an independent marketing team may be able to help out with this, the publisher managing this relationship, especially with teams either internal or external that they have experience with, allows the studio to focus on their development efforts.
That's not to say this is always sunshine and rainbows. The stories of publisher imposed deadlines, restrictions, etc. are true, usually without a lot of the inside baseball color of the why of these deadlines are required. That said, when Other People's Money comes into play, things always change. The cost of delaying a release is not small, even more so when there are physical products being made and fulfillment to be managed. That's not me being an apologist, just trying to add a bit more color to the social media talking points.
To the point I think you're trying to make though, with the amount of self publishing tools available, it's definitely not the necessity that it used to be to be. However, the dynamics of whether one can do something, vs. whether they're the right ones to do so something are always nuanced, especially when it comes down to the calculus of whether the benefits and the trade offs line up.
Having a similar tool to automate not only bootable media creation, but also selection of distro and acquisition of install media would indeed make installation more simple. Unetbootin used to do that (still might? Haven't used it in ages), but IIRC, keeping the list of distros up to date was a challenge.
It's fair for us to be gunshy. There's simply too many examples of OSS projects highly used across the web that made these kind of promises earlier on in the product's lifecycle, many if not most of them with the best of intentions at the time the promise was made. I trust that what you're saying is true today. Until we start to see more OSS projects with sustainability models that are both successful at staving off negative influence from funding partners, and those sustainability models leading to companies making good on the declarations of altruism they made when they were younger, I think we're going to remain unsure and unconfident in promises like this.
Don't think it's going to stop us from checking out your product or potentially building really cool stuff with it. But until you prove to us that you'll keep this ethos, we will start using this really cool framework with one hand while we keep another hand free to stabilize ourselves in what feels like an inevitable rugpull that isn't a matter of if, but when.
To your point though, the `_make_command` method here is not setting hints in its arguments. I'm not super familiar if this is considered "fine" in a pydantic world, as I found for my usage, native python type hints were more than fine to make my code more usable and safer. Based on the code though, it seems like there are cases where the `command_attribute` is not a callable. What I don't understand is why this isn't hinted as a Union of Callable and whatever other types it could receive. I'd have to spend more than 3 minutes looking at the code base to understand how it's used to get a stronger idea here.
As an aside, viewing an HTTP website over VPN is indeed useful when the threat actor is the public WiFi provider, but it doesn't if your threat actor is the VPN provider, or in between the VPN provider and the hosting provider. I'll cede that this is beyond the scope of the situation talked about in the article though.
They're just different games. I love them both for what they are. It's a shame that Interplay tried to use the Descent name to sell more copies, because even if there was some minor inspirations in development, Freespace definitely stands solidly on its own two feet without the tie.
What Thunderbolt can do however that is quite magical, is operate as a point to point network interface. Driver support can be a bit dodgy, but it's totally feasible to build a 3 node compute cluster with point to point cluster node networking over Thunderbolt at 20 Gb/s.
What the shinier VDI/Remote Desktop solutions like Sunshine+Moonlight, Parsec, Horizon, Citrix do for you is make all of this easier to set up and use. But as far as capability is concerned, RDP is quite powerful and quite capable, assuming you jump through the hoops to set it up right.
It sounds like you made more space, and that allowed you to invest more in things that interested you, which translated to being able to make a career change. I imagine that could be swapped with "thinking about how to improve one's mental well being" or "engaging with other folks to discuss things that bother you".