lol, essentially yes. sorry about that. there's a lot of regulations around software that's used for aerospace and defense, and that's where a lot of the new builds are happening these days. but here's a little decoder ring:

ERP: the core system that manages/plans everything from accounting to inventory MES: the shop floor QMS: the quality system that keeps track of what's went wrong and how we're fixing it CMMC: government regulation NIST 800-171: spec that drives the regulation

there's a lot of good reasons, but the best is there's no perfect off the shelf ERP. things need to become business specific. open-source allows anyone to make the system specific to their business.

Understood, and I would definitely agree!

ERPNext is more general purpose, Carbon has a lot more for manufacturing.

thanks for taking a look. very good read of the state of things. Netsuite level accounting and mrp v2 are what we’re building now. We focused on running a manufacturing business from an “everyone else” perspective first.

I think you’re right in a sense that we’re building the thing I would have wanted — and you’re also right in a sense that there are people out there that know more than me. The key is to learn from them.

most run on BYOC or managed hosting. but for the forks you can tell claude "merge upstream and fix the merge conflicts"

> merge upstream and fix the merge conflicts"

Is this software developed in that spirit - letting a probabilistic calculator randomly fix merge conflicts?

Sounds like a recipe for disaster. But then again, I’m not the manufacturer using this software.

But then again the original question seems strange as self-hosters have to manage their own upgrade by design.

embarrassed founder here. shipped an update to make it look less generic.

Why would you be embarrassed? when bootstrap came out it took like 10 years for websites to start looking "not bootstrap". These people are just looking for something to complain, maybe GP is a designer and it's running out of work to do... As long as the product is solid...

Haha thanks brother. Hopefully it looks better now

haha sorry, I didn't mean to be harsh it looks like a cool product. But yeah theres just a lot out there right now thats biting the same style.

oh not at all, i was thinking the same thing. i just needed to hear it from someone else

you can run the community edition for free. there's enough in there to run a full manufacturing business.

founder here. extremely accurate comment. we had a customer send us this website recently. they said "we think you need a better website, we made this with claude"

lol, wow. What else did they say?

they're awesome. we highly value their opinion. they were the ones who gave me the confidence to open source it

https://minimal.tech -- they build the whole stack from PCB to hardware to wiring to mechanical assembly to telematics software themselves

I've been using this for a few years. It's great.

(other Trigger.dev co-founder here) That's awesome.

Let us know if there's anything we can do to make the product better for you

huge fan of elixir. and definitely have some dumb questions.

in some of the realtime architectures i've seen, certain processes get priority, or run at certain Hz. but i've never seen this with the beam. afaik, it "just works" which is great most of the time. i guess you can do: Process.flag(:priority, :high) but i'm not sure if that's good enough?

Beam only promises soft realtime. When switching processes, runnable high priority tasks will be chosen before runnable normal or low priority tasks, and within each queue all (runnable) tasks run before a task runs again. But beam isn't really preemptive; a normal or low priority task that is running when a high priority task becomes runable won't be paused; the normal task will continue until it hits its reduction cap or blocks. There's also a chance that maybe you hit some operation that is time consuming and doesn't have yield points; most of ERTS has yield points in time consuming operations, but maybe you find one or maybe you have a misbehaving NIF.

Without real preemption, consistently meeting strict timing requirements probably isn't going to happen. You might possibly run multiple beams and use OS preemption?

I spoke with Peer (the creator of Grisp) about this at Elixirconf earlier in the year, and I'm not an expert here so I hope I don't misrepresent his comments:

Grisp puts enough controls on the runtime that soft-realtime becomes hard-realtime for all intents and purposes, outside of problems that also cause errors in hard-realtime systems.

(Also, thanks Peer for being tremendously patient with a new embedded developer! That kind of friendly open chat is a huge draw to the Elixir community)

I did the same workshop some years ago with him also, very nice and patient guy, I can recommend attending if anyone is curious how microelectronics actually work :}