I'd say mostly not.
Sure, you can browse the Internet and play music at the same time on any platform today, but a lot has changed.
Much of what was good about BeOS was breaking with the past and starting from zero based on today's desktop needs, a modern take on the Amiga in many ways.
Existing platforms may be able to steal an idea or two, but that's different from being built from the ground up to solve a specific class of problems.
To begin with, absolutely everything was multi-threaded, there was just no way around it.
Fast file system queries that could be stored as shortcuts were nice, still haven't seen that implemented nearly as well elsewhere.
I wrote some software interfacing the system C++ API's and found everything very convenient, clean and tidy compared to any other platform I've programmed.
NTFS metadata architecture really inspired by BeFS, or at the least, a fellow traveler.
You can tweak the Windows Explorer (the filesystem UI) to operate on arbitrary metadata. Well, I was able to get an email inbox, where each email message is a text file, just using Explorer the BeOS way, on Windows 2000. It wasn't exactly fast.
Somewhat of an aside, but I wish there existed a kind of "encyclopedia" of operating system features (both UI and otherwise, with a special emphasis on "dead ends" like BeOS), that pulled together demos and documentation into one exhaustive reference.
It seems like a lot of good ideas get lost is the sea of lowest common denominator solutions, and an ecyclopedic reference would make it easier to resurrect those ideas.
I cant tell you how often I waste time searching for the lication of a specific file. But never gad this probkem with BeOS/Haiku.
Some examples:
Every email received was stored as a file. All metadata about the email (sender ,subject, headers, etc) were stored as attributes.
Tracker, the file manager application, could display any arbitrary attribute. I seem to remember that instead of an email application's window, my inbox was a simple Tracker window showing the specific attributes required to know about my emails.
My music collection was stored and displayed the same way.
Everything was searchable but also usable. File attributes weren't hidden behind CLI commands and flags like xattr, they were part of the GUI and every application using the SDK would know/understand them.
This was, at least in part, how Microsoft's "Internet News and Mail" worked. Not sure where it kept metadata, but the initial implementation seemed like an Windows Explorer extension, which was a very clever approach, IMHO.
I wish Gnome did an e-mail client like that, synchronizing a local folder with a remote IMAP mail store, or presenting a remote IMAP storage as a mounted folder under an IMAPFS sort of thing. Arguably, that's easier to do with POP3. Same thing with an outbox, where writing a properly formatted file would send an e-mail.
> File attributes weren't hidden behind CLI commands and flags like xattr
This is a design choice in the UI, not something intrinsic to the OS.
personally, I thought it was because it was macos, which was riddled with a lot of legacy code, for example 68k emulation in the innards of the kernel, and tacked on cooperative/preemptive multitasking.
I remember playing with a leaked version of Copeland/Gershwin. It felt way more modern in a different way than BeOS, but I can't remember how complete it was.
Likewise on Intel, you had Windows 9x that didn’t support SMP so you were stuck with the NT line if you wanted multi processor support. I recall NT4 being pretty poor for desktop usage due to patchy driver support but Windows 2000 was amazing. Linux and BSD weren’t really desktop ready either.
So BeOS was basically a workstation class operating system designed to be running on lower footprint hardware (the comparison someone else made to Amiga is pretty apt).
As much as I typically hate Windows and prefer Linux and FreeBSD, Windows 2000 was pretty solid release and particularly when you place it in its era where only BeOS really competed with it in terms of performance and stability on commodity hardware.
You can get a lot of snappiness from prioritizing GUI processes and lowering the priority of everything else. In modern machines, with lots of cores, you can also try to increase affinity of different interactive processes with a set of cores so that they avoid migrating and losing caches. Finally, Apple is placing low-priority process in the efficient cores and leaving interactive code on the performance ones.
Any direct influence would probably be felt most on the mobile side rather than desktop.