Hacker News Reader

> "Shared libraries are bogus."

Are you implying that "shared" = dynamically linked? Was there not a version of Motif that could be statically linked?

In the 90's, the most popular UI library for Windows was MFC (Microsoft Foundation Classes), which could be linked either statically or dynamically.

For the most part, MFC was and is a thin wrapper over the user32 and comctl32 libraries that ship with Windows. So the true Windows equivalent of statically linking Motif would be to statically link user32 and comctl32, and that's impossible.

Actually it was OWL and VCL, until Borland lost their way and we were forced to migrate to MFC.

Really? I have no numbers to back it up, but it felt to me that Visual Studio (and Visual C++/Basic before that) were more popular than the Borland tools.

Not on my geography.

Worldwide, no idea.

Back in those days, Visual Studio was priced a lot higher than Borland offerings - this goes all the way back to DOS, actually. Borland had always priced its developer tools very aggressively compared to the state of the market, and they reaped the benefits. Thus, Turbo Pascal or Turbo C++ used with Turbo Vision was by far the most popular DOS TUI (as opposed to, say, VB for DOS), and OWL/VCL was the most popular Win16/32 framework, if you discount raw Win32 API (of which it was a wrapper).

Visual Basic ate a considerable chunk of Delphi's lunch in the enterprise area, where price was less of an issue, and large dev shops would buy an MSDN subscription anyway. But it was never more popular than Delphi for desktop apps.

"Was there not a version of Motif that could be statically linked?"

The GP seems to be confused about the meaning of "shared library", and seems not to be aware of the existence of static libraries -- which would (as you point out) be perfectly usable in the case of Motif.

I've heard of static libraries a time or two.

'Perfectly usable' is a bit of a reach given how huge Motif was at the time. I shudder to think about the size of a directory with a bunch of X applications that each snarf in all their dependencies; remember we're talking 1990s.

Is "GP" a variation of "OP"? I keep seeing it on HN used in that context...

> Is "GP" a variation of "OP"?

No, GP is “grandparent”, that is, the post two posts upthread from the post in which the term is used (or, in some contexts, the user who posted the post two posts upthread.)

Similarly, GGP is “great grandparent” (3 posts up), and so on.

OP is “original post” or “original poster”, which is (in the general case) a different thing than GP.

Thank you, I've been curious about this for a long time. Is this a new thing or did I miss the boat on some old message board thing?

I think I first encountered it on Slashdot a decade or more ago, but I've rarely seen it outside of Slashdot or, more recently, HN, so I think it's a Slashdottism that migrated to HN with Slashdot users.

Though I could be wrong, as my exposure to internet message boards is weirdly eclectic, but far from comprehensive.

"Shared library" is a synonym for "dynamically linked library".

It seems to me that the issue isn't between shared code and no shared code but between statically and dynamically linking that code. It's a question of bundling dependencies. You can generally statically link a GUI toolkit; you just have to deal with the extra disk and network usage. You can dynamically link the same library but then you just have to deal with all the familiar dependency issues you've probably dealt with. (DLL hell and related issues) It's a trade off, but in either case you're still sharing code.

DLL hell happened because Windows used to lack a package manager, leaving apps to bundle their dependencies and overwrite other versions (without semver names!) in common directories.

