Hacker News Reader

Comment by sdevonoes | Hacker News Reader

It was simpler to teach Unix because what we expected from Unix back then was simpler to what we expect from Unix these days.

Back then we expected programs like: `telnet`. A program that can be developed by one person (or a few at most) and requires just a few tools to be developed (gcc, gdb, vim, make).

Nowadays we expected programs like: `Twitter`. A program that cannot be developed by one person but hundreds (don't ask me why, I don't get it either), and requires hundreds of tools to be developed (html, css, sass, ruby, ror, ansible, git, javascript, babel, docker, docker-compose, yaml, json, make, vscode, kubernetes(?), mysql, nginx, ...).

View on HN

I find comparing telnet to Twitter disingenuous. Back in the days big banks/insurance had big application, developed by big teams.

I'm not saying that what point out is not true, but telnet is prolly best compared to openssh, which is seems to be developed by 2[0] devs, and waaaaay more complex. Both are tools, both may be used for various over-the-network interactions with OSes.

> don't ask me why, I don't get it either

It's an ad network. It has to deal with compliance in many regions. There are mobile apps.

[0]: https://github.com/openssh/openssh-portable/graphs/contribut...

Right. I wanted to focus though in the most "demanded" programs back then and now.

I would say back then, the most demanded programs were command line programs (small utilities that do one thing well).

Nowadays the most "demanded" programs are programs that want to attract as many users as possible (and so, they have to "scale", they have to be "distributed"), programs that need to grow as much as possible (the bigger the program the bigger the company the bigger the profit), programs that need to be rewritten in new tech stacks every 3 or so years.

I guess the mentality has changed along the way as well.

Demanded is a weird term here. No one demands "ls", not the banks/insurance companies back then, not the Twitter users today. It's a tool, not an application. You dont buy your computer (or cloud VM) to run "ls".

Back in the days consumers were not in the software picture so much. Maybe some pre-PCs were catering for home users, maybe some BBS to dial into, but that was it.

This has changed. And this is why we have Twitter.

> programs that need to be rewritten in new tech stacks every 3 or so years.

Where do you get this from? I dont see such trend at all. Okay, some library needs to be replaced, and we share more code nowadays (the stacks are deeper, but what would you expect? more cycles to burn and more ecosystems). But no-one factors in the cost of constant rewriting to stay up to date with the hippest stacks.

> > programs that need to be rewritten in new tech stacks every 3 or so years.

> Where do you get this from?

I'd guess front end dev. 3 years is positively prehistoric laughing material for all the up and coming resume-driven-development front end rockstars.

No it's not, get your facts checked. React.js for instance is 7 years old and here to stay. Angular 2+ and Vuejs are both younger but here to stay too.

Frontend dev has largely matured and stabilized, it's not the shit show it used to be anymore.

Anything can be developed by one person or thousands people. It depends on how organisation is managed and what other software the software need to support and communicate with.

> Nowadays we expected programs like: `Twitter`. A program that cannot be developed by one person but hundreds (don't ask me why, I don't get it either),

I'd say this is wrong. Creating a twitter-clone is simple, and can be done by one person. The hundreds are neccessary for making it scale and managable. And many of those hundred are even there for the content, not the tool. They filter out fakenews and nasty behaviour, monetize the platform and do all kind of other things which are not in the realm of Unix-tools itself.

Twitter the server is hard and requires hundreds, twitter the client is easy and requires 1.

What client?

by client I mean anything that allows you to send tweets and read whatever tweets you are currently subscribed to, so a theoretical command line client for twitter (assuming of course the twitter api allows that kind of thing nowadays which I am not at all sure of)

Ok, I disagree. Such a client is even more work. Because you need to add an additional API for connecting this client, and recreate the whole interface again in a different environment.

No, doing a twitter-clone is quite simple, because the interface is not very complicated. It's even on the usual list of tutorial-examples these days. So in worst case you can just copy&paste the whole interface from somewhere. The backend is also not quite complicated for an average developer.

The hard part in doing twitter is scaling up your poor clone which works well enough in a single instance for some hundred users, to an architecture of multiple instance serving million users.

But this comparison is unfair, because the original telnet-client&server was also only a single instance-solution, not some upscaled monster for millions. Even though a twitter-clone still needs a bit more knowledge than telnet, it's still on a level one person alone can handle.

>The hard part in doing twitter is scaling up your poor clone which works well enough in a single instance for some hundred users, to an architecture of multiple instance serving million users.

