Live data from Hacker News

Mercury OS

mercuryos.com

141–150 of 165 posts

Re: Mercury OS

#141
This is fascinating. I've long thought we needed some ground-up thinking in this area.

But I now wonder if it's also why stripped-out UIs like GNOME are favoured by so many folks in (e.g.) the Linux space... which is famously full of neurodivergent people.

15min to pick a filename?! Really?

But I've seen SO MANY desktops like the pics in that blog.

This made me think in different directions. I already knew some users find current models very hard... But that they were this trying for them is news to me.

Maybe that's why some folk like working on iPads instead of laptops?

What is horribly frustrating & limiting to me, might be their exhilarating liberation from the endless suffering of window, and file and directory, management?

Could this be why so many aspie/ADHD-spectrum techies actually like GNOME or tiling window managers & lots of xterms?

My favourite non-pointer-driven GUI has for >~30 years been EPOC16 from the Psion 3 series. That could have lessons to teach here. No desktop, and the launcher is also a categorised columnar file manager with automatic grouping. It was an inspired design.

Screenshot gallery, but it doesn't give a good flavour of it.

https://guidebookgallery.org/screenshots/sibo3a

Re: Mercury OS

#142

> Mercury rejects the Desktop Metaphor and App Ecosystems as fundamentally inhumane. Inhumane is a strange word choice, to say the least. It’s neat to think about the possibilities of future UX, but to suggest the current system is cruel just sounds ridiculous.

It is a direct reference to Jef Raskin's work, which he called the Humane Interface.

https://en.wikipedia.org/wiki/The_Humane_Interface

He is namechecked right there in the story as a pointer. You're on the WWW. If you don't recognise the name, the idea is that you Google it and find out. That's how this stuff works. It's not 1993; you don't need to try to guess what they meant...

Re: Mercury OS

#143

Earlier quoted context omitted.

You've shared quite a number of misconceptions there (not least of all your definition of "failed" -- Linux is used by millions of consumers every day so if that's a "failure" then you have some rather unrealistic expectations of what is considered a success. But ultimately "Linux" isn't an OS anyways so it isn't really fair comparing it as one). > That thinking is why What kind of thinking? Acknowledging that writin…

It definitely failed. Having lived through 20+ “the year of the Linux desktop”s I can tell you the goal was clearly to become he dominant desktopOS that everyone used. About that last part… the op was talking about people, it actual hardware, you seem to have missed that. Hardware is in fact predictable, unless it’s failing or just that poorly designed.

> Having lived through 20+ “the year of the Linux desktop”s I can tell you the goal was clearly to become he dominant desktop so that everyone use

Again, Linux isn't an operating system like Windows, macOS or even FreeBSD. Even the broader definition of Linux has it as multiple different collections of different individuals sharing different groups of packages. What one team might aim to do with Linux is very different to what another team might want to do. And "The year of the Linux desktop" wasn't a universal goal by any means. Case in point: I've been using Linux (as well as several flavors of BSD, Macs, Windows and a bunch of other niche platforms that aren't household names) for decades now and I've never once believed Linux should be the dominant desktop. I'm more than happy for it to be 3rd place to Windows and macOS just so long as it retains the flexibility that draws me to use Linux. For me, the appeal of Linux is freedom of choice -- which is the polar opposite of the ideals that a platform would need hold if it were aiming for dominance.

So saying "Linux failed" isn't really a fair comment. A more accurate comment might be that Canonical failed to overtake Windows but you still need to be careful about the term "failed" given that millions of regular users would be viewed as successful by most peoples standards -- even if it didn't succeed at some impossible ideology of a desktop monopoly.

> About that last part… the op was talking about people, it actual hardware, you seem to have missed that.

No i got that. It's you who missed the following part:

> Hardware is in fact predictable, unless it’s failing or just that poorly designed.

Don't underestimate just how much hardware out there is buggy, doesn't follow specifications correctly, old and failing, or just isn't used correctly by users correctly (eg people yanking USB storage devices without safely unmounting them first). The reality is that hardware can be very unpredictable yet operating systems still need to handle that gracefully.