Yeah, Windows has traditionally been worse than Linux in this capacity, but my point is that dependency management is a non-trivial problem. My experience is that package managers usually work but not always (I've had occasional issues on Arch) and the fact that you need a package manager, and how sophisticated they often have to be, shows how tricky the problem can be to solve.

As if Linux is any better, specially regarding glibc.

it is better. (Unix/ELF generically, not linux). versioned symbols are a YUGE improvement over DLLs.

Hence why I explicitly mentioned Linux.

Also Aix uses the same model as Windows.

Finally, .NET Assemblies are versioned, and Microsoft has introduced Application Manifests around Windows XP.

https://docs.microsoft.com/en-us/windows/desktop/sbscs/appli...

So it a matter of actually taking the effort of specifying the versions that the application works with.

All assemblies are versioned and can potentially have unique strong names, not just .NET assemblies. A native DLL can still be an assembly.

https://en.wikipedia.org/wiki/Side-by-side_assembly

> Finally, .NET Assemblies are versioned,

But then, you still have to put up with defining potentially hundreds of <bindingRedirect>s in config files to even get an application to run correctly, even though they mostly don't share their DLLs.

The only thing it takes is Nuget dowloading a newer version of some dependency another library depends on, even if it's backwards compatible with the old API. Which, of course, it should always be if you haven't switched to a new major version.

Edit: Also, I find it very disturbing that the resulting errors always happen to be crashes during runtime instead of up-front. If that happens with a plugin or through reflection: fine. But for most of .NET code, dependencies should be able to be loaded during startup.

To be even more specific, it happened because apps dumped DLLs into shared system directories instead of bundling them alongside the app binary. Since on Windows, each app has its own directory, it's easy to bundle in a way that doesn't mess up other apps.

It became so once the DLL search path was changed to put the .exe file's containing folder first.

Prior to that, the system dirs were searched first, which was the trigger for the DLL hell issue.

I mean, if all apps avoided writing to the global folders (i.e. reserve it for OS-managed components), there wouldn't be an issue even with the old arrangement.

But not even Microsoft's own products respected that in practice.

Static libraries are a potentially bigger problem when your library is tightly coupled to a particular version of some other process (eg an X windows server).

The real distinction in my view is between tightly coupled components and loosely coupled ones. Loosely coupled as a design paradigm is harder to design and maintain for the programmer and in some cases has a performance impact, but a lot nicer for the admin and feels ‘cleaner’ to me, at least.

As a UI person, I think shared UI libraries are bad for usability in many ways. They lead people to design UIs that happen to be made of the widgets that are available, rather than designing something truly suitable to the user task.

This is one of the reasons the web eclipsed native applications. The web only provided the most basic common widgets, so designers were forced to reimplement the UI toolkit, but also given the freedom to have their own take on it.

I personally would prefer to see a UNIX-like UI library made of many composeable parts. With idependant codebases.

In that world, having a single giant dynamically linked UI blob doesn’t help.

I’m not saying standardization is bad, just that forced standardization at the architectural level is bad.

Just so I'm following properly, do you mean something like how you have {React | React Native | React VR} + a cornucopia of community-supplied custom components? imo it's a system that works well - you have a common system + easily extensible custom bits.

(take my experience with a grain of salt, I've only used React on side-projects, never anything complicated or that I was forced to develop on because of work, and never ran into any perf issues)

Not the person you replied to, but that's what I imagine he/she is getting at. What I think of when someone mentions a Unix UI library is something like Qt, which provides a number of conventions, such as:

- Standard layouts

- Standard input and display components

- Standard event and message handling

- Standard user interactions

- Standard color themes

Which is great for developers to set up an initial UI, but makes every application look the same and takes a lot of work to customize in a way that's consistent with the defaults.

On the other hand, building a complex, feature-rich UI requires a lot of skill both in terms of implementation and design, which is less than common. So that Qt UI will be functional and predictable to users, even if it was not very well thought out, and the broken web UI will be useless to everyone.

Personally I like consistency. I've actually moved away from GUI apps in general because the terminal is more consistent, so I feel like there's less to learn with each new tool.

This is exactly why I like to use these UI toolkits, and despise most web "UI" frameworks. That uniformity is why these applications are usable and predictable, and yes, boring. Deviating from the defaults takes effort, and that's a subtle hint that it's something to reconsider. You're deviating from the norm, and that might indulge a developer's whims or the demands of a manager who wants their application to stand out from the crowd. But that superficial difference is something I've despised ever since we have WinAmp and XMMS skinning the UI like many media players, purely to look different at the expense of usability.

Even after reading lots of UI guidelines, and developing several tools and applications, it's taught me that I'm terrible at it, and should let an expert do that part while I stick to the other parts!

Yes, I should’ve said UNIX-philosophy or something... what I said was pretty ambiguous. I meant UNIX-style in terms of single purpose tools that work together over a common bus without being tightly coupled.

Not actually UNIX UI libraries.

Isn't it also a reason why it's said that accessibility sucks on the web?

> I personally would prefer to see a UNIX-like UI library made of many composeable parts. With idependant codebases.

OK, and those parts ought to be shared libraries.

As a person who has to use those web apps that supposedly "eclipsed" native applications, I hope this stage will pass, and we're back to the sanity of consistent UI across apps and frameworks.

The theory of UI libraries is that users can take their knowledge between applications. When you start using a new app, you already know mostly how it will behave, because it shares the UI vocabulary with other apps.

The web has been terribly violent to this idea. Native UIs are expected to support keyboard navigation, keyboard shortcuts, a menu bar, type select, drag and drop, accessibility, scripting... And in any given interaction there are advanced modes: multiple selection, modifier keys, etc.

Hardly any of this works on the web; even if it did you wouldn't think to try it. Does type select works in GMail's custom context menu? Can you command-C copy a message in one folder, and paste it in another? Would it even occur to you to try those things?

That stuff is ancient I know, and it would be one thing if the web were pioneering new UI vocabulary that displaced the old. But it's not. There's nothing new that has taken hold, no replacement for what is lost. Gmail has its janky, app-specific keyboard shortcuts, which is at least something, but there's no mechanism for it to spread.

We're in a Dark Age. Every web page now has its own custom CSS-style menu that only supports the most basic hover-and-click, and the bar for good UI is just lying on the floor.

you can statically link a ui library.

I found during my ten years in Plan9 it was the most usable OS I have experienced in my 35 years of computing. My only problem with it is every other platform is now ruined because I gnash my teeth and say "would have been easy in Plan9".

> my ten years in Plan9

Using it primarily? I would find that very difficult with today's dependence on the web, especially with how complex the web has become today.

yes, and I was a website devops during that time.

that's my desktop in wikipedia

https://en.wikipedia.org/wiki/Acme_(text_editor)

what did you browsed the web with?

or as relevant at the time: how did you communicate via msn/aim/yim/icq? I hope you're not one of those condescending Unix types that only had online interactions on irc :P

No need to be rude, and not everyone uses chat software.

Googling for the web browser options online, it seems Links[1] and Abaco[2] are the best options right now. There are others listed in Wikipedia[3].

I wonder if there's someone out there that has put in the effort to improve their Plan9 environment. I wonder how difficult it might be to port something like Chromium, Firefox, or Webkit to Plan9. Maybe it's not as tremendously difficult as I imagine it, but maybe I'm dreaming thinking this.

[1] https://en.wikipedia.org/wiki/Links_(web_browser)

[2] https://en.wikipedia.org/wiki/Abaco_(web_browser)

[3] https://en.wikipedia.org/wiki/List_of_Plan_9_programs#Web_br...

Plan 9's improvement is called Inferno, by the same devs.

It's not Plan9's improvement. It was never designed that way. It's a stand alone product. It has nowhere near the richness of Plan9.

Source: I worked as an Inferno developer.

> I worked as an Inferno developer.

Ah man, that's really cool.

So what's your favorite operating system? Is there one you find ideal or do you like different ones for their different trade-offs? What do you wish was the most widely used OS in the world?

I ask these questions thinking of the OS foundations and ignoring that OSes like Plan9 and Inferno are lacking many things only found in more popular OSes by virtue of being popular.

Plan9 was far superior as a developer's system. It's text based tools are the best, bar none. But really it owes that to Project Oberon.

"Everything is a file" as an abstraction enables you to build really powerful through composition. e.g. running TCP/IP over a serial connection just by mounting files in certain places.

Your end user program doesn't need to know anything about networking, it just reads from files.

this is an irc bot written in shell script

http://proweb.co.uk/~matt/chugly.rc

It's not perfect, of course, it had problems with throughput - we were forever discussing at conferences how to improve the protocol to implement streaming.

I describe it as a racing car, not everyone can drive it, you need to work to keep it going, you might kill yourself but when you're out front, it feels amazing.

> Your end user program doesn't need to know anything about networking, it just reads from files.

Basically, suckless's ii seems to imitate that.

Interesting that you put it that way, as I don't get where Plan 9 gets to be richer than Inferno.

the internet is not the web

yep, IRC, if I was at the computer I had a window with FreeNode and QuakeNET.

And a condescending Plan9 user, "Not only is UNIX dead, it's starting to smell really bad", as we say.

10 years without a browser? Your sanity levels must be off the charts!

Plan9 has multiple native web browsers, Mothra, Abaco & Charon. You could run Opera in Linux emulation mode and also use VNC to another machine.

Did you see the part where I was a website devops for 10 years using Plan9?

> You could run Opera in Linux emulation mode and also use VNC to another machine.

What? There's a Linux emulation mode in Plan9? O_o How well does it work? Could I run anything Linux in Plan9?

EDIT: Woah.

https://9p.io/wiki/plan9/Linux_emulation/index.html

What's wrong with IRC? IRC is great. It's so simple you can knock together a decent client of your own in an afternoon.

Netsplits, hilarious lack of security (nickserv identify uses plain text passwords sent over an unencrypted TCP connection), you can't retrieve channel history, no support for threads, images, basic markdown formatting... Shall I go on?

Very little of that is a problem in practice, and proprietary systems like AIM had more than their fair share of problems too.

>no support for threads

That one's just wrong. You can make a threaded client if you want one, although it's not totally clear why you would since the CPU load of IRC is going to be very low in any reasonable situation.

Edit: Oh I see, threads as in forum threads.... just open a new channel. Otherwise, the concept seems to map poorly to ephemeral real time discussion. This is the first I've ever heard of AIM,etc of having forum threads.

Slack-style threads work very well for real-time discussion. It's far easier to follow a channel with them than without.

Opening a new channel wouldn't work for fairly obvious reasons (nobody would be in it, you'd effectively have to do it for every single message, etc.).

Nickserv identify can be encrypted from your client to the services server if the network supports it. (SSL between you and all servers)

No channel history, no threads, and no images are features.

There's formatting: bold/italic/underline and colours.

How is no channel history a feature? I think if you take a look at your reasoning you'll see that you are just defending IRC because you like it. Which is fine, but it is intellectually dishonest to pretend that flaws are not flaws.

Aren't a lot of these addressed with IRCv3? https://ircv3.net/

Some of these are already in place, eg. IRCCloud can render simple markdown, supports push notifications, can show inline images, supports display pictures, Slack-like threads, emojis, etc...

An example: https://twitter.com/IRCCloud/status/971416931373854721

Hopefully longer term we won't need to use IRCCloud/a bouncer to keep chat history. AFAIK an IRCv3 server should be able to offer that natively (to an IRCv3 client).

As for unencrypted TCP... a lot of IRC networks seem to offer TLS these days.

Not saying this is perfect -- far from it, but people are working on improving IRC!

Eh, most of these seem like features to me. Slack's threading support is enraging, and I consider plaintext a courtesy. One of the fallouts of the lack of centralisation for things like chat logs was a thriving bot culture (years before it became cool and VC fundable).

SASL auth and TLS are fairly common nowadays, threaded discussion is not really mandatory for a good modern chat (Telegram, Discord for example don't have anything like that,) image unfurling can be done by the client, and there is actually formatting and some clients will autoconvert basic markdown to it for you.

IrcCloud is an example of a client that tries to solve pretty much all the issues and you can even plug it into a desktop IRC client and get most of the functionality including history. It's not necessarily better than modern chat or anything, but I love having a modern chat experience while being able to discuss things with people and groups who virtually only use IRC.

If you aren't a fan of hosted services you can run your own BNC. Some IRC servers have built in BNC services that give you things like better security and channel history.

Let me reaffirm that I am not of the position that IRC is perfect or modern. But you are misrepresenting it a fair bit, even in 2006 I was connecting with TLS (sometimes self signed certs though.)

Speaking as someone who's used IRC for nearly a decade and who has developed extensively for it, it most definitely has not stayed simple, what with all the nonstandard extensions every network has brought with it. And while I dislike Discord for many reasons, its moderation tools is not one of those reasons; I'd like to see a good, open chat standard come along that adapts features such as invite tokens, rather than depending on accounts or IP addresses or someone manually inviting you into a channel.

To have a functional, modern IRC client, you have to not only implement what there is in the RFCs (which incidentally, no IRC daemon follows anymore, not even the original ircd2) but you also have to pull in IRCv3, SASL, ISUPPORT parsing, CTCP parsing, a TLS library, ... the list goes on. And for a good experience you also want scripting and the ability to abstract away the differences between services implementations (Atheme and Anope, mainly). Not to mention you have no clientside encryption option on IRC short of any number of buggy OTR implementations.

IRC is not great. It might be okay, but by no stretch is it great.

What do you dislike about Discord?

Curious because I actually haven't seen anyone that disliked it beyond the loading screen's silliness.

Memory usage, extreme lag, the bugs (apparently I need firefox 37+ to access the voicechat feature, I am at 65 though), centralized (a big issue considering the censorship that they apply), no way to use it over tor (as far as I know at least), you are not allowed to make/use a 3rd party client, the official client is closed source, no e2e encryption or authentication, etc.

Discord wastes a few seconds of my time every time my Mac boots up because it can't just open at login without stealing the focus once or twice for no good reason.

I’ve assumed the 2018 version of the dynamic library view is bad is that non-operating system dynamic libraries are bad (and operating systems should provide a GUI library), use a web browser, or use the command-line.

> 1) "Shared libraries are bogus."

Starwman, nobody said that. Shared libraries make sense when a program wants to load additional code at run time. A classical example is loading and unloading plugins.

For everything else, not so much.

2) "Anyone who likes normal-looking user interfaces rather than plain boxes with text in them is a poopipants."

