if you just want to make a simple program. It still needs to run in kubernetes.

“hello OPS-team. Here is my simple program. Have fun running it on your kubernetes”

It’s at most 40 years old technolog

the 60s were 60 years ago

. But it is trained well enough to correlate left and right together

eliza could do that 60 years ago

However you will now have rodent problems

chicken got you covered on that front too https://www.youtube.com/watch?v=iubf1oJdQQQ

============ Top 5: =============== HasThisTypePatternTriedToSneakInSomeGenericOrParameterizedTypePatternMatchingStuffAnywhereVisitor: 97
AbstractAnnotationConfigDispatcherServletInitializer: 52
AbstractInterruptibleBatchPreparedStatementSetter: 49
AbstractInterceptorDrivenBeanDefinitionDecorator: 48
GenericInterfaceDrivenDependencyInjectionAspect: 47

============ Factories: ===============
DefaultListableBeanFactory$DependencyObjectFactory
ObjectFactoryCreatingFactoryBean
SimpleBeanFactoryAwareAspectInstanceFactory
SingletonBeanFactoryLocator$BeanFactoryGroup
ConnectionFactoryUtils$ResourceFactory
DefaultListableBeanFactory$DependencyProviderFactory
ObjectFactoryCreatingFactoryBean$TargetBeanObjectFactory
JndiObjectFactoryBean$JndiObjectProxyFactory
DefaultListableBeanFactory$SerializedBeanFactoryReference
AbstractEntityManagerFactoryBean$SerializedEntityManagerFactoryBeanReference
BeanFactoryAspectInstanceFactory
SingletonBeanFactoryLocator$CountingBeanFactoryReference
TransactionAwarePersistenceManagerFactoryProxy$PersistenceManagerFactoryInvocationHandler
AbstractEntityManagerFactoryBean$ManagedEntityManagerFactoryInvocationHandler

https://gist.github.com/thom-nic/2c74ed4075569da0f80b

the fact that a system eventually becomes complex and flawed is not due to engineering failures - it is inherent in the nature of changing systems

it is not. It’s just that there will be some point, where you need significant effort to keep the systems structure up to the new demands {1}. I find the debt-metaphor is quite apt [2]: In your scenario the debt accumulates until it’s easier to start fresh. But you can also manage your debt and keep going indefinitily. But in contrast to financial debt, paying of technical debt is much less obvious. First of all it is pretty much impossible to put any kind of exact number on it. On the other hand, it’s very hard to tell what you actually should do to pay it off. (tangent: This is why experienced engineers are worth so much: (among other things) they have seen how debt evolves over time, and may see the early signs).

[1] https://tidyfirst.substack.com/p/the-openclosedopen-principle

[2] https://blog.pragmaticengineer.com/tech-debt/

“sudo MacOS” sounds like a legit way to describe “gnome+ubuntu”

KDE on steamdeck, because it came preinstalled

Gnome on work-pc, because it came preinstalled

also gnome on notebook, because the multi-workspace thing works very nice OOTB in gnome

I just want to point out, that what you are saying sounds good in an ideal world. But the realitiy looks different. (I actually typed out some points, but then I remembered that I don’t want to engage in yet another lengthy internet-debate, that ultimately comes down to personal preferences and philosophy)

I use like 3 of the git-feature from intellij (out of 100 or so). But these 3 features save me a lot of time.

(the other 2 being the 3-way-merge-view and the commit-view where I can select changes for staging)

why would rebasing a feature branch change main?

the image does not update the feature branch. It merges the featurebranch into main with a regular old merge-commit on the main branch.

Another advice …quick way to squash all your commits

in your IDE select the commits you want to squash. Then rightclick. Then “squash”. All done.

it’s all of them

EMBRACE

how does it compare to this? https://tianweiy.github.io/dmd/

for me it was on a pi5. maybe the amd64 was what made it work for me? idk.

snappy it feels versus the official rpi OS

I blame the desktop manager. Once I ditched the default von on the pi, and replaced it with standard gnome, the pi became almost as snappy as my regular notebook.

in general: standard debian should be exactly as light-weight as arch.

the linux-file-deletion is used as a example for good software design. It has a very simple interface with little room for error while doing exactly what the caller intended.

In John Ousterhout’s “software design philosophy” a chapter is called “define errors out of existence”. In windows “delete” is defined as “the file is gone from the HDD”. So it must wait for all processes to release that file. In Linux “unlink” is defined as “the file can’t be accessed anymore”. So the file is gone from the filesystem immediately and existing file-handles from other processes will life on.

The trade-off here is: “more errors for the caller of delete” vs “more errors due to filehandles to dead files”. And as it turns out, the former creates issues for both developers and for users, while the later creates virtually no errors in practice.

open suse (or was it mandrake? idk) around 2006. I remember trying it, and thinking “wow. This is trash” and then sticking with windows for 10 more years until giving ubuntu a try (and sticking to it). I tried other non-debian linuxes since then, but they all gave me that “wow, trash”-kind of feeling

it’s a great candidate. It was my first “real” languages (i.e. the first language, that is not php/js)

you have a text file. then call the compiler on it, and then you have a exe file, that you can run. It does exactly what it is supposed to do without thinking about the browser, the webserver, the JVM, or some other weirdness.

I get, that doing “good cpp” is difficult. And using all the weird languages features is difficult. But as long as you use strings, ints, ifs, fors, you should be fine. Just don’t use generics, templates, new (keep everything on the stack), multi-inheritance, complex libraries, and it’s a nice beginner language.