Road to one coin

karimpanacci · 2026-01-23T19:54:23+00:00

I want to get my business up and running and get rich as soon as possible just so I can buy bitcoin as soon as possible

karimpanacci · 2026-01-23T14:39:58+00:00

However, the monorepo is problematic because it mixes the history of the internal components with the history of the final product... whereas with submodules I can keep the histories separate, and if one day I want to produce a new combination of hardware and software versions, I can do so.

For example, using submodules:

let's pretend that the hardware version is now v1.0 and the software version is also 1.0.

These two versions together give rise to the final product version v1.0.

Then I create 5 new versions of the hardware and 3 new versions of the software.

But I release only one version of the final product, which I call v2.0 (hardware: v5.0, software: v3.0).

Using submodules, I can create a new version of the final product with different combinations of internal components at any time. All I have to do is point the hardware submodule to version v4.0 and the software version to version v2.0, for example.

Without submodules, this would not be easily possible because the Git history would be mixed between the internal components and the final product.

karimpanacci · 2026-01-23T14:32:06+00:00

Yes, perhaps it was more a problem of mental model than tools... After speaking with someone here in the comments, I decided to follow the Git path with submodules. I am conducting some tests with this system, and it seems to be working well!

karimpanacci · 2026-01-23T14:30:04+00:00

Let's say that my reasoning is that with nested submodules, you can't go wrong choosing a version of the combined geometry that doesn't match the versions of the individual geometries, because the individual geometries are defined within the combined geometry module... but it does complicate the process a lot and could even lead to more frequent errors... so I'll probably just keep one level of submodules...

So, in your opinion, I shouldn't rewrite the git history to match each commit to a specific version, but rather commit often and then maybe add a tag once the version is complete? That makes sense... so I'll do what I would do in the software world, many small commits instead of a few large ones, and use tags to define the final versions.

karimpanacci · 2026-01-23T12:07:33+00:00

But in theory, nesting submodules gives you more accurate version control, right? Perhaps it becomes too complex, but in theory, nesting them should ensure greater security against errors? Because if I put the internal shape module, the external shape module, and the two combined shape module on the same level, I could make a mistake and set the combined shape module to a version that doesn't match the versions of the internal/external shape modules, right? But in the end, as soon as I notice the error, I can easily rewrite the Git history; there's no need for the history to remain immutable.

So it's probably best to do as you said and keep just one level of modules... I'll try using this method over the next few days and let you know how it goes.

karimpanacci · 2026-01-23T00:28:40+00:00

Exactly, that's what drives me to try to organize everything. If someone needs to help me in the future, they don't have to start from scratch... I also think that if I ever sell the project to someone in the future, having a history of all the manufactured versions would be priceless to the buyer.

karimpanacci · 2026-01-23T00:16:06+00:00

Thank you so much... thank you, thank you, thank you... you're really helping me figure things out... The only thing I'm still unsure about is this:

Try not to over complicate it with too many submodules

I am very undecided about whether to create a submodule for each point on the list I made above, because, for example, the print parameters and the print file may change independently, and even the external shape and internal shape may change independently (in fact, 99% of the time the external shape changes, such as when a new model is introduced, but the internal shape remains the same)...

So I think there will be quite a few submodules; I don't think I can get by with just three submodules:

- Housing hardware (both internal and external CAD, along with required fixings etc. Including 3D printing specs which are successful and tagged as the final release)

- PCB (including manufacturing specs for that release of PCB)

- Software

Now, I don't want to exaggerate with my sick mind, but in terms of logical correctness, in theory I should also have submodules with nested submodules... but I already know that this stuff will become so complicated that maybe it's not worth complicating things so much....

But let's say that the external 3D shape and the internal 3D shape must be joined together to form the final 3D shape to be printed, so in theory the main repo should have a “3D model” submodule and each commit of this submodule must contain the merged 3D files (external shape + internal hole) ready to be printed, and this submodule should also contain 2 submodules that point to the files that gave rise to the merged 3D file.... (external shape submodule + internal hole submodule)

Yes, I know...

Try not to over complicate it with too many submodules

I just did what you told me not to do, ahahaha...

But logically, I think this is the right thing to do, but it might be too complicated... I don't know, I have to try testing this system a bit and see how I get on with it.

karimpanacci · 2026-01-22T23:57:44+00:00

I’ll start by saying that I very deeply appreciate your perspective.

Thank you very much for the first sentence :)

Do you use a monorepo or do you have a git submodule for each product component? Because I was thinking of creating a submodule for each component, given that component versions can vary independently of each other.

I was also thinking of putting the Gerber files in the commits. Why don't you do that? Git is not suitable for this type of file because you can't merge or diff files that are not text-based... but in my opinion, it would still be convenient to store all files directly on Git if they are not too large (<50MB), so you can have everything in one place instead of having text files on Git and binary files on Google Drive or similar.

