[nerdponx]

That doesn't imply anything is out of control. How do you know it's unreadable and unmaintainable? Just browsing the repo it seems pretty under control and organized to me. Firmware projects tend to get complicated, see also QMK for keyboards.

[hvasilev]

Well, it is unmaintainable, because maintaining this set of dependencies is absurd for what this firmware is and it is unreadable, because I tried to read it and lost interest in a few minutes later, because of all the bullsh*t.

[k_roy]

This seems a bit more like a "you" issue.

I dug through it and even compiled it quickly without an issue. The code looks clean, and well organized, and even supports multiple languages.

Just because code isn't PHP, python, or "hello world", doesn't means that it's absurd and unmaintainable. Especially when you have the attention span of a may-fly and declare it to be "bullsh*t" after a few minutes

[hvasilev]

I don't think it is a "me" issue. On the contrary, I think this project has a lot of issues similar to what contemporary modern web development has. Generally firmware engineers know not to do this kind of stuff, since we have a highly derivative work that spans across decades.

I'll give you an example - because of chip shortages I had to redo a couple of devices and their firmware for the past few years. I had to dig into code that hasn't been touched for 12 years on more than one occasions and I had no issue compiling it more than a decade later. The reason why is because people weren't trying to be fancy and they kept the dependencies to a minimum.

Imagine if you stop pumping oxygen into this project for a month...

[jorisd]

This is a project which builds firmware for multiple devices and processor architectures, supporting developers running various operating systems locally, and includes support for documentation generation and firmware localization. It doesn't sound too strange to me that such a project includes a decent amount of tooling to ensure that compiling things is accessible for a layperson, and ensure a healthy influx of community and corporate contributions which don't diminish software quality. None of the dependencies mentioned in the Dockerfile [1] really seem out of place, to me, and I don't think the documentation generation or checkstyle packages are critical to compiling the firmware.

Besides, you can always treat a built Docker image as a stable toolchain archive if that's a concern; there's little reason to assume that it won't work 12 years into the future as - as far as I can tell - none of the software relies on it being run inside a Docker container.

[1] https://github.com/Ralim/IronOS/blob/80c4b58976268849b6d1c8d...

[hvasilev]

> This is a project which builds firmware for multiple devices and processor architectures, supporting developers running various operating systems locally, and includes support for documentation generation and firmware localization.

exactly the source of the issue. The scope of the project is just preposterous for what it is. I'm not sure what the proportion between boilerplate and actual useful functionality would is, but from the little that I saw it is outrageous.

> Besides, you can always treat a built Docker image as a stable toolchain archive if that's a concern; there's little reason to assume that it won't work 12 years into the future as

I heavily disagree with this assumption and the rest of the assumptions related to the stability of the dependencies.

[jorisd]

The scope of the project is for the project to decide. It seems that 168 contributors and thousands of users seem to disagree with you here.

I'm not really sure what fewer dependencies you are used to other than a compiler, make, a scripting environment to orchestrate things (bash) and some (other) scripting environment to cook assets (Python3). I suppose that that last bit is something you're not used to in a more embedded world, but in the world of user-facing tools with UIs, it's really not uncommon at all to have a dependency on some font library or internationalization library so that you can generate an image or display some text. The latter of which is presumably fairly important, given that the users and hardware manufacturers that this project supports aren't based out of locations where English is the native language. I'm not sure localization can be pulled out of scope, because of that.

> > Besides, you can always treat a built Docker image as a stable toolchain archive if that's a concern; there's little reason to assume that it won't work 12 years into the future as

> I heavily disagree with this assumption and the rest of the assumptions related to the stability of the dependencies.

Docker images quite literally contain an entire (userspace) root filesystem. As long as you have an existing Linux installation on an x86 processor, a Linux kernel that didn't cause any breaking changes compared with the one that was used when the image was built, and some way of extracting a gzipped tarball, you can take the image that you previously built 12 years ago, extract its contents, and run all of the tools (gcc, Python3, make, bash) embedded within outside of Docker, without any dependency issues because all of the dependent libraries can be found within the image already (if they weren't in there, the project's CI builds would not work at all!).

You can verify this quite easily: install Docker, then run `docker pull ubuntu:latest; docker save --output test.tar.gz ubuntu:latest`.

I'll agree with you that if you are a user that stumbles upon this project 12 years from now (assuming they ceased development today) there are likely some challenges as you'll have to source the dependencies from somewhere and the repository URLs used today may no longer be available by then (most projects probably suffer from this). But if today someone builds the IronOS development image from the Dockerfile and saves it, I really don't know what'll have to happen for it to be impossible to get the compiler and other tools contained within to run on supported hardware in 12 years.

EDIT: Imagine what the project owners would have to do to do the same things they're doing now (building documentation, cooking required assets) but without relying on third party tools or programming languages other than C. They'd have to spend time writing font parsers, documentation generators, build scripting tooling, and much more! In a sibling comment you mentioned that "it seems to me that at some point this industry stopped trying to solve real issues", but I'd argue that the project pulling in the scope of building those tools to avoid dependency issues is exactly that: them solving issues that is not within their scope or merit to solve.

[k_roy]

> is because people weren't trying to be fancy and they kept the dependencies to a minimum

I've been in professional development for 25 years now, and I've heard people say this before NUMEROUS times.

You know who the people who say this are?

People who live and breathe Dunning-Kruger and in reality, just unable to keep up and being unwilling to learn and evolve.

Usually this is someone that likes to talk the talk, but put something that actually requires critical thinking and it's instantly broken, the libraries are broken, the language is broken. Don't worry, the developer isn't the problem, it's all the tools and scaffolding.

And I've hired and fired at least 100 developers over the course of my career in Fortune 100 companies so I've seen them all.

Whatever. Your opinion vs my opinion.

Nobody said you had to run this on your soldering iron. And it's not like it's supporting a huge catalog of devices. It's just an alternative option for tinkerers.

> Imagine if you stop pumping oxygen into this project for a month...

And nothing will change... This is a simple OS for a $26 soldering iron with what amounts to a custom form-factor SBC.

But don't worry, hvasilev knows everything about development and this project is bullsh*t.

[hvasilev]

i honestly didn't read half of this post. i have no interest in engaging into this sort of conversation. have a nice day.

[lightedman]

"You know who the people who say this are?

People who live and breathe Dunning-Kruger"

Or those of us that actually paid attention to good coding practice in the 90s.

Try again when you've got 4 decades under your belt.

[k_roy]

lol, are you seriously trying to state that there's been zero evolution in coding practice in 30+ years?

Do you still using CVS as well? Is OOP the only way to live in your world? Java+Flash seems like a great way to make interactive web pages. Let's concat together some sql with user input and pass it straight into the database.

Gotta ship that project with some Extreme Programming. Do you still believe a programmer with 20+ years of experience but can't navigate modern tools, scaffolding, and methodology and hasn't grown and evolved their skills is more valuable than a programmer with 2 years of experience?

I am a hack programmer at best and I can admit that. But I've also worked with and managed the best and the worst of engineers and it takes about 5 seconds to smell out the BS and the people who are locked into their ways.

Yeaaaaah.... read what I wrote again repeatably above until you don't represent it.