They do with app runner, but last I checked, for some reason services were capped at low CPU/Memory and didn't allow basic ECS features like attached storage. I think they also had another one... AWS is very fragmented and strange.
I built something very similar to this a few years ago, sold it for way less ($3/service), and ultimately decided not to spend money marketing it. Building the product made it super clear that AWS costs were grossly inflated, which they hid with dark UX, and I wanted to help small teams and hobbyists. Today, if you are a small team that doesn't really need more than one large VPS, you should seriously consider Docker Swarm. Not to say that Flightcontrol looks bad. In fact, it looks quite nice. Something like this could save you a lot of money if you would otherwise need full-time devops.
I have it on my shelf. Fascinating to read the perspective of regular citizens who organized themselves to do something terrible. Likely to remain relevant for as long as people can read it.
As someone who grew up homesteading and seeing the benefits of it, I find it wild that people want to not only send their kids away to school full-time but also institutionalize them afterwards just so they can spend seemingly excessive amounts of time at work. The economic machine demands sacrifices apparently.
Sixty percent of Americans cannot afford a basic quality of life on their income in the US [1] [2]. Half of American renters are cost burdened [3]. I find it wild someone thinks "Why don't you just stay home with your kids?" looking at the macro. Can't all just live on a farm and homestead to raise kids in an unfavorable, punishing macro. Parents work because they have to work. To work, they need childcare and flexible work arrangements.
> "The economic machine demands sacrifices apparently."
Indeed. Is the solution to sacrifice for it? Or tax it to care for the human? [4] We can make better choices, as New Mexico shows. I'm tired of hearing its impossible. It isn't, it's just a lack of will and collective effort in that direction, based on all available evidence.
Nobody said homesteading is the solution. Allowing a parent of young children to care for them is not a radical idea though. It should not be hard to imagine a society that is more flexible to childcare being performed by parents, because that was the norm for all of human history prior to industrialization. People should seriously consider the ways in which their imaginations on this subject (and others!) are constrained by their post industrial upbringing, and importantly, why the current norms exist and who they benefit.
Indeed, this only occurs with unions and rising wages, where a single income from a secure job can support a family while a parent stays home to perform childrearing. Are we there? When will we get there? These are important questions to ask if this is a dependency to improving household financials to encourage the outcome in this context (a stay at home parent).
If jobs are tenuous or insecure, long term financial obligations will not be made (the cost to raise a child in 2023 dollars is $330k, not including childcare or college). If jobs do not pay enough, people will need to put their kids in childcare (which will have to be subsidized) or they will forgo having children [1] [2].
Regulation, my man. Doesn't require fitting into the existing framework that was invented to as a stopgap for dangerous factory working conditions. The barrier is people's preconceived notions on what work day, weeks, and lives have to look like.
Can you expound on this? What regulation? What "preconceived notions on what work day, weeks, and lives have to look like"? Unions and higher wages enable people to afford families, and I am an aggressive proponent of a 4 day work week at 100% pay considering productivity gains over the last half century, but I'd be interested in your thoughts.
There are infinite ways to do this and we could riff all day on it. The simplest as I see it would simply be giving individuals with young children the autonomy to dictate their work schedules, allowing them the option to make up the hours later, or even choose not to. In a way this already happens informally in nicer companies.
The email was sent from the 'npmjs dot help' domain. I'm not saying you're wrong, but also basic due diligence would have prevented this. If not by email, the maintainer may have been able to be compromised over text or some other medium. And today maintainers of larger projects can avoid these problems by not importing and auto-updating a bunch of tiny packages that look like they could have been lifted from stack overflow
This exactly. It's actually wild how much valid emails can look like phishing emails, and how confusing it is that companies use different domains for critical things.
One example that always annoys me is that the website listing all of Proton's apps isn't at an address you'd expect, like apps.proton.me. It's at protonapps.com. Just... why? Why would you train your users to download apps from domains other than your primary one?
It also annoys me when people see this happening and point out how the person who fell for the attack missed some obvious detail they would have noticed. That's completely irrelevant, because everyone is stupid sometimes. Everyone can be stressed out and make bad decisions. It's always a good idea to make it harder to make bad decisions.
I can answer why this is at the company I work at right now:
It's a PITA to coordinate between teams, and my team doesn't control the main domain. If I wanted my team's application to run on the parent domain, I would have to negotiate with the crayon eaters in IT to make a subdomain, point it at whatever server, and then if I want any other changes to be made, I'd have to schedule a followup meeting, which will generate more meetings, etc.
If I want to make any changes to the mycompany.othertld domain, I can just do it, with no approval from anyone.
Do they work there or not? I deeply appreciate that everyone's threat model is different, but I'd bet anyone that wants to create a new DNS record also has access to credentials that would do a ton more actual damage to the company if they so chose
Alternatively, yup, SOC2 is a thing: optionally create a ticket tracking the why, then open a PR against the IaC repo citing that ticket, have it ack-ed by someone other than the submitter, audit trail complete, change managed, the end
It's not possible to rug pull an open-source project by just switching new work to a different license. The real issue with open-source is that we don't live in a utopia where you can publish all of your work for free and still live a quality of life comparable to working at an average developer job, and yet so many non-maintainers somehow feel they are owed future labor. Maintainers come and go. Without sponsorship, the half life on maintainers is going to be relatively short, and more developers are going to be pushed to publishing less permissively.
I'm reminded of the infamous Mojang/Microsoft fiasco with the Bukkit community. They gave no support to a project, after "secretly" acquiring it when they hired some of the developers, letting a volunteer work hard for years maintaining it.
He was rightfully outraged when he discovered he had basically done years of free labor for Microsoft, and ended up leveraging a DMCA notice to shutter the project, due to the lack of a CLA and the inherent nature of Bukkit being ultimately glued onto the Mojang server jar to be useful.
I agree. Its an incentives issue if I am being honest.
If I ever generate software, I would also prefer to open source it but there are mechanisms where either cloud providers or anybody can take my changes and earn over them without me getting anything in return...
I mean, it is technically what it means to have a foss license but I just can't shake the feeling that we as a society are feeling so entitled that people are advocating against sspl licenses or etc. when I do think that if you are a dev and you wish to work on foss full time then something like sspl might be good in that regards.
Open source Contributors just don't get paid for the work they are doing. They are sadly doing free labour. I feel like I personally might start coding stuff in sspl or maybe just source available licenses if they get more favourable. The whole terminology behind source available licenses is kinda weird in the sense that basically a single clause which is meant to stop big cloud providers from selling your service that you built can make something like agpl foss and sspl not foss/source available.
You've touched on some interesting points here. I have also felt the entitlement, but while contemplating why it exists I came to the conclusion that it is due to a misplaced belief that open-source primarily benefits the individual and as such is a righteous crusade. While individuals may become beneficiaries in particular use-cases, I would argue that it is actually corporations that benefit the most, and not by a small margin. Just think of all that labor they get away with not having to pay for and all that specialized knowledge they don't have hire for. Then they also benefit from publishing libraries to end users so that their platforms may be more deeply integrated in customer's tech stacks. Meanwhile the guy maintaining the various open-source libraries that underpin those commercial services doesn't get anything at all. One might even be able to claim that open-source is predominantly an upwards transfer of wealth from engineers to executives.
On the other hand, individual developers not working directly on the projects benefit immensely from OSS being easy to integrate and “exploit” by companies. How many skills can you pick up that are instantly transferable between jobs because “everyone” uses the open source project. Surely we’re all better off with most major companies using and deploying to Linux even if most of them will never contribute money or time to it
yes mostly agree but, this has "ten blind men and an elephant" feel to it, also. Long, long ago (in Internet years) it was not clear that certain code, standard, stacks and practices would survive let along prevail, facing slick marketing, inside contract practices (MSFT etc) and the drumbeat of quarterly results reports. "open source" software was a go-board move.. to gain traction in a way that was not easily reversible, given the motivations and then, the time frame -- recall the Silicon Valley motto in the extreme-expansion years "it is faster to adapt an existing stack and then compete, than to start by developing your own before you can compete" .. later changed to "open source your business complement".
So "win" is a multi-layered definition. Business, big business and Corporations win in economic terms often because, they have economic objectives and then execute them. Authors scratch an itch, or finish a college degree, or move on to join another band. none of those things have the aggregate, countable result that a quarterly income statement has.. in 2025, what code is stable, generally available and (often) maintained? is that "winning" ? other corollaries possible..
AGPLv3 doesn't block folks from selling services based on your software, they just have to ensure their users can get a copy of the code. Also AGPL is FOSS.
The reason Go does not have a grand framework is that the language has a severely underdeveloped type system, which makes building complex libraries that meaningfully complement each other overly difficult. I waited nine years before starting on my first Go database toolkit so I could use generics. I succeeded, but can't shake the feeling that I know I had a better experience doing it with Java in undergrad. Being able to map/filter/reduce from a result type into another generic type would be a complete game changer. Being able specify union types would eliminate my need for the "any" type. Being able to overload would clean up a lot of code. It needs more time in the oven.
That's a complimentary point, not a counterpoint. I'm talking about Go's type system being restrictive. PHP and many other languages avoided that particular trap by allowing variables to be reassigned to any type. Java and many other languages went in a different direction and instead chose to build more complete type systems.
This sort of flexibility has its own problems and it is only possible because of the very lax type system of PHP but it is also extremely powerful when it comes to developing reusable frameworks.
PHP has fully looped back around and have a more capable type system than Go or even JS or Python. It took a long time, but it got there and it did it pretty competently.
In the past it got away with it because of PHP magic. PHP let's you do pretty much whatever, at least in the past.
I think the Java stream API is amazing, and I do like that.
Not having the equivalent of hibernate level ORMs is not a disadvantage for me personally, just because I don't like ORMs - Asking chatgpt to spit out some SQL and mapping code for me and being able to tweak the actual SQL over time is preferable (but again that is just my preference).
I don't really agree with the idea that Go has an underdeveloped type system, I think its contraints lend itself to productivity in other ways. Of the various languages I've worked with, Go programs I expand have the highest chance of working the first time I run them, because the compiler and language server A) give meaningful indications of mismatched usages and B) older Go projects have a very good chance of just working, without me having to worry about getting them going with my IDE again. B is a product of the fact that they have been very conservative with the language.
Is it possible that some of the mismatch in how people view Go's type system is due to experiences differing from writing applications vs writing libraries? I personally find some of the repetition in Go code to be tolerable when writing web applications and CLI tools, but a real issue for the composability of libraries with different purposes. Going back to the database toolkit example, the query builder can easily return a result type, but what if I also want to handle validation of input before the query and then later return a HTTP response? Well to chain a result type end-to-end in Go requires it to have knowledge of all the different types/interfaces that it could map to, which I believe is way too broad of a responsibility for one type, even though all of those features feel as though they could very naturally chain together and reduce down to a single error. These kinds of type limitations effectively force Go libraries to live on their own islands where they don't compose with one another.
The "Go-ithic" way to write a library is to be strict with its API and place the onus on the consumer to do the work to map to and from it. So if I understand your example correctly (I might not), then it would be totally acceptable and in fact preferable for a Go codebase to map between the validator, then the query builder, and then the http response. Its preferable because I want libraries to have a thin API and be focused on doing one thing well, and I also want to have it clearly presented to me how I am mapping to and from an external dependency.
Another way of putting is that the Go philosophy is not to abstract details away or try and hide them, its to make the actual control flow of the program as plain and obvious as possible.
I understand that is the Go philosophy. I care more about what is practical than dogmatic. It seems clear to me as a complex library author that the type system leads to way too much glue code, which is expensive to write and maintain.
As a Go developer of a few years now, I don't find it that way. I've found it to be very easy to write the glue code, because its largely the same as other glue code, and I find it easy to maintain because the plain control flow makes finding bugs easy. But perhaps the takeaway here is that, because Go certainly is opinionated, its a way of doing business that works for some and not others. And that's cool.
It's not clear from the article, but is this for local development or production deployments? Because it's worth noting that Swarm solves a lot of the limitations that Compose and Podman have for running containers in a production environment. Swarm runs well on singular vms and people with Docker experience can learn the ropes in a day.
reply