> "Money is neither created nor destroyed, it simply moves from one hand to another".
With regards to how money is created, you may want to read on credit and how banks create money virtually out of nothing, or how the state has a monopoly on printing money (turning "not money" -- paper and ink -- into "money").
The destroying part is much simpler: you can perform an experiment of burning a banknote yourself.
Homo sapiens is a genus full of anxiety, as our ancestors who didn't "worry about tomorrow" either died from hunger, or got killed by those who did. Anxiety is an evolutionary feature.
I used to think this way. Spent decades justifying it as a motivator. It's a trap.
It made sense if you were risking your life whenever you went to get food. If you're trying to recreate those feelings by undercharging the battery of your smartphone, you're just bored
It doesn’t matter. You’re not trying to recreate anything. Your brain is just wired that way already. You’ve got it from your parents, who got it from their parents, all the way to our predecessors in Africa.
Anything around 20 degC ambient temperature should be fine. More important is that the phone can easily dissipate heat. It should not be covered by blanket or near a heater or in direct sunlight.
I guess you've missed my point, which is: I don't work for my phone. My phone works for me. As such, I shouldn't find myself in the situations where I have to create the optimal conditions for my phone, but rather my phone should somehow accommodate the conditions that I deem optimal for me. The idea that somehow I should provide "cool temperatures" in order to "give a much better lifespan" to my phone while it is "fast charging" ... seems completely idiotic to me. Cooling my room to 20C all year round will incur huge electricity costs, but even if the cost was zero, I don't work for my phone. The other options -- whether slow charge, or replacing the battery, or replacing the phone -- render the option of cooling my home inconvenient to the extreme.
What's bad about this is when these children would need to fit inside a certain circle with other people, who don't behave like machines do. Circle like school, work, or family. These children might have issues accommodating there.
You may then ask, "maybe humans don't need schools, work, or families," but that would be a different conversation.
Modularity hasn't been the proclaimed goal for the Pro line, as far as I can remember. Granted, they were modular once. Today, not so much. The RAM is literally sitting on the die of the chip that includes the CPU and the GPU. This allows for tremendous increases in performance, but RAM upgradeability is sadly out of question.
Q: How do you determine what date it was 180 days ago?
A: Easy! You just spin up a Kubernetes pod with Alpine image, map a couple of files inside, run a bash script of "date" with some parameters, redirect output to a mapped file, and then read the resulting file. That's all. Here's a YAML for you. Configuration, baby!
I wasn’t. This goes to show that when all you have is a YAML hammer, every problem has to look like a YAML-able nail. Still there would be people who would say I’m “blaming my tools” and “everything is covered in chapter 1 of yaml for dummies.”
The problem starts when that graph cannot be determined in advance and needs to be computed in runtime. It's a bit better when it's possible to compute that graph as a first step, and it's a lot worse when one needs to do a couple of stages before being able to compute the next elements of the graph. The graph computation is terrible enough in e.g. Groovy, but having to do it in YAML is absolutely horrendous.
> Take a look at GitLab CICD for a pipeline with build, test, and delivery stage
Yeah, if your workflow fits in a kindergarten example of "build, test, and delivery", then yeah, it's YAML all the way baby. Not everyone is so fortunate.
You can't put a breakpoint in YAML. You can't evaluate variables in YAML. You can't print debugging info from YAML. You can't rerun YAML from some point.
YAML is great for the happy-flow where everything works. It's absolutely terrible for any other flow.
FWIW there's no reason why you shouldn't be able to put a breakpoint in pipeline YAML. I'm not aware of anyone implementing such a thing, but a DAP adapter that VSCode could attach to remotely should be pretty straightforward.
MSBuild, for example, is all XML, but it has debugging support in Visual Studio complete with breakpoints and expression evaluation.
> You can't put a breakpoint in YAML. You can't evaluate variables in YAML. You can't print debugging info from YAML. You can't rerun YAML from some point
It's a DSL. There is no execution, only configuration. The only thing that's executed are the custom scripts you create yourself, and any intro tutorial on the subject will eventually teach you that if you want to run anything beyond a single straight-forward command then you should move those instructions to a shell script to make them testable and reproducible.
Things are so simple and straight forward that you need to go way out of your way to create your own problems.
I wonder how many people in this discussion are blaming the tools when they even bothered to learn the very basics.
Your attitude of "how is everyone so stupid" does not help the discussion.
> It's a DSL. There is no execution, only configuration.
Jenkins pipelines are also DSL. I still can print out debugging information from them. "It's a DSL" is not an excuse for being a special case of shitty DSL.
> any intro tutorial on the subject will eventually teach you
Do these tutorials have a chapter on what to do when you join a company with 500 engineers and a ton of YAMLs that are not written in that way?
> you should move those instructions to a shell script to make them testable
Yeah, no. How am I supposed to test my script that is supposed to run on Github-supplied runner with a ton of injected secrets and Github-supplied JSON of 10,000 lines, when I don’t have the runner, the secrets, or the JSON?
The YAML is fed into an agent which reads it to decide what to execute. Any time you change the control flow of a system by changing data, you are doing a form of programming.
That’s just the same “my pip is too slow” problem which some people don’t have.
I work in a place with 200 developers, and 99% of pip usage is in automated jobs that last an hour. Shaving a couple seconds off that will not provide any tangible benefit. However moving 200 people from a tool they know to one they don’t comes at a rather significant cost.
> Shaving a couple seconds off that will not provide any tangible benefit.
It could be more than that.
I switched from pip to uv today in a Dockerized project with 45 total dependencies (top level + sub-dependencies included).
pip takes 38 seconds and uv takes 3 seconds, both uncached. A 10x+ difference is massive and if uv happens to be better suited to run on multiple cores it could be even more because my machine is a quad core i5 3.20ghz from 10 years ago.
> I work in a place with 200 developers
In your case, if you have 200 developers spending an hour on builds that could in theory be reduced down to 5 minutes per build. That's 11,000 minutes or 183 hours of dev time saved per 1 build. I know you say it's automated but someone is almost always waiting for something right?
For what it's worth uv is fully compatible with pip. just replace 'pip --foo bar' with 'uv pip --foo bar'. One project I'm working on is 100% 'classic' pip based with no plans of moving, but I still use uv when working on it as it is completely transparent. Uv manages my venvs and python versions and makes things like switching between different versions of python and libraries much smoother, and I can still use the same pip commands as everybody else, it's just that all my pip commands run faster.
* uv makes some design choices that aren't always strictly compatible with the spec
* uv correctly implements the spec and it turns out pip, or the underlying library, didn't (I have worked on fixing a couple of these on the pip side)
* uv doesn't support legacy features still in pip
* Tool specific features or exact output diverge
This is not a criticism, but I've seen some users get irate with uv because they were under the impression that it was making much stronger compatibility guarantees.
With regards to how money is created, you may want to read on credit and how banks create money virtually out of nothing, or how the state has a monopoly on printing money (turning "not money" -- paper and ink -- into "money").
The destroying part is much simpler: you can perform an experiment of burning a banknote yourself.
reply