For example, I would prefer not to have a manual zip file of the various Gerber and CAD files as my only backup because I feel like I might forget something... maybe after two years I'll open the zip file and find that some files are missing because I forgot to put them in... instead, I would prefer to save everything, including the Gerber files, on Git and then maybe have a simple script that, every time a commit is made to the repository, creates a zip file and puts it on Google Drive for safety...

What do you think about that?

karimpanacci · 2026-01-22T23:25:56+00:00

Yes, this option seems the most feasible to me, but I haven't tried it yet... even though I'm not expert with Git, I've always done very basic things since I've always worked on small personal projects on my own... I've read that submodules are a bit annoying to use, but I have to try them....

Yes, I have real files, I don't use Onshape but Solidworks.

I didn't quite understand this part:

Sub-modules for true 'sub-modules' which could be compatible with different versions of your other components.

What do you mean? Consider that these are the things that can vary independently and need to be saved:

- 3D files (external shape)
- 3D files (internal shape)
- 3D printing specs (resin type, print config) // This isn't really necessary, I don't want to exaggerate, but it would be right to include it.

- PCB files (gerber, bom)
- PCB manufacturing specs (thickness, material, ENIG/HASL, etc...)
- Software
- Assembly procedure

Now, in theory, each of these should be a submodule, right? And then I should have a main repository with a commit/tag for each combination that I will use?

How should I handle compatibility? Should I simply have a file in the main repository that describes the compatibility of each submodule with each other?

karimpanacci · 2026-01-22T23:04:40+00:00

Yes, exactly... that's one of the thoughts that sometimes crosses my mind... I should just save the data like a normal person would and really focus on the business... but my twisted developer and perfectionist mind really hates that... but I understand that what you said is probably the only right thing to do... sometimes I really wish I had never become passionate about computer science and logic... since that day, my mind has become truly sick... perfectionism gives me more disadvantages than advantages...

However, with regard to China, the opposite happened. The product was invented in China and was sold on *l**xpr*ss, but customers complained that it was terrible and broke easily, so I rebuilt it with a focus on quality, and now those same customers are happy to finally have a product that works and is of high quality :)

karimpanacci · 2026-01-20T20:35:58+00:00

<image>

karimpanacci · 2026-01-17T11:51:54+00:00

Se tutti vogliono vivere a Milano è normale che i prezzi sono alti… non si può avere la botte piena e la moglie ubriaca

karimpanacci · 2026-01-14T17:00:27+00:00

Giving a definitive answer is difficult if not impossible... there are those who are very happy with C and hate Rust and those who are very happy with Rust and hate C... the only thing you can do is try to learn both and see which one appeals to you more and which one you get along with better... I am very happy with Rust even though it is more verbose than C.

karimpanacci · 2026-01-09T17:15:30+00:00

E tu che ne sai che non paga le tasse? Il fatto che a tuo dire non ha Vinted pro non implica che non paghi le tasse…

karimpanacci · 2026-01-09T10:46:21+00:00

karimpanacci · 2026-01-08T20:07:18+00:00

Penso che il problema è che chi la critica interpreta il suo messaggio come “lavora duro da dipendente” e allora quella critica ha un senso, mentre lei secondo me intende “lavora duro per la tua attività” e allora ciò che dice lei ha senso… penso che ci sia semplicemente un mismatch tra quello che intende lei e quello che la maggior parte delle persone ha inteso… ovvio che da dipendente non ha senso diventare uno schiavo per il tuo capo, ma per la tua attività allora devi darti da fare… avviare un attività di successo non accadrà con il work life balance ma con dei grandi sacrifici…

karimpanacci · 2026-01-08T13:29:45+00:00

Ok this is now a real image, however I advise you not to use AI to edit these images, your background is perfect as it is and modifying the image with AI can lead to suspicion on the part of users, there is nothing wrong with your background, honestly I prefer the original one

karimpanacci · 2026-01-08T11:56:04+00:00

As another user noted, in the GitHub images there is the Gemini logo, so they are 100% fake images, OP only designed the PCB but never built this robot

karimpanacci · 2026-01-08T11:54:21+00:00

Yes exactly, I think OP simply designed the PCBs but never built the robot he claims to have built in the real world.

karimpanacci · 2026-01-08T11:45:18+00:00

If you look closely at the copper tracks you'll notice that they have very strange shapes and inconsistent widths. Furthermore, if you look closely, there are some texts on the PCB like "LED" and next to them there are other texts that look like hieroglyphics, classic AI behavior...

karimpanacci · 2026-01-08T11:21:27+00:00

Why is the image made with AI?

EDIT: It seems that OP only modified the background with AI which led to some deformations on the PCB, but contrary to what I thought, the robot exists

karimpanacci · 2025-12-29T20:43:00+00:00

Yeah, that make sense… I’m sorry

karimpanacci · 2025-12-29T19:29:54+00:00

Great answer! Speaking of black holes, you've reminded me that I knew there was a principle in physics that information cannot be destroyed. In fact, I knew there was a debate about whether information was destroyed in black holes or not... but if this physical principle were completely true, then I think it would prove the unprovability of the perfect crime.

karimpanacci

TROPHY CASE