
Ideal OS: Rebooting the Desktop Operating System - daureg
https://joshondesign.com/2017/08/18/idealos_essay
======
joshmarinacci
I'm the original author. I hadn't planned to publicize this yet. There are
still some incomplete parts, broken links, and missing screenshots. But the
Internet wants what it wants.

Just to clarify a few things.

I just joined Mozilla Devrel. None of this article has anything to do with
Mozilla.

I _know_ that none of the ideas in this article are new. I am a UX expert and
have 25 years experience writing professional software. I personally used
BeOS, Oberon, Plan 9, Amiga, and many others. I read research papers for fun.
My whole point is that all of this has been done before, but not integrated
into a nice coherent whole.

I _know_ that a modern Linux can do most of these things with Wayland, custom
window managers, DBus, search indexes, hard links, etc. My point is that the
technology isn't that hard. What we need is to put all of these things into a
nice coherent whole.

I _know_ that creating a new mainstream desktop operating system is hopeless.
I don't seriously propose doing this. However, I do think creating a working
prototype on a single set of hardware (RPi3?) would be very useful. It would
give us fertile playground to experiment with ideas that _could_ be ported to
mainstream OSes.

And thank you to the nearly 50 people who have signed up to the discussion
list. What I most wanted out of this article was to find like minded people to
discuss ideas with.

Thanks, Josh

~~~
NotUsingLinux
Hi Josh,

You raise some interesting points in your article. I wonder how to comment or
discuss this the most efficient way (here or elsewhere?)

Some questions: Have you looked at haiku?

What you describe as modules, I think Alan Kay calls "objects" in the
smalltalk/Xerox tradition.

Have you looked at his research project: STEPS reinventing programming?

