Roll it up, just like you would roll back toilet paper on its roll, or sewing thread. Then you can roll them around your hand with no tangling issues.
Just like you would with a garden hose, or a rope on a sailing boat. Tangled ropes is a potential problem there so no one would flail your hands about and hope for the best. Instead you roll neatly.
> at Netflix type scale that nobody is sshing into individual instances to troubleshoot
Have you worked at Netflix?
I haven't, but I have worked with large scale operations, and I wouldn't hesitate to say that the ability to ssh (or other ways to run commands remotely, which are all either built on ssh or likely not as secure and well tested) is absolutely crucial to running at scale.
The more complex and non-heterogenous environments you have, the more likely you are to encounter strange flukes. Handshakes that only fail a fraction of a percent of all times and so on. Multiple products and providers interaction. Tools like tcpdump and eBPF becomes essential.
Why would you want to deploy on a mature operating system such as Linux and not use tools such as eBPF? I know the modern way is just to yolo it and restart stuff that crashes, but as a startup or small scale you have other things to worry about. When you are at scale you really want to understand your performance profile and iron out all the kinks.
Yes, there are numerous other ways to run remote commands than ssh, all of them less secure. (Running commands via your monitoring system can even be a very handy back door in a pinch.)
The argument here was that remote commands was less useful at scale, not that ssh was a particularly bad way of implementing it. Which doesn't make sense. You tend to have more complex system interactions at scale, not less.
> you probably want your docs updates to be coordinated with your product releases
People keep saying that but I can't help to wonder if they're every on the receiving end of documentation.
Documentation isn't code. It may all be text, and share other similarities, but it's something fundamentally different. You can't substitute code for docs, or docs for code. The above reasoning is what ends up publishing /docs/5.3/chapter1/installing.html. Reading documentation for a specific version of the product is not desirable.
To understand the product, it's very relevant what happens in version 5.4, and I should not have to diff different releases of the docs to find out. The documentation should say clearly that this function will be deprecated, or look different in the next version. In short, documentation should neither be branched with code, nor released with it. It should live in parallel and describe not only how the product works, but more importantly why it works like it does.
That's the real AI revolution. Not in manufacturing content for the masses, but how to sell ads when the vast majority of consumers could be suspected to be bots.
BBSes was such a huge part of being into computers in the 80s and 90s.
I really wish this culture could be understood by future generations. Yes, we have the BBS Documentary movie but we need so much more. Everything non-US is underdocumented, and all the subcultures such as the eLiTe scene, the demo scene, the vision impaired stuff, all of that risks being forgotten with time.
This is a relevant reflection and I have contemplated collecting BBS memories from my network and strangers. Will be doable once my kids are a bit older and work is a bit leds intense.
Let us stay in touch!
2:206/149 or about in my profile and you’ll find me :)
Even when you had a networked forum like FidoNet's Echomail (or Usenet, for that matter), it would take time for messages to propagate through the network - and they could sometimes fail to be delivered.
One of the more popular DOS-based BBS software platforms of the early 90s was VBBS. It was interoperable with WWIVnet, which is part of why it was popular.
Its author/developer/maintainer was blind. You can imagine how well it worked with screen readers and other accessible technology (which was primitive at the time, and yet somehow better than it is today).
Text on a terminal is much better suited to accessibility technologies, whether readers or braille terminals. BBSes were all about text on terminals, and it was a place where folks who used accessibility tools could choose whether to identify themselves as someone who needed it... and most of the time if they chose not to make it known, none of the other users had any idea.
"You are your own words" is a BBS-ism. For people who are in the deaf community or who used tools because of their sight, being able to be known primarily by their words and not by the way that they used them was absolutely incredible.
I want to see a documentary of this in the style of alternating scenes of a) narration over still photos and b) contemporary music alongside silent video of the people behind this community.
What are some websites that host the text files, ansi art, and computer programs from old school BBS systems? I would really love to be able to mirror that with wget and explore it in emacs.
Valid reasons for backwards incompatible changes to language syntax:
1. The language guarantees have become inconsistent, and the syntax breaks security boundaries or realtime guarantees that the language explicitly promises, and it is unfixable.
2. The universe of all written code is small enough that there are guarantees the syntax is unused, or we can change all instances of the syntax in an atomic manner.
Invalid reasons for backwards incompatible language changes:
Just like you would with a garden hose, or a rope on a sailing boat. Tangled ropes is a potential problem there so no one would flail your hands about and hope for the best. Instead you roll neatly.
reply