I think the cost of paying for a dedicated email service is worth it. (There are plenty of smaller, privacy-oriented services such as Proton Mail or Fast Mail.)
They're better at it than I am, and it means I don't have to fill up my free time maintaining another server.
One solution is to use a unique email address for every website, and change the address if the site gets compromised (with the old address getting added to a spam filter).
This reminds me of a story that I heard from a tree surgeon. A customer complained about the cost of removing a tree as it was "unskilled" labour, and he asked them if they knew how to remove a 30-metre high tree without it falling on his house or car, or if he even owned the right tools, or if he was able and willing to climb up to the top of that tree and remove branches.
The list of so-called skilled labor jobs like lawyer, etc., that I would be willing to fake if I had to is pretty long the list of un skilled labor jobs basically starts with ditchdigger and ends there, and I’m even even scared of that one because of how you can die in a ditch if it collapses.
Nowadays I'd wager most ditchdigging is done with small excavators and I wouldn't want to operate one without some form of training. But I can use a broom if needed...
Not in developing countries: most small excavations in Chile are done by hand, even during road construction. Very few bobcats around here, so anything where a backhoe would be too big is done with shovels.
I was raised a farm boy where a lot of time was spent maintaining buildings, yards, machinery, etc., so I was exposed to most of the trades and could fake them if I had to.
Which is why I know that the trades are skilled labour. Because I don't have any of that skill.
Some of the boomers I know like to explain that they are paying for a brain. someone who has taken the time in school and is "smart"
This of course doesn't really work out as you have explained. I always like to point out that I'm one of those "smart" people and I'm a middle school drop out slacker who is just clever with computers.
in it, the author of the article uses the example of building a stair to motivate the discussion of how in practice, when rubber meets the road, things get complicated in very interesting ways
Unfortunately you're quite right. Maybe because those workers are also "trained" to see what they do as unskilled work, like everyone else says? So unskilled work is what they deliver. Now if only the society would give proper attention and value to those jobs... Edit: I'm also a diplomed electrician, but I have never practiced and would not even dream to practice nowadays without proper updated training. I guess not everybody is that self conscious, because hey it's unskilled right, so here we are.
I hear them in pubs bragging about how great they are and now people need them etc. They're anything but downbeat
They deliver shit work because they know they can charge high rates regardless, because of lack of DIY skills and lack of tradespeople. There's not enough competition - bring back the Polish I say.
Depends on how much you're willing to pay and how long you're willing to wait for them to be available.
The best carpenters will be making custom furniture and wood panels for mansions, and have multi-year waiting lists.
There are tradespeople who are excellent and available to mere mortals, though. But there's often a waiting list, and you may pay more. (I've had the best luck with auto-mechanics.)
Indeed. I was forced out of my home town to much further way due to the actions of successive governments to over-inflate house prices. Thank you for reminding me. Stay classy
If you're on a 3 year old version of the library because the library introduced a change which you will never be able to adopt so you're forever stuck on the 3 year old version, you're in a much worse position than if you're just 3 versions behind because you haven't taken the time to upgrade yet. As such, libyears become an optimistic measure of badness in that situation.
Nor did I claim it would. If you are auditing your dependencies like that then you don't need it, I said, as in it's not going to give you any extra information.
If you're not, and very many people are not, then total age of dependencies is a decent low-effort approximation for the probability of bug fixes affecting parts of dependencies that you're using.
That depends on the changes to the library since, and how and where the library is used.
Suppose I regularly generate a CSV file, all ASCII, where all the rows are integers or fixed precision numbers. I have a ten year old CSV library that processes that file, and has worked without any problem for ten years.
I have no interest in updating the library. Updates can introduce downtime, but provide no improvement. In fact, they introduce a slight performance hit because of new features and that I don't need. There is also the risk that the updates will introduce bugs, and then I'll have to spend time diagnosing the bug, and coming up with a fix.
Now let me reverse this: suppose there are two libraries to do the same task, A and B. They don't have the same features, but for your use case, they are both easy to use and do exactly what you need.
A was first released in the 1980s and was last updated five years ago. It's still maintained and is available in most Linux distributions.
B was first released three years ago and has had 20 updates since, 18 of which included fixes for security issues that don't affect A. (The website for A is regularly updated to indicate that it has been tested and these issues do not affect t.)
I see the overall point as not seeing every dependencies as things that need upgrade.
Any library that is effectively a dataset could fall into this as well: if you want to freeze your environment at a specific reference point and only update the actual moving parts, the libyear measurement won't be for you.
This reminds me of interface softwares that keep old version of some libraries to emulate the original behavior, butnin a controlled and isolated way.
On the other hand, it was only somewhat recently that CLDR acknowledged that languages with noun inflection exist, so it’s kind of a wash. E.g. in Russian, Ukrainian, and Belarusian (at least) you use the nominative of the month’s name in May 2024, but the genitive in 9 May 2024, etc., rendering most older allegedly-localized software that used a generic list of month names ungrammatical.
My immediate thought looking at this number was not that it should be minimized but that there ought to be a sweet spot range and a number below which it probably shouldn't go and a number above which it shouldn't go.
It's always context-dependent. Take Lisp languages. For Common Lisp, when I see a library that was last released or updated 10 years ago, I'm thinking it's probably as feature-complete as it's ever going to be, and otherwise perfectly fine. Same in case of Emacs Lisp? I'm thinking generations out of date, and has a solid chance of not working anymore. Here, it's a difference between a battle-tested, standardized (ANSI/ISO) platform (CL), vs. fast-evolving one (Emacs).
Stack Overflow has been less useful for several years before OpenAI.
I find for web technologies it's less useful because the technologies keep change, and what was a good answer in 2010 is not now. To answer questions I find it more useful to consult a primary source, such as the documentation on a some software's website, or a forum dedicated to that software.
On SO I often get no replies, or unhelpful and often toxic comments along the lines of "Technology X is bad, use Y instead".
Or I often get people who answer the question as if they show applying for a job at Google. No, I just need help with some software to process a few thousand rows and send a summary once a month by email. I'm not trying to process petabytes of data with a response time of <1ms.
They're better at it than I am, and it means I don't have to fill up my free time maintaining another server.