because of two bodies can not occupy the same space, the feather and the ball will be in different position when you drop them. And therefor gravitation will pull the earth slightly more toward the ball and slightly less toward the feather.

I like the explanation that devious spirits cannot say this phrase and that’s why it’s used

Evil spirits can not say the same word twice in a row. Foxes can not say “moshi”. With “moshi moshi” you get a 2-for-1 special.

Most Adobe tools don’t have any good free alternatives even for home use.

inkscape is on a level with illustrator (maybe even better)

for drawing: try krita

if you want to pay money (much much less than for adobe): Affinity is on a level with fotoshop

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

Only reason to include 2 full bridge rectifiers

they look like runes.

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

eliza could do that 60 years ago

But only temporarily

but is it?

I thought the temporal improvement would be for everyone who already used the high way (because they will get to their destination a little bit faster). And for the few extra people, who start to use the highway but didn’t use it before, the improvment will stay.

When you add a new lane to a road, people think that the traffic will be easier there, so they take that route instead of their normal one

so for these people the new lane will create marginal improvement, right?

However you will now have rodent problems

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

soft failures add complexity and ambiguity to your system, as it creates many paths and states you have to consider. It’s generally a good idea to keep the exception handling simple, by failing fast and hard.

here is a nice paper, that highlights some exception handling issues in complex systems

https://www.usenix.org/system/files/conference/osdi14/osdi14-paper-yuan.pdf

============ 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/

why not?

yes.

also employees don’t need to have a shitty job to survive.

Now people have to decide between “doing a shitty job” and “starving”. With UBI people can choose between “doing a shitty job” and “chilling at home”. So if employers want their shitty job to be done, they will actually have to make it worth it (either by increasinge wages, or by making the job less shitty).

in other words: good jobs will get subsidized by UBI. Shitty jobs will compete with UBI

https://www.youtube.com/watch?v=ne6nj9AgY7M

it’s safe to assume there are similar issues in closed source. A big part of the snowden leaks was about how NSA could access lots of data at will. It wouldn’t surprise me if they also could execute code.

Also there is stuxnet. But I am not sure, if there were intentional backdoors, or only some “natural occuring” RCE.

it takes away my charging port

is that really the main issue? if so, there are also adapters, which also expose the charging port

is stateless possible without kubernetes? (and without vendor lock in?)

GP said:

RE: Containers, even if you DO go that route, do you really need Kubernetes, which will come at an additional monetary and also maintenance cost? The likely answer at least initially is a big fat “no”.

I agree, that good cloud engineers can save costs in the cloud. But I also think good non-cloud engineers, can save much much more.

When you are rewriting your entire stack to leverage cloud performance, you could probably spend a similar effort for a rewrite that increases regular performance by a similar factor.

RE: Containers, even if you DO go that route…

I was under the impression, that stateless stuff without containers requires a strong vendor login (aws lambda, google functions, azure function). Are you saying, I could do stateless without vendor-lockin and without containers and without kubernetes? This is news to me. Please point me to some resources