The market is flooded with mechanical HDDs from reputable manufacturers which don't follow specifications correctly because those devices can fake higher throughput by sending successful write messages back to the OS even when the drives are still caching those writes. Or cheap flash storage that fails often. And hot pluggable devices in the form of USB and Thunderbolt have only exasperated the problem because now you have devices that can be connected and disconnected without any warning.

Then you have problems that power saving introduces. You now have an OS with hardware that shouldn't be connected and disconnected yet still able to power that on and off gracefully (otherwise your OS is borderline useless on any laptop).

...and all of this is without even considering external conditions (ie the physical nature of hardware -- the reason it's called "hardware"). From mechanical failures, hardware getting old, dusty, dropped etc. Through to unlikely but still real world problems like "cosmic bit-flips".

Now imagine trying to implement all of this via reverse engineering - because device manufacturers are only going to support Windows, maybe macOS and, if you're lucky, Linux. And imagine trying to implement that for hundreds of different hardware types, getting each one stable. Even just testing across that range of hardware is a difficult enough problem on its own.

There's a reason BeOS-clone Haiku support FreeBSD network drivers, SkyOS's user land was eventually ported to Linux, and Linux (for a time at least) supported Windows WiFi drivers. It isn't because developers are lazy -- it's because this is a fscking hard problem to solve. And lets be clear, using another OS's driver model isn't an easy thing to implement itself.

Frankly put: fact that you think hardware is easy and predictable is proof of the success of Linux (and NT, Darwin, BSD, etc).

Re: Mercury OS

#144
post #95

Earlier quoted context omitted.

I have the opposite problem. If I open too many Windows, the Windows window manager starts glitching out. When I open an app, it doesn't always come to the front and I have to go alt-tab through dozens of windows to find it. (Sometimes it ends up at the bottom, so alt-shift-tab switches to it... but sometimes it ends up in the middle ...) Also if I open too many windows, opening Windows explorer takes 1-2 or more sec…

Why are you still relying on alt+tab in 2023? I haven't touched a windows for more than 5 minutes in a long time, aren't there a function to show all windows like in most Linux DE and Mac OS ?

Real question is why I'm still using Windows ;)

I just looked it up, there's a thing called Task View (Win+Tab) which is this big scrolling view of open window thumbnails.

Curiously, Alt+Tab itself is very slow (half a second of lag?) but if I kill explorer.exe I get a different Alt+Tab screen which is extremely responsive.

(And Win+Tab is, of course, much slower than even the slow Alt+Tab...)

I wish I could just leave explore.exe killed, but it makes it a bit harder to do things. Maybe I should do that, to force me to program my own alternatives in Python. (They'd still be faster than what Microsoft made...)

Re: Mercury OS

#145
post #53

Earlier quoted context omitted.

Yeah, this whole thread is why Hacker News has the "orangesite" reputation it does. I wouldn't have shared anything like this on here, and that is a criticism of HN, not projects like Mercury OS. I thought this was an interesting project. The site is well-designed. The UI is attractive. As a designer, I really enjoy reading about these things. The fact that this isn't something you'd build your personally customized…

Why wouldnt you build this on Linux?

No, I said the OS didn't look like something you'd use for heavy-duty development work.

I was being a little sarcastic, but I was just amazed at all the people who spent ten seconds looking at this and said "this is useless, it clearly wouldn't be very good for all the extremely complicated powerful things I want to do. Can it handle fifteen different terminal windows? Fail!!1"

Re: Mercury OS

#146

Earlier quoted context omitted.

It definitely failed. Having lived through 20+ “the year of the Linux desktop”s I can tell you the goal was clearly to become he dominant desktopOS that everyone used. About that last part… the op was talking about people, it actual hardware, you seem to have missed that. Hardware is in fact predictable, unless it’s failing or just that poorly designed.

> Having lived through 20+ “the year of the Linux desktop”s I can tell you the goal was clearly to become he dominant desktop so that everyone use Again, Linux isn't an operating system like Windows, macOS or even FreeBSD. Even the broader definition of Linux has it as multiple different collections of different individuals sharing different groups of packages. What one team might aim to do with Linux is very differe…

Today I learned that humans are predictable and consistent, but hardware is not....

Re: Mercury OS

#147

Earlier quoted context omitted.

I don't know why you people are so touched about somebody's attempt at redesigning an OS. Here's the thing: You are not the target audience of this OS and you are by no means required to use it. In my opinion, this is a solid attempt at creating an operating system for non-techies. Way fewer concepts to learn, way easier interaction.

They’re not redesigning an OS. They are describing a theoretical UI. This is about as close to designing an operating system as drawing a front cover is to writing a book.

This is yet another thing that non-techies sincerely don't care about. For them, it is the OS.

Now you can walk around telling every grandma that they should not refer to it as OS, but you will unlikely succeed in that mission. Accept it...

Re: Mercury OS

#148
post #52

Earlier quoted context omitted.

+1 to this, it's crazy to lose all (or most) contexts across a reboot or when switching between machines. Each app has some sync capabilities (e.g. PowerPoint, web browsers, Google docs, chrome tabs, Firefox tabs), but there is still no universal solution. Fuck.

MacOS is actually pretty good about this. It restores applications on restart, and it’s provided applications pick up where they left off. I don’t use the workspace feature on the Mac, I assume they’re recovered as well. Obviously applications need to be restart aware as well. I really like how the provided Mac apps (Pages, Numbers, etc. ) work with the first class document model in the system. I have dozens of Untit…

Unfortunately not. After reboots, which are annoyingly often, MacOS places all my carefully organized windows and their layout into a messy pile on the first/primary space and I have to spend a significant amount of time to get everything back to the state I want. This is also a huge pain in the ass when moving between external and internal monitor, where my windows and their size ends up not how I want them every single time.

Re: Mercury OS

#149

Just for context: this is a 4 yo design study by friend and amazing product designer Jason Yuan, who also worked on Sprout.place and more recently some stuff at Apple (@jasonyuandesign). A lot of the comments currently seem to miss this and are focusing on immediate feasibility, “successful” design, or ability to deploy irl. That is not the point here. Things like this are both creative exposition, as well as corner…

That's all non obvious. As far as I can tell this was just as serious as any of the other, 'this is the future', post. See the recent humane keynote for example, and the vergecast's reaction to it. That said, it's absolutely valid to question stuff like this. A lot of design student type stuff miss HUGE usability issues.

Can you really identify usability issues on something that is both a) just a concept and b) is meant to shift the work paradigm substantially?

Local optimization for your existing workflow is not the intended goal of this exploratory project.

Re: Mercury OS

#150

Earlier quoted context omitted.

> Having lived through 20+ “the year of the Linux desktop”s I can tell you the goal was clearly to become he dominant desktop so that everyone use Again, Linux isn't an operating system like Windows, macOS or even FreeBSD. Even the broader definition of Linux has it as multiple different collections of different individuals sharing different groups of packages. What one team might aim to do with Linux is very differe…

Today I learned that humans are predictable and consistent, but hardware is not....

I wasn't making any comment about the predictability of humans. However there have been plenty of studies that have proven humans are indeed predictable. If we weren't then dark UI patterns for email sign ups, cookie consent pop ups, and so on wouldn't work. The reason UI can be tuned for "evil" is precisely because of our predictability. But this is a psychological point and thus tangential from the discussion :)

To come back on topic. I wasn't saying hardware is unpredictable per se -- just that it often behaves unpredictably. And I say that because there are a set of expectations which, in reality, hardware doesn't always follow.

However the predictability of humans vs hardware is a somewhat moot point because that's only part of the story for why writing hardware-interfacing code is harder than human interfaces. I did discuss cover a few of those other reasons too but you seem fixated on the predictability of the interfaces.

Post reply on HN