Most people I know use a tiling window manager with terminals. So plain boxes with text in them seems to make sense for many people.

It's hard to recall conversations from 1994, but I came away with the overwhelming sense that the Plan 9 guys thought shared libraries were bogus - certainly that they were bogus for the non-plugin use case (which is the one that pertains to this discussion; libraries like Motif were not plugins). So you've accused me of raising a strawman (actually a "starwman" - "he'd like to cwome and mweet us, but he thinks he'd blow our mwinds") by raising a point absolutely not germane to the discussion, but you when refute my point with this devastating rebuttal:

"For everything else, not so much".

Most people I know also use the web and menus and buttons and dialog boxes and so forth and expect all this stuff to look vaguely like other computers do. The fact that the Plan 9 folks were trundling over to non-P9 machines to read the web seemed to suggest that they also liked seeing things that weren't just text in plain boxes.

The point remains that these two propositions are both at the least contentious, and only by combining these unrelated points could anyone really seriously take Plan 9's approach to shared libraries (at the time) seriously.

If Plan 9 guys really thought shared libraries were bogus, they wouldn't have created the follow up version heavily based on dynamic packages for Limbo.

Here's a page which contains some authoritative discussion of the Plan 9 attitude to shared libraries: http://harmful.cat-v.org/software/dynamic-linking/

