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.
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.
Worldwide, no idea.
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.
'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.
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.
Though I could be wrong, as my exposure to internet message boards is weirdly eclectic, but far from comprehensive.
Prior to that, the system dirs were searched first, which was the trigger for the DLL hell issue.
But not even Microsoft's own products respected that in practice.
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.
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.
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.
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.
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.
(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)
- 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.
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!
Not actually UNIX UI libraries.
OK, and those parts ought to be shared libraries.
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.
that's my desktop in wikipedia
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
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...
Source: 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.
"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.
Basically, suckless's ii seems to imitate that.
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.
Curious because I actually haven't seen anyone that disliked it beyond the loading screen's silliness.
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!
>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.
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.).
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.)
No channel history, no threads, and no images are features.
There's formatting: bold/italic/underline and colours.
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.
Did you see the part where I was a website devops for 10 years using Plan9?
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.
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.
"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.
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.
Well, he wrote a browser for Plan9 (Mothra), so if he said that, it's not for lack of experience.
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.
> 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
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/
[1]: http://edbrowse.org/
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.
1) "Shared libraries are bogus."
2) "Anyone who likes normal-looking user interfaces rather than plain boxes with text in them is a poopipants."
Both of these propositions are contentious to say the least, but what bothered me was that two propositions were mutually supporting while being (to my mind) orthogonal. The obvious and most compelling example of a shared library on the Unixen at the time were all the various UI libraries (Motif and various other abominations; all of them huge and unwieldy). It seemed necessary to accept that these libraries were obviously Completely Unnecessary to buy into the Plan 9 idea that shared libraries didn't do anything worth mentioning.
I'm sure it's possible to design a better UI library (or maybe even a wacky user level file system for user interfaces; in fact, my honours project in 1993!) but at the time the way people made interfaces that looked vaguely like what other people expected computer programs to look like was to use big-ass shared libraries on Linux.
This was also the way (dragging in one of those godawful blobs like Motif etc) that anyone might have exerted themselves to port across a (not completely pitiful) web browser, but the degree of aggressive disinterest in supporting Other Peoples Code was extreme (Howard Trickey's "ANSI POSIX Environment" or "APE" didn't get much love as far as I could tell).
It was quite undignified to watch people struggling with text-based web browsers or firing them up on non-P9 boxes because of the inability to support the web at the time.