Freelance software engineer with experience across a wide range of areas in web and software development. Skilled in delivering projects that require autonomy and focus.
Expertise includes JavaScript, Go, Python, and PHP, along with frameworks such as Node.js, Django, Flask, and Laravel. Proficient in cloud and infrastructure tools, including AWS, Kubernetes, Terraform, and Serverless.
Capable of handling static websites, web applications, and custom cloud solutions with a focus on simplicity and thoughtful design.
This is a well known concept called the "Hedonic Treadmill", which exists since the 70ies, not "doomer psychology". It also does not say treating depression is not possible. Depression is a disease.
Freelance software engineer with experience across a wide range of areas in web and software development.
Skilled in delivering well-defined, scoped projects that require autonomy and focus.
Expertise includes JavaScript, Go, Python, and PHP, along with frameworks such as Node.js, Django, Flask, and Laravel.
Proficient in cloud and infrastructure tools, including AWS, Kubernetes, Terraform, and Serverless.
Capable of handling static websites, web applications, and custom cloud solutions with a focus on simplicity and thoughtful design.
The ICE Wifi is using very exotic IPs for their gateway here, so this is not really Docker's fault.
For reference, this can be worked around by deleting your Docker networks, logging in and recreating the networks, which should pose no problems on a dev machine.
What are "exotic" IPs? By using "common" ones, would the probability of a conflict even grow?
I am not aware of any guidance how to use privat IPv4 addresses. In practice 192.168.1.0/24 seems to be the most commonly used one, so you might want to avoid that.
It's not that irrelevant, considering that podman managed to solve both problems - necessity of a daemon and keeping the default network namespace clean. That said, I don't want to take away the credit of Docker being the pioneers in their field (yes it existed before. But it wasn't this popular).
Isn't Podman only able to do this because of user namespaces, which are a very recent addition to Linux? I wonder how Podman will do, if that's the case, now that user namespaces are being turned off by default due to their security implications.
I always thought containerization - including docker - was the result of Linux namespaces (more so than even cgroups). Checking again, Linux namespaces were introduced in 2002. Docker was released more than a decade later - in 2013. I believe that Docker always used namespaces - that's how they achieved process isolation. But they didn't use it to its full potential initially - including network namespaces and pods.
A package appearing in go.sum does not necessarily mean it's being used. It just means it has been downloaded once, but might have been replaced by some other version at some point.
This has bitten me before. A security scanner reported a vulnerability from this that was blocking me from my “use X at work” request.
I ended up having to teach the vendor of the tool about go mod.
But if you are publishing a “release” I personally think it is good to tidy that up. Even just to prevent misconceptions. No reason to preserve ancient versions and especially failed library experiments.
In a cursory survey [1] of the alcoholics I've known (both recovering/acknowledged and not), for 80% social drinking hasn't been the problem. The problem was what they did when they were alone with a bottle.
[1] Not an SRS, clearly anecdotal and entirely in my head, so all caveats apply, etc.
Stylistic nitpick: don't use the word cancerous for things that don't make too much of a difference for anything but your "ethos". Real cancer has people die (animals too). Bloated websites might be annoying, but you will survive them even if your the 1337est hacker around.
I can definitely imagine situations where being able to load a page quickly is indeed a matter of life or death. This is indeed part of the design rationale for the min css framework: https://mincss.com/index.html
> Min is used by over 65,000 people in 195+ countries, from North Korea to South Sudan to Mongolia to Somalia. Think your software is critical? Try a webapp keeping you alive in a warzone.
Now, whether or not this actually happens is a good question, but it does seem like a plausible possibility.
One example that comes to mind even here in the US would be getting emergency info out (evacuation orders, contact info, etc.) during natural disasters like wildfires and storms. A lot of rural areas are still stuck with dial-up and low-bandwidth cellular data at best, so every kilobyte matters. This also applies even in places with abundant cellular coverage; congestion can and often does cause issues with thousands or millions of people trying to get info or reach out to emergency contacts all at once.
Min's rationale further brings to mind things like disseminating info on hospitals, shelters, etc. in war zones, often to people who at most have an ancient (by first-world standards) phone with expensive and slow network connectivity.
The problem with bloated website is, that the cumulative time lost while waiting for them to load is (for many) measured in many, many years. Pages like google/facebook/... optimizing load time by a couple of hundredths of a second, means years of real people time saved.
I know it sucks waiting for a website to load, but it's not like your life depends on it. You can still be an overall happy person while doing so, time is not "lost".
Performance metrics are better when put into perspective.
I built something similar back when jQuery plugins were still a thing (oh my), but video seems broken in nowaday's browsers unfortunately: https://github.com/m90/jquery.abc
Freelance software engineer with experience across a wide range of areas in web and software development. Skilled in delivering projects that require autonomy and focus.
Expertise includes JavaScript, Go, Python, and PHP, along with frameworks such as Node.js, Django, Flask, and Laravel. Proficient in cloud and infrastructure tools, including AWS, Kubernetes, Terraform, and Serverless.
Capable of handling static websites, web applications, and custom cloud solutions with a focus on simplicity and thoughtful design.