Your "most people I know" comment is bizarre: even hardcore terminal users need to browse the web, and it's been years since lynx or w3m could be claimed to be adequate for most web tasks.

But the Plan 9 folks consciously made it difficult to write or port web browsers and other consumer software. I think I remember Tom Duff stating that writing a web browser was a "fool's errand", which I guess captures the sense of heightened seriousness, privilege, and lack of concern for the average mainstream user that informed Plan 9's design.

On the subject of web browsers, I wonder if Plan 9 aficionados would appreciate edbrowse [1]. As the name suggests, it's a combination ed-like editor and web browser. It includes the duktape JavaScript engine. The project even distributes a statically linked binary for Linux using musl.

[1]: http://edbrowse.org/

In theory, that could even be ported to some versions of Plan 9. I remember that the Jehanne OS dev had said something along the lines of "Netsurf (another Duktape browser) could be ported soon".

Kinda funny that history has proven him right, in a way. It certainly would be a fool's errand to try and write a web browser in 2019.

> I think I remember Tom Duff stating that writing a web browser was a "fool's errand"

Well, he wrote a browser for Plan9 (Mothra), so if he said that, it's not for lack of experience.

Yes and no.

I tracked down the original message in the archive of the 9fans mailing list. The fate of Mothra is discussed.

http://p9.nyx.link/netlib/9fans/9fans.0007

