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
meanwhile in america: public sectors heavility relied on microsoft, and now they deal with the fallout from a recent security incident at microsoft
https://www.heise.de/news/Nach-Microsoft-Hack-muessen-US-Behoerden-gross-aufraeumen-9682556.html
tldr: microsoft was hacked big time. Now hackers have free reign over all Microsoft-customers, among which are many government agencies.
============ 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
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
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.
also any beginner-friendly distro should be popular enough for the beginner to find it in the first place.
(big exception: if it came pre-installed on their device)
how far can you get with arch without opening the terminal or the wiki?
Yes, the arch wiki is very good and useful. The issue is, that you need the wiki in the first place. In a user-friendly distro everything would either work OOTB, or it could be done intuitively via GUI.
how far can you get in arch without opening the terminal?
“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
- Users are finally figuring out that some Linux distros are easy to use
so recommending arch linux to newbies was counter productive all along?
suprised_pikachu.bmp
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
One’s an active decision
There are not so many quality notebooks without any brand-logos on them.
Also wearing a brand-logo when you have the choice not to, is kinda cringe.
what does “get surprised on their own call” mean?
Because megacorps are at least “smart enough” to pretend they aren’t trying to take over the world.
there are enough examples for corps doing evil things. You hear about them less often, because they cover their tracks and the outcry is generally smaller than when governments do similar things.
Whereas governments have a tendency to justify a lot of horrible shit for righteous reasons.
corps justify a lot of horribble shit for financial reasons. Is that better?
who else should be a significant backer for an open source project? google? microsoft?
chicken got you covered on that front too https://www.youtube.com/watch?v=iubf1oJdQQQ