[https://www.youtube.com/watch?v=YyIQKBzIuBY](https://www.youtube.com/watch?v=YyIQKBzIuBY)

Some bits and parts of this is open source.

Imagine a full system running on 10000 LoC I think this could be a step
forward.

Also this blurs if not throws away the distinction between "desktop and
web(remote)" applications. Because if integration of remote objects is
sandboxed but still transparent you get improved usability.

Also I think you go not far enough. Databases for file system are fine but I
think the ida of widgets or UI libraries altogether is not feasible anymore.

The system has to adopt to a individual level, people have different needs and
workflows.

Highly adoptable and conversational interfaces are needed.

WDYT?

~~~
joshmarinacci
Yep. I'm very familiar with STEPS. It's what makes me think that it is
actually possible to build a new open source OS.

------
Damogran6
So what he's saying is: REmove all these layers because they're bad, but add
these OTHER layers because they're good.

Thats how you make another AmigaOS, or Be, I'm sure Atari still has a group of
a dozen folks playing with it, too.

The OS's over the past 20 years haven't shown much advancement because the
advancement is happening higher up the stack. You CAN'T throw out the OS and
still have ARkit. A Big Bloated Mature Moore's Law needing OS is also stable,
has hooks out the wazoo, AND A POPULATION USING IT.

4 guys coding in the dark on the bare metal just can't build an OS anymore, it
won't have GPU access, it won't have a solid TCP/IP stack, it won't have good
USB support, or caching, or a dependable file system.

All of these things take a ton of time, and people, and money, and support (if
you don't have money, you need the volunteers)

Go build the next modern OS, I'll see you in a couple of years.

I don't WANT this to sound harsh, I'm just bitter that I saw a TON of awesome,
fledgling, fresh Operating systems fall by the wayside...I used BeOS, I WANTED
to use BeOS, I'da LOVED it if they'd won out over NeXT (another awesome
operating system...at least that survived.)

At a certain level, perhaps what he wants is to leverage ChromeOS...it's
'lightweight'...but by the time it has all the tchotchkes, it'll be fat and
bloated, too.

~~~
oneplane
On top of that, most hardware and protocol implementations are either secret
and under NDA or free and open but lacking a full implementation to begin
with.

The post contains many idealistic proposals, but most of them boil down to
lawyer stuff and money, not technical problems. You can't have nice GPU access
because GPU's are secret. You can't have things work together because nobody
wants to share their secret sauce. Everyone is trying to 'be the best' and get
an edge on the rest, but in a way that nobody really profits from it from a
technical standpoint.

Aside from the shit-ton of reverse-engineering and some cleanroom design,
there is very little that can be done to improve this, and no company is going
to help, and thus no big pile of resources is coming to save the day.

This does of course not only go for GPU's, but CPU's and their BSP's and
secret management controllers as well, as the dozen or so secret binary blobs
you need to get all the hardware to work at all.

Fixing this from the ground up, i.e. for x86, would mean something like
getting coreboot working on the recent generations of CPU's, and that's not
happening at the moment due to lack of information and secret code signing
keys needed to actually get a system to work.

~~~
edraferi
> You can't have things work together because nobody wants to share their
> secret sauce. Everyone is trying to 'be the best' and get an edge on the
> rest, but in a way that nobody really profits from it from a technical
> standpoint.

I feel like enterprise customers could provide some demand for IdealOS for
this reason. BigCorps have lots of data and application silos, as well as lots
of knowledge workers who are expected to synthesize all that data. There are a
lot of smart people who are power users but not devs. (i.e., macro jockies).
Something like IdealOS could really increase productivity in these places.

Of course you have to deal with all the usual enterprise headaches, mostly
security and backwards compatibility. But then they'd pay a premium.

~~~
tmzt
I've been suggesting that one way into an enterprise environment is to _give
the hardware away_.

Make a device with enough RAM, Bluetooth for a mouse, USB ports, and one or
two HDMI ports. A stick computer might be a good starting point.

Then build your OS for that device. Enable cloud management, integrate with
Active Directory, focus on an amazing out of the box web browser experience
and expand with an app store for well-thought-out, well designed open and
commercial apps.

Now give ten to every company with a DUNS number.

Sell more with a subscription including more advanced management and enable
pushing modified Windows group policies to them.

Make it good enough for a casual knowledge worker to use .

------
cs702
Yes, existing desktop applications and operating systems are hairballs with
software layers built atop older software layers built atop even older
software layers.

Yes, if you run the popular editor Atom on Linux, you're running an
application built atop Electron, which incorporates an entire web browser with
a Javascript runtime, so the application is using browser drawing APIs, which
in turn delegate drawing to lower-level APIs, which interact with a window
manager that in turn relies on X...

Yes, it's complexity atop complexity atop complexity all the way down.

But the solution is NOT to throw out a bunch of those old layers and replace
them with new layers!!!

Quoting Joel Spolsky[1]:

 _" There’s a subtle reason that programmers always want to throw away the
code and start over. The reason is that they think the old code is a mess. And
here is the interesting observation: they are probably wrong. The reason that
they think the old code is a mess is because of a cardinal, fundamental law of
programming: It’s harder to read code than to write it. ... The idea that new
code is better than old is patently absurd. Old code has been used. It has
been tested. Lots of bugs have been found, and they’ve been fixed. ... When
you throw away code and start from scratch, you are throwing away all that
knowledge. All those collected bug fixes. Years of programming work."_

[1] [https://www.joelonsoftware.com/2000/04/06/things-you-
should-...](https://www.joelonsoftware.com/2000/04/06/things-you-should-never-
do-part-i/)

~~~
DashRattlesnake
> "When you throw away code and start from scratch, you are throwing away all
> that knowledge. All those collected bug fixes. Years of programming work."

But, sometimes, that's exactly what you should do. It brings to mind OpenSSL
after Heartbleed. I remember reading that the LibreSSL people were ripping out
all kinds of stuff (like kludges and workarounds to support _OpenVMS_ ), and
rightly so. You might call it "knowledge [and] collected bug fixes," but
sometimes the crap is just crap.

~~~
vacri
> _It brings to mind OpenSSL after Heartbleed._

It's three years later. What general-purpose OS other than OpenBSD is using
LibreSSL?

~~~
smitherfield
Not LibreSSL, but Apple replaced OpenSSL with their own library, Common
Crypto.

[https://developer.apple.com/library/content/documentation/Se...](https://developer.apple.com/library/content/documentation/Security/Conceptual/cryptoservices/Introduction/Introduction.html)

[https://opensource.apple.com//source/CommonCrypto/CommonCryp...](https://opensource.apple.com//source/CommonCrypto/CommonCrypto-7/)

------
jcelerier
> Why can I dock and undock tabs in my web browser or in my file manager, but
> I can't dock a tab between the two apps? There is no technical reason why
> this shouldn't be possible.

that's absolutely possible on linux with i3wm for instance

> I'd like to pipe my Skype call to a video analysis service while I'm
> chatting, but I can't really run a video stream through awk or sed.

awk and sed, no, but there are many CLI tools that accept video streams
through pipe. e.g. FFMPEG. You wouldn't open your video through a GUI text
editor, so why would you through CLI text editors ?

> Window Managers on traditional desktops are not context or content aware,
> and they are not controlable by other programs.

Sure they are, on linux:
[https://linux.die.net/man/1/wmctrl](https://linux.die.net/man/1/wmctrl)

Fifteen years ago people were already controlling their WM through dbus:
[http://wiki.compiz.org/Plugins/Dbus#Combined_with_xdotool](http://wiki.compiz.org/Plugins/Dbus#Combined_with_xdotool)

The thing is, no one really cares about this in practice.

~~~
posterboy
Tabbing is not implemented by the wm, as far as I know.

~~~
ori_b
Tabbing is not implemented _exclusively_ by the WM, currently -- that's
correct. But there exist window managers that handle tabbing. So, it's largely
a matter of removing code. Lots of code. And then fixing more code that makes
assumptions that it controls the drawing of the tabs.

And there's already the Xembed protocol for embedding windows in other
windows, so it's technically possible to even move tabs from one application
into another, with a coordinating dance. None of the changes that he wants
really needs changes to X11 (although, as far as I know, it would be totally
impossible under Wayland.)

It just needs someone to change applications to support it. I'd be interested
to see an attempt.

~~~
posterboy
I fail to see the use of web tabs in the file explorer. What's the use case?

~~~
jcelerier
it's very useful for keeping folders pinned without them taking space in your
desktop. Just like for terminals, etc.

~~~
posterboy
folders? we were talking web-content-tabs.

Sure many file-browsers (thunar, pcmanfm ...) can tab file-browser views, but
I don't see the need for web-tabs in a not-web-browser. Firefox likewise can
show folder content for file:///, but not feature complete compared to a file-
browser.

~~~
jcelerier
uh ? I'm re-reading all the parent conversation chain and cannot see where
there is mention of "web".

------
spankalee
This sounds a lot like Fuchsia, which is all IPC-based, has a syncable object-
store[1], a physically-based renderer[2], and the UI is organized into cards
and stories[3] where a story is "a set of apps and/or modules that work
together for the user to achieve a goal.", and can be clustered[4] and
arranged in different ways[4].

[1]:
[https://fuchsia.googlesource.com/ledger/](https://fuchsia.googlesource.com/ledger/)

[2]:
[https://fuchsia.googlesource.com/escher/](https://fuchsia.googlesource.com/escher/)

[3]: [https://arstechnica.com/gadgets/2017/05/googles-fuchsia-
smar...](https://arstechnica.com/gadgets/2017/05/googles-fuchsia-smartphone-
os-dumps-linux-has-a-wild-new-ui/)

[4]: [https://fuchsia.googlesource.com/sysui/#important-
armadillo-...](https://fuchsia.googlesource.com/sysui/#important-armadillo-
non_widget-classes)

[5]:
[https://fuchsia.googlesource.com/mondrian/](https://fuchsia.googlesource.com/mondrian/)

~~~
enugu
Looking at [1] and the key value database described there, it would need some
key coordination mechanism to make use of the system database. For instance, a
way for an app to say that a document it stores is either directly of a given
type or implements the interface (ex: an email or a music data), so that other
apps can use this document. So the type field would refer to a standardized
type like a uuid associated with some type of data or a URI (like in RDF).
Also, it can have some mechanism for other types to implement the interface or
extend existing types and for users to create new types just like we can
register urls today.

Having a database with standardized interfaces for documents replace a
filesystem is a really important feature mentioned in the article. It will
allow the development of many useful apps like the itunes or email examples.
Also, this is not specific to any OS can be standardized independently and
implemented on current OSes we use by having some extension which stores
metadata along with a file.

~~~
joshmarinacci
OP here: Yes, there would need to be standards for the metadata. I suspect
these would be developed over time as people use it, then later codified.

~~~
Damogran6
Look at LDAP to see where that goes. For a 'Lightweight' construct, it's not
very lightweight.

[http://www.kouti.com/tables/userattributes.htm](http://www.kouti.com/tables/userattributes.htm)

------
zug_zug
I really don't understand the negativity here. I sense a very dismissive tone,
but most of the complaints are implementation details, or that this has been
tried before (so what?).

I think anybody who really thinks about it would have to agree modern OSes are
a disgusting mess.

\-- Why does an 8 core mac have moments that it is so busy I can't even click
anything but only see a pinwheel? It's not the hardware. No app should have
the capability, even if it tried, to slow down the OS/UI (without root
access).

\-- Yes, it should be a database design, with permissions.

\-- Yes, by making it a database design, all applications get the ability to
share their content (i.e. make files) in a performant searchable way.

\-- Yes, permissions is a huge issue. If every app were confined to a single
directory (docker-like) then backing up an app, deleting an app, terminating
an app would be a million times easier. Our OSes will never be secure until
they're rebuilt from the ground up. [Right now windows lets apps store garbage
in the 'registry' and linux stores your apps data strewn throughout /var/etc,
/var/log, /app/init, .... These should all be materialized views [i.e. sym-
links])

\-- Mac Finder is cancer. If the OS were modularizable it'd be trivial for me,
a software engineer, to drop-in a replacement (like you can with car parts).

\-- By having an event-driven architecture, this gives me exact tracking on
when events happened. I'd like a full record of every time a certain file
changes, if file changes can't happen without an event, and all events are
indexed in the DB, then I have perfect auditability.

\-- I could also assign permission events (throttle browser CPU to 20% max,
pipe all audio from spotify to removeAds.exe, pipe all UI notifications from
javaUpdater to /dev/null)

I understand the "Well who's gonna use it?" question, but it's circular
reasoning. "Let's not get excited about this, because nobody will use it,
because it won't catch on, because nobody got excited about it." If you get an
industry giant behind it (Linus, Google, Carmack) you can absolutely reinvent
a better wheel (e.g. GIT, chrome) and displace a huge marketshare in months.

~~~
pjc50
> \-- Why does an 8 core mac have moments that it is so busy I can't even
> click anything but only see a pinwheel? It's not the hardware. No app should
> have the capability, even if it tried, to slow down the OS/UI (without root
> access).

Back in 1999 I saw a demo of Nemesis at the Cambridge Computer Lab: a
multithreaded OS that was designed to resist this kind of thing. Their demo
was opening up various applications with a video playing in the corner and
pointing out that it never missed a frame.

Even back then I understood that this was never going to make it to the
mainstream.

> If the OS were modularizable it'd be trivial for me, a software engineer, to
> drop-in a replacement

You can do shell replacements and shell extensions on Windows. You can replace
whatever you want on Linux. Non-customisability of MacOS is a Jobsian
deliberate choice.

> event-driven architecture

Windows is actually rather good at this.

> all applications get the ability to share their content

> every app were confined to a single directory

Solving this conflict is extremely hard.

~~~
mnw21cam
> Back in 1999 I saw a demo of Nemesis at the Cambridge Computer Lab: a
> multithreaded OS that was designed to resist this kind of thing. Their demo
> was opening up various applications with a video playing in the corner and
> pointing out that it never missed a frame.

Yes, but Nemesis was a proper real time OS. The video-playing application had
asked the OS for a guarantee that it would get X MB/s of disc bandwidth, and
that it would have Y ms of CPU time every Z ms. The scheduler then gave that
application absolute priority over everything else running while inside those
limits, in order to make that happen.

This isn't hard. However, it conflicts with the notion of fair access to
resources for all. The OS can only give a real-time guarantee to a limited
number of processes, and it cannot rescind that guarantee. Why should one
application get favourable access to resources just because it was the first
one to reserve them all? How does the OS tell a genuine video-playing
application from an application that wants to slow down the OS/UI?

This is why applications need special privileges (i.e. usually root) in order
to request real-time scheduling on Linux. It's complicated.

Nemesis also did some nifty stuff with the GUI - individual applications were
given responsibility to manage a set of pixels on the screen, and would update
those pixels directly. This was specifically to avoid the problems inherent in
the X-windows approach of high-priority tasks being funnelled through a lower-
priority X server.

------
noen
As a current developer, former 10 year UX designer, and developer before that,
this kind of article irks me to no end.

He contradicts his core assertion (OS models are too complex and layered) with
his first "new" feature.

Nearly everything on this manifesto has been done before, done well, and many
of his gripes are completely possible in most modern OS's. The article just
ignores all of the corner cases and conflicts and trade-offs.

Truly understanding the technology is required to develop useful and usable
interfaces.

I've witnessed hundreds of times as designers hand off beautiful patterns and
workflows that can't ever be implemented as designed. The devil is in the
details.

One of the reasons Windows succeeded for so long is that it enabled people to
do a common set of activities with minimal training and maximizing reuse of as
few common patterns as possible.

Having worked in and on Visual Studio, it's a great example of what happens
when you build an interface that allows the user to do anything, and the
developer to add anything. Immensely powerful, but 95% of the functionality is
rarely if ever used, training is difficult because of the breadth and pace of
change, and discovery is impossible.

~~~
pavlov
_One of the reasons Windows succeeded for so long is that it enabled people to
do a common set of activities with minimal training and maximizing reuse of as
few common patterns as possible._

And ironically, one of the reasons why Windows was successful in developing
these patterns for office applications is that much of the work was done by
IBM.

The UI in Windows 3 was functionally almost identical to the Presentation
Manager interface that had been designed for the IBM-Microsoft collaboration
OS/2\. The design implemented an IBM standard called CUA [1].

CUA is not an exciting UI, but it did a good job of consolidating existing
desktop software patterns under a consistent set of commands and interactions.
The focus on enabling keyboard interaction was crucial for business apps, and
a strong contrast to the mouse-centric Mac (which didn't even have arrow keys
originally).

The kind of extensively data-driven UI system development that CUA represented
is totally out of fashion nowadays, though. Making office workers' lives
easier is terribly boring compared to designing quirky button animations and
laying out text in giant type.

[1]
[https://en.m.wikipedia.org/wiki/IBM_Common_User_Access](https://en.m.wikipedia.org/wiki/IBM_Common_User_Access)

~~~
BatFastard
Good observations. Truth is "It's really hard to develop user interfaces that
are easy to use and powerful at the same time." I have been working on one in
my passion project for years, and the balance between presenting just enough
information with a clear path to more, and filled the screen with overload is
a delicate balance.

------
avaer
> I suspect the root cause is simply that building a successful operating
> system is hard.

It's hard but not that hard; tons of experimental OS-like objects have been
made that meet these goals. Nobody uses them.

What's hard is getting everyone on board enough for critical inertia to drive
the project. Otherwise it succumbs to the chicken-and-egg problem, and we
continue to use what we have because it's "good enough" for what we're trying
to do right now.

I suspect the next better OS will come out of some big company that has the
clout and marketing to encourage adoption.

~~~
XorNot
What's hard is making your backwards compatiblity story sane. You need to
somehow make your new system provide some obvious advantages even to ported
apps, while still plausibly allowing them to work with minimal porting effort.

But I think this "reinvent the world" concept has a deeper flaw - in all the
discussion I didn't see any mention of how you make it _performant_ despite
that being an identified problem. If everything's message passing...how much
memcpy'ing is going on in the background? What does it mean to pipe a 4gb
video file to something if it's going to go onto a message bus as ... 4kB
chunks? 1 mb?

Remember this is a proposal to rebuild the entire personal computing
experience, so "good enough" isn't good enough - it needs to absolutely
support a lot of use cases which is why we have so many other mechanisms. And
it also (due to the porting requirement) should have a sensible way to degrade
back to supporting old interfaces.

Microsoft owns the desktop partly because they absolutely were dedicated to
backwards compatiblity. You want to make progress - you need to have a plan
for the same.

~~~
SilasX
Yep: "The reason God could finish the earth in six days is that He didn't have
to worry about backward compatibility."

------
dcow
Android already tried things like a universal message bus and a module-based
architecture and while nice it doesn't quite live up to the promise for two
reasons:

1\. Application devs aren't trained to architect new software. They will port
old shitty software patterns from familiar systems because there's no time to
sit down and rewrite photoshop for Android. It's sad but true.

2\. People abuse the hell out of it. Give someone a nice thing and someone
else will ruin it whether they're trying to or not. A universal message bus
has security and performance implications. Maybe if Android was a desktop os
not bound by limited resources it wouldn't have pulled out all the useful
intents and neutered services, but then again the author's point is we should
remove these complex layers and clearly the having them was too
complex/powerful/hungry for android.

I do think there's a point to be made that we're very mouse and keyboard
centric at the primitive IO level and in UI design. I always wondered what the
"command line" would look like if it was more complex than 128 ascii
characters in a 1 dimensional array. But it probably wouldn't be as intuitive
for humans to interface with unless you could speak and gesture to it as the
author suggests.

------
nwah1
I agree with a lot of the critics in the comments, but I will say that the
author has brought to my attention a number of features that I'm now kind of
upset that I don't have.

I always thought LED keyboards were stupid because they are useless, but if
they could map to hotkeys in video players and such, that could be very
useful, assuming you can turn off the LEDs.

His idea for centralized application configs and keybindings isn't bad if we
could standardize using something like TOML . The Options Framework for
Wordpress plugins is an example of this kind of thing, and it does help. It
won't be possible to get all the semantics agreed upon, of course, but maybe
80% is enough.

Resurrecting WinFS isn't so important, and I feel like there'd be no way to
get everyone to agree on a single database unless every app were developed by
one team. I actually prefer heterogeneity in the software ecosystem, to
promote competition. We mainly need proper journalling filesystems with all
the modern features. I liked the vision of Lennart Poettering in his blog post
about stateless systems.

The structured command line linked to a unified message bus, allowing for
simple task automation sounds really neat, but has a similar problem as WinFS.
But I don't object to either, if you can pull it off.

Having a homogenous base system with generic apps that all work in this way,
with custom apps built by other teams is probably the compromise solution and
the way things have trended anyways. As long as the base system doesn't force
the semantics on the developers, it is fine.

~~~
andrewflnr
Why settle for TOML in your config? It should be a database.

~~~
diegof79
The Windows registry is a database. Introduced in Windows 3.1 to handle COM
classes, and later extended as the preferred config mechanism over .ini files.

If you are a Windows user you'll notice the problems that it introduces in
terms of security and maintainance. Files are much better in both aspects.

To me the underlying issue is not centralization into a single database, but
the usability of advanced configuration. Every OS have multiple attempts to
resolve that problem, which ended in more fragmentation for end users (i.e.
macOS plist / registry / rc files / etc).

------
ghinda
You have most of these, or at least very similar versions, in Plasma/KDE
today:

> Document Database

This is what Akonadi was when when it came out for 4.x. Nepomuk was the
semantic search framework so you could rate/tag/comments on files and search
by them. They had some performance problems and were not very well received.

Nepomuk has been superseded by Baloo, so you can still tag/rate/comment files
now.

Most KDE apps also use KIO slaves: [https://www.maketecheasier.com/quick-easy-
guide-to-kde-kio-s...](https://www.maketecheasier.com/quick-easy-guide-to-kde-
kio-slaves/)

> System Side Semantic Keybindings

> Windows

Plasma 4 used to have compositor-powered tabs for any apps. Can't say if it
will be coming back to Plasma 5. Automatic app-specific colors (and other
rules) are possible now.

> Smart copy and paste

The clipboard plasmoid in the system tray has multiple items, automatic
actions for what to do with different types of content and can be pinned, to
remain visible.

> Working Sets

These are very similar to how Activities work. Don't seem to be very popular.

~~~
joshmarinacci
Those KIO slaves are really interesting. I've never seen those before. Thanks!

------
diegof79
What the author wants is something like Squeak. The idea behind Smalltalk
wasn't to do a programming language, but a realization of the DynaBook (google
for the essay "History Behind Smalltalk").

While I agree with the author that more innovation is needed on the desktop; I
think that the essay is very disinformed.

For example, Squeak can be seen as an OS with very few layers: everything is
an object, and sys calls are primitives. As user you can play with all the
layers, and re-arrange the UI as you want.

So why the idea didn't took off? I don't know exactly (but I have my
hypothesis). There are many factors to balance, those many factors are the
ones that makes design hard.

One of those factors is that people tend to put the wrong priorities of where
innovation should be. A good example is what the author mentions as priorities
for him. None of the items mentions fundamental problems that computer users
face today (from my perspective of course).

~~~
fremontfan
Indeed, Smalltalk was designed in this way and for the use case mentioned. A
good resource that explains that is "Design Principles Behind Smalltalk":
[https://www.cs.virginia.edu/~evans/cs655/readings/smalltalk....](https://www.cs.virginia.edu/~evans/cs655/readings/smalltalk.html)

------
antoineMoPa
I appreciate the article for its coverage of many OS (including BeOS, wow, I
should try that). What about package management though? Package management
really defines the way you live under your flavor of linux, and there is a lot
of room for improvement in current package managers (like decentralizing them,
for example).

Also:

> I know I said we would get rid of the commandline before, but I take that
> back. I really like the commandline as an interface sometimes, it's the pure
> text nature that bothers me. Instead of chaining CLI apps together with text
> streams we need something richer [...]

I can't agree with that, it is the plain text nature of the command line that
makes it so useful and simple once you know a basic set of commands
(ls,cd,find,sed,grep + whatever your specific task needs). Plain text is easy
to understand and manipulate to perform whatever task you need to do. The
moment you learn to chain commands and save them to a script for future use,
the sky is the limit. I do agree with using voice to chain commands, but I
would not complain about the plain text nature and try to bring buttons or
other forms of unneeded complexity to command-line.

~~~
taktoa
Nix(OS) is the future of package/configuration management IMO. It'd be such a
shame if someone built a new OS without learning from NixOS.

------
lake99
> Traditional filesystems are hierarchical, slow to search, and don't natively
> store all of the metadata we need

I don't know what he means by "traditional", but Linux native filesystems can
store all the metadata you'd want.

> Why can't I have a file in two places at once on my filesystem?

POSIX compatible filesystems have supported that for a long time already.

It seems to me that all the things he wants are achievable through Plan9 with
its existing API. The only thing missing is the ton of elbow grease to build
such apps.

~~~
XorNot
There's also a reason no-one uses hard links: because you can't tell if you
edit a file, where else you might be editing it.

~~~
pjmlp
Worse, if you ask around most people are unsure what happens to the original
file when you delete an hard link.

~~~
contras1970
there is no "original file": hard links are just synonymous names for a single
blob. _rm_ / _unlink_ essentially just reduce a reference counter and the
storage gets freed when the counter drops to zero.

~~~
pjmlp
I know that, most users don't.

------
hackermailman
This guy wants GuixSD for 60% his feature requests, like isolated apps,
version control, snapshots, ease of configuration, and ability to abstract all
of it away, and Hurd for his multi-threaded ambitions, modularity, ability to
do things like mount a database in a home directory to use as a fileserver,
and message passing. This is slowly happening already
[https://fosdem.org/2017/schedule/event/guixhurd/](https://fosdem.org/2017/schedule/event/guixhurd/)

Then he wants to completely redesign a GUI to manage it all, which sounds a
lot like Firefox OS with aware desktop apps, but with the added bonus that
most things that req privileges on desktop OSs no longer need them with Guix.
Software drivers are implemented in user space as servers with GNU Hurd, so
you can now access these things and all the functionality that comes with
them, exactly what the author wants.

------
jmull
This isn't worth reading.

(It's painfully naive, poorly reasoned, has inaccurate facts, is largely
incoherent, etc. Even bad articles can serve as a nice prompt for discussion,
but I don't even think this is even good for that. I don't we'd ever get past
arguing about what it is most wrong about.)

~~~
alexandercrohde
I think is borderline ad-hominem.

~~~
khedoros1
I think that the comment is attacking the essay, rather than attacking the
essay by attacking the author. I think it's worth reading, but I also think it
would've been better if it didn't repeatedly contradict itself, say that
features don't exist that clearly do, and so on.

------
chrisleader
"First of all, it’s quite common, especially in enterprise technology, for
something to propose a new way to solve an existing problem. It can’t be used
to solve the problem in the old way, so ‘it doesn’t work’, and proposes a new
way, and so ‘no-one will want that’. This is how generational shifts work -
first you try to force the new tool to fit the old workflow, and then the new
tool creates a new workflow. Both parts are painful and full of denial, but
the new model is ultimately much better than the old. The example I often give
here is of a VP of Something or Other in a big company who every month
downloads data from an internal system into a CSV, imports that into Excel and
makes charts, pastes the charts into PowerPoint and makes slides and bullets,
and then emails the PPT to 20 people. Tell this person that they could switch
to Google Docs and they’ll laugh at you; tell them that they could do it on an
iPad and they’ll fall off their chair laughing. But really, that monthly
PowerPoint status report should be a live SaaS dashboard that’s always up-to-
date, machine learning should trigger alerts for any unexpected and important
changes, and the 10 meg email should be a Slack channel. Now ask them again if
they want an iPad." \- Benedict Evans

------
xolve
Not an ideal article for anything. Looks like written with limited research,
that by the end of it I an hardly keep focus.

> Bloated stack. True, there are options which author hasn't discussed.

> A new filesystem and a new video encoding format. Apple created new FS and
> video format. These are far more fundamental changes to be glossed over as
> trivial in a single line.

> CMD.exe, the terminal program which essentially still lets you run DOS apps
> was only replaced in 2016. And the biggest new feature of the latest Windows
> 10 release? They added a Linux subsystem. More layers piled on top. Linux
> subsytem is a great feature of Windows. Ability to run bash on Windows
> natively, what's the author complaining about?

> but how about a system wide clipboard that holds more than one item at a
> time? That hasn't changed since the 80s! Heard of Klipper and similar app in
> KDE5/Plasma. Its been there for so long and keeps text, images and file
> paths in clipboard.

> Why can't I have a file in two places at once on my filesystem? Hard links
> and soft links??

> Filesystem tags Are there!

What I feel about the article is: OSes have these capabilities since long,
where are the killers applications written for these?

------
benkuykendall
The idea of system wide "document database" is really intriguing. I think the
author identified a real pattern that could be addressed by such a change:

> In fact, many common applications are just text editors combined with data
> queries. Consider iTunes, Address Book, Calendar, Alarms, Messaging,
> Evernote, Todo list, Bookmarks, Browser History, Password Database, and
> Photo manager. All of these are backed by their own unique datastore. Such
> wasted effort, and a block to interoperability.

The ability to operate on my browser history or emails as a table would be
awesome! And this solves so many issues about losing weird files when trying
to back up.

However, I would worry a lot about schema design. Surely most apps would want
custom fields in addition to whatever the OS designer decided constitutes an
"email". This would throw interoperability out the window, and keeping it fast
becomes a non-trivial DB design problem.

Anyone have more insights on the BeOS database or other attempts since?

(afterthought: like a lot of ideas in this post, this could be implemented in
userspace on top of an existing OS)

------
mwcampbell
I'm glad the author thought about screen readers and other accessibility
software. Yes, easy support for alternate input methods helps. But for screen
readers in particular, the most important thing is a way to access a tree of
objects representing the application's UI. Doing this efficiently over IPC is
hard, at least with the existing infrastructure we have today.

Edit: I believe the state of the art in this area is the UI Automation API for
Windows. In case the author is reading this thread, that would be a good place
to continue your research.

~~~
joshmarinacci
I'm not familiar with UI Automation API for Windows. Thank you for the tip.

[https://msdn.microsoft.com/en-
us/library/windows/desktop/ff4...](https://msdn.microsoft.com/en-
us/library/windows/desktop/ff486375\(v=vs.85\).aspx)

------
dgreensp
I love it, especially using structured data instead of text for the CLI and
pipes, and replacing the file system with a database.

Just to rant on file systems for a sec, I learned from working on the Meteor
build tool that they are slow, flaky things.

For example, there's no way on any desktop operating system to read the file
tree rooted at a directory and then subscribe to changes to that tree, such
that the snapshot combined with the changes gives you an accurate updated
snapshot. At best, an API like FSEvents on OS X will reliably (or 99%
reliably) tell you when it's time to go and re-read the tree or part of the
tree, subject to inefficiency and race conditions.

"Statting" 10,000 files that you just read a second ago should be fast, right?
It'll just hit disk cache in RAM. Sometimes it is. Sometimes it isn't. You
might end up waiting a second or two.

And don't get me started on Windows, where simply deleting or renaming a file,
synchronously and atomically, are complex topics you could spend a couple
hours reading up on so that you can avoid the common pitfalls.

Current file systems will make even less sense in the future, when non-
volatile RAM is cheap enough to use in consumer devices, meaning that "disk"
or flash has the same performance characteristics and addressability as RAM.
Then we won't be able to say that persisting data to a disk is hard, so of
course we need these hairy file system things.

Putting aside how my data is physically persisted inside my computer, it's
easy to think of better base layers for applications to store, share, and sync
data. A service like Dropbox or BackBlaze would be trivial to implement if not
for the legacy cruft of file systems. There's no reason my spreadsheets can't
be stored in something like a git repo, with real-time sync, provided by the
OS, designed to store structured data.

~~~
rdiddly
[https://msdn.microsoft.com/en-
us/library/system.io.filesyste...](https://msdn.microsoft.com/en-
us/library/system.io.filesystemwatcher.changed\(v=vs.110\).aspx)

~~~
dgreensp
It's not that file-watching APIs (and libraries that abstract over them and
try to clean them up) don't exist, it's that they are complex and unreliable,
with weak semantics. Typically an "event" is basically a notification that
something happened to a file in the recent past. As noted in the remarks on
that page, moving a file triggers a cascade of events, which differs depending
on interactions with the computer's antivirus software. You aren't making any
claims about this API, though, so there is not really anything for me to
refute.

If the file system operated in an event-sourcing model, you'd be able to
listen to a stream of events from the OS and reconstruct the state of the file
system from them. If it acted like a database, you'd be able to do consistent
reads, or consistent writes (transactions! holy cow).

~~~
zvrba
> If it acted like a database, you'd be able to do consistent reads, or
> consistent writes (transactions! holy cow).

[https://en.wikipedia.org/wiki/Transactional_NTFS](https://en.wikipedia.org/wiki/Transactional_NTFS)

------
jimmaswell
Patently false that Windows hasn't innovated, UX or otherwise. Start menu
search, better driver containment/other bsod reduction, multi-monitor
expanding task bar, taskbar button reordering, other Explorer improvements,
lots of things.

------
microcolonel
> _Why can 't I have a file in two places at once on my filesystem?_

You can! Use hardlinks.

> _Window Managers on traditional desktops are not context or content aware,
> and they are not controlable by other programs._

There are well established standards for controlling window managers from
programs, what on earth are you talking about?

> _Applications would do their drawing by requesting a graphics surface from
> the compositor. When they finish their drawing and are ready to update they
> just send a message saying: please repaint me. In practice we 'd probably
> have a few types of surfaces for 2d and 3d graphics, and possibly raw
> framebuffers. The important thing is that at the end of the day it is the
> compositor which controls what ends up on the real screen, and when. If one
> app goes crazy the compositor can throttle it's repaints to ensure the rest
> of the system stays live._

Just like Wayland!

> _All applications become small modules that communicate through the message
> bus for everything. Everything. No more file system access. No hardware
> access. Everything is a message._

Just like flatpak!

> _Smart copy and paste_

This is entirely feasible with the current infrastructure.

> _Could we actually build this? I suspect not. No one has done it because,
> quite honestly, there is no money in it. And without money there simply aren
> 't enough resources to build it._

Some of this is already built, and most of it is entirely feasible with
existing systems. It's probably not even that much work.

------
IamCarbonMan
All of this is possible without throwing out any existing technology (at least
for Linux and Windows; if Apple doesn't envision a use case for something it's
very likely never going to exist on their platform). Linux compositors have
the ability to manipulate the window however the hell they want, and while
it's not as popular as it used to be, you can change the default shell on
Windows and use any window manager you can program. A database filesystem is
two parts: a database and a filesystem. Instead of throwing out the filesystem
which works just fine, add a database which offers views into the filesystem.
The author is really woe-is-me about how an audio player doesn't have a
database of mp3s, but that's something that is done all the time. Why do we
have to throw out the filesystem just to have database queries? And if it's
because every app has to have their own database- no they don't. If you're
going to rewrite all the apps anyways, then rewrite them to use the same
database. Problem solved. The hardest concept to implement in this article
would be the author's idea of modern GUIs, but it can certainly be done.

On top of this, the trade-off of creating an entirely new OS is enormous.
Sure, you can make an OS with no apps because it's not compatible with
anything that's been created before, and then you can add your own editor and
your own web browser and whatever. And people who only need those things will
love it. But if you need something that the OS developer didn't implement,
you're screwed. You want to play a game? Sorry. You want to run the software
that your school or business requires? Sorry. Seriously, don't throw out every
damn thing ever made just to make a better suite of default apps.

------
remir
Seems a lot like Fuchsia, the new OS Google is currently developing:

[https://fuchsia.googlesource.com/docs/+/HEAD/book.md](https://fuchsia.googlesource.com/docs/+/HEAD/book.md)
[https://fuchsia.googlesource.com/modular/+/master/docs/modul...](https://fuchsia.googlesource.com/modular/+/master/docs/module.md)
[https://fuchsia.googlesource.com/docs/+/HEAD/filesystems.md](https://fuchsia.googlesource.com/docs/+/HEAD/filesystems.md)

------
Animats
If you want to study user interfaces, look at programs which solve a hard
problem - 3D animation and design programs. Learn Inventor or Maya or Blender.

Autodesk Inventor and Blender are at opposite ends of the "use the keyboard"
range. In Inventor, you can do almost everything with the mouse except enter
numbers and filenames. Blender has a 10-page list of "hotkeys". It's worth
looking at how Inventor does input. You can change point of view while in the
middle of selecting something. This is essential when working on detailed
objects.

------
vbezhenar
I think that the next reboot will be unifying RAM and Disk with tremendous
amount of memory (terabytes) for apps and transparent offloading of huge video
and audio files into cloud. You don't need filesystem or any persistence
anymore, all your data structures are persistent. Use immutable stuff and you
have unlimited Undo for the entire device life. Reboot doesn't make sense, all
you need is to flush processor registers before turning off. This experience
will require rewrite OS from ground up, but it would allow for completely new
user experience.

~~~
mike_hearn
It's not even clear to what extent you'd have to rewrite.

3D X-Point memory is coming. This is about 10x slower than DRAM but persistent
and at a fraction of the cost. At 10x slower you can integrate it into NUMA
systems and treat it as basically the same as RAM. One of the first features
prototyped with it is "run a JVM with the heap made entirely persistent".

I agree that there's a lot of scope for innovation in desktop operating
systems but it probably won't come from UI design or UI paradigms at this
point. To justify a new OS would require a radical step forward in the
underlying technology we use to build OS' themselves.

------
zaro
> I suspect the root cause is simply that building a successful operating
> system is hard.

Well, it is hard, but this is not the main source of issues. The obstacle to
having nice things on the desktop is this constant competition and wheel
reinvention, the lack of cooperation.

The article shows out some very good points, but just think of this simple
fact. It's 2017, and the ONLY filesystem that will seamlessly work with macOS,
Windows and Linux at the same time is FAT, a files system which is almost 40
years old. And it is not because it is so hard to make such a filesystem. Not
at all. Now this is at the core of reasons why we can't have nice things :)

~~~
arthurfm
> It's 2017, and the ONLY filesystem that will seamlessly work with macOS,
> Windows and Linux at the same time is FAT, a filesystem which is almost 40
> years old.

Universal Disk Format? [1]

ExFAT can also be used on all currently supported versions of Windows & macOS
and added to Linux very easily via a package manager.

You could argue there isn't any need for a cross-platform filesystem these
days. It's often easier to simply transfer files over Ethernet, Wi-Fi or even
the Internet.

[1] [https://tanguy.ortolo.eu/blog/article93/usb-
udf](https://tanguy.ortolo.eu/blog/article93/usb-udf)

~~~
eltoozero
Not sure why the downvotes, ExFAT mostly doesn't suck these days for random
go-between work.

To your last comment, I will reply with the "old" adage to "never
underestimate the raw bandwidth of a stationwagon loaded with tapes/drives
barreling down the highway."[0]

[0]:
[https://en.m.wikiquote.org/wiki/Andrew_S._Tanenbaum](https://en.m.wikiquote.org/wiki/Andrew_S._Tanenbaum)

------
thibran
Interesting to read someone else ideas about that topic, which I though myself
quite a lot about. The basic building block of a better desktop OS is IMHO –
and as the OP wrote – a communication contract between capabilities and the
glue (a.k.a apps). I don't think we would need that many capability-services
to be able to build something useful (it doesn't even need to be efficient at
first). For the start it might be enough to wrap existing tools and expose
them and see if things work or not.

Maybe by starting to build command-line apps and see how good the idea works
(cross-platform would be nice). I guess that the resulting system would have
some similarities with RxJava, which allows to compose things together (get
asynchronously A & B, then build C and send it to D if it contains not Foo).

If an app would talk to a data-service it would no longer have to know where
the data is coming from or how it got there. This would allow to build a whole
new kind of abstractions, e.g. data could be stored in the cloud and only
downloaded to a local cache when frequently used, just to be later synced back
to the cloud transparently (maybe even ahead of time because a local AI
learned your usage patterns). I know that you can have such sync-things today,
they are just complicated to setup, or cost a lot of money, or work only for
specific things/applications, also they are often not accessible to normal
users.

Knowing how to interact with the command-line gives advanced users
superpowers. I think it is time to give those superpowers to normal users too.
And no, learning how to use the command-line is not the way to go ;-)

A capability-services based OS could even come with a quite interesting
monetization strategy by selling extra capabilities, like storage, async-
computation or AI services, beside of selling applications.

------
Groxx
> _Consider iTunes. iTunes stores the actual mp3 files on disk, but all
> metadata in a private database. Having two sources of truth causes endless
> problems. If you add a new song on disk you must manually tell iTunes to
> rescan it. If you want to make a program that works with the song database
> you have to reverse engineer iTunes DB format, and pray that Apple doesn 't
> change it. All of these problems go away with a single system wide
> database._

Well. Then you get Spotlight (on OSX, at least) - system-wide
file/metadata/content search.

It's great! It's also quite slow at times. Slow (and costly) to index, slow to
query (initial / common / by-name searches are fast, but content searches can
take a second or two to find _anything_ \- this would be unacceptable in many
applications), etc.

I like databases, but building a single well-performing one for all usages is
quite literally impossible. Forcing everyone into a single system doesn't tend
to add up to a positive thing.

------
lou1306
Windows 10 didn't add any UX feature? What about Task View (Win+Tab) and
virtual desktops?

And why bashing the Linux subsystem, which is surely not even developed by the
UX team (so no waste of resources) and is a much needed feature for
developers?

BTW, there is a really simple reason why mainstream OSs have a rather
conservative design: the vast majority of people just doesn't care and may
even get angry when you change the interaction flow. Many of the ideas exposed
in the post are either developer-oriented or require significant training to
be used proficiently.

~~~
agumonkey
My favorite Win7/10 UX features: drag n snap (with the corresponding Win +
arrow bindings). Whoever managed to pitch the idea to MS, thanks a lot.

~~~
digi_owl
Could use some refinement though. Only a two window left/right split is able
to resize both windows when dragging one. You can't have say one window on the
left, and two on the right and expect all of them to be resized to maintain
that layout.

~~~
agumonkey
It's probably done on purpose. Average feature for simple productivity, most
people will need a 2 panels split.

I would love a few more options, like pinning one and having two windows share
the remaining space (like a video player on a corner)

~~~
digi_owl
I guess i explained it poorly.

You can, at least with Windows 10, have the screen split into 4. But once you
go beyond a left/right split, the other windows will not resize to maintain
their areas if you resize one of them.

------
nickpsecurity
The author keeps questioning why certain siloing like App Store happens. The
author then offers technical solutions that won't work. The reason is the
siloing is intentional on part of companies developing those applications to
reduce competition to boost profits. They'd rather provide the feature you
desire themselves or through an app they get 30% commission on.

A lot of other things author talks about keep the ecosystems going. The
ecosystems, esp key apps, are why many people use these desktop OS's. Those
apps and ecosystems take too much labor to clean slate. So, the new OS's tend
not to have them at all or use knock-offs that don't work well enough. Users
think they're useless and leave after the demo.

The market effects usually stomp technical criteria. That's why author's
recommendations will fail as a whole. "Worse Really is Better" per Richard
Gabriel.

~~~
cmiles74
This shouldn't be an issue on a free and open operating system, like Linux.
Profit isn't a driver for LibreOffice or Blender, but these apps are still
siloed off from each other. I think the author is right in that if the
operating system offered both a richer and simpler set of tools to make it
easier to add OS components and to communicate between applications, we could
really see some interesting stuff.

Personally, I do find the idea of an operating system composed of services and
applications that all share the same messaging statement compelling.

~~~
tonyedgecombe
Profit is definitely a driver for much open-source software, Google pushes
Android so they can control mobile advertising, Oracle pushes Java to stop
Microsoft having a stranglehold on corporate development, RedHat pushes Linux
so it can sell services. There aren't many big open source projects that are
purely altruistic.

~~~
cmiles74
For sure there are projects that are driven by dollars, but many that are
not... If we're going to get a desktop environment with the level of openness
that the OP would like, I do think this would be a job for libre developers as
it is fundamentally at odds with the pursuit of dollars via lock-in (that is,
every app would be increasing the value of the OS and sacrificing lock-in of
the customer's data).

~~~
tonyedgecombe
It's a dilemma isn't it, without funding it probably won't happen, with
funding it's corrupted in some way.

~~~
cmiles74
I'm not seeing how products that are funded are "corrupted". I think that
products that are funded need to make money and that drives the pressure to
cordon off the customer's data and to lock them into the specific application.
I'm not saying that this is innately bad (though some people might), but that
it runs counter to this idea of building an OS that does more than simply
launch software and store data. If you're feeling pressure to own the
customer's data, then you won't be all that interested in making your
application available to the rest of the OS by providing a suite of services.

------
snarfy
What we have today grew together organically over time like a city. To do what
is described in the article is akin to demolishing the city and completely
rebuilding it from scratch. But it's not just from scratch, it's replacing all
of the infrastructure and tooling that went into building the parts of the
city, like plumbing and electrical. A state of the art substation requires
it's own infrastructure to build. It's akin to requiring a whole new compiler
tool chain and software development system just to get started with rebooting
the OS.

If this happens it's only going to happen with a top-down design from an
industry giant. Android and Fuchsia are examples of how it might happen. Will
it? It seems these days nobody cares as long as the browser renders quickly.

~~~
gldalmaso
I think this is a good analogy.

To complement it a bit. There's the problem of bootstrapping. Once all that
new city infrastructure and beautiful planning is complete, who wants to move
into that new city that has no markets, stores, bars, restaurants, etc?

Desktop is full of old cruft because people use old crufty software today.
They must be able to continue to use old crufty software because they need to
until a better alternative exists, but they use multiple old crufty software
and better alternatives come slowly.

Desktop builds the new city adjacent to the old one and makes the grass
greener there, but it takes quite a while for the old city to get empty.

------
Skunkleton
In 2017 a modern operating system such as Android, iOS, or Chrome (the
browser) exists as a platform. Applications developed for these platforms
_must_ conform to the application model set by the platform. There is no
supported way to create applications that do not conform to the design of the
platform. This is in stark contrast to the "1984" operating systems that the
OP is complaining about.

It is very tempting to see all the complexity of an open system and wish it
was more straight forward; more like a closed system. But this is a dangerous
thing to advocate. If we all only had access to closed systems, who would we
be seceding control to? Do we really want our desktop operating systems to be
just another fundamentally closed off walled garden?

~~~
TuringTest
The idea wouldn't be to lose open systems, it's building open systems in a
different way, including all the lessons learned in the past 30 years about
working and organizing information in digital systems connected to the
internet

Like, for example, the WWW. Why is it that desktops have no native support for
the user to organize web applications, and everything is handled through a
single app, the browser?

------
bastijn
Apart from discussing the content. Can I just express my absolute love for
(longer) articles that start with a tl;dr?

It gives an immediate answer to "do I need to read this?", and if so, what key
arguments should I pay attention to?

Let me finish with expressing my thanks to the author for including a tl;dr.

Thanks!

~~~
joshmarinacci
I'm glad you liked it.

------
joshmarinacci
OP here. I wasn't quite ready to share this with the world yet, but what are
you gonna do.

I'm happy to answer your questions.

------
jonahss
The author mentions they wished Object-based streams/terminals existed. This
is the premise of Windows Powershell, which today reminds me of nearly
abandoned malls found in the Midwest: full of dreams from a decade ago, but
today an empty shell lacking true utility, open to the public for wandering
around.

~~~
ZenoArrow
Bit of a stretch. PowerShell is used a ton, especially by Windows
sysadmins/devops engineers, and is actively developed. Perhaps you've just got
that impression because you haven't been following it with much interest.

~~~
orangeshark
It has also been open sourced and can be used on Linux and MacOS. Not sure if
many people are using it on these systems though.
[https://github.com/powershell/powershell](https://github.com/powershell/powershell)

------
raintrees
I have been conceptualizing what it would take to abstract away the actual
physical workstation into a back-end processing system and multiple UI modules
physically scattered throughout my home (I work from home) and grounds.

For example, as in shift my workspace from my upstairs office to my downstairs
work area just by signing in on the different console setup downstairs. All of
my in-process work comes right back up. Right now I do this (kind of) using
VMs, but they are limited when addressing hardware, and now I am multiplying
that hardware.

Same thing with my streams - Switch my audio or video to the next room/zone
where I want to move myself to. Start researching how to correctly adjust my
weed whip's carburetor, then go out to the garage and pull up my console there
where my work bench is and the dismantled tool.

Eventually my system would track my whereabouts, with the ability (optionally
turned on) to automatically shift that IO to the closest hardware setup to me
as I move around the structure/property.

And do something like this for each person? So my wife has her streams?
Separate back end instance, same mobility to front-end UI hardware?

Can this new Desktop Operating System be designed with that hardware
abstraction in mind?

------
mherrmann
What I hate is the _bloat_. Why is GarageBand forced upon me with macOS? Or
iTunes? Similarly for video players etc on all the other OSs. I am perfectly
capable of installing the software I need, thank you very much.

~~~
oneplane
It's not forced, it is a part of the product and you are free to not use it or
remove it.

Where some people might not want certain defaults, most people have no clue
how to get access to software and will take whatever is already there. This is
part of the reason all Windows devices come preinstalled with 50% windows and
50% OEM bloat; the OEM gets paid and the customer might 'use what is already
there' and for the bloatware vendors hopefully purchase a full version or
subscription.

What you want and what other people want most likely doesn't line up and never
will. This is because there is no universal configuration for everyone and
because the median is not going to work for anyone at all (i.e. install
Garageband but not a browser, or install Numbers but not Pages)

------
ksec
I hate to say this, but an ideal Desktop OS, at least for majority of
consumers is mostly here, and it is iOS 11.

Having use the newest iPad Pro 10.5 ( along with iOS 11 beta ), the first few
hours were pure Joy, after that were frustration and anger flooding in.
Because what I realize, is this tiny little tablet, costing only half a
Macbook Pro or even iMac, limited by Fanless design with lower TDP, 4GB of
memory, no Dedicated GPU, likely much slower SSD, provides a MUCH better user
experience then the Mac or Windows PC i have ever used, that is including the
latest Macbook Pro.

Everything is fast and buttery smooth, even the Web Browsing experience is
better. The only downside is you are limited touch screen and Keyboard. I have
number of times wonder If I can attach a separate monitor to use it like
Samsung Desktop Dock.

There are far too many backward compatibility to care for with both Windows
and Mac. And this is similar to the discussion in the previous Software off
Rails. People are less likely to spend time optimizing when it is working good
enough out of the box.

~~~
make3
you don't have access to the file system in iOS. This makes me crazy. You also
can't do any change that changes the os's behavior in any meaningful way. For
a dev at least, even for mobile, it feels really limiting to use.

~~~
pjmlp
The new version does provide access.

------
gshrikant
While I'm not sure I agree with everything in the article, it does mention a
point I've been thinking about for a while - configuration.

I really do think applications should try to zero-in on a few standard
configuration file formats - I really don't have a strong preference on one
(although avoiding XML would be nice). It makes the system uniform and makes
it easier to move between applications. Of course, applications can add
extended sections to suit their need.

Another related point is the location of configuration files - standard
Linux/Unix has a nice hierarchy /etc/ for and /usr/local/etc and others for
user-specific configurations (I'm sure Windows and OS X should have a similar
hierarchy too) but different applications still end up placing their
configuration files in unintuitive places.

I find this lack of uniformity disturbing - especially because it looks so
easy (at least on the surface) to fix and the benefits would be nice - easier
to learn and scriptable.

A last unrelated point - I don't see why Linux distributions cannot
standardize around a common repository - Debian and Ubuntu both share several
packages but are yet forced to maintain separate package databases and you
can't easily mix and match packages between them. This replication of effort
seems more ideological than pragmatic (of course, there probably are some
practical reasons too). But I can't see why we can't all pool resources and
share a common 'universal' application repository - maybe divide it into
'Free', 'Non-Free', 'Contrib/AUR' like granular divisions so users have full
freedom to choose the packages they want.

Like other things, I think these ideas have been implemented before but I'm a
little disappointed these haven't made it into 'mainstream' OS userlands yet.

~~~
khedoros1
> A last unrelated point - I don't see why Linux distributions cannot
> standardize around a common repository

Because there are enough differences between distros that a lot of the
software is packaged with different build options, configurations, file paths,
etc. Keeping a separate repository of software that doesn't differ increases
complexity of all the distros involved, requires more inter-distro
administration decisions, and just generally generates more work than keeping
them separate does.

You've either got more-complex packages with multiple sets of configurations
available, or you erase the differences between distros (which exist for some
good reasons). The way things are, effort is duplicated, but only
accidentally, when the decisions of two distros about a particular package
just happen to be the same.

------
nebulous1
I much preferred the second half of this to the first half.

However, both seemed to end up with the same fundamental flaw: he's either
underestimating or understating how absurdly difficult most of what he's
suggesting is. It's all well and good saying that we can have a standardized
system for email, with everything being passed over messages, but what about
_everything_ else? It's extremely difficult to standardize an opinionated
system that works for everything, which is exactly why so many operating
system constructs are more general than specific. For this to all hang
together you would have to standardize _everything_ , which will undoubtedly
turn into an insane bureaucratic mess. Not to mention that a lot of software
makers actively fight against having their internal formats open.

------
hyperfekt
This would be neat, but isn't radical enough yet IMHO. If everything on the
system is composed of pure functions operating on data, we can supercharge the
OS and make everything both possible AND very simple. The whole notion of
'application' is really kind of outmoded.

------
doggydogs94
FYI, most of the author's complaints about the command line were addressed by
Microsoft in PowerShell. For example, PowerShell pipes objects, not text.

------
agumonkey
I see
[https://birdhouse.org/beos/refugee/trackerbase.gif](https://birdhouse.org/beos/refugee/trackerbase.gif)
for 2 seconds and I feel happy. So cute, clear, useful.

~~~
romanovcode
I still don't understand what is it. An email client? What is this yellow
"data" on top?

Seems rubbish to me.

~~~
eltoozero
You're looking at a file browser from BeOS.

The file-system in BeOS can operate as a database, so files can have
attributes and metadata baked alongside them natively.

The mail-client operated as a daemon running in the background periodically
fetching and writing entries to an OS folder that was a searchable database
with to, from, subject, body, and time stamp as "fields" abstracted
"magically" to the window view.

------
EdSharkey
Hacker News is most interesting when a controversial article like this is
written without all the necessary facts or research. I learned a lot about a
range of existing OS and application tech just through all the refuting going
on here.

Anyhow, my $0.02 is that all software dies. Either software lands in a niche
due to its architecture and doesn't survive industry paradigm shifts or it
groans under its own weight of cruft allowing more nimble competitors to enter
the market and take marketshare. I'm no fan of full-system rewrites because of
the tremendous cost and typical failure, but even so all software does
eventually die and replacements will emerge.

So, it at least makes sense for some well-heeled upstart to begin thinking
about the next-gen operating system in case an opportunity presented itself to
establish a market. If that upstart were me, my focus would be on
productivity, performance, stability/security.

Especially with regards to UX, I would focus on defining UX Guidelines and a
windowing toolkit that would only change very infrequently (like once every
10-20 years.) To me, a tacky-looking, "outdated" UX that billions of people
know by heart and can play like a fiddle is infinitely more valuable than one
that changes look-and-feel year to year. My devs would be laser focused on
fixing bugs and performance enhancements, not feature-itis.

------
al2o3cr

        Window Managers on traditional desktops are not context or content aware, and they are not controlable by other programs.
    

My copy of Divvy is confused by this statement. :)

------
st3fan
> And if you wanted to modify your email client, or at least the one above
> (Mail.app, the default client for Mac), there is no clean way to extend it.
> There are no plugins. There is no extension API. This is the result of many
> layers of cruft and bloat.

I am going to say that it is probably a product decision in case of Mail.app.

Whether Mail.app is a big steaming pile of cruft and bloat inside - nobody
knows. Since it is closed source.

~~~
oneplane
Mail.app actually does have plug-ins.

~~~
efficax
Yes but the plugin API is undocumented.

------
gumby
I really agree that the hermetic siloization of applications and their data
over the past 30 years has been a _major_ step backwards. I also wish all apps
were composable.

It seems to require a mental shift few developers are willing to adopt
however. Good luck -- you are on the right track on many things (even if I
can't imagine life without a command line).

------
casebash
I wouldn't say that innovation in Desktop is dead, but most of it seems to be
driven by features or design patterns copied from mobile or tablet. Take for
examples Windows 8 and Windows 10, Windows 8 was all about moving to an OS
that could run on a whole host of devices, while Windows 10 was all about
fixing up all the errors made in this transition.

------
mcny
Hi Josh,

Thank you for writing this.

Just noticed a small typo (I think)

> For a long time Atom couldn't open a file larger than 2 megabytes because
> scrolling would be to slow.

to should be too.

Sincerely,

------
PrimHelios
This seems to me to be written by someone who uses MacOS almost exclusively,
but has touched Windows just enough to understand it. The complete lack of
understanding of IPC, filesystems, scripting, and other OS fundamentals is
pretty painful.

>Why can I dock and undock tabs in my web browser or in my file manager, but I
can't dock a tab between the two apps? There is no technical reason why this
shouldn't be possible. Application windows are just bitmaps at the end of the
day, but the OS guys haven't built it because it's not a priority.

I'm an idiot when it comes to operating systems (and sometimes even in
general), but even _I_ know why there are issues with that. You need a
standardized form of IPC between the two apps, which wouldn't happen because
both devs would be convinced their way is the best. On top of that, it's a
great way to get an antitrust against you if you aren't careful [0]

>Why can't I have a file in two places at once on my filesystem? Why is it
fundamentally hierarchical?

Soft/hard links, fam. Even Windows has them.

>Why can['t] I sort by tags and metadata?

You can in Linux, you just need to know a few commands first.

>Any web app can be zoomed. I can just hit command + and the text grows
bigger. Everything inside the window automatically rescales to adapt. Why
don't my native apps do that? Why can't I have one window big and another
small? Or even scale them automatically as I move between the windows? All of
these things are trivial to do with a compositing window manager, which has
been commonplace for well over a decade.

Decent point IMO. There's a lot of native UI I have a hard time reading
because it's so small. That said, I think bringing in the ability to zoom
native widgets would bring in a lot of issues that HTML apps have.

>We should start by getting rid of things that don't work very well.

The author doesn't understand PCs. The entire point of these machines is
backwards-compatibility, because we _need_ backwards compatibility. I'm
sitting next to a custom gaming PC and I have an actual serial port PCIe card
because I need serial ports. Serial ports. In 2017. I'd be screwed if serial
wasn't supported anymore.

I won't touch the rest of the article because I there's a lot I disagree with,
but he seems to just want to completely reinvent the "modern OS" as just
chromebooks.

[0]:
[https://en.wikipedia.org/wiki/United_States_v._Microsoft_Cor...](https://en.wikipedia.org/wiki/United_States_v._Microsoft_Corp).

~~~
mikelward
Not if tabs are a higher-level concept, e.g. handled by the window manager, as
Fluxbox does.

[http://fluxbox.sourceforge.net/features/tabs.php](http://fluxbox.sourceforge.net/features/tabs.php)

~~~
khedoros1
That's what I was thinking. There's no reason a window manager can't have the
concept of tabs, and display different programs as tabs on the same window.

I used to use Fluxbox, but I didn't know it was already capable of that.
Pretty cool!

------
Zigurd
A few years ago I wrote a book about developing big complex networked apps. It
had "Enterprise" in the title, based on the idea that mobile device OSs would
become dominant - which they did - and that the evolution of tablet devices
would continue to where powerful devices like the iPad Pro would overtake the
use of Mac and Windows laptops - which they didn't.

Windows and MacOS are full of compromises but are usable. Chrome OS is a
contender for users that need a simpler system. What addressable segment is
left? You pretty much have to make the case for replacing Windows. But you can
only hope to replace the "voluntary" Windows seats. Many Windows users have no
choice.

------
oconnor663
> Wayland is supposed to fix everything, but it's been almost a decade in
> development and still isn't ready for prime time.

Mutter's Wayland implementation is the default display server for Gnome Shell
right now. How much more prime time do can you get?

~~~
danieldk
And Fedora has shipped two releases with Wayland as the default display
server.

~~~
dylan-m
And Ubuntu is poised to bite the bullet and do the same in a release or two :)

And it works comfortably with the offical drivers for modern ATI graphics
cards. (One of the earlier fears about Wayland).

I really wish people would cut it out with the "Wayland is doomed" myth. This
is just how free software works: you see stuff before it's done. Then (given
sufficient backing) it gets finished. Then it works.

------
atemerev
"A solution in search of a problem".

What problem of mine "piping my Skype stream to video analysis service" is
supposed to solve? Why would I want to dock and undock different application
parts to all places they don't belong? Etc.

------
blueworks
The reference to atom and it's performance to the underlying electron and
nodejs runtime is inappropriate since another popular editor Microsoft's VS
Code which also uses electron but is very fast and is a pleasure to work with.

------
linguae
I've been thinking a lot about the problem of modern desktop operating systems
myself over the past year. I believe that desktop operating system
environments peaked last decade. The Mac's high water mark was Snow Leopard,
the Linux desktop appeared to have gained momentum with the increasing
refinement of GNOME 2 during the latter half of the 2000's, and for me the
finest Windows releases were Windows 2000 and Windows 7. Unfortunately both
the Linux desktop and Windows took a step in the wrong direction when
smartphones and tablets became popular and the maintainers of those desktops
believed that the desktop environments should resemble the environments of
these new mobile devices. This led to regressions such as early GNOME 3 and
Windows 8. GNOME 3 has improved over the years and Windows 10 is an
improvement over Windows 8, but GNOME 2 and Windows 7, in my opinion, are
still better than their latest successors. Apple thankfully didn't follow the
footsteps of GNOME and Windows, but I feel that the Mac has stagnated since
Snow Leopard.

I agree with the author of this article that desktop operating systems should
develop into workstation operating systems. They should be able to facilitate
our workflows, and ideally they should be programmable (which I have some more
thoughts about in my next paragraph). In my opinion the interface should fully
embrace the fact that it is a workstation and not a passive media consumption
device. It should, in my opinion, be a "back to basics" one, something like
the classic Windows 95 interface or the Platinum Mac OS interface.

One of the thoughts that I've been thinking about over the years is the lack
of programmability in contemporary desktop GUIs. The environments of MS-DOS
and early home computers highly encouraged users to write programs and scripts
to enhance their work environment. Unix goes a step further with the idea of
pipes in order to connect different tools together. Finally, the ultimate form
of programmability and interaction would resemble the Smalltalk environment,
where objects could send messages to each other. What would be amazing would
be some sort of Smalltalk-esque GUI environment, where GUI applications could
interact with each other using message passing. Unfortunately Apple and
Microsoft didn't copy this from Xerox, instead only focusing on the GUI in the
early 1980s and then later in the 1980s focusing on providing an object-
oriented API for GUI services (this would be realized with
NeXTSTEP/OPENSTEP/Cocoa, which inspired failed copycat efforts such as
Microsoft Cairo and Apple/IBM Taligent, but later on inspired successful
platforms such as the Java API and Microsoft .NET). The result today is
largely unprogrammable GUI applications, though there are some workarounds
such as AppleScript and Visual Basic for Applications (though it's far from
the Smalltalk-esque idea). The article's suggestion for having some sort of
standardized JSON application interface would be an improvement over the
status quo.

I would love to work on such an operating system: a programmable GUI
influenced by the underpinnings of Smalltalk and Symbolics Genera plus the
interface and UI guidelines of the classic Mac OS. The result would be a
desktop operating system that is unabashedly for desktop computer users. It
would be both easy to use and easy to control.

~~~
TheCowboy
A lot of hate in this thread seems against even discussing this, but I think
it's worth exploring.

I usually refer to some of these groups of ideas as "composability of
workspaces". People question why you would want to dock or undock a tab from
different apps, but we already work like this a lot when we use modern IDEs
and web browsers. I'd argue that Emacs and Linux CLI still has a lot of appeal
for this reason of workspace composability.

Are we better thinking and debating about how we want computational
environments to exist, or simply hope that the next version of iOS or Windows
'does not suck'? Will we be able to seamlessly compute across multiple
devices; will OSes become specialized? What would be optimal?

There are social, economic (scarcity of programmer time), and institutional
limitations to undertaking huge projects. But that doesn't rule out any type
of progress toward a long-term goal, or prevent people from booking small
wins.

------
pier25
I agree with some of the points stated. For years I've been thinking that a
tag based file system would be superior to a folder based one in many aspects.

macOS has tags, but the UX/UI for interacting with them is really poor.

------
jacinabox
In regards to the issue of file systems being non-searchable, it's definitely
worth taking a look at compressed full-text indexes:
[http://pizzachili.dcc.uchile.cl/resources/compressed_indexes...](http://pizzachili.dcc.uchile.cl/resources/compressed_indexes_in_practice.pdf)

Under this scheme each file on disk would be stored as an index with constant
factor overhead. The original file is not needed; all of the data can be
decoded out of the index.

------
sddfd
I think electron is a step into the right direction.

Let's assume for a moment there weren't the problem with JavaScript
performance (because, for example, web assembly can replace it).

Then electron is a platform everyone can build his applications on. And once
that happens, operating systems are free to shed the library cruft.

This is just one possible migration path, and I am not saying it's going to
happen or that it is even a good idea.

But if you have to write cross platform apps it seems, that this has clear
advantages.

~~~
contras1970
Electron solves nothing, it's a prime example of the Inner Platform[0], it
will go through all the growing pains of solving the "library cruft" inside
it, and will still require all the "cruft" below it.

BTW, you say you think electron is a step in the right direction, and follow
it with "I am not saying [...] it is even a good idea." it can't be a step in
the right direction and a bad idea at once, so which is it? is it a good idea
or not?

[0] [https://en.wikipedia.org/wiki/Inner-
platform_effect](https://en.wikipedia.org/wiki/Inner-platform_effect)

~~~
sddfd
> right direction, vs not even a good idea

I think it is a step in the right direction because it allows you to build
platform independent software today, with a relatively defined interface to
the system (dom + JavaScript). This is a great opportunity to gain experience
about the requirements for systems like electron. So I think it is good that
electron exists, and would like to see it improved to address the issues that
are discovered by using it.

On the other hand, I am not sure if developing application software in
JavaScript is a good idea. I am not sure if compiling to webassembly just to
have it execute in another virtual machine is a much better idea. I don't know
if the dom abstraction is a good idea in the long run (it seems to work for
the web though). And I am not sure if there is another less popular technology
around that should be used instead electron.

------
dgudkov
Many interesting ideas and concepts, no question. However, if it was a startup
pitch I would struggle to see a killer application. I can see _features_ (some
are very exciting!) here, but I'm failing to see a _product_. What kind of
real-life problem would such OS solve? Is this problem worth billions of
dollars required for developing a new OS and a tool kit of apps for it?

------
saagarjha
> if you wanted to modify your email client, or at least the one above
> (Mail.app, the default client for Mac), there is no clean way to extend it.
> There are no plugins.

Mail.app supports plugins.

> Why can't I have a file in two places at once on my filesystem?

So…a hardlink?

> Why don't my native apps do that?

Dynamic text lets you do this, but it's mobile-only currently.

> have started deprecating the Applescript bindings which make it work
> underneath

Since when?

------
jonahss
Look to Mobile OSs for innovation in OS design. Like the author stated, it's
currently where the money is. It's the closest we have to "starting over" and
alot of things were rethought, such as security and sandboxed apps. IPC is
limited to start, but slowly growing.

I wouldn't be surprised if the workstation OSs of the future grew out of our
current Mobile OSs

~~~
pjmlp
This is what I would like to see on desktops.

Unsafe code constrained to the bottom layers of the OS, with everything else
on memory safe languages.

~~~
wolfgke
> Unsafe code constrained to the bottom layers of the OS, with everything else
> on memory safe languages.

Chrome, that is used on Android and is a large code base, is written mostly in
C++, which you would probably not call a memory safe language.

~~~
pjmlp
Yeah but writing web apps in HTML/CSS/JavaScript is not the same as using C++.

I would prefer the lower layers also to be written in a memory safe systems
programming language, but having the userspace 100% in such a language, would
already be quite an improvement versus the current situation.

------
atmartins
I'm surprised at all the negative, pessimistic views about looking forward
with operating systems. I welcome conversations about what things could be
like in the future. Obviously Google's pondering this with Fuchsia. Maybe it
will take a more vertical approach, where only certain hardware could take
advantage of some features for a while.

------
coldtea
> _In fact, in some cases it 's worse. It took tremendous effort to get 3D
> accelerated Doom to work inside of X windows in the mid 2000s, something
> that was trivial with mid-1990s Microsoft Windows. Below is a screenshot of
> Processing running for the first time on a Raspberry Pi with hardware
> acceleration, just a couple of years ago. And it was possible only thanks to
> a completely custom X windows video driver. This driver is still
> experimental and unreleased, five years after the Raspberry Pi shipped._

That's because of Open Source OSes though, which vendors don't care about and
volunteers aren't enough and able to match the work needed for all things to
play out of the box. Nothing about this particular example has anything to do
with OS research or modern OSes being behind.

> _Here 's another example. Atom is one of the most popular editors today.
> Developers love it because it has oodles of plugins, but let us consider how
> it's written. Atom uses Electron, which is essentially an entire webbrowser
> married to a NodeJS runtime. That's two Javascript engines bundled up into a
> single app. Electron apps use browser drawing apis which delegate to native
> drawing apis, which then delegate to the GPU (if you're luck) for the actual
> drawing. So many layers._

Again, nothing related to modern OSes being inadequate. One could use e.g.
Cocoa and get 10x what Electron offers, for 10x the speed, but it would be
limited in portability.

> _Even fairly simple apps are pretty complex these days. An email app, like
> the one above is conceptually simple. It should just be a few database
> queries, a text editor, and a module that knows how to communicate with IMAP
> and SMTP servers. Yet writing a new email client is very difficult and
> consumes many megabytes on disk, so few people do it._

First, I doubt one of the reasons "few people do it" is because it "consumes
many megabytes on disk" (what? whatever).

Second, the author vastly underestimates how hard it is handling protocols
like IMAP, or writing a "text editor" that can handle all the subtleties of
email (which include almost a whole blown HTML rendering). Now, if he means
'people should be able to write an emailer easily iff all constituent parts
where available as libraries and widgets', then yeah, duh!

> _Mac OS X was once a shining beacon of new features, with every release
> showing profound progress and invention. Quartz 2D! Expose! System wide
> device syncing! Widgets! Today, however Apple puts little effort into their
> desktop operating system besides changing the theme every now and then and
> increasing hooks to their mobile devices._

Yeah, and writing a whole new FS, a whole new 3D graphics stack, memory
compression, seamless cloud file storage, handoff, move to 64-bit everything,
bitcode, and tons of other things besides. Just because they are not shiny,
doesn't mean there are no new futures there.

> _A new filesystem and a new video encoding format. Really, that 's it?_

Yeah, because a new FS is so trivial -- they should also rewrite the whole
kernel at the same time, for extra fun.

> _Why can I dock and undock tabs in my web browser or in my file manager, but
> I can 't dock a tab between the two apps? There is no technical reason why
> this shouldn't be possible. Application windows are just bitmaps at the end
> of the day, but the OS guys haven't built it because it's not a priority._

There's also no real reason this should be offered. Or that it should be a
priority. If every possible feature someone might thing was "a priority" OSes
would be horrible messes.

> _Why can 't I have a file in two places at once on my filesystem? Why is it
> fundamentally hierarchical? Why can I sort by tags and metadata?_

Note how you can do all those things in OS X (you can have aliases and
symlinks and hard links, can add tags and metadata, and can sort by them). And
in Windows I'd presume.

And it's "fundamentally hierarchical" because that's how we think about stuff.
But it also offers all kind of non hierarchical views, Spotlight and Tags
based views for one.

> _Any web app can be zoomed. I can just hit command + and the text grows
> bigger. Everything inside the window automatically rescales to adapt. Why
> don 't my native apps do that? Why can't I have one window big and another
> small? Or even scale them automatically as I move between the windows? All
> of these things are trivial to do with a compositing window manager, which
> has been commonplace for well over a decade._

Because bitmap assets. Suddenly all those things are not so "trivial".

There are good arguments to be made about our OSes being held back by legacy
cruft (POSIX for one) and new avenues to explore, old stuff that worked better
than what we have now, etc.

But TFA is not making them.

------
ageofwant
Most all the author craves for can be cobbled together from existing
components. On Linux at least. If you don't use Linux you have bigger issues
to deal with first.

He can start by using a tiling window manager, like i3.

"It ain't what you don't know that gets you into trouble. It's what you know
for sure that just ain't so."

~~~
joshmarinacci
As I stated in the article. None of this is new. It just hasn't been put
together into a usable package.

------
free_everybody
Realistically, how difficult is it to write a brand new operating system like
this? Could a few people with full-time jobs write a working model in a year?
Maybe 10 people? Is it just too time consuming with too little of a payout?
There should be more options; I think a lot of people can agree on that.

~~~
joshmarinacci
While I was unemployed I almost launched a Kickstarter to build it, but I
figured not enough people were interested.

I think a runnable prototype could be done by a couple of people in a year if
you focused on a very tight hardware subset, say Raspberry Pi 3 and VirtualBox
x86.

------
anc84
> It took tremendous effort to get 3D accelerated Doom to work inside of X
> windows in the mid 2000s, something that was trivial with mid-1990s
> Microsoft Windows.

Huh? I am not aware of a 3D accelerated Doom version on Windows in that
timeframe nor that it was hard on Linux 10 years later. Any pointers?

------
zvrba
This sounds like a rant from a person not really acquainted with operating
systems.

> Why can I dock and undock tabs in my web browser or in my file manager, but
> I can't dock a tab between the two apps?

How would this even be semantically meaningful? What about top-level
components like menus which are completely different?

> Why can't I have a file in two places at once on my filesystem?

Umm, soft and hard links do exactly that.

> Why can't I speak commands to my computer

Cortana takes a shot at that. Personally, I don't even want to try out the
feature until it has the level of comprehension corresponding to a human.
Otherwise, I'll just be guessing how to spell out my sentences / commands..

> or have it watch as I draw signs in the air, or better yet watch as I work
> to tell me when I'm tired and should take a break.

Because these are hard problems in computer vision, unrelated to operating
systems.

> Each application has its own part of the filesystem

Yes, I wouldn't want to give up on that. It's orderly.

> its own config system, and its own preferences, database

Well, Windows unifies this in the registry. It's somewhat unpopular.

> Traditional filesystems are hierarchical, slow to search, and don't natively
> store all of the metadata we need.

NTFS can store extended metadata + arbitrary data in alternate data streams.
Doesn't seem to be used very much.

> I'd like to pipe my Skype call to a video analysis service while I'm
> chatting, but I can't really run a video stream through awk or sed.

The video stream is a stream of bytes. Skype interprets it and constructs a
video from that byte stream. Does he suggest that this interpreter should be
part of the kernel? That there is one single video streaming protocol that
fits all purposes?

> Native Applications are heavy weight,

Um? I have yet to see a "non-native" application that is as snappy as a native
one.

> take a long time to develop and very siloed.

 _Any_ application takes a long time to develop. If you care about stability,
crash recovery, etc.

> Wouldn't it be easier to build a new email client if the database was
> already built for you?

Exists, integrated in the Windows OS:
[https://en.wikipedia.org/wiki/Extensible_Storage_Engine](https://en.wikipedia.org/wiki/Extensible_Storage_Engine)

> The UI would only be a few lines of code.

It's logic behind the UI that's complicated, not building the UI itself (heck,
you can just draw it if you use C# or VB).

> If you want to make a program that works with the song database you have to
> reverse engineer iTunes DB format

Even if the hypothetical document DB existed, how would one program know about
the schema of other programs? Or schema versioning, or...? The problems with
proprietary formats won't just disappear, it'll just become easier to do the
wrong thing based on misinterpretation of the other program's schema.

> Message Bus [...] All applications become small modules that communicate
> through the message bus for everything.

COM, DCOM, CORBA... The first two are made user-friendly on Windows by C#.
Don't know whether it's possible to snoop on COM messages, but given the
thickness of the documentation on COM, I'd say the answer is "yes".

> However, this also means we have to rebuild everything from scratch.

Yes. Windows already exposes an insane amount of helper objects as COM
components.

> You could build a new email frontend in an afternoon...

In which alternate universe?

> I really like the commandline as an interface sometimes, it's the pure text
> nature that bothers me. Instead of chaining CLI apps together with text
> streams we need something richer, like serialized object streams (think JSON
> but more efficient).

He should read up on Powershell. It's also extensible and can directly invoke
COM components (+ all of the .net framework).

> System Side Semantic Keybindings

That one may be original. I think KDE has something like this.

> The clipboard should be visible on screen as some sort of a shelf that shows
> the recent items I've copied.

IIRC, I've seen something like this in KDE. Earlier versions of Windows had
some "clipboard manager" too, though it seems to have disappeared in new
versions. Plenty of freeware ones though.

> In the new system all applications are tiny isolated things which only know
> what the system tells them.

That's how Windows UWP applications behave. Appstore ones too. IIRC, some old,
then-mainstream OS-es tried the kind of separation and it didn't work well
with users. Sometimes you want to share data between isolation domains.

> None of this is New

No, and it seems that, feature-wise, Windows is closest to his dream OS. Now
he just needs to convince programmers to use the features that are already
there :-)

~~~
mikelward
Tabs should just be a window manager concept. You wouldn't be docking one app
into another, you'd be merging two windows into a shared window (or: multiple
panes into a single frame, if you want to extend the metaphor).

See Fluxbox for an example.
[http://fluxbox.sourceforge.net/features/tabs.php](http://fluxbox.sourceforge.net/features/tabs.php)

------
meesterdude
> I could take a snapshot of a screen. This would store the current state of
> everything, even my keybindings. I can continue working, but if I want I
> could rollback to that snapshot.

we can already do this with virtualization (and i make use of it extensively)

~~~
egypturnash
The fun part: making this something a non-technical user would ever even
realize is a possibility, much less consider doing.

------
jokoon
There are really millions of small things that I would make in a new desktop
OS.

First would be to forget the whole idea of resizable windows. Windows should
only tile automatically. A tab interface have shown that a simple task bar is
just enough.

File explorers would have their columns be resized automatically... I can't
believe how both OS X and windows 10 still have this wrong.

Ultimately I would let applications use hardware directly instead of relying
on how the OS do things. This would increase cross compatibility and developer
freedom. Good bye Qt and all those horrors of the past.

Not to mention how there are millions of small utilities and functionalities
like windirstat, foobar2000 that would be ideal to make the OS a little more
useful.

------
michaelmrose
"Window Managers on traditional desktops are not context or content aware, and
they are not controlable by other programs."

What does this mean? Some can be via IPC

------
OOPMan
Ah, the age-old assumption among developers:

Everything is terrible and broken, the only way to fix it is to throw
everything in the bin and start from scratch.

Some things never change...

------
untangle
Perhaps the new OS prototypes could be built on top of a hypervisor. Yes, it's
a layer. But building hypervisor-up would be a nice jump-start.

------
jrs95
I'm not really sure if a system wide document database is an improvement over
Core Data or not...

------
djhworld
I like the optimism in this post, there's are lot of dismissive comments on
here.

However I just don't think any of the ideas would ever really function. The
idea of letting you pipe your Skype video feed to some video analysis tool
would never happen

Similarly you'd never get application developers to open up their apps in such
a way where you can extract/import content.

------
osteele
This could be the first half of a good article. It's a list of things the
author cares about that variously: aren't (yet) possible, aren't a good idea,
nobody cares enough to make happen, or (maybe) indicate a market force
failure.

What would make this interesting (to me) is a discussion not _that_ these
features don't exist, but _why_.

~~~
TheOtherHobbes
They don't exist because your OS will only succeed if you're a successful
monopoly (in at least a couple of market segments) with the market leverage to
force adoption.

And if you're a monopolist with the market leverage to force adoption, you're
very unlikely indeed to also be a leader in OS R&D.

A more fundamental problem is that this wish list is only really of interest
to developers. The average user doesn't care about OS configurability or the
kind of OS-level task programming that's being talked about here, and they're
unlikely to use these features unless there's a super-simple UI to make them
accessible.

Personally I'd love to see more debate about OS design, and more movement and
improvement. IMO all the modern OS options pretty much suck in many ways.

But realistically I know you don't get much bottom-up invention in a market
driven economy when niches have already been filled with okay-I-guess
solutions.

You only get commoditisation and tinkering, and those are a long way from
streamlined genius-level excellence.

------
consultSKI
>> think JSON but more efficient

Amen. Seriously tho, a lot of great insight.

------
d4r114
PJON could fit as the message bus the author describes

------
SomeHacker44
Please write it from the ground up in Common Lisp. :)

------
jackcosgrove
How does this new OS handle backwards compatibility?

I've always thought the next evolution of the OS was to be a hypervisor for
application containers that can communicate via a common message bus.

~~~
yberreby
Sounds like what you want a microkernel with excellent IPC. There is still the
problem of the window manager, incompatible protocols, and backwards
compatibility, but I think a very small, robust core with discrete components
that communicate in an isolated way instead of sharing resources is the way
forward.

If you start viewing the filesystem as a huge global variable, it becomes
obvious that something is wrong with modern OS / app design. One wouldn't
tolerate this kind of uncontrolled sharing in a regular program; why should we
tolerate it in an OS? Permissions help, but don't solve the issue, as they are
still an access control measure on top of an already flawed model.

------
maxekman
The suggested OS sounds a lot like Plan 9 to me.

------
rado
macOS' recent Metal feature is great and extended my MacBook Air's life by 2
years. People keep forgetting it.

------
nkristoffersen
Sounds like he should be using iOS honestly.

------
Xorlev
I believe understand the vision that the author is trying to paint. I don't
think he's alone, but the reality is that building a full OS is a pretty
massive undertaking. Additionally, his idea of simplicity may be complexity
for others. I want to explore this a bit from a point of optimism, because
it's very very easy to find flaws in a manifesto that desires to redesign an
operating system.

There's a lot of interesting experimentation in OS-land. BeOS (and it's
successor, Haiku [1]) are called out explicitly by the author. BeOS/Haiku use
this idea of apps as modules to expose functionality across a message bus.
Redox OS (A Rust OS), is built on the microkernel concept. These are both kind
of on the fringe at the moment, so let me bring up one more platform that many
of us use daily: the modern web browser.

Chrome (and Firefox, ChromeOS, etc.) actually do take many of these concepts
to heart. Now, I know more about Chrome than Firefox or ChromeOS, so let me
set those aside for a moment.

\- "Everything done via a message bus." This is Chrome extensions in a
nutshell. \- "Dockable tabs in any window." \- "A CLI with structured data."
Sorta Chrome debugger+JS. With some effort, this could be a lot more powerful.
The author's desire to pipe a video call to an analysis service is a fairly
tough requirement here and obviously wouldn't fly in Chrome either, but that
isn't to say that it'd be impossible. \- "A built-in document database."
(IndexedDB) \- "Working sets." Chrome profiles -- try them! \- "Apps become
Modules." This is more of a miss, but if you squint enough through a powerful
enough lens, the APIs exposed by Chrome to extensions/webpages are a lot like
this. That said, given that everything on Chrome is more site-centric vs.
computer-centric, things are namespaced vs. Spotify being able to execute
arbitrary queries for MP3s.

Now, I'm not going to say that Chrome is IdealOS. There is much from that
vision that's missing. And I'd also say that webapps just aren't always an
acceptable substitute for native applications. Through massive wastes of
computing power, we are getting closer (see: Slack, Atom, all things
Electron). We aren't there yet. I'll always take a native app if it's written
decently.

It seems to me like in general much of this vision is being expressed through
disparate efforts, but only a few are tackling the idea of replacing the full
OS. Chrome seems best poised in many ways because it's already on your
existing OS. Yes, it's having to use the underlying OS' APIs and such, but you
can argue it's just one more layer. ChromeOS seems to do a pretty good job of
eliminating even that.

In general, I'm excited to see discussion on operating systems. The OSes used
by the general public are already here: Android and iOS. It's up to us to
build a better future for those of us using workstations

Disclaimer: I do not work on Chrome, but do work for its parent organization.
My views in no way reflect that of my employer's.

[1]
[https://en.wikipedia.org/wiki/Haiku_(operating_system)](https://en.wikipedia.org/wiki/Haiku_\(operating_system\))
[2]
[https://en.wikipedia.org/wiki/Redox_(operating_system)](https://en.wikipedia.org/wiki/Redox_\(operating_system\))

------
tomc1985
I'm getting to the point where Medium articles with stock imagery are
instantly ignored.

------
pvdebbe
Complecting a GUI into an OS doesn't sound very ideal to me.

------
kyberias
So much incorrect stuff in the text, I stopped reading.

------
halo
This aligns a lot with my personal thoughts about desktop operating systems,
especially the document database, ala BeFS on steroids, which is something
I've thought about for years and would be a huge improvement over the current
situation in a lot of use-cases.

I've long felt that applications and "package management" is still extremely
poor. Applications should be self-contained to a single file (software.app)
and have no shared dependencies outside the OS. The OS could have built-in
support for compression (e.g. software.app.compressed) for software that needs
it. Each application has one settings file per user. Sending, moving and
backing up software then becomes a breeze. Uninstalling becomes a matter of
deleting a file.

No shared libraries. It's 2017 and bandwidth and disk space are not major
problems. An OS will be able to figure out when it doesn't need to load more
than one copy of a dynamic library to avoid using excess memory. The OS should
be 'batteries included' so truly native applications will be tiny. You want to
proactively discourage ports to encourage native software, and need developers
to think twice before using bloated or interconnected dependencies.

This greatly simplifies creating any "app store"/"package manager". It will
largely download and update individual files.

All software is sandboxed, with permissions required to do anything
interesting, ala iOS.

Title bars should be stackable to turn into tabs, ala Haiku's stack-and-tile
([https://www.haiku-os.org/docs/userguide/en/gui.html#stack-
ti...](https://www.haiku-os.org/docs/userguide/en/gui.html#stack-tile)).
Everyone uses tabs in web browsers, it is overdue to bring them as first-class
features into desktop OSes, where it would greatly improve multitasking. The
title bar goes from being redundant into a core feature.

I agree that creating a good new operating system requires starting from
scratch and that is really, really hard. Broadly speaking, you want to
discourage ports, as it's a short-cut that will remove a lot of the advantages
of the OS and will discourage people from creating native software. Any new OS
needs to have the outright aim of making commercial software viable to be
successful, which is something Linux has struggled with.

Any new OS needs to be very polished and slick visually, which should be one
of the lessons from Mac OS X and its relative success over BeOS and NeXTSTEP,
which were much less visually appealing.

Practically, I've wondered if you could focus on a single low-cost piece of
hardware - a Raspberry Pi-in-a-box, perhaps, coupled with a VM version. This
could limit the scope of the task and you might get a good amount of
enthusiasts beyond free software evangelists.

I also wonder if thin translation layers over established libraries would
vastly speed up development by allowing a working version to be produced much
faster, even though you would want to replace them with something better in
the long run.

------
Ezhik
I was throwing out hypotheticals with a couple of friends a few days back. One
problem that I felt things like Samsung DeX and Windows Continuum were trying
to solve was the fact that all your devices are ultimately separate computers.

Your currently open apps, configuration, even things like your wallpaper - are
still ultimately different across your devices. Each device has its own
_state_ , and while with things like cloud file syncing and Pushbullet and
etc, you can make your devices at the very least aware of each other, in the
end, they still have separate _states_.

The endgame would be to just have a single _state_ , period. Your computer
would be every device you have. You would be able to drag a window from your
phone to your desktop to your HoloLens. Every file you have in your life, is
always with you.

But that's the faraway future.

Something possible with today's hardware (but not software), however, would be
to have phones with smart docks. Instead of just being hubs to connect the
phone to a screen and a keyboard, they would also have processing power, and
be proper computers in their own right to which the phone would be able to
offload complex computations. But I'm thinking it should be less like an
external GPU dock, and more like a server for remote compilation or video
rendering. This way, for example, you'd even be able to do things like
starting to render a video while your phone is docked, then undocking while
the video is still rendering on the dock, or you could launch a game that runs
on the dock and is controlled from your phone - something like AirPlay, but
the processing takes place on the dock. So ultimately, while you still have
multiple computers, there is only a single _state_ , which is on your phone.

The software is the hard part here. We can build a smartphone and a smart
dock, and have a fast enough data protocol to transfer content between each
other through USB-C. But who will write the OS? Where do you get the apps? Why
would Adobe bother porting After Effects to run on a _phone_ of all things,
and then also restructure it to be aware of the whole smart dock concept, when
After Effects can do something like this today as it is? Why would game
developers bother writing their games in a way that specifically supports this
dock paradigm when they can get the same general idea on the Nintendo Switch
for free? And so on.

This, just like OP's idea, would take a reboot. The problem with a reboot is
that it's a reboot. You cannot do that. Microsoft cannot do it, which is why
Windows 10 still runs very old software. Apple can't do it, which is why
Carbon was a thing. Linux can't do that, because Red Hat and Canonical will
not throw their customers under a bus.

But still, it's fun to daydream. Being told to stop even imagining the
impossible is not exactly going to help innovation.

------
ZenPsycho
this runs parallel to a lot of my thoughts. one thing that you don't quite
address, and which i believe has derailed all efforts to do stuff like this,
is the challenge of getting a large group of developers to agree on a single
set of data formats. it is only once you nail that, that doing many of the
composition/copy/paste things become possible. some of these formats are easy:
jpeg, png, utf-8. when it comes to something like: the meta data schema for a
song? a recipe? that's a can of worms and flamewars.

to some extent you've got the DBFS thing that everything shares but that's
only of use for sharing so far as you can get easy agreement about what
fieldnames should he available for a kind of thing.

you've also got security concerns. if everything shares the same database, any
random bit of code can ship that data off to a russian data mining op. or
corrupt your song database. or encrypt everything and ransom it. you kind of
address this by puttin a layer of indirection here, and having security and
access managed via the message bus, but this needs a UI, and i don't think
apple, android, or facebook has really mastered the ui for permissions.

------
SiempreZeus
Most of the stuff he wants is either trivial, or an implementation hell that
Will never happen. Hard and soft links solve the hierarchical filesystem
problem, kwin has windows tabbing (nobody uses it), rewriting every single app
from scratch for a theoretical gain? Sure that's happening.

The only good idea is the system documents database, and it isn't really that
useful.

------
fundabulousrIII
I used to think a system bus concentrator for disparate communications was the
way forward but it always ends in tears. You have created an interrupt
handling system in userspace with n * x permutations and specifications..this
is the literal tower of babel and is very easily abused.

------
romanovcode
> In the screenshot below the user is lifting the edge of a window up to see
> what's underneath. That's super cool!

> [https://joshondesign.com//images2/lift-
> window.png](https://joshondesign.com//images2/lift-window.png)

Is this a sarcasm? Because it is complete garbage.

~~~
rocky1138
Why is it complete garbage? There have been a ton of times I've been typing
something in but needed to see what's behind it. Reaching over for the mouse
is slow.

In fact, do you know what the keybinding is to roll up windows in KDE or XFCE
is? I could use that.

~~~
lscotte
That's why I use a tiling wm (i3). All windows are always on top.

~~~
rocky1138
Is there an easy way to avoid horizontal scrolling on webpages in these
windows? That always bugs the crap out of me. I wish there was "fit to window"
zoom in Chrome/Firefox.