There's more discussion in this file between Howard Trickey (who refers to himself as an "erstwhile fool", having written Charon for Inferno), Duff and other Plan 9 enthusiasts.

The displayed level of knowledge and engagement with the requirements for building a web browser isn't exactly off the charts. I think it's fair to say that Duff didn't have a lot of patience with the project. He saw it as a moving target that probably couldn't ever be hit. For Plan 9 the classic web browser is a culturally alien type of software: complex and to some degree necessarily monolithic.

Here's what Duff said:

  > how come mothra bit the dust?
  I wrote it.  It was not in good condition when I left
  Bell Labs.  Understantably, nobody else wanted anything
  to do with it, so it died.

  Its biggest shortcoming (other than its general
  internal hidousness) was that its document imaging
  model was fixed before <table> entered the picture.
  Deep down it believed that documents were running text
  with embedded line-breaks and indent changes, meaning
  there's no good way to get tables or frames to work.

  Also, if your browser doesn't closely match Netscape
  and Microsoft, people will believe that it just doesn't
  work, regardless of how good a job you do of meeting the
  published specifications.

  On the other hand, I still think its idea of how to handle
  navigation (mostly the panel with an LRU list of pages 
  visited) was better than anything else I've seen.

  Writing a web browser is a fool's errand.  The 
  specification was changing faster than I could type, and 
  still is.

And here's Rob Pike:

  > Surely somebody must be trying to port Mozilla to Plan 9?

  While that would be better than no browser at all, Mozilla 
  is just the sort of stand-alone monolith that we're trying 
  to argue against. And of course, everyone else in the 
  world is trying to turn their system into a giant web 
  browser. I'd rather see web access be one aspect of a 
  system in which the pieces work in concert.

  -rob

I think most people who've given the web browser platform any serious thought would agree that the way Duff and Pike are talking is indicative of not really having taken the problem seriously. The discussion continues in that speculative vein.

They had the luxury of being able to choose (effectively) to reject the web user experience and they took that option. Tom Duff probably wouldn't claim that he was speaking about the intricacies of web browser development with great authority!

There's more discussion in the 9fans archive. And see also Abaco, another attempt at a graphical browser for Plan 9: http://lab-fgb.com/abaco/

> Most people I know use a tiling window manager with terminals. So plain boxes with text in them seems to make sense for many people.

As my human-computer interaction prof said back in undergrad: You are not normal. There is a reason that no modern operating system outside the "Other Linux/BSD" bucket ships with this as a default.