Hacker Newsnew | past | comments | ask | show | jobs | submit | more evantbyrne's commentslogin

Is it arrogance or is it experience combined with a different perspective? One developer may love React because of the component ecosystem and talent pool, and another developer may dislike it because they're writing custom HTML/CSS anyways and React requires them to write way more JS than their preferred approach. Would I ever choose backbone? No. But many developers may be surprised by how little vanilla JS that it takes to build modern web apps. More than ever the tradeoffs of different frontend stacks need to be evaluated on a project-by-project basis.


It is worth learning to use Docker Swarm. Deployments are as simple as pushing a new container to your registry and running one command. I built a free CLI tool rove.dev that simplifies provisioning and does service diffing.

Either that or use a PaaS that deploys to VMs. Can't make recommendations here but you could start by looking at Semaphore, Dokku, Dokploy.


I'm looking for simple k8s alternatives like docker swarm and kamal. Rove looks really interesting.


Definitely check out swarm. I've heard so many great things from engineers that use it on large projects, and it takes very little time to learn if you already know the docker cli.


Not convinced the Grail approach is safe and effective for low-risk cohorts given the false-positive rate. Follow-up diagnostics are not risk-free.


The non-invasive followup for people with positive test results would knock out a lot of the false-positives. At least, thats what I understand of "the usual result of a positive test result for a serious illness, is that a repeat test does not confirm it"

That said, at what level of risk of follow up diagnostic would you baulk? Any procedure which requires a general is bad news, and if you are over 70 its a lot more bad.


Their advertised sensitivity and specificity put them in the ballpark of what other liquid biopsies advertise. The ones I know of target high-risk cohorts where the benefits of other screenings already outweigh the risks of taking them. It doesn't make sense for the average person to be getting periodic full chest CT scans for instance, but it might for a decades-long smoker.


Sure, that's a concern. But for screenings like this the ultimate metric is all-cause mortality (perhaps adjusted for costs and quality of life). It will take several years before we have a clear signal on that.


At first glance, I don't understand the design choice of appending HTML templates to the python controller files. Seems like a lot of complexity just to remove a template render call. What am I missing?


It's in sync with the Locality of Behavior [0] principle that htmx follows.

It's inspired by Astro Pages [1] which are the same thing in the javascript world. I really liked the developer experience working with them.

[0] https://htmx.org/essays/locality-of-behaviour/ [1] https://docs.astro.build/fr/basics/astro-pages/


ECS is good, just expensive and still requires more devops than it should. Docker Swarm is an easy way to run production container services on VMs. I built a free golang tool called Rove that provisions fresh Ubuntu VMs in one command and diffs updates. It's also easy-enough to use Swarm directly.


I’ve used a modified version of this for 8 years - I didn’t write it. Updating your ECS Docker image is just passing in the parameter of your new image and updating the cloudformation stack.

https://github.com/1Strategy/fargate-cloudformation-example/...


Thanks for sharing! I'll bookmark that.


Honestly I didn't have a good experience with ECS (Fargate) - I remember I had to write a ton of CF deployment scripts+bash scripts, setting up a private AWS docker registry, having a terrible time debugging while my CF deployment always failed, deploys taking forever, finding out that AWS is too miserly to pay Docker to use the official repo so they are stuck on the free tier, meaning sometimes deploys would fail due to Dockerhub kicking the AWS docker agent out etc. It had limitations like not being able to attach a block volume to the docker instance, so overall I remember spending a week setting up the IaC for a simple-ass CRUD app on Fargate ECS.

Setting up the required roles and permissions was also a nightmare. The deployment round trip time was also awful.

The 2 good experiences I had with AWS was when we had a super smart devops guy who set up the whole docker pipeline on top of actual instances, so we could deploy our docker compose straight to a server in under 1 minute (this wasn't a scaled app), and had everything working.

Lambda is also pretty cool, you can just zip everything up and do a deploy from aws cli without much scripting and pretty straightforward IaC.


A lot of AWS requires way too much config. It is a mystery to me why AWS doesn't lean into extending the capabilities of App Runner. I actually built a whole continuous deployment PaaS for AWS ECS with a Heroku-like UX, ended up shutting it down eventually because although useful, their pricing is pretty awful. What I need to do is figure out how to bring it back, just minus the hosted service so I can use it on corporate projects that require AWS...


I posted a link to a CloudFormation template I’ve used to deploy to ECS off an on for 8 years in a sibling reply. It’s stupid simple.

But the easy solution is just to use AWS’s own Docker registry and copy the images to it. Fargate has allowed you to attach EFS volumes for years.


Sounds useful! I hear mixed things about Swarm. You like it?

Edit: found it. Cool! https://rove.dev/


Yeah I haven't had any issues with Swarm. Heard good things from people running substantial clusters. Would be interested in hearing about what rough edges people have run into as well!


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.


Can you elaborate on Docker Swarm? I thought it lost out to Kubernetes and was effectively dead.


Swarm never died. Kubernetes was designed for an entirely different level of scale and there is inherent complexity in that. Whereas starting a production-ready container service with Swarm only takes a few commands on a fresh Docker installation.


Honestly, Docker Swarm is so great. We use it with 6 very beefy machines (each 1tb memory/96cpu cores) for years already. It's so stable and well done, no restarts, crashes, or weird behaviors. We use it in a Hetzner VLAN and performance is excellent. We are very satistfied with it, and I would use it for even bigger scenarios. I even thought about building something like coolify/flightcontrol on top of it, so I can really easy have proper deployments of my stuff


I've been using Docker Swarm for almost 6 years now deploying entire stacks for customers on top of it — it's stable and incredibly cheap to maintain.


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.

[1] https://www.cbsnews.com/news/cost-of-living-income-quality-o...

[2] https://lisep.org/mql

[3] https://news.ycombinator.com/item?id=43119657

[4] https://www.youtube.com/watch?v=paaen3b44XY

(I am once again asking to think in systems)


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].

[1] https://www.marketplace.org/story/2024/07/29/fewer-adults-ha...

[2] https://www.pewresearch.org/social-trends/2024/07/25/reasons...


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


Re: "npmjs dot help", way too many companies use random domains -- effectively training their users to fall for phishing attacks.


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.


Are you arguing that it’s a good idea for random developers to be able to set up new subdomains on the company domain without any oversight?


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


What's your threat model that says they shouldn't? If you don't trust your senior devs, you're already pwned.


Too many services will send you 2FA codes from different numbers per request.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: