I wish I worked a simple manual labor job like a supermarket. It's just hard to make a living wage, savings, retire, pay for unexpected high costs for transportation or health care, and I wouldn't be able to travel. Otherwise it would be great. Stacking boxes all day? Helping customers with their bags? Doing inventory? Checking people out at the register? A simple job where I don't have to sit in a chair, can plan, organize, do rote manual tasks, socialize, and help people? Sign me up. Heck I might even do it part time when I retire.
I don't mind '0' == 0 when it's used for scripts and dumb stuff. That's literally how shellscript works, and I love shellscript, so I can't complain about that.
But I would never use shellscript to build an entire business's user interface with a giant shellscript framework. That would be insane. A language that was designed as a throwaway scripting thing for doing some miscellaneous tasks, and never designed for full application purposes? No sane person would use that for a business's core product.
I read this when I was younger, but I only now get it, and realize how true it all is.
13) Humans writing code is an inherently flawed concept. Doesn't matter what form the code takes. Machine code, assembly language, C, Perl, or a ChatGPT prompt. It's all flawed in the same way. We have not yet invented a technology or mechanism which avoids it. And high level abstraction doesn't really help. It hides problems only to create new ones, and other problems simply never go away.
21) Loosely coupled interfaces made our lives easier because it forced us to compartmentalize our efforts into something manageable. But it's hard to prove that this is a better outcome overall, as it forces us to solve problems in ways that still lead to worse outcomes than if we had used a simpler [formal] logic.
34) We will probably end up pushing our technical abilities to the limit in order to design a superior system, only to find out in the end that simpler formal logic is what we needed all along.
55) We're becoming stupider and worse at using the tools we already have. We're already shit at using language just for communicating with each other. Assuming we could make better programs with it is nonsensical.
For a long time now I've been upset at computer science's lack of innovation in the methods we use to solve problems. Programming is stupidly flawed. I've never been good at math, so I never really thought about it before, but math is really the answer to what I wish programming was: a formal system for solving a problem, and a formal system for proving that the solution is correct. That's what we're missing from software. That's where we should be headed.
For me power draw is about battery life. If you occasionally need to work without a power plug, or carrying your laptop from meeting to meeting all over the office, you really appreciate when the power lasts all day. My T14s battery draw of ~6.5W on the 57Wh battery will last me ~8 hours, good enough for a day unplugged at the office. (I'd love a bigger battery, but it is what it is...)
There's a fallacy often repeated for computers: "It's lasted a long time so it's going to keep lasting a long time." The thing is, failure of computer hardware is often due to manufacturing flaws. There's many that could have flaws, and they're subject to (varying) environmental stresses (both at build time at run time), so there's many failure modes.
It's difficult to know exactly when a server might fail. It might be within 1 month of its build, it might be 50 years. But what's clear is that failure isn't less likely as the machine gets older, it's more likely. There are outliers, but they;re rare. The failure modes for these things are well recorded, and the whole thing is designed to fail within a certain number of hours (if it's not the hard drive, it's the fan, the cpu, the memory, the capacitors, the solder joints, etc). It doesn't get better as it ages.
But environmental stress is often a predictor of how long it lives. If the machine is cooled properly, in a low-humidity environment, is jostled less, run at low-capacity (fans not running as hard, temperature not as high, disks not written to as much, etc), then it lives longer. So you can decrease the probability of failure, and it may live longer. But it also might drop dead tomorrow, because again there may be manufacturing flaws.
If given the choice, I wouldn't buy an old machine, because I don't know what kind of stress it's had, and the math is stacked against it.
It depends on the components. The bathtub curve applies the most manufactured equipment in some way. But specific kinds of hardware are more prone to it than others. Hard drives, fans, power supplies, dedicated controllers, RAM and CPU modules, etc all fail at different rates. Combine that with the varying failure rates of different grades of components, with manufacturer/model differences, environmental differences, and load differences, and it's all over the map. But in general, any one of these components is effectively a system failure, so there is always this varying degree of failure over time due to the fluctuation of all these variables.
I also believe there's a psychic component to failures. The machines know when you're close to product launch, or when someone has just discovered the servers haven't been maintained in a while and are at risk of failing. Then they'll fail for sure. Especially if there are hot-spare or backup servers, which will conveniently fail as well.
I've always found these general solutions kind of confusing. All uses of distributed data are inherently flawed, and have specific limitations, so you have to pick a solution that closest matches your specific use case.
I like the idea behind graft, but it immediately runs into some complications. Like the fact that, as an edge device with unreliable networking, its client may not have availability to fetch the pages it needs when it needs them. If anything, what the client really needs is to fetch all the data whenever it can, so that when it does need to access it, it isn't waiting.
But if you have a lot of data, that could take forever! That's why the application needs to be more intelligent about what data it's requesting, and do things like create priorities and classes for its data so it can fetch what it needs the most first.
The fact that this is built for SQLite kind of reinforces the point. Distributed relational databases are usually a bad idea, because usually people want them to be ACID-like, but you can't enforce that in a distributed way. That's why things like CRDTs exist; you treat every "copy" as an independent thing, breaking the false narrative that you can really distribute the same thing in multiple places reliably. (And that shows you why relational databases just aren't good for replicating; to replicate an entire relational database with CRDTs, you need one CRDT per cell, which multiplies your data)
I like the premise of the joke, but then as the explanation ran on... I suddenly became depressed. So much broken stuff, so much complexity.... to, what, make a network tunnel? If all this extra work was the joke, that would be funny.
We had to do some Plan 9 work, which makes sense when doing something new, but the actual Tailscale implementation is far _less_ work than for other Unixes.
I can call an ink pen "a sword". I can even justify this by saying some nonsense like "pens are used to wage war". But if I rush headlong at a Samurai with nothing but a Bic Rollerball, I should not expect to come out of the encounter with all my limbs, much less the expectation of injuring the Samurai. Just calling it "a sword" doesn't mean it has anything to do with an actual sword.
"Tech debt" isn't debt. It has nothing to do whatsoever with the concept of debt. What people mean when they say "Tech debt" is really "I'm putting off work I know I should be doing now, until later, and I'm doing something else instead that I know I'lll need to undo" That's not debt. That's procrastination. That's delaying the inevitable. It ain't debt.
You don't pay off a car loan with procrastination. You don't decide to put off painting your house and then call that a loan.
"Tech debt" has nothing to do with interest, with a lienholder, a creditor, a payment plan, etc. There is nobody to call in the loan. There is no incremental payment. There is no credit. There is nothing whatsoever to do with the entire concept of debt, much less any of the actual practical real-world implications, actions, or actors, behind debt.
Please let's stop perpetuating this cargo cult myth. There is no such thing as "tech debt". There is only compromises and procrastination, and justifying regrettable decisions by pretending there's a good rationale for them. There isn't.
Having worked at jobs for an extended time, you see how it is not just redoing for the same price. It compounds, for example a DB schema, over time people build more and more on top of it with leaky abstractions.
Are you aware of this thing called a "metaphor"? Do you also find it aggravating when someone tells you about a program that is "running" because it's not using its legs to move along the ground? Or when someone says that they're going to "take a rain check" on an activity that doesn't have an entry fee?
>You don't pay off a car loan with procrastination.
Following the metaphor, the car loan itself would be the result of procrastination (i.e. you procrastinated when you decided to put off paying for the car by taking on debt).
>You don't decide to put off painting your house and then call that a loan.
I mean, I don't see what would prevent you from doing that, as long as everyone understands what you mean.
Nobody acts like a server has legs when they say it's running. They do act like there is actual debt, or something that functions just like debt, when they say it's "tech debt".
If I said to you, "I know I should be on a diet right now, but I'm going to eat these donuts for a few months anyway." - is that diet debt? You might say yes, you might say no. Either way, I'm an idiot if I think I can eat those donuts now and just "pay them back" in a few months. That's not how food works. That's not how health works. It's not "good" that I'm packing on the pounds now. It's going to be harder to work them off later.
There's so many different decisions I could have taken to lessen the impact of this, like limiting my donut intake, or exercising after eating the donut, only eating half a donut, only eating a donut after I've reached a milestone, etc. But none of that goes into my diet debt idea. Because in my head, I can justify any shit decision I take now, with the idea of magically paying it off later with magic diet money. This was not a good decision, and calling them debt didn't make it a good or justifiable decision. I was just being fat and lazy.
People are literally considering the putting-off-of-necessary-work as equivalent to the functioning and value of a financial instrument (wherein debt is an actually constructive thing). They say, "tech debt is good, because <insert justifications>, and we can just pay it off later!".
Which is of course total nonsense, verging on insanity. You don't "pay off" generic bad decisions now with generic good decisions later. How about we nuke Russia tomorrow, and just "pay it back" by giving aid to Africa in 100 years? Hmmmmm. Nuclear debt? Sounds good to me!
There are bad metaphors, and then there's group psychosis covered by a metaphor. So much shit is constantly excused with this trite nonsense. It's a universal "do whatever the fuck you want" excuse. Do anything you know is wrong, and say "well, you know, it's just tech debt!", and all is forgiven and allowed. Like doing ten Hail Mary's after fondling the alter boy. Intone the magic words and you're free to sin again.
>Either way, I'm an idiot if I think I can eat those donuts now and just "pay them back" in a few months. That's not how food works. That's not how health works. It's not "good" that I'm packing on the pounds now.
In fact, that's exactly how food works. If you don't weight thousands of kilos right now it's because how much you've eaten and how much you've burned are more or less balanced, even if you're not at your ideal weight.
>It's going to be harder to work them off later.
Why? Literally, why? A Joule is a Joule whether it's now or later. It will literally cost you the same effort to burn a Joule's worth of fat now as it will ten years from now, because that's what effort is.
The way technical debt and "dieting debt" are different from financial debt is not in how (or whether) they're accrued and paid off, but in that financial debt has a time component, because the debt is with a second party. You can't hold a significant debt indefinitely, someone eventually comes to find you. Technical debt and dieting debt are debts you have with yourself -- or rather with your future self. There's no one to come looking for you, and you're only screwing yourself if you let the debt sit there unpaid and causing problems for yourself. That's why it's stupid to accrue it, not because of some effort calculus about how much more effort it's going to take to repay later.
I always thought it meant "I'll go check if it's raining (and never come back)", but it turns out that a rain check is an IOU given out when an outdoor activity is disrupted by weather, so you can use it for a later event.
Building large battery arrays out of old recycled cells does not require bringing the workers to the battery cells, any more than building iPhones requires you to bring the workers to where they mine ore. Large-scale product development often involves shipping materials and half-finished products around the world multiple times.
