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].
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.
OP here: I agree. Fuchsia is very exciting. Google is one of the few companies with resources to actually build a new OS from scratch, and deal with backwards compatibility.
I don't trust Google. I couldn't use fuchsia on principle.
Ignoring the reasons why I don't trust Google, being able to trust your tools, especially your desktop, is the most important thing for me. I would love to have my emails delivered to a global document store so many smaller apps could take advantage of them, but only so long as I could guarantee there is no special 'google play services' app needing to run in the background doing who-knows-what with root.
Just out of curiosity, what smartphone and OS do you use, if I may ask? iOS and Windows Phone are closed source, which I'd argue it's worse than using Google services. Android seems pretty much unusable without Google integration. So...?
So we are forced to use a major manufacturer for our smartphones. Does that mean we can’t criticize them? They’re not on our side, they’re out to make a profit. I don’t trust them either, and I use a smartphone.
I do think it’s important that we create open hardware and open software. I’m realizing Richard Stallman was right all along.
I took my hat out of the desktop race a long long time ago. the only thing that has really affected me recently was Mate switching entirely to GTK3. my text editor now does all sorts of things the maintainer of the editor can't change, like smooth-scrolling when using the find dialog.
I really want to get behind this effort for an improved desktop, even if it means breaking everything. but I have to be able to trust each of the components.
> 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.
Exactly. You need to have the most critical apps running on your OS (development IDE, modern web browser and mail mostly). That's going to be a significant effort especially if those apps need to be rewritten as modules to take advantage of the paradigms the new OS offers.
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.
The author doesn't want "an OS", but "an OS that operates like one out of a sci-fi movie, tracking and interpeting my actions and responding to natural language". Toy OS projects aren't this.
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.
I think the author wants a bunch of really specific personal workflow ideas/concepts they have to be the standard, which is typically what these rants are. Such rant posts are always interesting to me as I do question my own workflow just to see if there are good ideas I'm missing out on, but a lot of the author's ideas just don't strike me as all that important in most cases, and in some of the complaints, I'm not sure what the complaint is.
Their complaint on the filesystem, for example, falls flat for me, but partially because I think I don't understand what they want or how BeOS did it. Maybe the author has a special meaning for "...sort by tags and metadata", but this looks to be baked right into Finder at the moment; I can add in a bunch of columns to sort by, tag my items with custom tags (and search said tags), add comments, and so on. Spotlight also has rendered a lot of organization moot as you just punch in a few bits of something about what you're looking for (tags, text within the document, document name, file type, date modified by, etc.) and you'll find it. I don't know exactly what is missing from modern OSes (Windows search isn't too bad either) that the author isn't contented with.
The idea of multiple forms of interaction with the computer are okay, but quite frankly it starts to get into an eerie situation for me where I'd rather have to take a lot of steps to set up such monitoring as opposed to it being baked into the OS. I realize that I'm squarely in luddite territory given the popularity of Home Assistants (Echo, Apple Homekit, Google Home), but to me these seem like very intentional choices on the part of a customer; you have to go out of your way to get the hardware for it and disabling it is as simple as pulling the plug. Look at the non-sense we're having to deal with in regards to Windows Telemetry - to me this is what happens when such items get baked into the OS instead of being an additional application; you end up with a function you no longer can control, and for no other reason than to satisfy the complaint of "I have to download something? No thank you!"
I could go on, but the author's rant just doesn't seem consistent and instead seems to just want some small features that they liked from older OSes to be returned to modern OSes. There is a huge issue with bloat and cruft and some real legacy stuff in Windows and macOS, and desktop OSes aren't getting the attention they should be, but these suggestions aren't what desktop OSes are missing or what they need.
A fascinating piece of trivia I was not aware of. To me it seems reasonable that instead of trying to reinvent the whole shebang that instead you get these incremental changes over time that just make an OS really really good.
OS X too a lot of getting used to for me as a kid, as I had an old mac clone and an iMac with 10.1 side by side in my living room, and I loved my little mac clone. OS X didn't immediately win me over because I was just too used to OS 9 and had everything I needed on my offline mac clone. But I distinctly remember Spotlight being what really sold me on OS X because from the get-go it worked basically as intended, and man was it magnificent. If the author of Spotlight is on APFS, I have a lot of faith in it then.
Ars Technica did a retrospective on the BeOS filesystem[1] which may help explain things. The tl;dr of it is that the filesystem is the canonical database that all applications can use and query without any special domain specific knowledge. I'm not up to date with how MacOS works so it's possible they've added a layer on top of the filesystem which works similarly. However, I do know that Windows is nowhere near that level, mainly because it's encouraged for metadata to be stored in file specific ways.
On the Mac, the metadata is stored in a file (inside /.Spotlight-V100) rather than inside the filesystem (a la BeOS File System). An application can provide Spotlight Importer that can extract metadata from a file during index (this is why mdimport is taking a lot of CPU time).
AFAIK, this approach is contrary to the BeOS approach, where application write the metadata directly. Spotlight's approach do have few benefits, though, such as able to provide metadata for files in network drives, or for removable disks that might not be using filesystem that supports metadata.
No, that's only part of the story. Early on, they were using resource forks for data but metadata as well. Then they moved to filesystem attributes and those just grew. You can have tags in there, as well as text, icons, settings etc. It's pretty standardized, but on top of that, you can use Spotlight metadata too, both in the EA as well ans the V100 DB.
Using a structure other than the file to store information about the file seems like a big problem (like the iTunes example Josh used). It's inherently not portable. Even if the OS took extra steps to copy the additional data along with the file, that still replies on the target OS to recognize the additional file(s), and incorporate it into whatever search functionality it has. Supporting the tags or metadata in the file simplifies things quite a bit.
>I think the author wants a bunch of really specific personal workflow ideas/concepts they have to be the standard, which is typically what these rants are.
This one in particular:
>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?
Yeah gnu tried and not to be too harsh failed with mach and hurd. They designed an OS according to their principles and nobody came to the party. Heck, mach uses Linux device drivers which tells you how much effort volunteers are willing to put into each project.
I don't think we'll see a change from Linux and Windows (edit: and IOS) until there's another compelling reason to switch; some feature that can't or won't be available in the other two operating systems and their surrounding ecosystems of software.
When was the last time we really had a "Visicalc sold more Apples than Apples sold Visicalc" moment? I can't think of one after Linux wafflestomped all the propietary hardware and os unix vendors, or to give Apple their due, when they released the iPhone.
Edit: duh, of course cloud taking over for bespoke hardware and software defined storage pushing out EMC and the like are two recent examples of industry game changers, but on the other hand both still rely primarily on Linux so my assertion about operating systems still stands.
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.
Probably a point in the middle would be the right compromise, most people think its binary (its closed hardware or its free+open) but I don't; I think there should be a hardware company (with all the stack: GPU + CPU + kernel) that goes the same way Epic went with Unreal (their game engine); meaning you can use their hardware for free and the specs are public but if your company evers get more than 50K in profits you have to pay them 20% of your profits; or something like that.
Yesss I've been waiting for this moment for nearly two decades haha :)
And it's definitely possible, just look at the C64 and Amiga demoscene. Those machines haven't evolved for ages, but they've been making them do one (thought to be) "impossible" thing after another for a very long time after the platforms were essentially considered dead. I've seen things at demoparties around 2000 where C64 demos showed stuff that was thought to be impossible to do on these machines (or so I was told, I'm not an expert on the C64's capabilities, but the thing runs in the single megahertzes and doesn't have a divide instruction, so yeah). One I remember had a part with a veeery low resolution realtime raytracer, about 10fps I think, the scene consisting of just a plane and a sphere (IIRC) ... but it was done on a C64.
I wonder how long it will take for PCs though. Moore's Law broke already a few years ago didn't it? But it's not really happening, so far. Or maybe it is. I haven't been keeping up with what's happening in the PC demoscene lately. They used to be way ahead of the curve compared to PC videogames, this changed somewhere in the 200Xs, probably because around that time videogames started getting Hollywood-size budgets.
> 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.
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 .
"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."
My first thought was actually "what about data formats?" These days, most data formats are at least nominally open, but you still need to write code to work with those formats, and most of the existing code is still in C or C++ libraries. The IdealOS will fail instantly as soon as a user receives a DOCX or XLSX file and it displays the document wrong. It can't just launch LibreOffice and use that. Even LibreOffice can't always parse random MS Office documents correctly, and LO represents decades of coder-years.
Well they could probably come up with some solution perhaps using a virtual LibreOffice to import it or whatnot. We've known for ages that those formats aren't particularly "ideal" and we should be starting letting them go, regardless of dreaming about a hypothetical OS or not.
I mean, you could also probably come up with some solution to have a guest over who brings their pet cow without doing too much damage to your nicely decorated apartment. Doesn't mean that's an ideal situation, and it most definitely is no reason to not dream about living somewhere nicer than a stable, and what that would look like to you.
The latter part, about dreaming how NICE your house could look like if you did not have to accommodate guests with cows barging into your living room all the time. That is what the article is actually about, he's pretty clear about his awareness that technical possibility is very different from the availability of a realistic road to transition from where we are now to the possibilities he sketches.
It's also a very important matter of combating learned helplessness. If you dismiss dreaming about an IdealOS beforehand because there's no way (that you can see now) to get there from where desktop OS's are today, then you most assuredly will miss the opportunity to attain even some of these improvements, were they to come within reach through some circumstance in the future.
Also, I remember programming on a 386. And on the one hand it amazes me that the thing in my pocket today is so much more powerful than that old machine, let alone my current desktop. And on the other hand, it infuriates me that some tasks on my desktop today are quite slow when really they have no right to be, and some of these tasks are even things that my 386 used to have no problems with whatsoever (but then, TPX was a ridiculously fast compiler, a true gem).
We should not let that slip out of sight, demand better and keep dreaming.
I guess that the article did annoy me. Partly because I remember GNUStep, Longhorn, OLPC etc. etc. which attempted some of these things, and we already know why those projects failed completely, and partly because I can now see the desktop slowly improving month-by-month on the Linux+GNOME stack. Yes, it's painfully slow and gradual, but it's sustainable progress: Wayland compositors, GNOME, Flatpak, and Atomic Workstation are actual shipping code that will only get better and more heavily used over time.
> 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.
Well, they wouldn't need to any more. They can adopt drivers from Linux or any other free operating systems. The inner work of a driver might be arcane, the interface to an operating system is generally well defined. Adopting a existing driver is definitely doable.
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.
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.
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.
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).
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.
Control of quality and auditing is another reason why apps stores exist and are useful: The (on average) high quality of the apps in the iOS store is the result of a rather strict auditing process, which in the end is also beneficial for the user. This is something that usually doesn't happen naturally with completely open systems. Even the Linux distributions (that are usually run mostly by volunteers and not profit-oriented) often have very strict criteria that your package needs to fulfill in order to be included in the official repository.
More benign versions of the same idea: app developers want to "provide a seamless experience"; they want their apps to be visually distinctive; they want to be portable across different OSes; they want clear boundaries between what they have to support and what they don't (is a copy-paste idiosyncracy something we have to document?); they can get performance advantages by implementing functionality themselves; and they're worried that the OS will change a critical subsystem or interaction in a way that isn't straightforward for them to adapt to.
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.
I agreed, and personally I think it's great that Windows 10 can still (mostly) run applications built for Windows XP, as often the original developers of these apps do no longer maintain / update them but they nevertheless provide some good value.
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.
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.
> What about Task View (Win+Tab) and virtual desktops?
Virtual desktops have been part of Windows since at least Windows XP. The necessary architecture was already in place, Microsoft just didn't include a virtual desktop manager. There were/are several available.
> 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.
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.
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.
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."
He doesn't suggest to trow away the old layers just because they're old, but because he suggests a different approach. Anyway that's a really good quote, I like it very much.
It is, but one just doesn't replace a proper BTree filesystem with a document database. Just because the author saw a document db, and thought it's cool, without looking at why BTrees won.
> But the solution is NOT to throw out a bunch of those old layers and replace them with new layers!!!
Neither is keeping everything as it is and keep pretending it's fine!
> When you throw away code and start from scratch, you are throwing away all that knowledge.
I disagree with Joel on here. There's lots to be learned from throwing everything away and starting from scratch, and if anything those innovations could make their way into the current infrastructure, as it has happened with Midori and Windows.
> "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.
> You might call it "knowledge [and] collected bug fixes," but sometimes the crap is just crap.
Key word here is "Sometimes".
Reviewing code means you get to find out the reason these hacks were written in the first place, and then decide wheter to keep, rework or delete them.
Starting from scratch means you get rid of the worthless crap, yes, but you also lose all the valuable crap.
LibreSSL is a special case which doesn't fit your example. They threw away code and didn't rewrite most of it - because it was supporting useless stuff. Features like heartbeat (see Hearbleed), obsolete and insecure ciphers, tons of crap no one should ever use again but is supposed to be there for FIPS-140 or other compliance requirements which in 2017 do far, far more harm than good.
It is vital to have regular cleanup in a code base to avoid the feeling that it should "all" be scrapped. There will always be code worth keeping for all the reasons mentioned (bugs fixed, etc.) but there will always be something that should just go away.
I like a lot of what Joel writes, but I profoundly disagree with him on this, and I'm not alone in my dislike of accidental complexity which, which I think is now an order of magnitude greater than essential complexity. So there is a "silver bullet". It just needs someone to bite it.
The author of the article recognizes there's a problem, but is less clear on how to go about solving it. A clue is in this article by Erik Naggum: http://naggum.no/erik/complexity.html
Dan Ingalls once wrote: "Operating System: An operating system is a collection of things that don't fit into a language. There shouldn't be one." What he meant is we should migrate the functionality of the operating system into the programming language. This is possible if there's a REPL or something similar, so no need for the shell or command line. The language should be image-based, so no need for a file system. So, a bit like Squeak, or a Lisp with a structure editor.
There's still a gap between the processor and the language, which should be eliminated by making the processor run the language directly. This was done in Burroughs mainframes and Lisp machines.
Further up the "stack", software such as word processors and web browsers are at present written entirely separately but have much in common and could share much of their code.
Thanks for the link to Erik's essay - it was a great read.
I like the idea of an image based system, eliminating the need for the filesystem itself. I think the 'filesystem' and 'executable-process' ideas are so prevalent that they frame our thinking, and any new OSes tend to adopt these right away. But more interesting and powerful systems might emerge if we find a new pattern of operation and composition. Are you aware of any image based full stack systems that are in active development?
Android is one such system. Each app gets its own image (called Bundle) where it can store it's state. OS manages those state bundles to offer multitasking on memory-constrained devices and persist app state across reboots.
Android has a file system. It's a operating system (a Linux variant). I'm suggesting that neither a file system nor an operating system is necessary, or even desirable. Just run an interactive programming language continuously on the bare metal, with its image periodically backed up to secondary storage.
Joel's assertion applies to the situation where the old code and the new code will reach roughly the same complexity at the end (for example, this is often the case when the requirements are complex enough and cannot be changed). If you have a very good idea to greatly reduce the complexity, ignore him and go ahead.
In the other words, the point is that you always have to do the cost-benefit analysis for any such endeavor and the history tells that rewriting is intrinsically very expensive.
>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.
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.
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.
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.
Thus you can see the contents of both the upper and lower windows at once, and not just briefly. Very useful on a laptop with limited screen space. I know adjustable window transparency is definitely possible on Linux too.
On the other hand, this looks like it's just effects for the sake of effects.
The example may not be doing the idea any service, but the idea itself seems to be to be able to peek at the content of a window without having to actually bring the window to the front.
That said, i wonder if this is why some people love using "focus follows mouse" or whatever it is called. Just drag the mouse pointer to the window you want to peek at, then back to the main window once done. No need to look for safe place to click or use keyboard commands (though i guess something similar could be achieved with a WM that brings each window to front as you alt-tab around).
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.
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.
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.
> Truly understanding the technology is required to develop useful and usable interfaces.
+100. This is something I have advised to any designer that would listen. You must have at least a basic understanding of the technology in order to understand the set of affordances with which you use to design your flows.
Adobe used to have a product they inherited from Macromedia called Fireworks that I enjoyed getting designs in, as a developer. It no longer exists, to my knowledge, but it spat out CSS land basic HTML, which I liked.
Still exists (although discontinued). Open the Adobe CC dialogue, go to the Apps part, tick "View older versions" (or something like that), and you should find its CS6 version.
That 5% is critical though and part of the reason that Office is so hard to dislodge. For that 5% of users, that feature is critical. Stack up enough features and you can be unassailable.
Well, that does make the common stuff excellent. And I would guess that the amount of people that have a weird must-have feature (that isn't just a result of misunderstanding the software) is pretty low.
There's a tyranny of designers, they must be stopped. Their "beautiful" designs have infected everything and now everything is all super-low data-density, full-screen interstitials, and hero units!
> 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.
I feel like the only power user in the world who liked this design. Yeah VS is big and scary but I disagree with your comments on discoverability. I learned to program on VB6 and then early VS.NET and I discovered features in either just fine. There was a standard protocol for getting to know big hairy beasts like VS or 3DS or FLStudio: set aside a week to play around, click everything in the menus to see what happens, and then come up with a goal and figure out how to achieve it. VS was dense but never stood in my way in this regard. (Though I could say the complete opposite about the documentation, with its dense, verbose style and unique, Microsoft vocabulary)
I disagree with your statement on VS discoverability. It is quite the opposite actually. I learn to use VS 2008 (my first IDE) on my own with very few googling after a year or so of computer science class. On the other hand using Eclipse or Netbeans for some class always ended in coding with Vim because the UI and framework integration was non obvious.
Finally one things that I precisely dislike with VS Code is that this whole discoverability ease was throw out of the windows and almost any complex task can't be completed without looking in the documentation.
I'd still like to have QNX-type messaging. The UNIX/Linux world started out with no interprocess communication, and ended up with a large number of incompatible ways to add it. The Windows world started out with interprocess communication with everybody in the same address space, and gradually tightened up. QNX started with messaging as the main OS primitive, and everything on QNX uses it.
The key to efficient IPC is that the scheduler and the interprocess communications system have to be tightly coupled. Otherwise you have requests going to the end of the line for CPU time on each call, too many trips through the scheduler, and work switching from one CPU to another and causing heavy cache misses. QNX got this right.
(Then they were bought by a car audio company, Harmon, and it was all downhill from there.)
QNX messaging isn't a "bus" system, and it has terrible discovery. Once communications are set up, it's great, but finding an endpoint to call is not well supported. The designers of QNX were thinking in terms of dedicated high-reliability real-time systems. It needs some kind of endpoint directory service. That doesn't need to be in the kernel, of course.
QNX is a microkernel, with about 60KB (not MB) of code in the kernel, and it offers a full POSIX interface. (There used to be a whole desktop GUI for it, Photon, good enough to run early versions of Firefox, but Blackberry blew off the real-time market and dropped that.) File systems, networking, and drivers are all in user processes, and optional. L4 is more minimal, probably too minimal - people usually run Linux on top of it, which doesn't result in a simpler system.
Small additions here: the networking components of QNX moved to kernel space quite some time ago, I don't even know if io-net is still supported. As far as I know they've reused the NetBSD stack for performance reasons. Also, those 60KB gives you a bare-bones system that is far from what people expect a POSIX system to be; you'd have to add plenty of additional processes to get there.
I still have a soft spot for QNX though; I hope they'll survive RIM.
Aw, they put networking in the kernel? Dan Dodge would not have approved.
60KB was just the kernel, not the additional processes that run in user space. The great thing about such a tiny kernel was that it could be fully debugged. The kernel didn't change much from year to year back in QNX 6.
Many embedded systems put the kernel in a boot ROM, so the system came up initially in QNX, without running some boot loader first. You built a boot image with the kernel, the essential "proc" process, and whatever user space drivers you absolutely had to have to get started.
QNX went open source for a while, starting September 2007, and there had been a free version for years. After the RIM acquisition, they went closed source overnight and took all the sources offline before people could copy them. That was the moment when they totally lost the support of the open source community.
> 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 :)
I really wish that UDF would get official blessing for use beyond optical media.
Yes you can kinda hack it into usage, but programs like gparted will not allow me to make a UDF partition last i checked (Windows sorta can, under the live drive moniker, iirc).
> 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.
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]
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.
Did you read the article? His entire premise is now that consumers have finished with the desktop, we can get them back to being workstations again, unencumbered by the requirements of consumers.
Talking about how iOS is great for consumers but doesn't have a good keyboard is a bit tone deaf.
My bad. Sorry I Skim Read it, Headlines and Tl;dr. May be he should name it as Workstation OS, although I guess all "Desktop" are pretty much Workstation these days.
But if Non-Consumer, Workstation OS is what we want, then I value backward compatibility over everything else. Which means everything he wanted to remove are here to stay.
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.
Quite true. I'm genuinely surprised how much progress Apple has made with iOS 11. The fact that they are giving users a file management app means they are finally ready to handle real work. With a really good Bluetooth keyboard....
Wut? MailDrop is what you're talking about and it's optional on top of only kicking in with attachments over 25mb IIRC.
Maybe you prefer whalemail, yousendit, or one of the other sign-up-free and get-ads-forever services for large attachments, and that's fine, they're not going away.
Neither is DropBox, for the time being. I'm both worried and excited about DropBox's new offerings and I'm all for it as long as they don't become Evernote and start selling backpacks and rebranded Fujitsu scanners. :(
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?
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.
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.
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?
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...
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).
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.
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.
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.
(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.)
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.
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.
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!
That's actually a really good point. However, I read that point more as having the new tab in the other application, as opposed to having a different app on each tab.
>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.
It just seems like what the author describes could be easily implemented as a Compiz plugin. I mean, when it first came out, people went crazy with all sorts of plugins that were more fun than useful, but nicely showed off what the system was capable of.
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.
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).
> I love it, especially using structured data instead of text for the CLI and pipes
Actually, that's a main selling point for Powershell. Commandlets take and return objects, which means common operations such as filtering, sorting and formatting are quite easy.
351 comments
[ 4.1 ms ] story [ 137 ms ] thread[1]: https://fuchsia.googlesource.com/ledger/
[2]: https://fuchsia.googlesource.com/escher/
[3]: https://arstechnica.com/gadgets/2017/05/googles-fuchsia-smar...
[4]: https://fuchsia.googlesource.com/sysui/#important-armadillo-...
[5]: https://fuchsia.googlesource.com/mondrian/
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.
http://www.kouti.com/tables/userattributes.htm
Ignoring the reasons why I don't trust Google, being able to trust your tools, especially your desktop, is the most important thing for me. I would love to have my emails delivered to a global document store so many smaller apps could take advantage of them, but only so long as I could guarantee there is no special 'google play services' app needing to run in the background doing who-knows-what with root.
I do think it’s important that we create open hardware and open software. I’m realizing Richard Stallman was right all along.
I took my hat out of the desktop race a long long time ago. the only thing that has really affected me recently was Mate switching entirely to GTK3. my text editor now does all sorts of things the maintainer of the editor can't change, like smooth-scrolling when using the find dialog.
I really want to get behind this effort for an improved desktop, even if it means breaking everything. but I have to be able to trust each of the components.
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.
So good HTML 5.0 support is key, but there are a lot of layers between that and bare metal.
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.
If UWP had been there in Windows 8, with something like .NET Standard already in place, the app story would be much different.
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.
Their complaint on the filesystem, for example, falls flat for me, but partially because I think I don't understand what they want or how BeOS did it. Maybe the author has a special meaning for "...sort by tags and metadata", but this looks to be baked right into Finder at the moment; I can add in a bunch of columns to sort by, tag my items with custom tags (and search said tags), add comments, and so on. Spotlight also has rendered a lot of organization moot as you just punch in a few bits of something about what you're looking for (tags, text within the document, document name, file type, date modified by, etc.) and you'll find it. I don't know exactly what is missing from modern OSes (Windows search isn't too bad either) that the author isn't contented with.
The idea of multiple forms of interaction with the computer are okay, but quite frankly it starts to get into an eerie situation for me where I'd rather have to take a lot of steps to set up such monitoring as opposed to it being baked into the OS. I realize that I'm squarely in luddite territory given the popularity of Home Assistants (Echo, Apple Homekit, Google Home), but to me these seem like very intentional choices on the part of a customer; you have to go out of your way to get the hardware for it and disabling it is as simple as pulling the plug. Look at the non-sense we're having to deal with in regards to Windows Telemetry - to me this is what happens when such items get baked into the OS instead of being an additional application; you end up with a function you no longer can control, and for no other reason than to satisfy the complaint of "I have to download something? No thank you!"
I could go on, but the author's rant just doesn't seem consistent and instead seems to just want some small features that they liked from older OSes to be returned to modern OSes. There is a huge issue with bloat and cruft and some real legacy stuff in Windows and macOS, and desktop OSes aren't getting the attention they should be, but these suggestions aren't what desktop OSes are missing or what they need.
OS X too a lot of getting used to for me as a kid, as I had an old mac clone and an iMac with 10.1 side by side in my living room, and I loved my little mac clone. OS X didn't immediately win me over because I was just too used to OS 9 and had everything I needed on my offline mac clone. But I distinctly remember Spotlight being what really sold me on OS X because from the get-go it worked basically as intended, and man was it magnificent. If the author of Spotlight is on APFS, I have a lot of faith in it then.
[1] https://arstechnica.com/information-technology/2010/06/the-b...
AFAIK, this approach is contrary to the BeOS approach, where application write the metadata directly. Spotlight's approach do have few benefits, though, such as able to provide metadata for files in network drives, or for removable disks that might not be using filesystem that supports metadata.
This one in particular:
>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?
I mean, you can. It's called the taskbar.
I don't think we'll see a change from Linux and Windows (edit: and IOS) until there's another compelling reason to switch; some feature that can't or won't be available in the other two operating systems and their surrounding ecosystems of software.
When was the last time we really had a "Visicalc sold more Apples than Apples sold Visicalc" moment? I can't think of one after Linux wafflestomped all the propietary hardware and os unix vendors, or to give Apple their due, when they released the iPhone.
Edit: duh, of course cloud taking over for bespoke hardware and software defined storage pushing out EMC and the like are two recent examples of industry game changers, but on the other hand both still rely primarily on Linux so my assertion about operating systems still stands.
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.
Maybe. The fact that Moore's Law finally broke may paradoxically help that.
When you can simply get 2x the (cost, performance, features) simply by doing nothing, there is no incentive to optimize anything.
Now that you can't simply "do nothing", people will start looking at alternatives.
And it's definitely possible, just look at the C64 and Amiga demoscene. Those machines haven't evolved for ages, but they've been making them do one (thought to be) "impossible" thing after another for a very long time after the platforms were essentially considered dead. I've seen things at demoparties around 2000 where C64 demos showed stuff that was thought to be impossible to do on these machines (or so I was told, I'm not an expert on the C64's capabilities, but the thing runs in the single megahertzes and doesn't have a divide instruction, so yeah). One I remember had a part with a veeery low resolution realtime raytracer, about 10fps I think, the scene consisting of just a plane and a sphere (IIRC) ... but it was done on a C64.
I wonder how long it will take for PCs though. Moore's Law broke already a few years ago didn't it? But it's not really happening, so far. Or maybe it is. I haven't been keeping up with what's happening in the PC demoscene lately. They used to be way ahead of the curve compared to PC videogames, this changed somewhere in the 200Xs, probably because around that time videogames started getting Hollywood-size budgets.
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.
But exhibit A: SAP.
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 .
My first thought was actually "what about data formats?" These days, most data formats are at least nominally open, but you still need to write code to work with those formats, and most of the existing code is still in C or C++ libraries. The IdealOS will fail instantly as soon as a user receives a DOCX or XLSX file and it displays the document wrong. It can't just launch LibreOffice and use that. Even LibreOffice can't always parse random MS Office documents correctly, and LO represents decades of coder-years.
I mean, you could also probably come up with some solution to have a guest over who brings their pet cow without doing too much damage to your nicely decorated apartment. Doesn't mean that's an ideal situation, and it most definitely is no reason to not dream about living somewhere nicer than a stable, and what that would look like to you.
The latter part, about dreaming how NICE your house could look like if you did not have to accommodate guests with cows barging into your living room all the time. That is what the article is actually about, he's pretty clear about his awareness that technical possibility is very different from the availability of a realistic road to transition from where we are now to the possibilities he sketches.
It's also a very important matter of combating learned helplessness. If you dismiss dreaming about an IdealOS beforehand because there's no way (that you can see now) to get there from where desktop OS's are today, then you most assuredly will miss the opportunity to attain even some of these improvements, were they to come within reach through some circumstance in the future.
Also, I remember programming on a 386. And on the one hand it amazes me that the thing in my pocket today is so much more powerful than that old machine, let alone my current desktop. And on the other hand, it infuriates me that some tasks on my desktop today are quite slow when really they have no right to be, and some of these tasks are even things that my 386 used to have no problems with whatsoever (but then, TPX was a ridiculously fast compiler, a true gem).
We should not let that slip out of sight, demand better and keep dreaming.
Well, they wouldn't need to any more. They can adopt drivers from Linux or any other free operating systems. The inner work of a driver might be arcane, the interface to an operating system is generally well defined. Adopting a existing driver is definitely doable.
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.
Personally, I do find the idea of an operating system composed of services and applications that all share the same messaging statement compelling.
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.
Heck, you could probably run stuff from the 3.x era, if you installed Win10 as a 32-bit OS.
This is related to how x86 CPUs do 64-bit btw, not the OS itself.
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)
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.
The network settings menu in the status bar is much better. I can turn wifi on and off easily.
I like the new notification panel, and setting reminders in Cortana.
The new Mail app is great. The Money app is great. The News app is great. The Calendar app is great. The Weather app is great. Very simple to use.
You can set dark color schemes nearly system-wide.
The lock screen is cool.
Edge doesn't suck.
Virtual desktops have been part of Windows since at least Windows XP. The necessary architecture was already in place, Microsoft just didn't include a virtual desktop manager. There were/are several available.
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.
Seems rubbish to me.
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.
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-...
Neither is keeping everything as it is and keep pretending it's fine!
> When you throw away code and start from scratch, you are throwing away all that knowledge.
I disagree with Joel on here. There's lots to be learned from throwing everything away and starting from scratch, and if anything those innovations could make their way into the current infrastructure, as it has happened with Midori and Windows.
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.
Key word here is "Sometimes".
Reviewing code means you get to find out the reason these hacks were written in the first place, and then decide wheter to keep, rework or delete them.
Starting from scratch means you get rid of the worthless crap, yes, but you also lose all the valuable crap.
So, they weren't starting over. They forked, refactored and removed things no longer needed. Completely different thing.
It's three years later. What general-purpose OS other than OpenBSD is using LibreSSL?
https://developer.apple.com/library/content/documentation/Se...
https://opensource.apple.com//source/CommonCrypto/CommonCryp...
Related: "legacy code is code that doesn't have tests" not sure who said this but also very true IMO
Michael Feathers in "Working with legacy code" (A book I can highly recommend)
The author of the article recognizes there's a problem, but is less clear on how to go about solving it. A clue is in this article by Erik Naggum: http://naggum.no/erik/complexity.html
Dan Ingalls once wrote: "Operating System: An operating system is a collection of things that don't fit into a language. There shouldn't be one." What he meant is we should migrate the functionality of the operating system into the programming language. This is possible if there's a REPL or something similar, so no need for the shell or command line. The language should be image-based, so no need for a file system. So, a bit like Squeak, or a Lisp with a structure editor.
There's still a gap between the processor and the language, which should be eliminated by making the processor run the language directly. This was done in Burroughs mainframes and Lisp machines.
Further up the "stack", software such as word processors and web browsers are at present written entirely separately but have much in common and could share much of their code.
I like the idea of an image based system, eliminating the need for the filesystem itself. I think the 'filesystem' and 'executable-process' ideas are so prevalent that they frame our thinking, and any new OSes tend to adopt these right away. But more interesting and powerful systems might emerge if we find a new pattern of operation and composition. Are you aware of any image based full stack systems that are in active development?
In the other words, the point is that you always have to do the cost-benefit analysis for any such endeavor and the history tells that rewriting is intrinsically very expensive.
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...
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.
https://msdn.microsoft.com/en-us/library/windows/desktop/ff4...
> https://joshondesign.com//images2/lift-window.png
Is this a sarcasm? Because it is complete garbage.
In fact, do you know what the keybinding is to roll up windows in KDE or XFCE is? I could use that.
I use Windows, where there is this utility which lets you adjust the transparency of windows from the keyboard: http://www.vanmiddlesworth.org/vitrite/
Thus you can see the contents of both the upper and lower windows at once, and not just briefly. Very useful on a laptop with limited screen space. I know adjustable window transparency is definitely possible on Linux too.
On the other hand, this looks like it's just effects for the sake of effects.
That said, i wonder if this is why some people love using "focus follows mouse" or whatever it is called. Just drag the mouse pointer to the window you want to peek at, then back to the main window once done. No need to look for safe place to click or use keyboard commands (though i guess something similar could be achieved with a WM that brings each window to front as you alt-tab around).
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.
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
+100. This is something I have advised to any designer that would listen. You must have at least a basic understanding of the technology in order to understand the set of affordances with which you use to design your flows.
"Oh, but why should we allocate resources to something the majority of users won't use?" - everyone on HN
No need to get rilled up, just take the good and ignore the rest :)
Finally one things that I precisely dislike with VS Code is that this whole discoverability ease was throw out of the windows and almost any complex task can't be completed without looking in the documentation.
Ctrl + Shift + P (on Windows, might differ depending on OS) brings up command palette or whatever it is called.
Start typing.
When it has narrowed down to the command you need, make a mental note of the shortcut next to it, then hit esc and use it.
The key to efficient IPC is that the scheduler and the interprocess communications system have to be tightly coupled. Otherwise you have requests going to the end of the line for CPU time on each call, too many trips through the scheduler, and work switching from one CPU to another and causing heavy cache misses. QNX got this right.
(Then they were bought by a car audio company, Harmon, and it was all downhill from there.)
QNX messaging isn't a "bus" system, and it has terrible discovery. Once communications are set up, it's great, but finding an endpoint to call is not well supported. The designers of QNX were thinking in terms of dedicated high-reliability real-time systems. It needs some kind of endpoint directory service. That doesn't need to be in the kernel, of course.
QNX is a microkernel, with about 60KB (not MB) of code in the kernel, and it offers a full POSIX interface. (There used to be a whole desktop GUI for it, Photon, good enough to run early versions of Firefox, but Blackberry blew off the real-time market and dropped that.) File systems, networking, and drivers are all in user processes, and optional. L4 is more minimal, probably too minimal - people usually run Linux on top of it, which doesn't result in a simpler system.
I still have a soft spot for QNX though; I hope they'll survive RIM.
60KB was just the kernel, not the additional processes that run in user space. The great thing about such a tiny kernel was that it could be fully debugged. The kernel didn't change much from year to year back in QNX 6.
Many embedded systems put the kernel in a boot ROM, so the system came up initially in QNX, without running some boot loader first. You built a boot image with the kernel, the essential "proc" process, and whatever user space drivers you absolutely had to have to get started.
QNX went open source for a while, starting September 2007, and there had been a free version for years. After the RIM acquisition, they went closed source overnight and took all the sources offline before people could copy them. That was the moment when they totally lost the support of the open source community.
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 :)
Yes you can kinda hack it into usage, but programs like gparted will not allow me to make a UDF partition last i checked (Windows sorta can, under the live drive moniker, iirc).
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
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
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.
Talking about how iOS is great for consumers but doesn't have a good keyboard is a bit tone deaf.
But if Non-Consumer, Workstation OS is what we want, then I value backward compatibility over everything else. Which means everything he wanted to remove are here to stay.
Quite true. I'm genuinely surprised how much progress Apple has made with iOS 11. The fact that they are giving users a file management app means they are finally ready to handle real work. With a really good Bluetooth keyboard....
Maybe you prefer whalemail, yousendit, or one of the other sign-up-free and get-ads-forever services for large attachments, and that's fine, they're not going away.
Neither is DropBox, for the time being. I'm both worried and excited about DropBox's new offerings and I'm all for it as long as they don't become Evernote and start selling backpacks and rebranded Fujitsu scanners. :(
> 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?
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.
Overall I agree with you.
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.
> 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
> 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...
See Fluxbox for an example. http://fluxbox.sourceforge.net/features/tabs.php
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.
I'm happy to answer your questions.
(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.)
>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....
http://fluxbox.sourceforge.net/features/tabs.php
I used to use Fluxbox, but I didn't know it was already capable of that. Pretty cool!
>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.
Sounds like the Compiz Resize plugin, with the "stretch" option enabled: http://wiki.compiz.org/Plugins/Resize
Or maybe the Enhanced Zoom Desktop plugin: http://wiki.compiz.org/Plugins/Ezoom
It just seems like what the author describes could be easily implemented as a Compiz plugin. I mean, when it first came out, people went crazy with all sorts of plugins that were more fun than useful, but nicely showed off what the system was capable of.
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.
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).
https://en.wikipedia.org/wiki/Transactional_NTFS
Actually, that's a main selling point for Powershell. Commandlets take and return objects, which means common operations such as filtering, sorting and formatting are quite easy.