That's twitter the server right there.

twitter the client is sending in your tweets, and showing you a list of tweets from other people you are subscribed to in some order - probably chronological.

The twitter client does not need to keep any data (between sessions) but should be usable with just sending off requests for data from twitter's public APIs and posting your tweets to same. (assuming of course as I said that twitter APIs give access to this which I am not sure of)

> Twitter the server is hard and requires hundreds, twitter the client is easy and requires 1.

You are severely understimating the amount of work that goes into a (web) client application that is being used by as many people as Twitter's - UX design and testing, accessibility, internationalization, browser compatibility (including lots of exotic ones you may never have heard of)...

>Nowadays we expected programs like: `Twitter`

I didn't, and I'm sure I'm not alone. Let a website stay a website.

I expect it to be free and maintainable (from both developer and user perspectives).

> Let a website stay a website.

So you still need Chrome/Firefox, and Gnome/KDE/Mate/whatever to run them in.

I think the OP's underlying unhappiness is more that "the people who want to use unix now are fundamentally different people who want different things that the people who wanted to 'learn unix' 35 years ago.

(Though I'll bet 80+% of the people they taught to pipe ls to wc were within weeks using irc and mutt whenever they were looking the other way in class, because for most of us people are more fun than machines, and back then we used irc/usenet instead of Twitter/Facebook, but to fill the same sort of niche.)

> So you still need Chrome/Firefox

I think for most people learning unix, understanding chrome/firefox boils down to knowing "there is a chrome/firefox repo somewhere, it gets compiled/packaged for your distro somewhere and has a bunch of dependencies". DE doesn't need to have any provisions for Twitter specifically either, apart from what is already essential for most GUI applications.

I get what you mean, I guess I just twitched reading "unix twitter client" being something we expect from unix.

It's not that hard to build a browser (I'll say this because I've done it, and there are plenty of people who have done it better.) It's just tedious and not something you can put on the app store.

> It's not that hard to build a browser

One that reliably runs all the javascript needed to support modern Twitter/Facebook/GMail/whatever style webapps? I mean _maybe_, if you're pulling in someone else's code as dependencies to deal with your javascript runtime and your rendering engine. A lot of people could hammer out lynx or w3m in a weekend, but not something that'll run Twitter. (Hell, the Safari Tech Preview occasionally chokes on Titter...)

I liked the web better with HTML2.

There were simple technologies which did a lot too, like Hypercard.

The creeping complexity of the web isn't something which had to happen. I understand the reasons it did happen, but in an alternative timeline, without Netscape vs. IE, the dot-com boom/bust, and the whole Netscape meltdown, it might not have happened.

People were building sophisticated applications which did a lot in the days of NeXTStep, BeOS, SGI, and Amiga, without this massive complexity build-up. Altavista scaled well too.

Just like people got tired of "fancy" user interfaces and minimalism became somewhat fashionable, I hope the same will happen architecturally, possibly after especially bad yet-another vulnerability and breach.

>One that reliably runs all the javascript needed to support modern Twitter/Facebook/GMail/whatever style webapps?

That can stay within the browser or some shared library. It absolutely doesn't need to affect unix/linux architecture in any way.

You're vastly underestimating the effort required to go from a simple HTML renderer to a full-blown web browser. See [1].

[1]: https://drewdevault.com/2020/03/18/Reckless-limitless-scope....

Me neither. I guess that's something that has also changed. Back then, the "users" were a bunch of guys who required programs like `telnet` and `ls`. Today the "users" are practically everybody in the world (and the majority of the people out there wants Twitter, Instagram, Facebook).

Most of those technologies are deployment and infrastructure. There's Twitter the server program, and then there's Twitter the business. But whether or not an app runs on docker, or kubernetes, or is version-controlled by git, or what database it speaks to, is orthogonal to the technologies used in the app itself (or at least it should be). I wonder if one had a source package for the Twitter server if you could just run it on an arbitrary device with an arbitrary configuration, or if it actually was bound at the hip to docker or mysql or whatever configuration they choose for their own servers. Ideally, they should be separate concerns.

The problem with Unix is that people started building solutions on top of eachother while not hiding the underlying abstractions. Then you get annoyances like the "/etc/hosts" or "/etc/network/interfaces" files which are overwritten by some management tool.

how much is the basic features of twitter (account, tweets, feed) and how much is scaling, analytics ?

telnet is a bad example, it is full of quirks ans special cases.

Reply on news.ycombinator.com