nocman

sounds similar to rdiff-backup ( https://rdiff-backup.net ).

I know some folks that have been using that for a very long time as well.

Good one - made me and a coworker both LOL (in the literal sense) :D

Yeah, I didn't notice where the article was located at first, and I thought that's what it was going to be about also.

Um, please let your comment be sarcastic. It is ... right?

> sed is not "stream editor" as it says above, it's "stream ed"

Well, according to the man page, it is indeed "stream editor":

https://man.cat-v.org/unix_8th/1/sed

I was already aware of its relation to 'ed' (having had to actually use 'ed' in ancient times). However that doesn't change the fact that it does stand for "stream editor".

After reading your post, I thought "That doesn't seem right, I remember it specifically being referred to as 'stream editor'", so I went looking.

> There was strong cultural pressure to be able to write perl in as few bytes as possible

Hard disagree. Many Perl programmers enjoyed engaging in code golf (always just for fun, in my experience), but in my nearly 30 years of programming Perl, I never encountered anything that I would call pressure to do so -- not from anyone.

I don't think in this case that most people who know what Arduino is would be at all mislead by the title. Being "dead" doesn't have to mean that a company ceases to exist. There are plenty of what I would call "dead" companies that still make money every year. "Dead" can be used figuratively. In this case, meaning that though the company continues to exist, the reason for which many people bought their products is now gone.

And Randall deserves EVERY single one of them, IMHO!

Oh, good, I'm not the only one then.

"With traditional solutions (such as OpenVPN / IPSec) starting to run out of steam" -- and then zero explanation or evidence of how that is true.

I can see an argument for IPSec. I haven't used that for many years. However, I see zero evidence that OpenVPN is "running out of steam" in any way shape or form.

I would be interested to know the reasoning behind this. Hopefully the sentiment isn't "this is over five years old so something newer must automatically be better". Pardon me if I am being too cynical, but I've just seen way too much of that recently.

> for me, everything git is a pain point

Yeah, I was looking for something (or "things") specific. An "I hate everything about it" explanation doesn't really compel me to try out the alternative.

> "megamerges" are one such example. ive shared many links, here and in other posts

I read through one megamerge link you shared ( https://v5.chriskrycho.com/journal/jujutsu-megamerges-and-jj... ). So the argument seems to be (forgive me if I'm reading this wrong), if you have multiple versions of a single set of source files that all have differing changes, for you JuJutsu makes it easier (easier then git, that is) to merge them into the final commit you want to end up with. Is that correct?

Just trying to make sure I understand. Honestly, after reading that article I am still not feeling the need to try Jujustu out. I'm still open to being convinced, but have yet to see anything that makes me go "wow, I need to try that!".

> In git, if you get a conflict, you feel like you have to resolve it now.

I guess I view that as a positive rather than a negative. I'm not saying that dealing with merge conflicts is a picnic -- it isn't. I just find it difficult to believe that ignoring them and resolving them later will improve the situation in the long run.

Is there a particular pain point (or set of pain points) that you have using git which is removed when you use Jujutsu?

I am interested to know, because there seem to be a small number of people who really seem to like it, and up to this point I haven't been able to understand what it is that they are all so excited about.

> Some people just enjoy being contrarian.

And some people just happen to disagree - doesn't automatically mean they just like "being contrarian". I took the "Yup..." to mean "this is what I was expecting, because it agrees with what I have seen before on this topic".

> I always enjoy how on jj articles, 90% of commenters tried it and switched, 10% never bothered to try it, and 0% tried it but decided not to switch.

And some unknown quantity of readers don't see anything compelling enough to either try it and/or comment on it after they have (or have not) tried it.

> LLMs are smart enough to make the result seem "organic"

I would never describe the output I've seen from LLMs as "organic".

I'm not sure if you are being serious about not understanding "the whole centering a div meme". Your example handles a trivial case, but does not address the whole of the problem.

As others have pointed out, vertical centering is often the problem being discussed (although difficulties with horizontal centering do happen). Anyone I know that has written any non-trivial web application has run into the situation where they spent way more time than they thought they should have to getting some element in a web application centered on the page the way they wanted it to be.

This article is a good example of the complexity, I think:

https://css-tricks.com/centering-css-complete-guide/

The author makes a decision tree, which illustrates the complexity fairly well, and then there's a conversation in the comments between the author and a reader about whether parts of the decision tree are correct.

CSS is extremely complicated. It's easy to get lost in the complexity, and it can be very frustrating when you know how you want something to look, but can't quite figure out how to get it to happen.

That's why the meme is so popular. LOTS of people who deal with CSS can relate.

Well over 20 years of vim use, and I had to look up what f/F and t/T do. I'm pretty sure I've seen them before years ago, but I never use them. It's always interesting what others find invaluable that I try out and think "meh" afterward.

that's metaprogramming :D

> presuming to be able to identify "the best programmers"

He was identifying the best programmers he knows (as is obvious from the title). I don't think it is unreasonable at all for even a semi-technical person to be able to do that.

Also, it is highly likely that the author never expected their article to receive a high volume of web traffic, and allocated resources to it with that assumption. That doesn't say a thing about their technical abilities. You could be the best programmer in the world and make an incorrect assumption like that.

> I started using git around 2007 or so because that company I worked for at the time used ClearCase, without a doubt the most painful version manager I have ever used

Ah, ClearCase! The biggest pain was in your wallet! I saw the prices my company paid per-seat for that privilege -- yikes!

> Git sucks for serious projects.

again, hard disagree. I work on serious projects all day long. Git is fabulous for serious projects.

> Git was always worse than Mercurial.

hard disagree. Git was always way better than Mercurial.

> It won because of GitHub.

I and most of the developers I have worked with over the years all used git for many years before ever even trying GitHub. GitHub obviously has helped adoption, but I'm not convinced that git would not have won even if GitHub had never existed.

> Git is for hobby side projects. Perforce and Sapling are for adult projects.

The numbers I've seen say git has about 87-93% of the version control market share. That's just one of many reasons I think it is safe to say most professional developers disagree with you. I can understand someone prefering Perforce for their workflow (and yes, I have used it before). But saying Git is only "for hobby side projects" is just ridiculous. It has obviously proven its value for professional development work, even if it doesn't fit your personal taste.

The ones I did this from were "Compute!" and "Compute's Gazette! (for Commodore 64 and VIC-20)". They were all octal numbers, if I remember correctly, and the last number in each row was a checksum. I also paid my sister to type in some of them in for me. A lot of them were games, but there were also some very useful programs in there. I spent so many late nights typing away on that 8-bit machine. It was a cool time to be a kid who was interested in computers.

It all depends on how the contract between Microsoft and Id was worded.

Also, Rich has many years of experience using all three of those languages.

It's not odd at all. The underlying problems to be solved are identical.

In fairness the person you were responding to was referring to their own personal experience. They certainly are not the first person to conclude that doing non-trivial concurrent programming is too difficult for them. I agree that it is achievable with an appropriate level of care and experience, but I know there are many very smart people that conclude that multithreaded programming in C++ is too difficult for their taste.

Even Rich Hickey, when discussing concurrency in Java/C#/C++ said "I am tired of trying to get right, because it is simply far too difficult."

> In particular, talk about shared state, how we do it today, how you do it in C#, Java, or C++, what happens when we get into a multi-threaded context, and specifically what are some of the current solutions for that in those spaces. Locking, in particular. That is something I have done a lot of, over a long period of time, and I am tired of trying to get right, because it is simply far too difficult.

( https://github.com/matthiasn/talk-transcripts/blob/master/Hi... )

Yes, sadly I was not rich enough as a kid to own an Amiga. By the time I could have afforded one, it would have been more for the novelty of having one than something practical for me to spend money on.

Yeah, the main references I found to IVR systems and REXX were from IBM articles discussing IVR, and some open-source Asterisk-based systems using ooRexx that appear to have been created as an open-source alternative to IBM OS/2 IVR solutions that used REXX.

OS/2 is the primary environment where I had experience reading and writing REXX a long time ago. I was also aware of it being used in IBM mainframe systems, but I had no direct experience there.