It’s funny because that’s true that an old Linux binary is likely to have issues under Linux, but an similarly old Windows application might work better under Wine on Linux than modern Windows.
libc is actually relatively less likely, glibc is awfully conservative about changes, but there are a maze of likely service and library dependencies that were abandoned or didn’t regard backwards compatibility with the same importance.
I’m still on Windows 3.11 because I demand an edition for Workgroups and nothing else has it in the name!
Oh cool, let me install this software, what, it won’t install because it’s missing quicktime? Oh it needs directx 8 runtime? That could be a problem. Let’s advance the clock, 2004, that should be fine… What do you mean you can’t run .NET 1.1 applications and so that won’t run?
Ironically, wine is more likely to have a path to easily run those programs under Linux, but if you had a Linux binary from that era you’d likely have a hard time getting that to run, probably harder than the microsoft scenario. So old Windows software is more likely to run under Linux than old Linux software…
AI in vim is actually often convenient.
:set ai
Cool, now it will keep track of my indentation.
Now sometimes that gets in the way, and while you can:
:set noai
Usually it’s best for me to:
:set paste
And that’s my take on the utility of AI in vim. (that is what you meant right, there isn’t some other AI people are thinking of right?)
If you use it to make sure your deployment is sane and that your dev system didn’t have an invisible component that you assumed as a dependency, great. Containers are a great tool for simulating minimalist clean setups and not incurring surprise hidden dependencies.
If your application carries a whole container with it for the user to use and that’s the only way to use the software, that’s going to be annoying. ‘docker style’ for bloat, flatpak/snap depends on the app but sometimes the application functionality is broken by the container boundaries. Admittedly flatpak/snap is frequently acceptable, really depends on if the program has a lot of interoperability features that get broken in the flatpak/snap runtime model.
If your application only is deployable as a pod… I’m almost certainly going to want to avoid it if at all humanly possible. Pods as a self-hosted approach to do what you want, ok, fine and I own all that. If a third party pod is happening, I tend to see some part of it fall over it and no one can figure it out because the application is microserviced into oblivion and no human actually understands the whole flow… It’s possible also to do this with ‘traditional’ application delivery, but a pod is a very high sign that no one even bothered thinking hard about how it should come together and play nice with others.
Yeah, wifi is a crapshoot as to whether it might expect a cloud connection, so I have to research those devices carefully. I’m satisfied with my OpenGarage being on Wifi because I know it has no internet aspirations. I hope that Matter over Wifi devices are similarly local friendly, but I haven’t actually had anything to buy since that was an option.
Indeed, nice and layered.
If internet, wifi, internet, and zigbee/thread/zwave up, fully functional, can close my garage door from miles away
If internet is down, then everything still works within wifi range.
If local connectivity is down, well, all the local controls still work almost the same as a non-smart (the ‘on/off’ switches sit in the middle instead of being ‘on’ or ‘off’ since physical and logical state could otherwise disagree, but switch down to off, switch up to on still works).
It’s a bit of a curse, so often I come in and things magically start working… But that’s hardly satisfying, and the person that needs help just knows it’s going to bite them again… So I get to guess why it broke before it behaved for me and hopefully figure it out and fix it despite it currently working right now.
But the first half also says someone with ugly thoughts cannot ever look ‘pretty’, and not ‘oh people will know your inner ugliness and refuse to see your physical attractiveness’, but ‘your face will develop ugly features’. So it at least declares that pretty people should be considered ‘good’.
The top half illustration shows that ugly thoughts should be expected to manifest over time as ugly face, not body language, not behavior, not having ugly expressions on what could have been a lovely face, but the face gets uglier. Meaning someone who looks nice obviously must not be having ugly thoughts.
Yes, the second part suggests ‘ugly’ features can look lovely with the right attitude, but the first clearly says ugly thoughts make ugly features and by implication pretty people can’t be possessing of evil thoughts.
Funny thing is that at least in my wedding day there was no sex.
It was just way too exhausting to have energy left over for that.
What i find funny are people building golang binaries without cgo and still wrapping them in full distro containers. Your binary uses nothing from the container and still it gets packaged that way…
Seen so many developers incur a huge headache trying to figure out overly complicated container setup when they could just run their already static binary without any drama…