QuadriLiteral

joined 1 year ago
[–] [email protected] 1 points 3 weeks ago

Wonder how much of this relates to SUSE? How "normie-tolerant" is that? I've been printing for years without any issues for instance, and have a HP printer that used to hate my linux OS with a passion.

[–] [email protected] 4 points 1 month ago

What you say describes my experience 10 to 15 years ago, not my experience today. Compare the settings dialog in KDE Plasma to the windows settings dialog for instance. Or should I say myriad of Windows settings dialogues.

[–] [email protected] 1 points 1 month ago (2 children)

What was difficult in your experience?

[–] [email protected] 0 points 3 months ago

Huh odd, I guess it depends quite heavily on the system? Just to check I cleaned my build folder and am building now, ~700 files that take around 5 minutes to compile. I don't notice a thing, CPU (Ryzen 7 7700X ) is fully maxed out. I know that I do notice it on my laptop, but there reducing from 16 to 12 or even 14 is enough. Having to reduce to 4 is very different from what I experience. Currently on manjaro, the laptop has ubuntu.

[–] [email protected] 0 points 3 months ago* (last edited 3 months ago) (2 children)

If you don't want compilation to take all cores, use one or two cores less for the compile. I frequently compile C++ code, almost always I just let it max out 100%, haven't been really bothered by the lag. When I'm in a teams meeting for instance it can cause noticable lag so then I do ninja -n 8 or ninja -n 12 and problem solved.

[–] [email protected] 0 points 4 months ago (1 children)

I was very surprised yesterday to find out that Unreal Engine now offers native linux builds as well as linux targets. Works flawlessly too. So with all the hate linux seems to be getting from them from what you read in the occasional blog post, they must have devs working only on this support.

[–] [email protected] 2 points 4 months ago

Turns out you were the hacker all along

[–] [email protected] 1 points 6 months ago

I guess this is go, and I don't know what the scoping is. In C++ I also suggest putting as much in the if as possible, because it limits the scope of the variables.

[–] [email protected] 2 points 6 months ago

I found basic functioning of worktrees to fail with submodules. The worktree doesn't know about submodules, and again and again messes up the links to it. Basic pulling, switching branches, ..., all of this frequently fails to work because the link to the submodule is broken. I ended up creating the submodules as worktrees of a separate checkout of the submodule repo, and recreating these submodule worktrees over and over. I pretty much stopped using worktrees at that point.

Have you tried the global git config to enable recursive over sub modules by default?

Nope, fingers crossed it helps for you ;) Unrelated to worktrees but: in the end I like submodules in theory but found them to be absolutely terrible in practice, that's without even factoring in the worktrees. So we went back to a monorepo.

[–] [email protected] 16 points 7 months ago (4 children)

I'm a C++ dev, I have one checkout of the main repo and 3 worktrees. Switching branches can be expensive because of recompiles, so to do e.g. quick fixes I'll use worktree 1 where I typically don't even compile the code, just make the fix and push it to the CI system. Worktrees 2 and 3 I keep at older releases so I can immediately fire up development and one of those releases side by side and compare results as well as the code.

The cool thing about worktrees instead of multiple checkouts is that you only have one .git folder, so less disk space. But more importantly local branches (well everything actually) are shared, so you can create a local branch in the main checkout, and later come back to it in a worktree. You also don't need fetching/... in the worktrees, as they share the same .git folder.

Only thing that I found virtually impossible to work with is worktree + submodules.

[–] [email protected] 1 points 7 months ago

To me that sounds like “that machine prototype is inefficient - just skip the prototype next time and build the real thing right away.”

I don't think you understand my point, which is that developing the prototype takes e.g. 50% more time than it should because of complete lack of understanding of software development.

[–] [email protected] 1 points 7 months ago (1 children)

Mostly ML or data processing libraries I would assume, I've read tons of REST server and ORM python code for instance, none of that is written in C.

Wrt rust: no experience with that. I do do a lot of C++, there you quickly reach the end as typically you're consuming quite a bit of libraries but the complete sources of those aren't part of what is parsed by the IDE as keeping all that in memory would be unworkable.

view more: next ›