Hacker News new | past | comments | ask | show | jobs | submit | xorcist's comments login

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.


Compared to what? Compared to IRC, yes, but it's not really comparable.

The closest comparison is probably Matrix and that is a pretty complex protocol too.


You might be surprised how modern irc is nowadays... https://ircv3.net/

So, configuration?

Even if the three letter acronym space is a bit thin, perhaps best to avoid overloading the name of any one of the ten most used protocols out there?

> 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.


Can also use stuff like Datadog NPM/APM that uses eBPF to pick up most of what you need. Its been a long time since I've needed anything else.


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.


They could very well literally be.

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 :)


It's the standard antithesis of instant gratification culture. We had to actually wait for things to happen, to download, to render, to dial.

Finding something online was a journey and it's often the journey that teaches you more than the destination.


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.


Paging sysop... paging sysop... paging sysop...

:-)


Could you elaborate on 'the vision impaired stuff'? I'm visually impaired myself so I'm intrigued.

The demo scene is still alive and kicking, by the by :)


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.

(edit: typo)


interesting, I always heard this as "you own your own words": https://en.wikipedia.org/wiki/YOYOW


This is increasingly fascinating.

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.


Someone should get right on that.


I've been thinking this comment was just unnecessary snark, but... :P

http://www.bbsdocumentary.com/director.html


I found myself reading through textfiles.com just recently,a really good archive of BBS-era text files.


here is one nice site http://bbslist.textfiles.com/


Isn't that just a list of phone numbers?

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.

Edit: http://www.textfiles.com/directory.html looks good.


I saved a whole bunch of files from my BBS days, including screen captures of the BBSes themselves:

https://www.kmoser.com/bbs/


for my area code, some of the sysops have left commentary on the directory page that lists the numbers. also, i used to log in to many of them.


So you intentionally make code harder to read for most of the humans on this planet, so satisfy a desire to use longer identifiers?


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:

1. Everything else.


I disagree with this, because there are a lot of fairly benign language extensions that break compatibility in pathological cases.

Here's a C example.

C90 supported block comments with /* comment */.

C99 added BCPL style comments with // the rest of this line is a comment

They were already a common language extension and supported by C++.

Here's an example of C90 code that fails to compile under C99 because of // comments.

  int x = 12;
  int y = x //* I'm placing a comment here just to be difficult.*/ 3;
Should the committee have rejected this change to prevent breaking programs with similar code?


Consider applying for YC's W25 batch! Applications are open till Nov 12.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: